6 Protocol Specification and Implementation
29.3373GPPDiameter-based T4 Interface for communications with packet data networks and applicationsRelease 17TS
6.1 General
6.1.1 Use of Diameter Base Protocol
The Diameter base protocol as specified in IETF RFC 6733 [19] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and error codes as specified in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified.
6.1.2 Securing Diameter Messages
For secure transport of Diameter messages, see 3GPP TS 33.210 [4]
6.1.3 Accounting Functionality
Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the T4 interface.
6.1.4 Use of Sessions
Between the MTC-IWF and the SMS-SC, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server.
The Diameter base protocol specified in IETF RFC 6733 [19] includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions.
The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 [19]. As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses.
6.1.5 Transport Protocol
Diameter messages over the T4 interface shall make use of SCTP, see IETF RFC 4960 [5].
6.1.6 Routing Considerations
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.
The T4 reference point is defined as an intra-operator interface, and both MTC-IWF and the SMS-SC are located in the same network domain. If the MTC-IWF knows the address/name of the SMS-SC for a certain user, both the Destination-Realm and Destination-Host AVPs shall be present in the request. Otherwise, the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by the MTC-IWF.
The SMS-SC obtains the Destination-Host AVP to use in requests towards the MTC-IWF, from the Origin-Host AVP received in previous requests from the MTC-IWF. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the SMS-SC.
If the Vendor-Specific-Application-ID AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node, and it shall not be used for routing purposes.
6.1.7 Advertising Application Support
The MTC-IWF and SMS-SC shall advertise support of the Diameter T4 Application by including the value of the application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETF RFC 6733 [19].
6.1.8 Diameter Application Identifier
The T4 interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415.
The Diameter application identifier assigned to the T4 interface application is 16777311 (allocated by IANA).
6.1.9 Use of the Supported-Features AVP
When new functionality is introduced on the T4 interface, it should be defined as optional. If backwards incompatible changes cannot be avoided, the new functionality shall be introduced as a new feature and support advertised with the Supported-Features AVP. The usage of the Supported-Features AVP on the T4 interface is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [6].
When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.
As defined in 3GPP TS 29.229 [6], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specification, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another.
The Table 6.3.5 defines the features applicable to the T4 reference point for the feature list with a Feature-List-ID of 1.
6.2 Commands
6.2.1 Introduction
This section defines the Command code values and related ABNF for each command described in this specification.
6.2.2 Command-Code Values
This section defines Command-Code values for the T4 interface application as allocated by IANA.
Every command is defined by means of the ABNF syntax IETF RFC 5234 [10], according to the Command Code Format (CCF) specification defined in IETF RFC 6733 [19]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 6733 [19] shall apply.
The Vendor-Specific-Application-Id AVP shall not be included in any command sent by Diameter nodes supporting applications defined in this specification. If the Vendor-Specific-Application-Id AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node.
NOTE: The Vendor-Specific-Application-Id is included as an optional AVP in all Command Code Format specifications defined in this specification in order to overcome potential interoperability issues with intermediate Diameter agents non-compliant with the IETF RFC 6733 [19].
The following Command Codes are defined in this specification:
Table 7.2.2/1: Command-Code values for T4
|
Command-Name |
Abbreviation |
Code |
Section |
|
Device-Trigger-Request |
DTR |
8388643 |
6.2.3 |
|
Device-Trigger- Answer |
DTA |
8388643 |
6.2.4 |
|
Delivery-Report-Request |
DRR |
8388644 |
6.2.5 |
|
Delivery-Report-Answer |
DRA |
8388644 |
6.2.6 |
For these commands, the Application-ID field shall be set to 16777311 (application identifier of the T4 interface application, allocated by IANA).
6.2.3 Device-Trigger-Request (DTR) Command
The Device-Trigger-Request (DTR) command, indicated by the Command-Code field set to 8388643 and the "R" bit set in the Command Flags field, is sent from the MTC-IWF to the SMS-SC.
Message Format
< Device-Trigger-Request > ::= < Diameter Header: 8388643, REQ, PXY, 16777311 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Identifier }
{ SM-RP-SMEA }
{ Payload }
[ Serving-Node ]
*[ Additional-Serving-Node ]
[ Reference-Number ]
[ Validity-Time ]
[ Priority-Indication ]
[ SMS-Application-Port-ID ]
[ Old-Rference-Number ]
[ Trigger-Action ]
*[ Supported-Features ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.4 Device-Trigger-Answer (DTA) Command
The Device-Trigger-Answer (DTA) command, indicated by the Command-Code field set to 8388643 and the "R" bit cleared in the Command Flags field, is sent from the SMS-SC to the MTC-IWF.
Message Format
< Device-Trigger-Answer > ::= < Diameter Header: 8388643, PXY, 16777311 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
[ MTC-Error-Diagnostic ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Old-Reference-Number ]
[ Trigger-Action ]
*[ Supported-Features ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.5 Delivery-Report-Request (DRR) Command
The Delivery-Report-Request (DRR) command, indicated by the Command-Code field set to 8388644 and the "R" bit set in the Command Flags field, is sent from the SMS-SC to the MTC-IWF.
Message Format
< Delivery-Report-Request > ::= < Diameter Header: 8388644, REQ, PXY, 16777311 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Identifier }
{ SM-RP-SMEA }
{ SM-Delivery-Outcome-T4 }
[ Absent-Subscriber-Diagnostic-T4 ]
[ Reference-Number ]
*[ Supported-Features ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.2.6 Delivery-Report-Answer (DRA) Command
The Delivery-Report-Answer (DRA) command, indicated by the Command-Code field set to 8388644 and the "R" bit cleared in the Command Flags field, is sent from the MTC-IWF to the SMS-SC.
Message Format
< Delivery-Report-Answer > ::= < Diameter Header: 8388644, PXY, 16777311 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.3 AVPs
The following table specifies the Diameter AVPs defined for the T4 interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415).
Table 6.3.1/1: T4 specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Section defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
SM-Delivery-Outcome-T4 |
3200 |
6.3.1 |
Enumerated |
M, V |
No |
|||
|
Absent-Subscriber-Diagnostic-T4 |
3201 |
6.3.2 |
Enumerated |
M, V |
No |
|||
|
Trigger-Action |
3202 |
6.3.6 |
Unsigned32 |
V |
M |
No |
||
|
MTC-Error-Diagnostic |
3203 |
6.3.7 |
Unsigned32 |
V |
M |
No |
||
|
NOTE 1: The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [19]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. |
||||||||
The following table specifies the Diameter AVPs re-used by the T4 interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within T4.
Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol specified in IETF RFC 6733 [19], do not need to be supported. The AVPs from Diameter base protocol specified in IETF RFC 6733 [19] are not included in table 6.3.1/2, but they may be re-used for the T4 protocol.
Table 6.3.1/2: T4 re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
M-bit |
|---|---|---|---|
|
User-Identifier |
3GPP TS 29.336 [12] |
||
|
SM-RP-SMEA |
3GPP TS 29.338 [13] |
||
|
Payload |
3GPP TS 29.368 [15] |
||
|
Serving-Node |
3GPP TS 29.173 [14] |
See 6.3.3 |
|
|
Additional-Serving-Node |
3GPP TS 29.173 [14] |
See 6.3.4 |
|
|
Reference-Number |
3GPP TS 29.368 [15] |
||
|
Old-Reference-Number |
3GPP TS 29.368 [15] |
||
|
Validity-Time |
IETF RFC 4006 [17] |
||
|
Priority-Indication |
3GPP TS 29.368 [15] |
||
|
SMS-Application-Port-ID |
3GPP TS 29.368 [15] |
||
|
Supported-Features |
3GPP TS 29.229 [6] |
||
|
Feature-List-ID |
3GPP TS 29.229 [6] |
||
|
Feature-List |
3GPP TS 29.229 [6] |
||
|
IP-SM-GW-Name |
3GPP TS 29.336 [12] |
||
|
IP-SM-GW-Realm |
3GPP TS 29.336 [12] |
||
|
IP-SM-GW-Number |
3GPP TS 29.336 [12] |
||
|
MME-Number-for-MT-SMS |
3GPP TS 29.272 [16] |
||
|
DRMP |
IETF RFC 7944 [18] |
see clause 6.3.8 |
Must not set |
|
SMSF-3GPP-Number |
3GPP TS 29.338 [13] |
||
|
SMSF-Non-3GPP-Number |
3GPP TS 29.338 [13] |
||
|
SMSF-3GPP-Name |
3GPP TS 29.338 [13] |
||
|
SMSF-Non-3GPP-Name |
3GPP TS 29.338 [13] |
||
|
SMSF-3GPP-Realm |
3GPP TS 29.338 [13] |
||
|
SMSF-Non-3GPP-Realm |
3GPP TS 29.338 [13] |
||
|
NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. |
|||
6.3.1 SM-Delivery-Outcome-T4
The SM-Delivery-Outcome-T4 AVP is of type Enumerated and indicates the outcomes of the device trigger delivery. The following values are defined:
ABSENT_SUBSCRIBER (0)
This value is used when the device trigger delivery failed due to absent subscriber.
UE_MEMORY_CAPACITY_EXCEEDED (1)
This value is used when the device trigger delivery failed due to UE memory capacity exceeded.
SUCCESSFUL_TRANSFER (2)
This value is used when the device trigger delivery is successfully transferred to the UE.
VALIDITY_TIME_EXPIRED (3)
This value is used when the message was deleted in the SMS-SC due to expiration of the validity time.
6.3.2 Absent-Subscriber-Diagnostic-T4
The Absent-Subscriber-Diagnostic-T4 AVP is of type Enumerated and indicates the reason why the subscriber is absent if the device trigger failed to be delivered due to absent subscriber. The following values are defined:
NO_PAGING_RESPONSE (0)
This value is used when there is no paging response via some of the serving nodes.
UE_DETACHED (1)
This value is used when the UE is detached from all of the serving nodes.
UE_DEREGISTERED (2)
This value is used when the UE is deregistered in the network.
UE_PURGED (3)
This value is used when the UE is purged by some of the serving nodes.
ROAMING_RESTRICTION (4)
This value is used when the UE is roaming restricted.
UNIDENTIFIED_SUBSCRIBER (5)
This value is used when the user is unidentified in all of the serving nodes.
6.3.3 Serving-Node
The Serving-Node AVP is of type Grouped and it shall contain the name/number of the serving node to be used for T4-triggering. It is originally defined in 3GPP TS 29.173 [8].
Serving-Node ::= <AVP header: 2401 10415>
[ SMSF-3GPP-Name ]
[ SMSF-3GPP-Realm ]
[ SMSF-3GPP-Number ]
[ SMSF-Non-3GPP-Name ]
[ SMSF-Non-3GPP-Realm ]
[ SMSF-Non-3GPP-Number ]
[ SGSN-Name ]
[ SGSN-Realm ]
[ SGSN-Number ]
[ MME-Name ]
[ MME-Realm ]
[ MME-Number-for-MT-SMS ]
[ MSC-Number ]
[ IP-SM-GW-Number ]
[ IP-SM-GW-Name ]
[ IP-SM-GW-Realm ]
*[AVP]
The following combinations are allowed:
a) SGSN-Number
b) SGSN-Name & SGSN-Realm & SGSN-Number
c) MME-Name & MME-Realm & MME-Number-for-MT-SMS
d) MSC-Number
e) MSC-Number & MME-Name & MME-Realm
f) IP-SM-GW-Number
g) IP-SM-GW-Number & IP-SM-GW-Name & IP-SM-GW-Realm
h) SMSF-3GPP-Number
i) SMSF-3GPP-Name & SMSF-3GPP-Realm & SMSF-3GPP-Number
j) SMSF-Non-3GPP-Number
k) SMSF-Non-3GPP-Name & SMSF-Non-3GPP-Realm & SMSF-Non-3GPP-Number
6.3.4 Additional-Serving-Node
The Additional Serving-Node AVP is of type Grouped and when present it shall contain the name/number of an additional serving node to be used for T4-triggering. It is originally defined in 3GPP TS 29.173 [8],
Additional-Serving-Node ::= <AVP header: 2406 10415>
[ SMSF-3GPP-Name ]
[ SMSF-3GPP-Realm ]
[ SMSF-3GPP-Number ]
[ SMSF-Non-3GPP-Name ]
[ SMSF-Non-3GPP-Realm ]
[ SMSF-Non-3GPP-Number ]
[ SGSN-Name ]
[ SGSN-Realm ]
[ SGSN-Number ]
[ MME-Name ]
[ MME-Realm ]
[ MME-Number-for-MT-SMS ]
[ MSC-Number ]
*[AVP]
The following combinations are allowed:
a) SGSN-Number
b) SGSN-Name & SGSN-Realm & SGSN-Number
c) MME-Name & MME-Realm & MME-Number-for-MT-SMS
d) MSC-Number
e) MSC-Number & MME-Name & MME-Realm
f) SMSF-3GPP-Number
g) SMSF-3GPP-Name & SMSF-3GPP-Realm & SMSF-3GPP-Number
h) SMSF-Non-3GPP-Number
i) SMSF-Non-3GPP-Name & SMSF-Non-3GPP-Realm & SMSF-Non-3GPP-Number
6.3.5 Supported-Feature-List AVP for the T4 application
The syntax of this AVP is defined in 3GPP TS 29.229 [6].
For the T4 application, the meaning of the bits shall be as defined in table 6.3.5 for the Supported-Feature-List-ID of 1.
Table 6.3.5: Features of Feature-List-ID 1 used in T4
|
Feature bit |
Feature |
M/O |
Description |
|
0 |
Device-Trigger-Recall-Replace |
O |
This Feature indicates the support of the applicability to support the functionalty for device trigger recall and and device trigger replace. This Feature is applicable for the DTR/DTA command pair For recall if an MTC-IWF or SMS-SC does not indicate the support of the feature the MTC-IWF shall not send device trigger recall requests to an SMS-SC and send a negative reply to the SCS. For Replace if an MTC-IWF or SMS-SC does not indicate the support of the feature the MTC-IWF shall treat the device trigger replace as a new device trigger. |
|
Feature bit: The order number of the bit within the Supported-Features AVP, e.g. "1". Feature: A short name that can be used to refer to the bit and to the feature, e.g. " Device-Trigger-Recall-Replace ". M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O"). Description: A clear textual description of the feature. |
|||
6.3.6 Trigger-Action
The Trigger Action AVP is of type Unsigned32 and indicates the type of the device trigger. The following values are defined:
TRIGGER (0)
This value is used when device trigger requests the storage and sending of a new device trigger.
RECALL (1)
This value is used when device trigger requests the removal of a pending device trigger.
REPLACE (2)
This value is used when device trigger requests the replacement of a pending device trigger.
6.3.7 MTC-Error-Diagnostic
The MTC-Error-Diagnostic AVP is of type Unsigned32. The following values are defined:
– ORIGINAL_MESSAGE_NOT_DELETED (0)
This cause should be sent if the replace failed due to the fact that the old message is pending but could not be deleted in the SMS-SC.
– NEW_MESSAGE_NOT_STORED (1)
This cause should be sent if the replace failed due to the fact that the new message could not be stored in the SMS-SC e.g. no resource available.
6.3.8 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [18]. This AVP allows the SMS-SC and the MTC-IWF to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message.