6 Protocol Specification and Implementation
29.1283GPPMobility Management Entity (MME) and Serving GPRS Support Node (SGSN) interfaces for interworking with packet data networks and applicationsRelease 17TS
6.1 Introduction
6.1.1 Use of Diameter Base Protocol
The Diameter base protocol as specified in IETF RFC 6733 [32] 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 T6a/T6b interface, T6ai/T6bi interface and the T7 interface.
6.1.4 Use of Sessions
Diameter sessions shall be implicitly terminated between:
– the MME/SGSN and the SCEF, for the T6a/T6b interface;
– the MME/SGSN and the IWK-SCEF, for the T6ai/T6bi interface and
– the IWK-SCEF and the SCEF for the T7 interface.
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 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 [32]. 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 T6a/T6b, T6ai/T6bi and T7 interface shall make use of SCTP IETF RFC 4960 [7] as transport protocol.
6.1.6 Routing Considerations
6.1.6.1 Routing Considerations for Monitoring Event related Requests
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host for Monitoring Event related requests.
The MME/SGSN shall use the SCEF-ID and the SCEF realm previously received over S6a/b for a monitoring event configuration as the Destination-Host AVP and the Destination-Realm AVP in the Reporting-Information-Request for the monitoring event reports sent over the T6a/T6b or T6ai/bi interface.
The MME/SGSN shall use the pre-configured IWK-SCEF identify and the pre-configured IWK-SCEF realm as the Destination-Host AVP and the Destination Realm AVP in the Configuration-Information-Request for the monitoring event configuration sent over the T6ai/bi interface.
The IWK-SCEF behaves as a Diameter Proxy agent according to IETF RFC 6733 [32] for the Reporting-Information-Request received from the MME/SGSN over the T6ai/bi interface and shall forward these requests to the SCEF over the T7 interface by keeping unchanged the Destination Realm and Destination Host AVPs.
For monitoring events directly configured at the MME/SGSN by the SCEF, if the SCEF knows the address/name of the MME/SGSN, both the Destination-Realm AVP and the Destination-Host AVP shall be present in the request. Otherwise, only 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 Monitoring Event related requests initiated by the SCEF.
The Destination-Realm AVP is declared as mandatory in the ABNF for all Monitoring Event related requests. The Destination-Host AVP is declared as optional in the ABNF description of the Reporting-Information-Request and of the Configuration Information-Request.
6.1.6.2 Routing Considerations for Non-IP Data Related Requests
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host for Non-IP Data related requests.
The MME or SGSN shall use the SCEF-ID and the SCEF realm that it received in the subscribed APN associated to the T6a/b connection at its establishment as the Destination-Host AVP and the Destination realm AVP in the Non-IP data related request commands sent over the T6a/b and T6ai/bi interfaces.
The Destination-Host AVP is declared as optional and the Destination realm AVP as mandatory in the ABNF description of the Non-IP data related requests initiated by the MME or SGSN.
NOTE 1: For roaming cases, the routing of MME or SGSN initiated request commands to the IWK-SCEF relies on the Destination Realm AVP as according to the Diameter base protocol.
NOTE 2: The Diameter implicitly terminated sessions and their Session ID for the Non-IP data related traffic are end to end between the MME/SGSN and the SCEF.
The IWK-SCEF behaves as a Diameter Proxy agent according to IETF RFC 6733 [32] for the Non-IP related requests received from the MME or SGSN over the T6ai/bi interfaces and shall forward these requests to the SCEF over the T7 interface by keeping unchanged the Destination Realm and Destination Host AVPs.
The SCEF obtains the Destination-Host AVP and the Destination-Realm AVP to use in the Non-IP data related requests towards an MME or SGSN from the Origin-Host AVP and the Origin-Realm AVP received in previous Non-IP Data related requests from the MME or SGSN. The Origin-Realm AVP in the requests received by the SCEF in roaming cases should contain the domain name of the network to which the MME or SGSN belongs, encoded as specified in clause 19.2 of 3GPP TS 23.003 [24].
The Destination-Host AVP is declared as optional and the Destination realm AVP as mandatory in the ABNF for the Non-IP Data related requests initiated by the SCEF.
The IWK-SCEF behaves as a Diameter Proxy agent according to IETF RFC 3588 [3] for the Non-IP related requests received from the SCEF over the T7 interface and shall forward these requests to the MME or SGSN over the T6ai/bi interfaces by keeping unchanged the Destination Realm and Destination Host AVPs.
6.1.6.3 Handling of the Vendor-Specific-Application-Id AVP
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 SCEF, MME, SGSN and the IWK-SCEF shall advertise support of the Diameter T6a/T6b 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.
NOTE: Even though the reference point between the MME/SGSN and the IWK-SCEF is called T6ai/T6bi respectively and the reference point between the IWK-SCEF and the SCEF is called T7, all these reference points use the same Diameter Application ID.
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 [32].
6.1.8 Diameter Application Identifier
The T6a/T6b 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 T6a/T6b interface application is 16777346.
The T6ai/T6bi and the T7 interface protocol shall use the same Diameter application identifier as the T6a/T6b interface.
6.1.9 Use of the Supported-Features AVP
When new functionality is introduced on the T6a/T6b application, 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 T6a/T6b application is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [4].
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 [4], 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.
6.2 Commands
6.2.1 Introduction
This clause defines the Command code values and related ABNF for each command described in this specification. The ABNF for the commands on T6a/T6b, T6ai/T6bi and T7 are the same if not specified explicitly different.
6.2.2 Command-Code values
This clause defines Command-Code values for the T6a/T6b interface application as allocated by IANA.
Every command is defined by means of the ABNF syntax IETF RFC 5234 [8], according to the Command Code Format (CCF) specification defined in IETF RFC 6733 [32]. When the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 6733 [32] 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 IETF RFC 6733 [32].
The following Command Codes are defined in this specification for T6a/T6b:
Table 6.2.2-1: Command-Code values for T6a/T6b
|
Command-Name |
Abbreviation |
Code |
Clause |
|
Configuration-Information-Request |
CIR |
8388718 |
3GPP TS 29.336 [5] clause 8.2.3 and clause 6.2.3 below |
|
Configuration-Information-Answer |
CIA |
8388718 |
3GPP TS 29.336 [5] clause 8.2.4 and clause 6.2.4 below |
|
Reporting-Information-Request |
RIR |
8388719 |
3GPP TS 29.336 [5] clause 8.2.5 and clause 6.2.5 below |
|
Reporting-Information-Answer |
RIA |
8388719 |
3GPP TS 29.336 [5] clause 8.2.6 and clause 6.2.6 below |
|
Connection-Management-Request |
CMR |
8388732 |
6.2.7 |
|
Connection-Management-Answer |
CMA |
8388732 |
6.2.8 |
|
MO-Data-Request |
ODR |
8388733 |
6.2.9 |
|
MO-Data-Answer |
ODA |
8388733 |
6.2.10 |
|
MT-Data-Request |
TDR |
8388734 |
6.2.11 |
|
MT-Data-Answer |
TDA |
8388734 |
6.2.12 |
For these commands, the Application-ID field shall be set to 16777346 (application identifier of the T6a/T6b interface application, allocated by IANA).
6.2.3 Configuration Information Request (CIR) Command
The Configuration Information Request (CIR) command, indicated by the Command-Code field set to 8388718 and the "R" bit set in the Command Flags field, is sent from:
– the SCEF to the MME/SGSN;
– the SCEF to the IWK-SCEF and
– the MME/SGSN to the IWK-SCEF
This command is originally defined in 3GPP TS 29.336 [5].
For the T6a/T6b interface, the Configuration-Information-Request command format is specified as following:
Message Format:
< Configuration-Information-Request > ::= < Diameter Header: 8388718, REQ, PXY, 16777346 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
*[ Monitoring-Event-Configuration ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.4 Configuration-Information-Answer (CIA) Command
The Configuration-Information-Answer (CIA) command, indicated by the Command-Code field set to 8388718 and the "R" bit cleared in the Command Flags field, is sent from:
– the MME/SGSN to the SCEF;
– the IWK-SCEF to the SCEF and
– the IWK-SCEF to the MME/SGSN
This command is originally defined in 3GPP TS 29.336 [5].
For the T6a/T6b interface, the Configuration-Information-Answer command format is specified as following:
Message Format:
< Configuration-Information-Answer > ::= < Diameter Header: 8388718, PXY, 16777346 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
*[ Monitoring-Event-Report ]
*[ Monitoring-Event-Config-Status ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.5 Reporting-Information-Request (RIR) Command
The Reporting-Information-Request (RIR) command, indicated by the Command-Code field set to 8388719 and the "R" bit set in the Command Flags field, is sent from:
– the MME/SGSN to the SCEF;
– the MME/SGSN to the IWK-SCEF and
– the IWK-SCEF to the SCEF.
This command is originally defined in 3GPP TS 29.336 [5].
For the T6a/T6b interface, the Reporting-Information-Request command format is specified as following:
Message Format:
< Reporting-Information-Request > ::= < Diameter Header: 8388719, REQ, PXY, 16777346 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ OC-Supported-Features ]
*[ Supported-Features ]
[ User-Identifier ]
*[ Monitoring-Event-Report ]
**[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.6 Reporting-Information-Answer (RIA) Command
The Reporting-Information-Answer (RIA) command, indicated by the Command-Code field set to 8388719 and the "R" bit cleared in the Command Flags field, is sent from:
– the SCEF to the MME/SGSN;
– the SCEF to the IWK-SCEF and
– the IWK-SCEF to the MME/SGSN.
This command is originally defined in 3GPP TS 29.336 [5].
For the T6a/T6b interface, the Reporting-Information-Answer command format is specified as following:
Message Format:
< Reporting-Information-Answer > ::= < Diameter Header: 8388719, PXY, 16777346 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ Supported-Features ]
*[ Monitoring-Event-Report-Status ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.7 Connection-Management-Request (CMR) Command
The Connection-Management-Request (CMR) command, indicated by the Command-Code field set to 8388732 and the "R" bit set in the Command Flags field, is sent from:
– the MME or SGSN to the SCEF;
– the MME or SGSN to the SCEF via the IWK-SCEF for roaming cases;
– the SCEF to the MME or SGSN;
– the SCEF to the MME or SGSN via the IWK-SCEF for roaming cases.
For the T6a/b, T6ai/bi, T7 interfaces, the Connection-Management-Request command format is specified as following:
Message Format:
< Connection-Management-Request > ::= < Diameter Header: 8388732, REQ, PXY, 16777346 >
< Session-Id >
< User-Identifier >
< Bearer-Identifier >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ OC-Supported-Features ]
[ CMR-Flags ]
[ Maximum-UE-Availability-Time ]
*[ Supported-Features ]
[ Connection-Action ]
[ Service-Selection ]
[ Serving-PLMN-Rate-Control ]
[ Extended-PCO ]
[ 3GPP-Charging-Characteristics ]
[ RAT-Type ]
[ Terminal-Information ]
[ Visited-PLMN-Id ]
[ APN-Rate-Control-Status ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.8 Connection-Management-Answer (CMA) Command
The Connection-Management-Answer (CMA) command, indicated by the Command-Code field set to 8388732 and the "R" bit cleared in the Command Flags field, is sent from:
– the SCEF to the MME or SGSN;
– the SCEF to the MME or SGSN via the IWK-SCEF for roaming cases;
– the MME or SGSN to the SCEF;
– the MME or SGSN to the SCEF via the IWK-SCEF for roaming cases.
For the T6a/b, T6ai/bi and T7 interfaces, the Connection-Management-Answer command format is specified as following:
Message Format:
< Connection-Management-Answer > ::= < Diameter Header: 8388732, PXY, 16777346 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ Supported-Features ]
[ PDN-Connection-Charging-Id ]
[ Extended-PCO ]
[ APN-Rate-Control-Status ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.9 MO-Data-Request (ODR) Command
The MO-Data-Request (ODR) command, indicated by the Command-Code field set to 8388733 and the "R" bit set in the Command Flags field, is sent from:
– the MME or SGSN to the SCEF;
– the MME or SGSN to the IWK-SCEF and
– the IWK-SCEF to the SCEF.
For the T6a/b, T6ai/bi, T7 interfaces, the MO-Data-Request command format is specified as following:
Message Format:
< MO-Data-Request > ::= < Diameter Header: 8388733, REQ, PXY, 16777346 >
< Session-Id >
< User-Identifier >
< Bearer-Identifier >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ OC-Supported-Features ]
*[ Supported-Features ]
[ Non-IP-Data ]
*[ Proxy-Info ]
*[ Route-Record ]
[ RRC-Cause-Counter ]
*[AVP]
6.2.10 MO-Data-Answer (ODA) Command
The MO-Data-Answer (ODA) command, indicated by the Command-Code field set to 8388733 and the "R" bit cleared in the Command Flags field, is sent from:
– the SCEF to the MME or SGSN;
– the SCEF to the IWK-SCEF and
– the IWK-SCEF to the MME or SGSN.
For the T6a/b, T6ai/bi and T7 interfaces, the MO-Data-Answer command format is specified as following:
Message Format:
< MO-Data-Answer > ::= < Diameter Header: 8388733, PXY, 16777346 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ Supported-Features ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.11 MT-Data-Request (TDR) Command
The MT-Data-Request (TDR) command, indicated by the Command-Code field set to 8388734 and the "R" bit set in the Command Flags field, is sent from:
– the SCEF to the MME or SGSN;
– the SCEF to the IWK-SCEF and
– the IWK-SCEF to the MME or SGSN.
For the T6a/b, T6ai/bi, T7 interfaces, the MT-Data-Request command format is specified as following:
Message Format:
< MT-Data-Request > ::= < Diameter Header: 8388734, REQ, PXY, 16777346 >
< Session-Id >
< User-Identifier >
< Bearer-Identifier >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ OC-Supported-Features ]
*[ Supported-Features ]
[ Non-IP-Data ]
[ SCEF-Wait-Time ]
[ Maximum-Retransmission-Time ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
6.2.12 MT-Data-Answer (TDA) Command
The MT-Data-Answer (TDA) command, indicated by the Command-Code field set to 8388734 and the "R" bit cleared in the Command Flags field, is sent from:
– the MME or SGSN to the SCEF;
– the MME or SGSN to the IWK-SCEF and
– the IWK-SCEF to the SCEF.
For the T6a/b, T6ai/bi and T7 interfaces, the MT-Data-Answer command format is specified as following:
Message Format:
< MT-Data-Answer > ::= < Diameter Header: 8388734, PXY, 16777346 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
[ Requested-Retransmission-Time ]
*[ Supported-Features ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
[ TDA-Flags ]
*[AVP]
6.3 Result-Code AVP and Experimental-Result AVP Values
6.3.1 General
This clause defines result code values that shall be supported by all Diameter implementations that conform to this specification.
6.3.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 [32] shall be applied.
6.3.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 the Diameter base protocol specified IETF RFC 6733 [32] 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.
6.3.3.1 DIAMETER_ERROR_UNAUTHORIZED_REQUESTING_ENTITY (5510)
This result code shall be sent by the MME/SGSN or the IWK-SCEF to indicate that the SCEF is not allowed to request Monitoring services. This error code is defined in 3GPP TS 29.336 [5].
6.3.3.2 DIAMETER_ERROR_UNAUTHORIZED_SERVICE (5511)
This result code shall be sent by the MME/SGSN or the IWK-SCEF to indicate that the specific service requested by the SCEF is not allowed as per local policies. This error code is defined in 3GPP TS 29.336 [5].
6.3.3.3 DIAMETER_ERROR_CONFIGURATION_EVENT_STORAGE_NOT_ SUCCESSFUL (5513)
This result code shall be sent by the MME/SGSN to indicate that the specific service requested by the SCEF could not be stored. This error code is defined in 3GPP TS 29.336 [5].
6.3.3.4 DIAMETER_ERROR_CONFIGURATION_EVENT_NON_EXISTANT (5514)
This result code shall be sent by the IWK-SCEF to indicate that the requested deletion by the MME/SGSN could not be performed because the event does not exist. This error code is defined in 3GPP TS 29.336 [5].
6.3.3.5 DIAMETER_ERROR_REQUESTED_LOCATION_NOT_SERVED (5650)
This result code shall be sent by the MME/SGSN to indicate that the location for which a related monitoring event is configured (e.g. Number of UEs at a given geographical location) by the SCEF, is not served by the MME/SGSN.
6.3.3.6 DIAMETER_ERROR_USER_UNKNOWN (5001)
This result code shall be sent by the SCEF or the MME/SGSN to indicate that the user identified by the IMSI is unknown. This error code is defined in 3GPP TS 29.229 [4].
6.3.3.7 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101)
This result code shall be sent by the SCEF to indicate that the operation is not allowed when an EPS bearer context exists for the user. This error code is defined in 3GPP TS 29.329 [17].
This result code shall be sent by the SCEF or the MME/SGSN to indicate that the requested T6a/b connection action is not allowed.
6.3.3.8 DIAMETER_ERROR_INVALID_EPS_BEARER (5651)
This result code shall be sent by the SCEF or the MME/SGSN to indicate that there is no bearer context for the user.
6.3.3.9 DIAMETER_ERROR_NIDD_CONFIGURATION_NOT_AVAILABLE (5652)
This result code shall be sent by the SCEF to indicate that there is no valid NIDD configuration available.
6.3.3.10 DIAMETER_ERROR_ SCEF_REFERENCE_ID_UNKNOWN (5515)
This result code shall be sent by the SCEF to indicate that the SCEF reference ID is not known by the SCEF.
6.3.3.11 DIAMETER_ERROR_USER_TEMPORARILY_UNREACHABLE (5653)
This result code shall be sent by the MME or SGSN to indicate that the UE is temporarily not reachable due to a power saving function, and that the MME or SGSN will update the SCEF when it detects that the UE is reachable or about to become reachable as specified in clause 5.6.3.
6.3.3.12 DIAMETER_ERROR_UNREACHABLE_USER (4221)
This result code shall be sent by the MME to indicate that the UE is not reachable. This error code is defined in 3GPP TS 29.172 [26].
6.4 AVPs
6.4.1 General
The following table specifies the Diameter AVPs defined for the T6a/T6b 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).
For all AVPs which contain bit masks and are of the type Unsigned32, bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x00000001 should be used.
Table 6.4.1-1: T6a/T6b specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Clause defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
Communication-Failure-Information |
4300 |
6.4.4 |
Grouped |
M,V |
No |
|||
|
Cause-Type |
4301 |
6.4.5 |
Unsigned32 |
M,V |
No |
|||
|
S1AP-Cause |
4302 |
6.4.6 |
Unsigned32 |
M,V |
No |
|||
|
RANAP-Cause |
4303 |
6.4.7 |
Unsigned32 |
M,V |
No |
|||
|
BSSGP-Cause |
4309 |
6.4.8 |
Unsigned32 |
M,V |
No |
|||
|
GMM-Cause |
4304 |
6.4.9 |
Unsigned32 |
M,V |
No |
|||
|
SM-Cause |
4305 |
6.4.10 |
Unsigned32 |
M,V |
No |
|||
|
Number-Of-UE-Per-Location-Configuration |
4306 |
6.4.11 |
Grouped |
M,V |
No |
|||
|
Number-Of-UE-Per-Location-Report |
4307 |
6.4.12 |
Grouped |
M,V |
No |
|||
|
UE-Count |
4308 |
6.4.13 |
Unsigned32 |
M,V |
No |
|||
|
Connection-Action |
4314 |
6.4.18 |
Unsigned32 |
M,V |
No |
|||
|
Non-IP-Data |
4315 |
6.4.19 |
OctetSstring |
M,V |
No |
|||
|
Serving-PLMN-Rate-Control |
4310 |
6.4.21 |
Grouped |
M,V |
No |
|||
|
Uplink-Rate-Limit |
4311 |
6.4.23 |
Unsigned32 |
M,V |
No |
|||
|
Downlink-Rate-Limit |
4312 |
6.4.22 |
Unsigned32 |
M,V |
No |
|||
|
Extended-PCO |
4313 |
6.4.26 |
OctetString |
M,V |
No |
|||
|
SCEF-Wait-Time |
4316 |
6.4.24 |
Time |
M,V |
No |
|||
|
CMR-Flags |
4317 |
6.4.25 |
Unsigned32 |
M,V |
No |
|||
|
RRC-Cause-Counter |
4318 |
6.4.27 |
Grouped |
M,V |
No |
|||
|
Counter-Value |
4319 |
6.4.28 |
Unsigned32 |
M,V |
No |
|||
|
RRC-Counter-Timestamp |
4320 |
6.4.29 |
Time |
M,V |
No |
|||
|
TDA-Flags |
4321 |
6.4.31 |
Unsigned32 |
V |
M |
No |
||
|
Idle-Status-Indication |
4322 |
6.4.32 |
Grouped |
V |
M |
No |
||
|
Idle-Status-Timestamp |
4323 |
6.4.33 |
Time |
V |
M |
No |
||
|
Active-Time |
4324 |
6.4.34 |
Unsigned32 |
V |
M |
No |
||
|
Reachability-Cause |
4325 |
6.4.35 |
Unsigned32 |
V |
M |
No |
||
|
APN-Rate-Control-Status |
4326 |
6.4.36 |
Grouped |
V |
M |
No |
||
|
Uplink-Number-Of-Packets-Allowed |
4327 |
6.4.37 |
Unsigned32 |
V |
M |
No |
||
|
Number-Of-Additional-Exception-Reports |
4328 |
6.4.38 |
Unsigned32 |
V |
M |
No |
||
|
Downlink-Number-Of-Packets-Allowed |
4329 |
6.4.39 |
Unsigned32 |
V |
M |
No |
||
|
APN-Rate-Control-Status-Validity-Time |
4330 |
6.4.40 |
Unsigned64 |
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 [32]. 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 T6a/T6b interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within T6a/T6b.
Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol, do not need to be supported. The AVPs from Diameter Base Protocol are not included in table 6.4.1-2, but they may be re-used for the T6a/T6b protocol.
Table 6.4.1-2: T6a/T6b re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
|---|---|---|
|
Monitoring-Event-Configuration |
3GPP TS 29.336 [5] |
This AVP shall contain the monitoring event to be configured at the MME/SGSN or the IWK-SCEF. See 6.4.2. |
|
Monitoring-Event-Report |
3GPP TS 29.336 [5] |
This AVP shall contain the monitoring event reported by the MME/SGSN or the IWK-SCEF. See 6.4.3. |
|
SCEF-Reference-ID |
3GPP TS 29.336 [5] |
|
|
SCEF-ID |
3GPP TS 29.336 [5] |
|
|
SCEF-Reference-ID-for-Deletion |
3GPP TS 29.336 [5] |
|
|
Supported-Features |
3GPP TS 29.229 [4] |
|
|
Feature-List-ID |
3GPP TS 29.229 [4] |
|
|
Feature-List |
3GPP TS 29.229 [4] |
See 6.4.14 |
|
OC-Supported-Features |
IETF RFC 7683 [9] |
|
|
OC-OLR |
IETF RFC 7683 [9] |
|
|
Monitoring-Event-Config-Status |
3GPP TS 29.336 [5] |
This AVP shall contain the status of configuration of each monitoring event identified by an SCEF-ID and SCEF-Reference-ID. |
|
DRMP |
IETF RFC 7944 [15] |
see 6.4.15 |
|
User-Identifier |
3GPP TS 29.336 [5] |
See 6.4.16 |
|
Bearer-Identity |
3GPP TS 29.212 [10] |
See 6.4.17 |
|
Monitoring-Type |
3GPP TS 29.336 [5] |
|
|
Loss-Of-Connectivity-Reason |
3GPP TS 29.336 [5] |
|
|
Maximum-Number-of-Reports |
3GPP TS 29.336 [5] |
|
|
Monitoring-Duration |
3GPP TS 29.336 [5] |
|
|
Charged-Party |
3GPP TS 32.299 [20] |
|
|
UE-Reachability-Configuration |
3GPP TS 29.336 [5] |
|
|
Location-Information-Configuration |
3GPP TS 29.336 [5] |
|
|
Reachability-Information |
3GPP TS 29.336 [5] |
|
|
EPS-Location-Information |
3GPP TS 29.272 [16] |
|
|
Service-Selection |
IETF RFC 5778 [21] |
See 6.4.20 |
|
PDN-Connection-Charging-Id |
3GPP TS 32.299 [22] |
|
|
Maximum-Retransmission-Time |
3GPP TS 29.338 [27] |
|
|
Requested-Retransmission-Time |
3GPP TS 29.338 [27] |
|
|
Maximum-UE-Availability-Time |
3GPP TS 29.338 [27] |
|
|
3GPP-Charging-Characteristics |
3GPP TS 29.061 [29] |
|
|
RAT-Type |
3GPP TS 29.212 [10] |
|
|
Terminal-Information |
3GPP TS 29.272 [16] |
See 6.4.30 |
|
Visited-PLMN-Id |
3GPP TS 29.272 [16] |
|
|
Load |
IETF RFC 8583 [31] |
|
|
Subscribed-Periodic-RAU-TAU-Timer |
3GPP TS 29.272 [16] |
|
|
Monitoring-Event-Report-Status |
3GPP TS 29.336 [5] |
|
|
IMSI-Group-Id |
3GPP TS 29.272 [16] |
|
|
Reporting-Time-Stamp |
3GPP TS 29.336 [5] |
|
|
eDRX-Cycle-Length |
3GPP TS 29.272 [16] |
|
|
DL-Buffering-Suggested-Packet-Count |
3GPP TS 29.272 [16] |
|
|
PDN-Connectivity-Status-Report |
3GPP TS 29.336 [5] |
|
|
SCEF-Reference-ID-Ext |
3GPP TS 29.336 [5] |
|
|
SCEF-Reference-ID-for-Deletion-Ext |
3GPP TS 29.336 [5] |
6.4.2 Monitoring-Event-Configuration
The Monitoring-Event-Configuration AVP is of type Grouped. It shall contain the Monitoring event configuration related data. It is originally defined in 3GPP TS 29.336 [5].
For the T6a/T6b interface, the Monitoring-Event-Configuration AVP format is specified as following:
AVP format:
Monitoring-Event-Configuration ::= <AVP header: 3122 10415>
[ SCEF-Reference-ID ]
[ SCEF-Reference-ID-Ext ]
{ SCEF-ID }
{ Monitoring-Type }
*[ SCEF-Reference-ID-for-Deletion ]
*[ SCEF-Reference-ID-for-Deletion-Ext ]
[ Maximum-Number-of-Reports ]
[ Monitoring-Duration ]
[ Charged-Party ]
[ UE-Reachability-Configuration ]
[ Location-Information-Configuration ]
*[ Number-Of-UE-Per-Location-Configuration ]
*[AVP]
When the "Extended Reference IDs" feature is supported by the SCEF and MME/SGSN, the SCEF-Reference-ID-Ext and SCEF-Reference-ID-for-Deletion-Ext AVPs shall be used insted of SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion respectively.
6.4.3 Monitoring-Event-Report
The Monitoring-Event-Report AVP is of type Grouped. It shall contain the Monitoring event report data. It is originally defined in 3GPP TS 29.336 [5].
For the T6a/T6b interface, the Monitoring-Event-Report AVP format is specified as following:
AVP format:
Monitoring-Event-Report ::= <AVP header: 3123 10415>
{ SCEF-Reference-ID }
[ SCEF-Reference-ID-Ext ]
[ SCEF-ID ]
[ Monitoring-Type ]
[ Reachability-Information ]
[ EPS-Location-Information ]
[ Communication-Failure-Information ]
*[ Number-Of-UE-Per-Location-Report ]
[ Loss-Of-Connectivity-Reason ]
[ Visited-PLMN-Id ]
[ Idle-Status-Indication ]
[ Reporting-Time-Stamp ]
[ Maximum-UE-Availability-Time ]
*[ PDN-Connectivity-Status-Report ]
[ Reachability-Cause ]
*[AVP]
The AVPs applicable for each Monitoring-Type reported by the MME/SGSN are specified under clause 5.2.2.
When the "Extended Reference IDs" feature is supported by the SCEF and MME/SGSN, the SCEF-Reference-ID-Ext AVP shall be used insted of SCEF-Reference-ID; in such case, the required AVP "SCEF-Reference-ID" shall be included in the grouped AVP by the sender, but its content shall be discarded by the receiver.
6.4.4 Communication-Failure-Information
The Communication-Failure-Information AVP is of type Grouped. It shall contain the reason for communication failure.
AVP format:
Communication-Failure-Information ::= <AVP header: 4300 10415>
[ Cause-Type ]
[ S1AP-Cause ]
[ RANAP-Cause ]
[ BSSGP-Cause ]
[ GMM-Cause ]
[ SM-Cause ]
*[AVP]
6.4.5 Cause-Type
The Cause-Type AVP is of type Unsigned32 and it shall identify the type of the S1AP-Cause. The following values are defined:
RADIO_NETWORK_LAYER (0)
TRANSPORT_LAYER (1)
NAS (2)
PROTOCOL (3)
MISCELLANEOUS (4)
6.4.6 S1AP-Cause
The S1AP-Cause AVP is of type Unsigned32. It shall contain a non-transparent copy of the S1AP cause code as specified clause 9.2.1.3 of 3GPP TS 36.413 [13]. The RAN cause sub-category of the S1AP-Cause as specified in 3GPP TS 36.413 [13] shall be encoded in the Cause-Type AVP as specified in clause 6.4.5 above.
6.4.7 RANAP-Cause
The RANAP-Cause AVP is of type Unsigned32. It shall contain the non-transparent copy of the cause value of the RANAP cause code as specified in clause 9.2.1.4 of 3GPP TS 25.413 [11].
6.4.8 BSSGP-Cause
The BSSGP-Cause AVP is of type Unsigned32. It shall contain the non-transparent copy of the cause value of the BSSGP "Cause" as specified in clause 11.3.8 in 3GPP TS 48.018 [14].
6.4.9 GMM-Cause
The GMM-Cause AVP is of type Unsigned32. It shall contain the GMM cause code as specified in clause 10.5.5.14 of 3GPP TS 24.008 [12].
6.4.10 SM-Cause
The SM-Cause AVP is of type Unsigned32. It shall contain the SM cause code as specified in clause 10.5.6.6 and 10.5.6.6A of 3GPP TS 24.008 [12].
6.4.11 Number-Of-UE-Per-Location-Configuration
The Number-Of-UE-Per-Location-Configuration AVP is of type Grouped. It shall contain the location information for which the number of UEs needs to be reported by the MME/SGSN.
AVP format:
Number-of-UE-Per-Location-Configuration ::= <AVP header: 4306 10415>
{ EPS-Location-Information }
[ IMSI-Group-Id ]
*[AVP]
6.4.12 Number-Of-UE-Per-Location-Report
The Number-Of-UE-Per-Location-Report AVP is of type Grouped. It shall contain the location information along with the number of UEs found at that location by the MME/SGSN.
AVP format:
Number-of-UE-Per-Location-Report ::= <AVP header: 4307 10415>
{ EPS-Location-Information }
{ UE-Count }
[ IMSI-Group-Id ]
*[AVP]
6.4.13 UE-Count
The UE-Count AVP is of type Unsigned32. It shall contain the number of UEs counted against a given criteria (say location information).
6.4.14 Feature-List AVP
6.4.14.1 Feature-List AVP for the T6a/T6b application
The syntax of this AVP is defined in 3GPP TS 29.229 [4].
For the T6a/b application, the meaning of the bits shall be as defined in table 6.4.14.1-1 for the Feature-List-ID.
Table 6.4.14.1-1: Features of Feature-List-ID used in T6a/b
|
Feature bit |
Feature |
M/O |
Description |
|
0 |
MONTE |
O |
Configuration and reporting of monitoring events This feature is applicable to from an SCEF with CIR/CIA command pair and the reporting of events to the SCEF with RIR/RIA command pair. If the MME/SGSN does not support this feature, the SCEF shall not send monitoring event configurations to the HSS within CIR. |
|
1 |
NIDD |
O |
Support of Non-IP Data service over T6a/b This feature is applicable to CMR/CMA, ODR/ODA and TDR/TDA command pairs. If the SCEF does not indicate support of this feature in an CMA, the MME or SGSN may store this information and not send any further CMR commands to that SCEF. |
|
2 |
Filtering |
O |
Filtering Number of UEs present at given location by IMSI-Group This feature is applicable to the CIR/CIA command pair. If the MME/SGSN does not support this feature, the SCEF shall interpret the reported number of UEs per location as not being filtered by the provided IMSI-Group-Id. |
|
3 |
Extended Reference IDs |
O |
Extended Reference IDs This feature is applicable for the CIR/CIA and RIR/RIA command pairs. If the SCEF detects that the MME/SGSN does not support this feature, it shall refrain from sending CIR commands containing 64-bit long SCEF Reference IDs. If the MME/SGSN detects that the SCEF does not support this feature, it shall refrain from sending RIR commands containing 64-bit long SCEF Reference IDs. |
|
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. "MONTE". M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O"). Description: A clear textual description of the feature. |
|||
6.4.15 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [15]. This AVP allows the MME, the SGSN, the SCEF and the IWK-SCEF 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.
6.4.16 User-Identifier
The User-Identifier AVP is of type Grouped and it contains the different identifiers used by the UE.
It is defined in 3GPP TS 29.336 [5]
6.4.17 Bearer-Identifier
The Bearer-Identifier AVP contains either the identity of the EPS bearer used to identify the T6a connection between the MME and the SCEF or the NSAPI of the PDP context identifying the T6b connection between the SGSN and the SCEF. It is defined in 3GPP TS 29.212 [10].
6.4.18 Connection-Action
The Connection-Action AVP is of type Unsigned32 and it shall identify the action to be performed on the T6a/b connection. The following values are defined:
CONNECTION_ESTABLISHMENT (0)
This value shall be used if the T6a/b Connection-Management-Request applies to a T6a/b connection establishment.
CONNECTION_RELEASE (1)
This value shall be used if the T6a/b Connection-Management-Request applies to a T6a/b connection release.
CONNECTION_UPDATE (2)
This value shall be used if the T6a/b Connection-Management-Request applies to updating the properties of a T6a/b connection.
6.4.19 Non-IP-Data
The Non-IP-Data AVP is of type OctetString and it contains the Non-IP data conveyed between the MME or SGSN and the SCEF.
6.4.20 Service-Selection
The Service-Selection AVP is of type of UTF8String. This AVP shall contain the APN Network Identifier as specified in 3GPP TS 23.003 [24] clause 9.1.
The contents of the Service-Selection AVP shall be formatted as a character string composed of one or more labels separated by dots (".").
This AVP is originally defined in IETF RFC 5778[21].
6.4.21 Serving-PLMN-Rate-Control
The Serving-PLMN-Rate-Control AVP is of type Grouped and shall contain.
The AVP format shall conform to:
Serving-PLMN-Rate-Control::= <AVP header: 4310 10415>
[ Uplink-Rate-Limit ]
[ Downlink-Rate-Limit ]
*[AVP]
A Downlink-Rate-Limit set to 0 shall be interpreted that the Serving PLMN Rate Control for downlink messages is deactivated in the MME. If the Serving PLMN Rate Control is activated, the value of Downlink-Rate-Limit shall not be less than 10, see 3GPP TS 23.401 [25].
An Uplink-Rate-Limit set ot 0 shall be interpreted that the Serving PLMN Rate Control for uplink messages is deactivated in the MME. If Serving PLMN Rate Control is activated, the value of Uplink-Rate-Limit shall not be less than 10, see 3GPP TS 23.401 [25].
6.4.22 Downlink-Rate-Limit
The Downlink-Rate-Limit AVP is of type type Unsigned32 and shall contain the maximum number of NAS Data PDUs per deci hour for this UE for downlink.
6.4.23 Uplink-Rate-Limit
The Uplink-Rate-Limit AVP is of type Unsigned32 and shall contain the maximum number of NAS Data PDUs per deci hour for this UE for uplink.
6.4.24 SCEF-Wait-Time
The SCEF-Wait-Time is of type Time and it shall contain the timestamp (in UTC) until which the SCEF expects a response.
6.4.25 CMR-Flags
The CMR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.4.25/1:
Table 6.4.25/1: CMR-Flags
|
Bit |
Name |
Description |
|
0 |
UE-Reachable-Indicator |
This bit if set indicates that the UE has become or is about to become reachable. |
|
NOTE 1: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
6.4.26 Extended-PCO
The Extended-PCO AVP is of type OctetString. The Extended-PCO AVP shall contain the value part of the ePCO IE, starting from octet 4, as specified in clause 9.9.4.26 of 3GPP TS 24.301[28].
6.4.27 RRC-Cause-Counter
The RRC-Cause-Counter AVP is of type Grouped and shall contain the number of receptions of "MO Exception data" and the time when the cause " MO Exception Data" is received for the first time.
The AVP format shall conform to:
RRC-Cause-Counter::= <AVP header: 4318 10415>
[ Counter-Value ]
[ RRC-Counter-Timestamp ]
*[AVP]
6.4.28 Counter-Value
The Counter-Value AVP is of type type Unsigned32 and shall contain the number of occurrences of reception of RRC cause "MO Exception data".
6.4.29 RRC-Counter-Timestamp
The RRC-Counter-Timestamp AVP is of type Time and shall contain a timestamp.
6.4.30 Terminal-Information
The Terminal-Information AVP is of type Grouped. This AVP shall contain the information about the user’s terminal. It is originally defined in 3GPP TS 29.272 [16].
AVP format
Terminal-Information ::= <AVP header: 1401 10415>
[ IMEI ]
[ Software-Version ]
*[ AVP ]
6.4.31 TDA-Flags
The TDA-Flags AVP is of type Unsigned32 and it shall contain a bit map. The meaning of the bits shall be as defined in table 6.4.31-1:
Table 6.4.31-1: TDA-Flags
|
Bit |
Name |
Description |
|
0 |
Acknowledged Delivery |
This bit when set indicates that eNodeB has acknowledged the successful downlink NIDD delivery. |
|
NOTE Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
6.4.32 Idle-Status-Indication
The Idle-Status-Indication AVP is of type Grouped, and it shall contain the details when the UE transitions into idle mode.
AVP format:
Idle-Status-Indication::= <AVP header: 4322 10415>
[ Idle-Status-Timestamp ]
[ Active-Time ]
[ Subscribed-Periodic-RAU-TAU-Timer ]
[ eDRX-Cycle-Length ]
[ DL-Buffering-Suggested-Packet-Count ]
*[AVP]
The Subscribed-Periodic-RAU-TAU-Timer AVP shall contain the periodic TAU/RAU time granted to the UE by the MME/SGSN.
The eDRX-Cycle-Length AVP shall contain the eDRX cycle length granted to the UE by the MME/SGSN.
The DL-Buffering-Suggested-Packet-Count AVP shall contain the suggested number of downlink packets sent to the S-GW by the MME/SGSN.
6.4.33 Idle-Status-Timestamp
The Idle-Status-Timestamp AVP is of type Time and shall contain a timestamp (the time at which the UE transitioned into idle mode).
6.4.34 Active-Time
Active-Time AVP is of type Unsigned32 and shall provide the active time granted to the UE in seconds.
6.4.35 Reachability-Cause
The Reachability-Cause AVP is of type Unsigned32. The following values are defined:
CHANGE_TO_CONNECTED_MODE (0)
REACHABLE_FOR_PAGING (1)
Annex A (normative):
Diameter overload control mechanism
6.4.36 APN-Rate-Control-Status
The APN-Rate-Control-Status AVP is of type Grouped. It shall contain APN Rate Control Status Information as specified in figure 8.38-10 of 3GPP TS 29.274 [33].
6.4.37 Uplink-Number-Of-Packets-Allowed
The Uplink-Number-Of-Packets-Allowed AVP is of type Unsigned32. It shall contain information of octets k+1 to k+4 as specified in figure 8.38-10 of 3GPP TS 29.274 [33].
6.4.38 Number-Of-Additional-Exception-Reports
The Number-Of-Additional-Exception-Reports AVP is of type Unsigned32. It shall contain information of octets k+5 to k+8 as specified in figure 8.38-10 of 3GPP TS 29.274 [33].
6.4.39 Downlink-Number-Of-Packets-Allowed
The Downlink-Number-Of-Packets-Allowed AVP is of type Unsigned32. It shall contain information of octets k+9 to k+12 as specified in figure 8.38-10 of 3GPP TS 29.274 [33].
6.4.40 APN-Rate-Control-Status-Validity-Time
The APN-Rate-Control-Status-Validity-Time AVP is of type Unsigned64. It shall contain information of octets k+13 to k+20 as specified in figure 8.38-10 of 3GPP TS 29.274 [33].