7 Result-Code and Experimental-Result Values
29.3373GPPDiameter-based T4 Interface for communications with packet data networks and applicationsRelease 17TS
7.1 General
This section defines result code values that shall be supported by all Diameter implementations that conform to this specification.
7.2 Success
Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully completed. The Result-Code AVP values defined in the Diameter base protocol specified in IETF RFC 6733 [19] shall be applied.
7.3 Permanent Failures
Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and should not be attempted again. The Result-Code AVP values defined in Diameter base protocol specified in IETF RFC 6733 [19] shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent.
7.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001)
This result code shall be sent by the SMS-SC to indicate that the user identified by the IMSI or the MSISDN is unknown.
7.3.2 DIAMETER_ERROR_INVALID_SME_ADDRESS (5530)
This result code shall be sent by the SMS-SC to indicate that the SME address is invalid.
7.3.3 DIAMETER_ERROR_SC_CONGESTION (5531)
This result code shall be sent by the SMS-SC to indicate that SC is congested and unable to deliver the device trigger request.
7.3.4 Void
7.3.5 DIAMETER_ERROR_TRIGGER_REPLACE_FAILURE (5533)
This result code shall be sent by the SMS-SC to indicate that trigger replace has failed to delete the old message and/or to store the new message.
7.3.6 DIAMETER_ERROR_TRIGGER_RECALL_FAILURE (5534)
This result code shall be sent by the SMS-SC to indicate that trigger recall has failed.
7.3.7 DIAMETER_ERROR_ORIGINAL_MESSAGE_NOT_PENDING (5535)
This result code shall be sent by the SMS-SC to indicate that trigger recall or replace has failed because the original message to be recalled or replaced is not stored any more in the SMS-SC.
Annex A (normative):
Diameter message priority mechanism
A.1 General
IETF RFC 7944 [18] specifies a Diameter routing message priority mechanism that allows Diameter nodes to indicate the relative priority of Diameter messages. With this information, other Diameter nodes may leverage the relative priority of Diameter messages into routing, resource allocation, set the DSCP marking for transport of the associated Diameter message, and also abatement decisions when overload control is applied.
A.2 T4 interface
A.2.1 General
The Diameter message priority mechanism is an optional feature.
A.2.2 SMS-SC and MTC-IWF behaviour
When the SMS-SC or the MTC-IWF support the Diameter message priority mechanism over the T4 interface, the SMS-SC or the MTC-IWF shall comply with IETF RFC 7944 [18].
The SMS-SC or the MTC-IWF sending a request shall determine the required priority according to its policies. When priority is required, the SMS-SC or the MTC-IWF shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level.
When the SMS-SC or the MTC-IWF receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request.
When the SMS-SC or the MTC-IWF receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, the SMS-SC or the MTC-IWF may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, the SMS-SC or the MTC-IWF shall include the DRMP AVP in the response.
The SMS-SC and MTC-IWF decisions for a required priority and for the priority level value are implementation specific.
If:
– SMS-SC and the MTC-IWF supports using the Diameter message priority mechanism for DSCP marking purposes,
– the transport network utilizes DSCP marking, and
– message-dependant DSCP marking is possible for the protocol stack transporting Diameter,
then the SMS-SC and the MTC-IWF shall set the DSCP marking for transport of the request or response according to the required priority level.
Diameter requests related to high priority traffic shall contain a DRMP AVP with a high priority of which the level value is operator dependent.
If the SMS-SC supporting the Diameter message priority mechanism receives a request message containing both the Priority-Indication AVP and the DRMP AVP, the SMS-SC shall prioritize the request according to priority level received within the DRMP AVP.
Annex B (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2012-09 |
CT#57 |
CP-120486 |
TS prsented for information and approval |
11.0.0 |
|||
|
2012-12 |
CT#58 |
CP-120731 |
0001 |
2 |
T4 Device Triggering via IMS |
11.1.0 |
|
|
CP-120731 |
0002 |
1 |
MWD update |
||||
|
CP-120731 |
0003 |
1 |
Add Reference for the Information Elements |
||||
|
CP-120731 |
0004 |
3 |
Removal of Editor’s Notes |
||||
|
2013-03 |
CT#59 |
CP-130028 |
0005 |
– |
Application Port ID in T4 |
11.2.0 |
|
|
2013-06 |
CT#60 |
CP-130297 |
0006 |
– |
Delivery-Report-Request/Answer Description |
11.3.0 |
|
|
2013-06 |
CT#60 |
CP-130300 |
0007 |
1 |
T4 complements related to Diameter for SMS with SGSN |
12.0.0 |
|
|
2014-03 |
CT#63 |
CP-140180 |
0008 |
3 |
Protocol enhancements for the support of device recall and replace procedure |
12.1.0 |
|
|
2014-06 |
CT#64 |
CP-140251 |
0010 |
2 |
Handling of error scenarios on trigger replace |
12.2.0 |
|
|
CP-140251 |
0011 |
2 |
Error handling, MTC error diagnostic |
||||
|
2014-09 |
CT#65 |
CP-140508 |
0012 |
1 |
Reporting of Validity period of the trigger message expired in SMS-SC |
12.3.0 |
|
|
2014-12 |
CT#66 |
CP-140792 |
0014 |
1 |
Trigger action in device trigger request |
12.4.0 |
|
|
2015-06 |
CT#68 |
CP-150247 |
0016 |
– |
Payload T4 parameter |
12.5.0 |
|
|
CP-150247 |
0020 |
– |
SCS address for SMS over T4 |
||||
|
CP-150248 |
0018 |
1 |
IP-SM-GW-Realm |
||||
|
2015-09 |
CT#69 |
CP-150429 |
0023 |
– |
AVP names corrections |
12.6.0 |
|
|
2015-12 |
CT#70 |
CP-150746 |
0025 |
2 |
Destination Host in the DTR command, IMSI presence |
12.7.0 |
|
|
2015-12 |
CT#70 |
Automatic upgrade from previous Release version 12.7.0 |
13.0.0 |
||||
|
2016-03 |
CT#71 |
CP-160023 |
0026 |
1 |
Diameter message priority over T4 |
13.1.0 |
|
|
2016-12 |
CT#74 |
CP-160664 |
0027 |
– |
Correction to change IETF drmp draft version to official RFC 7944 |
13.2.0 |
|
|
2017-03 |
CT#75 |
CP-170036 |
0028 |
– |
SMS-MO over T4 |
14.0.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0029 |
– |
Update of reference for the Diameter base protocol |
14.0.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0030 |
1 |
Handling of the Vendor-Specific-Application-Id AVP |
14.0.0 |
|
|
2017-03 |
CT#75 |
CP-170048 |
0031 |
– |
Cardinality of the Failed-AVP AVP in answer |
14.0.0 |
|
|
2017-06 |
CT#76 |
CP-171018 |
0033 |
1 |
Support for signaling transport level packet marking |
14.1.0 |
|
|
2017-09 |
CT#77 |
CP-172013 |
0035 |
– |
Correction of DRMP Procedures |
14.2.0 |
|
|
2018-06 |
CT#80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
|
2020-07 |
CT#88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
|
2021-03 |
CT#91e |
CP-210048 |
0036 |
– |
Device Trigger Request for 5G Devices |
16.1.0 |
|
|
2022-04 |
– |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |