8 Protocol Specification for S6t
29.3363GPPHome Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applicationsRelease 18TS
8.1 Introduction
8.1.1 Use of Diameter Base Protocol
The Diameter base protocol as specified in IETF RFC 6733 [23] 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.
8.1.2 Securing Diameter Messages
For secure transport of Diameter messages, see 3GPP TS 33.210 [4].
8.1.3 Accounting Functionality
Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the S6t interface.
8.1.4 Use of 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 [23]. 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.
8.1.5 Transport Protocol
Diameter messages over the S6t interface shall make use of SCTP IETF RFC 4960 [5] as transport protocol.
8.1.6 Routing Considerations
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.
If the SCEF knows the address/name of the HSS for a certain user, 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 requests initiated by the SCEF.
As the HSS knows the address/name and the associated home network domain name of the SCEF to which it sends RIR and NIR commands from a previously received CIR command, both the Destination-Realm and Destination-Host AVPs shall be present in request commands sent by the HSS to the SCEF.
Destination-Realm AVP is declared as mandatory in the ABNF for all requests.
If the Vendor-Specific-Application-ID AVP is received in any of the commands, it may be ignored by the receiving node, and it shall not be used for routing purposes.
8.1.7 Advertising Application Support
The HSS and the SCEF shall advertise support of the Diameter S6t 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 [23].
8.1.8 Diameter Application Identifier
The S6t 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 S6t interface application is 16777345 (allocated by IANA).
8.1.9 Use of the Supported-Features AVP
When new functionality is introduced on the S6t 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 S6t application is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [7].
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 [7], 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.
8.1.10 User Identity to HSS resolution
The User identity to HSS resolution mechanism enables the SCEF to find the identity of the HSS that holds the subscription data for the target user when multiple and separately addressable HSSs have been deployed in the home network. The resolution mechanism is not required in networks that utilise a single HSS.
This User identity to HSS resolution mechanism may rely on routing capabilities provided by Diameter and be implemented in the home operator network within dedicated Diameter Agents (Redirect Agents or Proxy Agents) responsible for determining the HSS identity based on the provided user identity (e.g. external identifiers provided by the SCEF).
When the Diameter Load Control mechanism is supported (see IETF RFC 8583 [22]), load values from previously received Load AVPs of type HOST may be taken into account when determining the HSS identity.
NOTE: Alternatives to the user identity to HSS resolution Diameter based implementation are outside the scope of this specification.
8.2 Commands
8.2.1 Introduction
This clause defines the Command code values and related ABNF for each command described in this specification.
8.2.2 Command-Code values
This clause defines Command-Code values for the S6t interface application as allocated by IANA.
Every command is defined by means of the ABNF syntax IETF RFC 5234 [9], according to the Command Code Format (CCF) specification defined in IETF RFC 6733 [23]. When the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 6733 [23] 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 [23].
The following Command Codes are defined in this specification for S6t:
Table 8.2.2-1: Command-Code values for S6t
|
Command-Name |
Abbreviation |
Code |
Clause |
|
Configuration-Information-Request |
CIR |
8388718 |
8.2.3 |
|
Configuration-Information-Answer |
CIA |
8388718 |
8.2.4 |
|
Reporting-Information-Request |
RIR |
8388719 |
8.2.5 |
|
Reporting-Information-Answer |
RIA |
8388719 |
8.2.6 |
|
NIDD-Information-Request |
NIR |
8388726 |
8.2.7 |
|
NIDD-Information-Answer |
NIA |
8388726 |
8.2.8 |
For these commands, the Application-ID field shall be set to 16777345 (application identifier of the S6t interface application, allocated by IANA).
8.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 HSS.
Message Format:
< Configuration-Information-Request > ::= < Diameter Header: 8388718, REQ, PXY, 16777345 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Identifier }
[ OC-Supported-Features ]
*[ Supported-Features ]
*[ Monitoring-Event-Configuration ]
[ CIR-Flags ]
*[ AESE-Communication-Pattern ]
[ Enhanced-Coverage-Restriction ]
[ Group-Reporting-Guard-Timer ]
[ AdditionalIdentifiers ]
*[ Proxy-Info ]
*[ Route-Record ]
[ Suggested-Network-Configuration ]
*[AVP]
8.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 HSS to the SCEF.
Message Format:
< Configuration-Information-Answer > ::= < Diameter Header: 8388718, PXY, 16777345 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ Supported-Features ]
[ User-Identifier ]
[ Number-of-UEs ]
*[ Monitoring-Event-Report ]
*[ Monitoring-Event-Config-Status ]
*[ AESE-Communication-Pattern-Config-Status ]
*[ Supported-Services ]
[ S6t-HSS-Cause ]
[ Enhanced-Coverage-Restriction-Data ]
[ CIA-Flags ]
*[ IMSI-Group-Id]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
[ Suggested-Network-Configuration ]
*[AVP]
8.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 cleared in the Command Flags field, is sent from the HSS to the SCEF.
Message Format:
< Reporting-Information-Request > ::= < Diameter Header: 8388719, PXY, 16777345 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
*[ Supported-Features ]
[ User-Identifier ]
*[ Monitoring-Event-Report ]
*[ Group-Report ]
[ Updated-Network-Configuration ]
[ RIR-Flags ]
*[ Supported-Services ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
8.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 HSS to the SCEF.
Message Format:
< Reporting-Information-Answer > ::= < Diameter Header: 8388719, PXY, 16777345 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
*[ Monitoring-Event-Report-Status ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
8.2.7 NIDD Information Request (NIR) Command
The NIDD Information Request (NIR) command, indicated by the Command-Code field set to 8388726 and the "R" bit set in the Command Flags field, is sent from the SCEF to the HSS. It may also be sent from the HSS to the SCEF when the feature "NIDD Authorization Update" is commonly supported by the HSS and the SCEF.
Message Format:
< NIDD-Information-Request > ::= < Diameter Header: 8388726, REQ, PXY, 16777345 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Identifier }
[ OC-Supported-Features ]
*[ Supported-Features ]
[ NIDD-Authorization-Request ]
[ NIDD-Authorization-Update ]
[ NIR-Flags ]
*[ Group-User-Identifier ]
[ MTC-Provider-Info ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
8.2.8 NIDD-Information-Answer (NIA) Command
The NIDD-Information-Answer (NIA) command, indicated by the Command-Code field set to 8388726 and the "R" bit cleared in the Command Flags field, is sent from the HSS to the SCEF. It may also be sent from the SCEF to the HSS when the feature "NIDD Authorization Update" is commonly supported by the HSS and the SCEF.
Message Format:
< NIDD-Information-Answer > ::= < Diameter Header: 8388726, PXY, 16777345 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ Supported-Features ]
[ NIDD-Authorization-Response ]
*[ Group-User-Identifier ]
[ NIA-Flags ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[AVP]
8.3 Result-Code AVP and Experimental-Result AVP Values
8.3.1 General
This clause defines result code values that shall be supported by all Diameter implementations that conform to this specification.
8.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 Diameter base protocol specified in IETF RFC 6733 [23] shall be applied.
8.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 Diameter base protocol specified in IETF RFC 6733 [23] 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.
8.3.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001)
This result code shall be sent by the HSS to indicate that the user identified by the IMSI, MSISDN, or External-Identifier is unknown. This error code is defined in 3GPP TS 29.229 [7].
8.3.3.2 DIAMETER_ERROR_UNAUTHORIZED_REQUESTING_ENTITY (5510)
This result code shall be sent by the HSS to indicate that the SCEF is not allowed to request the service.
8.3.3.3 DIAMETER_ERROR_UNAUTHORIZED_SERVICE (5511)
This result code shall be sent by the HSS to indicate that the specific service requested by the SCEF is not allowed for an UE, or that it cannot be delivered according to the current subscribed services of the UE.
8.3.3.4 DIAMETER_ERROR_REQUESTED_RANGE_IS_NOT ALLOWED (5512)
This result code shall be sent by the HSS to indicate that the specific service requested by the SCEF is not allowed for an UE, or that it cannot be delivered according to the current subscribed services of the UE.
8.3.3.5 DIAMETER_ERROR_CONFIGURATION_EVENT_STORAGE_NOT_ SUCCESSFUL (5513)
This result code shall be sent by the HSS to indicate that the specific service requested by the SCEF could not be stored for an UE.
8.3.3.6 DIAMETER_ERROR_CONFIGURATION_EVENT_NON_EXISTANT (5514)
This result code shall be sent by the HSS to indicate that the requested deletion by the SCEF could not be performed for an UE because the event does not exist.
8.3.3.7 DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION (5451)
This result code shall be sent by the HSS to indicate that the APN is not authorized for an UE.
8.3.3.8 DIAMETER_ERROR_UNAUTHORIZED_MTC_PROVIDER (5516)
This result code shall be sent by the HSS to indicate that the MTC provider is not allowed to request the service.
8.4 AVPs
8.4.1 General
The following table specifies the Diameter AVPs defined for the S6t 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 8.4.1-1: S6t specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Clause defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
AESE-Communication-Pattern |
3113 |
8.4.25 |
Grouped |
M,V |
No |
|||
|
Communication-Pattern-Set |
3114 |
8.4.26 |
Grouped |
M,V |
No |
|||
|
Periodic-Communication-Indicator |
3115 |
8.4.27 |
Unsigned32 |
M,V |
No |
|||
|
Communication-Duration-Time |
3116 |
8.4.28 |
Unsigned32 |
M,V |
No |
|||
|
Periodic-time |
3117 |
8.4.29 |
Unsigned32 |
M,V |
No |
|||
|
Scheduled-Communication-Time |
3118 |
8.4.30 |
Grouped |
M,V |
No |
|||
|
Stationary-Indication |
3119 |
8.4.31 |
Unsigned32 |
M,V |
No |
|||
|
AESE-Communication-Pattern-Config-Status |
3120 |
8.4.32 |
Grouped |
M,V |
No |
|||
|
AESE-Error-Report |
3121 |
8.4.33 |
Grouped |
M,V |
No |
|||
|
Monitoring-Event-Configuration |
3122 |
8.4.2 |
Grouped |
M,V |
No |
|||
|
Monitoring-Event-Report |
3123 |
8.4.3 |
Grouped |
M,V |
No |
|||
|
SCEF-Reference-ID |
3124 |
8.4.4 |
Unsigned32 |
M,V |
No |
|||
|
SCEF-ID |
3125 |
8.4.5 |
DiameterIdentity |
M,V |
No |
|||
|
SCEF-Reference-ID-for-Deletion |
3126 |
8.4.6 |
Unsigned32 |
M,V |
No |
|||
|
Monitoring-Type |
3127 |
8.4.7 |
Unsigned32 |
M,V |
No |
|||
|
Maximum-Number-of-Reports |
3128 |
8.4.8 |
Unsigned32 |
M,V |
No |
|||
|
UE-Reachability-Configuration |
3129 |
8.4.9 |
Grouped |
M,V |
No |
|||
|
Monitoring-Duration |
3130 |
8.4.10 |
Time |
M,V |
No |
|||
|
Maximum-Detection-Time |
3131 |
8.4.11 |
Unsigned32 |
M,V |
No |
|||
|
Reachability-Type |
3132 |
8.4.12 |
Unsigned32 |
M,V |
No |
|||
|
Maximum Latency |
3133 |
8.4.13 |
Unsigned32 |
M,V |
No |
|||
|
Maximum Response Time |
3134 |
8.4.14 |
Unsigned32 |
M,V |
No |
|||
|
Location-Information-Configuration |
3135 |
8.4.15 |
Grouped |
M,V |
No |
|||
|
MONTE-Location-Type |
3136 |
8.4.16 |
Unsigned32 |
M,V |
No |
|||
|
Accuracy |
3137 |
8.4.17 |
Unsigned32 |
M,V |
No |
|||
|
Association-Type |
3138 |
8.4.18 |
Unsigned32 |
M,V |
No |
|||
|
Roaming-Information |
3139 |
8.4.19 |
Unsigned32 |
M,V |
No |
|||
|
Reachability-Information |
3140 |
8.4.20 |
Unsigned32 |
M,V |
No |
|||
|
IMEI-Change |
3141 |
8.4.22 |
Unsigned32 |
M,V |
No |
|||
|
Monitoring-Event-Config-Status |
3142 |
8.4.24 |
Grouped |
M,V |
No |
|||
|
Supported-Services |
3143 |
8.4.40 |
Grouped |
M,V |
No |
|||
|
Supported-Monitoring-Events |
3144 |
8.4.41 |
Unsigned64 |
M,V |
No |
|||
|
CIR-Flags |
3145 |
8.4.39 |
Unsigned32 |
M,V |
No |
|||
|
Service-Result |
3146 |
8.4.37 |
Grouped |
M,V |
No |
|||
|
Service-Result-Code |
3147 |
8.4.38 |
Unsigned32 |
M,V |
No |
|||
|
Reference-ID-Validity-Time |
3148 |
8.4.42 |
Time |
M,V |
No |
|||
|
Event-Handling |
3149 |
8.4.43 |
Unsigned32 |
M,V |
No |
|||
|
NIDD-Authorization-Request |
3150 |
8.4.44 |
Grouped |
M,V |
No |
|||
|
NIDD-Authorization-Response |
3151 |
8.4.45 |
Grouped |
M,V |
No |
|||
|
Service-Report |
3152 |
8.4.47 |
Grouped |
M,V |
No |
|||
|
Node-Type |
3153 |
8.4.48 |
Unsigned32 |
M,V |
No |
|||
|
S6t-HSS-Cause |
3154 |
8.4.50 |
Unsigned32 |
M,V |
No |
|||
|
Enhanced-Coverage-Restriction |
3155 |
8.4.51 |
Grouped |
V |
M |
No |
||
|
Enhanced-Coverage-Restriction-Data |
3156 |
8.4.52 |
Grouped |
V |
M |
No |
||
|
Restricted-PLMN-List |
3157 |
8.4.53 |
Grouped |
V |
M |
No |
||
|
Allowed-PLMN-List |
3158 |
8.4.54 |
Grouped |
V |
M |
No |
||
|
Requested-Validity-Time |
3159 |
8.4.55 |
Time |
V |
M |
No |
||
|
Granted-Validity-Time |
3160 |
8.4.56 |
Time |
V |
M |
No |
||
|
NIDD-Authorization-Update |
3161 |
8.4.57 |
Grouped |
V |
M |
No |
||
|
Loss-Of-Connectivity-Reason |
3162 |
8.4.58 |
Unsigned32 |
V |
M |
No |
||
|
Group-Reporting-Guard-Timer |
3163 |
8.4.59 |
Unsigned32 |
V |
M |
No |
||
|
CIA-Flags |
3164 |
8.4.60 |
Unsigned32 |
V |
M |
No |
||
|
Group-Report |
3165 |
8.4.61 |
Grouped |
V |
M |
No |
||
|
Group-Report-Item |
3166 |
8.4.62 |
Grouped |
V |
M |
No |
||
|
RIR-Flags |
3167 |
8.4.63 |
Unsigned32 |
V |
M |
No |
||
|
Type-Of-External-Identifier |
3168 |
8.4.64 |
Unsigned32 |
V |
M |
No |
||
|
APN-Validity-Time |
3169 |
8.4.65 |
Grouped |
V |
M |
No |
||
|
Suggested-Network-Configuration |
3170 |
8.4.66 |
Grouped |
V |
M |
No |
||
|
Monitoring-Event-Report-Status |
3171 |
8.4.67 |
Grouped |
V |
M |
No |
||
|
PLMN-ID-Requested |
3172 |
8.4.68 |
Enumerated |
V |
M |
No |
||
|
AdditionalIdentifiers |
3173 |
8.4.69 |
Grouped |
V |
M |
No |
||
|
NIR-Flags |
3174 |
8.4.70 |
Unsigned32 |
V |
M |
No |
||
|
Reporting-Time-Stamp |
3175 |
8.4.71 |
Time |
V |
M |
No |
||
|
NIA-Flags |
3176 |
8.4.72 |
Unsigned32 |
V |
M |
No |
||
|
Group-User-Identifier |
3177 |
8.4.73 |
Grouped |
V |
M |
No |
||
|
MTC-Provider-Info |
3178 |
8.4.74 |
Grouped |
V |
M |
No |
||
|
MTC-Provider-ID |
3179 |
8.4.75 |
UTF8String |
V |
M |
No |
||
|
PDN-Connectivity-Status-Configuration |
3180 |
8.4.76 |
Grouped |
V |
M |
No |
||
|
PDN-Connectivity-Status-Report |
3181 |
8.4.77 |
Grouped |
V |
M |
No |
||
|
PDN-Connectivity-Status-Type |
3182 |
8.4.78 |
Unsigned32 |
V |
M |
No |
||
|
Traffic-Profile |
3183 |
8.4.79 |
Unsigned32 |
V |
M |
No |
||
|
Updated-Network-Configuration |
3184 |
8.4.80 |
Grouped |
V |
M |
No |
||
|
Battery-Indicator |
3185 |
8.4.81 |
Unsigned32 |
V |
M |
No |
||
|
SCEF-Reference-ID-Ext |
3186 |
8.4.82 |
Unsigned64 |
V |
M |
No |
||
|
SCEF-Reference-ID-for-Deletion-Ext |
3187 |
8.4.83 |
Unsigned64 |
V |
M |
No |
||
|
Exclude-Identifiers |
3188 |
8.4.84 |
Grouped |
V |
M |
No |
||
|
Include-Identifiers |
3189 |
8.4.85 |
Grouped |
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 [23]. 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 S6t interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within S6t.
Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol specified in IETF RFC 6733 [23], do not need to be supported. The AVPs from Diameter base protocol specified in IETF RFC 6733 [23] are not included in table 8.4.1-2, but they may be re-used for the S6t protocol.
Table 8.4.1-2: S6t re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
M-bit |
||||
|---|---|---|---|---|---|---|---|
|
User-Identifier |
6.4.2 |
see 8.4.36 |
|||||
|
External-Identifier |
6.4.11 |
||||||
|
MSISDN |
3GPP TS 29.329 [10] |
||||||
|
User-Name |
IETF RFC 6733 [23] |
This AVP shall contain the IMSI of the UE |
|||||
|
Supported-Features |
3GPP TS 29.229 [7] |
see 8.4.23 |
|||||
|
Feature-List-ID |
3GPP TS 29.229 [7] |
||||||
|
Feature-List |
3GPP TS 29.229 [7] |
||||||
|
OC-Supported-Features |
IETF RFC 7683 [15] |
See 6.4.16 |
Must not set |
||||
|
OC-OLR |
IETF RFC 7683 [15] |
See 6.4.17 |
Must not set |
||||
|
Visited PLMN Id |
3GPP TS 29.272 [14] |
||||||
|
Charged-Party |
3GPP TS 32.299 [16] |
||||||
|
EPS-Location-Information |
3GPP TS 29.272 [14] |
see 8.4.21 |
|||||
|
MME-Location-Information |
3GPP TS 29.272 [14] |
see 8.4.34 |
|||||
|
SGSN-Location-Information |
3GPP TS 29.272 [14] |
see 8.4.35 |
|||||
|
E-UTRAN-Cell-Global-Identity |
3GPP TS 29.272 [14] |
||||||
|
Tracking-Area-Identity |
3GPP TS 29.272 [14] |
||||||
|
Current-Location-Retrieved |
3GPP TS 29.272 [14] |
||||||
|
Age-Of-Location-Information |
3GPP TS 29.272 [14] |
||||||
|
User-CSG-Information |
3GPP TS 29.272 [14] |
||||||
|
Cell-Global-Identity |
3GPP TS 29.272 [14] |
||||||
|
Service-Area-Identity |
3GPP TS 29.272 [14] |
||||||
|
Routing-Area-Identity |
3GPP TS 29.272 [14] |
||||||
|
eNodeB-ID |
3GPP TS 29.217 [17] |
||||||
|
Day-Of-Week-Mask |
IETF RFC 5777 [18] |
||||||
|
Time-Of-Day-Start |
IETF RFC 5777 [18] |
||||||
|
Time-Of-Day-End |
IETF RFC 5777 [18] |
||||||
|
DRMP |
IETF RFC 7944 [20] |
see 8.4.46 |
Must not set |
||||
|
Service-Selection |
IETF RFC 5778 [21] |
See 8.4.49 |
|||||
|
Load |
IETF RFC 8583 [22] |
See 6.4.20 |
Must not set |
||||
|
DL-Buffering-Suggested-Packet-Count |
3GPP TS 29.272 [14] |
||||||
|
Extended-eNodeB-ID |
3GPP TS 29.217 [17] |
Must not set |
|||||
|
Maximum-UE-Availability-Time |
3GPP TS 29.338 [12] |
||||||
|
Idle-Status-Indication |
3GPP TS 29.128 [24] |
Must not set |
|||||
|
Active-Time |
3GPP TS 29.128 [24] |
When used over S6t, this AVP contains the value of Maximum Response Time (see 3GPP TS 29.122 [26], clause 5.13.2.1.2) which is used to calculate the value of subscribed Active Time as described in 3GPP TS 23.682 [2], clause 4.5.21. |
Must not set |
||||
|
DL-Buffering-Suggested-Packet-Count |
3GPP TS 29.272 [14] |
Must not set |
|||||
|
Subscribed-Periodic-RAU-TAU-Timer |
3GPP TS 29.272 [14] |
When used over S6t, this AVP contains the value of Maximum Latency (see 3GPP TS 29.122 [26], clause 5.13.2.1.2) which is used to calculate the value of subscribed periodic RAU/TAU timer as described in 3GPP TS 23.682 [2], clause 4.5.21. |
Must not set |
||||
|
IMSI-Group-Id |
3GPP TS 29.272 [14] |
Must not set |
|||||
|
Number-of-UEs |
3GPP TS 29.154 [25] |
Must not set |
|||||
|
Terminal-Information |
3GPP TS 29.272 [14] |
Must not set |
|||||
|
PDN-Type |
3GPP TS 29.272 [14] |
Must not set |
|||||
|
Non-IP-PDN-Type-Indicator |
3GPP TS 29.272 [14] |
Must not set |
|||||
|
Non-IP-Data-Delivery-Mechanism |
3GPP TS 29.272 [14] |
Must not set |
|||||
|
Served-Party-IP-Address |
3GPP TS 32.299 [16] |
Must not set |
8.4.2 Monitoring-Event-Configuration
The Monitoring-Event-Configuration AVP is of type Grouped, and it contains the details of the monitoring event from the SCEF. At least SCEF-Reference-ID or one SCEF-Reference-ID-for-Deletion shall be present.
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 ]
[ Maximum-Detection-Time ]
[ UE-Reachability-Configuration ]
[ Location-Information-Configuration ]
[ Association-Type ]
[ DL-Buffering-Suggested-Packet-Count ]
[ PLMN-ID-Requested ]
[ MTC-Provider-Info ]
[ PDN-Connectivity-Status-Configuration ]
[ Exclude-Identifiers ]
[ Include-Identifiers ]
*[AVP]
At least one of the SCEF-Reference-ID or SCEF-Reference–ID-for-Deletion shall be present.
The Maximum-Number-of-Reports AVP, if present, shall contain the maximum number of event reports to be generated by the HSS, MME, or SGSN until the monitoring event configuration is considered to expire.
The Monitoring-Duration AVP, if present, shall contain the absolute time at which the monitoring event configuration is considered to expire.
If both Maximum-Number-of-Reports and Monitoring-Duration AVPs are present, the monitoring event configuration shall be considered to expire as soon as one of the conditions is met.
If both Maximum-Number-of-Reports and Monitoring-Duration AVPs are absent, the monitoring event configuration shall be considered as a one-time monitoring request (same behaviour as setting Maximum-Number-of-Reports to 1).
Monitoring-Type shall only be taken into account in combination with SCEF-Reference-ID; Monitoring-Type AVP shall be ignored for deletion of an event (in combination with SCEF-Reference-ID-for-Deletion).
The details of how to handle expiration of Monitoring events is described in 3GPP TS 23.682 [2].
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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.
When the "Dynamic-Group-Event-Monitoring" feature is supported by the HSS and SCEF, the Exclude-Identifiers AVP may be included to cancel the event monitoring for the listed UEs in a group for which there is a configured Monitoring Event, or the Include-Identifiers AVP may be included to create the event monitoring for the listed UEs in a group for which there is a configured Monitoring Event.
8.4.3 Monitoring-Event-Report
The Monitoring-Event-Report AVP is of type Grouped, and it contains the information to be reported as requested by Monitoring-Event-Configuration.
AVP format:
Monitoring-Event-Report::= <AVP header: 3123 10415>
{ SCEF-Reference-ID }
[ SCEF-Reference-ID-Ext ]
[ SCEF-ID ]
[ SCEF-Reference-ID-for-Deletion ]
[ SCEF-Reference-ID-for-Deletion-Ext ]
[ Visited-PLMN-Id ]
[ Roaming-Information ]
[ IMEI-Change ]
[ Terminal-Information ]
[ Reachability-Information ]
[ Maximum-UE-Availability-Time ]
[ EPS-Location-Information ]
[ Monitoring-Type ]
[ Event-Handling ]
*[ Service-Report ]
[ Loss-Of-Connectivity-Reason ]
[ Idle-Status-Indication ]
*[ PDN-Connectivity-Status-Report ]
*[AVP]
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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; 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.
8.4.4 SCEF-Reference-ID
The SCEF-Reference-ID AVP is of type Unsigned32 and it shall contain the identifier provided by the SCEF.
8.4.5 SCEF-ID
The SCEF- ID AVP is of type DiameterIdentity and it shall contain the identity of the SCEF which has originated the service request towards the HSS, i.e. when sent within a Monitoring-Event-Configuration AVP in S6t-CIR, SCEF-ID AVP and Origin-Host AVP shall have the same value.
8.4.6 SCEF-Reference-ID-for-Deletion
The SCEF-Reference-ID-for-Deletion AVP is of type Unsigned32 and it shall contain the SCEF-Reference-ID (in combination with the SCEF identified by the SCEF-ID) for the event to be deleted.
8.4.7 Monitoring-Type
The Monitoring-Type AVP is of type Unsigned32 and shall identify the type of event to be monitored. The following values are defined:
LOSS_OF_CONNECTIVITY (0)
UE_REACHABILITY (1)
LOCATION_REPORTING (2)
CHANGE_OF_IMSI_IMEI(SV)_ASSOCIATION (3)
ROAMING_STATUS (4)
COMMUNICATION_FAILURE (5)
AVAILABILITY_AFTER_DDN_FAILURE (6)
NUMBER_OF_UES_PRESENT_IN_A_GEOGRAPHICAL_AREA (7)
UE_REACHABILITY_AND_IDLE_STATUS_INDICATION (8)
AVAILABILITY_AFTER_DDN_FAILURE_AND_IDLE_STATUS_INDICATION (9)
PDN_CONNECTIVITY_STATUS (10)
8.4.8 Maximum-Number-of-Reports
The Maximum-Number-of-Reports AVP is of type Unsigned32. It shall contain the number of reports to be generated and sent to the SCEF.
This AVP shall not be present when Monitoring-Type is AVAILABILITY_AFTER_DDN_FAILURE (6).
This AVP shall not be greater than one if:
– Monitoring-Type is UE_REACHABILITY (1) and Reachability-Type is "Reachability for SMS" or
– Monitoring-Type is LOCATION_REPORTING (2) and MONTE-Location-Type is LAST_KNOWN_LOCATION (1).
8.4.9 UE-Reachability-Configuration
The UE-Reachability-Configuration AVP is of type Grouped, and it shall contain the details for configuration for UE reachability.
AVP format:
UE-Reachability-Configuration::= <AVP header: 3129 10415>
[ Reachability-Type ]
[ Maximum-Latency ]
[ Maximum-Response-Time ]
[ DL-Buffering-Suggested-Packet-Count ]
*[AVP]
8.4.10 Monitoring-Duration
The Monitoring-Duration AVP is of typeTime. It shall contain the absolute time at which the related monitoring event request is considered to expire.
8.4.11 Maximum-Detection-Time
The Maximum-Detection-Time AVP is of type Unsigned32. It shall contain the maximum number of seconds without any communication with the UE after which the SCEF is to be informed that the UE is considered to be unreachable. It is used to set the subscribed periodic RAU/TAU timer by the HSS.
8.4.12 Reachability-Type
The Reachability-Type AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.12-1:
Table 8.4.12-1: Reachability-Type
|
Bit |
Name |
Description |
|
0 |
Reachability for SMS |
This bit, when set, indicates that the monitoring for reachability for SMS of the UE is to be configured |
|
1 |
Reachability for Data |
This bit, when set, indicates that the monitoring for reachability for data of the UE is to be configured |
|
NOTE 1: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. NOTE 2: Bit 0 and 1 shall not be set simultaneously. |
||
The default value, when this AVP is not included, is Reachability for SMS (bit 0 set).
8.4.13 Maximum-Latency
The Maximum-Latency AVP is of type Unsigned32. It shall contain the maximum acceptable delay time for downlink data transfer in seconds. It is used to set the subscribed periodic RAU/TAU timer by the HSS.
8.4.14 Maximum-Response-Time
The Maximum-Response-Time AVP is of type Unsigned32. It shall contain the maximum time in seconds for which the UE stays reachable. It is used to set the active time by the HSS.
8.4.15 Location-Information-Configuration
The Location-Information-Configuration AVP is of type Grouped, and it contains the details for location reporting.
AVP format:
Location-Information-Configuration::= <AVP header: 3135 10415>
[ MONTE-Location-Type ]
[ Accuracy ]
[ Periodic-Time ]
*[AVP]
If present, Periodic-Time contains the mimum periodic location reporting time.
8.4.16 MONTE-Location-Type
The MONTE-Location-Type AVP is of type Unsigned32. It indicates the type of location information to be provided. The following values are defined:
CURRENT_LOCATION (0)
LAST_KNOWN_LOCATION (1)
The default value, when this AVP is not included, is LAST_KNOWN_LOCATION (1).
8.4.17 Accuracy
The Accuracy AVP is of type Unsigned32. It shall indicate the requested accuracy. The following values are defined:
CGI-ECGI (0)
eNB (1)
LA-TA-RA (2)
PRA(3)
PLMN-ID (4)
8.4.18 Association-Type
The Association-Type AVP is of type Unsigned32. It shall indicate the details of the event configuration related to the change of IMEI(SV)-IMSI association. The following values are defined:
IMEI-CHANGE (0)
The event shall be reported if the association between IMSI and IMEI has changed; if only the Software Version (SV) has changed, no event shall be reported.
IMEISV-CHANGE (1)
The event shall be reported if the association between IMSI and IMEI, or SV, or both, has changed (this includes the case where only the SV has changed).
8.4.19 Roaming-Information
The Roaming-Information AVP is of type Unsigned32. It shall indicate the roaming status of the subscriber. The following values are defined:
SUBSCRIBER_ROAMING (0)
SUBSCRIBER_NOT_ROAMING (1)
8.4.20 Reachability-Information
The Reachability-Information AVP is of type Unsigned32. It shall indicate the reachability of the subscriber. The following values are defined:
REACHABLE_FOR_SMS (0)
REACHABLE_FOR_DATA (1)
8.4.21 EPS-Location-Information
The EPS-Location-Information AVP is of type Grouped. It shall contain the information related to the user location relevant for EPS. It was originally defined in 3GPP TS 29.272 [49].
AVP format:
EPS-Location-Information ::= <AVP header: 1496 10415>
[ MME-Location-Information ]
[ SGSN-Location-Information ]
*[AVP]
8.4.22 IMEI-Change
The IMEI-Change AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.22-1:
Table 8.4.22-1: IMEI-Change
|
Bit |
Name |
Description |
|
0 |
IMEI |
This bit, when set, indicates that the IMEI has changed (regardless of whether the IMEI Software Version has changed or not). |
|
1 |
IMEISV |
This bit, when set, indicates that only the IMEI Software Version has changed but the IMEI has not changed. |
|
NOTE 1: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. NOTE 2: Bits 0 and 1 shall not be set simultaneously. |
||
When a change of IMEI(SV) is reported, the new IMEI(SV) values may be reported to the SCEF in the Terminal-Information AVP inside the Monitoring-Event-Report AVP (see clause 8.4.3).
8.4.23 Feature-List AVP
8.4.23.1 Feature-List AVP for the S6t application
The syntax of this AVP is defined in 3GPP TS 29.229 [7].
For the S6t application, the meaning of the bits shall be as defined in table 8.4.23-1 for the Feature-List-ID.
Table 8.4.23-1: Features of Feature-List-ID used in S6t
|
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 HSS does not support this feature, the SCEF shall not send monitoring event configurations to the HSS within CIR. |
|
1 |
AESE-Communication-Pattern |
O |
Configuration of CP parameter sets This feature is applicable to from an SCEF with CIR/CIA command pair. If the HSS does not support this feature, the SCEF shall not send CP parameter set to the HSS within CIR. |
|
2 |
NIDD-Authorization |
O |
Authorization of NIDD This feature is applicable to from an SCEF with NIR/NIA command pair. If the HSS indicates in the NIA command that it does not support Authorization of NIDD, the SCEF shall not send NIDD Authorizations requests to the HSS in subsequent NIR commands towards that HSS. |
|
3 |
Enhanced-Coverage-Restriction-Control |
O |
Control Of Enhanced Coverage Restriction This feature is applicable for the CIR/CIA command pair. If the SCEF detects that the HSS does not support this feature, it may refrain from sending further CIR commands containing an Enhanced-Coverage-Restriction AVP or a CIR-Flags AVP with the bit for Enhanced-Coverage-Query set. |
|
4 |
NIDD Authorization Update |
O |
Update/Revocation of NIDD Authorization This feature is applicable for the NIR/NIA command pair. It shall not be supported when NIDD-Authorization is not supported. If the SCEF indicates in the NIR command that it does not support NIDD Authorization Update, the HSS shall not send subsequent NIR commands to update or revoke a granted NIDD Authorization. The HSS may decide not to grant NIDD Authorization when Update/Revocation is not supported by the SCEF. |
|
5 |
Report-Eff-MONTE |
O |
Reporting Efficiency for MONTE This feature is applicable for the RIR/RIA command pair. If the SCEF indicates in the CIR command that it does not support Reporting Efficiency for MONTE, the HSS shall not make use of RIR-flags to indicate the cancellation/removal of all monitoring events nor a change of SCEF authorization for one or more monitoring events. |
|
6 |
Event Cancellation Report |
O |
Event Cancellation Report This feature is applicable to from an SCEF for the CIR/CIA and RIR/RIA command pairs. If the SCEF does not indicate in the CIR command that it does support Event Cancellation Report, the HSS shall not send a report indicating the cancellation of a report in the CIA or subsequent RIR commands towards that SCEF. |
|
7 |
Config-Eff-CP |
O |
Configuration Efficiency for Communication Pattern This feature is applicable for the CIR/CIA and RIR/RIA command pairs. If the SCEF indicates in the CIR command that it does not support this feature, the HSS shall not make use of RIR-flags to indicate the removal of all communication pattern. |
|
8 |
Config-Eff-NP |
O |
Configuration Efficiency for Network Parameter Configuration This feature is applicable for the CIR/CIA and RIR/RIA command pairs. If the SCEF indicates in the CIR command that it does not support this feature, the HSS shall not make use of RIR-flags to indicate the removal of all Suggested Network Configuration. |
|
9 |
Extended Reference IDs |
O |
Extended Reference IDs This feature is applicable for the CIR/CIA command pair. If the SCEF detects that the HSS does not support this feature, it shall refrain from sending CIR commands containing 64-bit long SCEF Reference IDs. |
|
10 |
Dynamic-Group-Event-Monitoring |
Dynamic Management of Group-based Event Monitoring This feature is applicable for the CIR/CIA command pair. If the SCEF detects that the HSS does not support this feature, it shall refrain from sending CIR commands to cancel or create the event monitoring for certain UEs (i.e. one individual UE or a sub-set of UEs) in a group of UEs for which there is a configured Monitoring Event. If the HSS detects that the SCEF does not support this feature, it shall refrain from sending RIR commands to inform the SCEF that the event monitoring is cancelled for certain UEs (i.e. one individual UE or a sub-set of UEs) in a group of UEs for which there is a configured Monitoring Event. |
|
|
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. |
|||
8.4.24 Monitoring-Event-Config-Status
The Monitoring-Event-Config-Status AVP is of type Grouped, and it contains the details of the result of the handling of the Requested action for the Monitoring event.
AVP format:
Monitoring-Event-Config-Status::= <AVP header: 3142 10415>
*[ Service-Report ]
{ SCEF-Reference-ID }
[ SCEF-Reference-ID-Ext ]
[ SCEF-ID ]
*[AVP]
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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.
8.4.25 AESE-Communication-Pattern
The AESE-Communication-Pattern AVP is of type Grouped, and it shall contain the details of the Communication-Pattern from the SCEF.
AVP format
AESE-Communication-Pattern ::= <AVP header: 3113 10415>
[ SCEF-Reference-ID ]
[ SCEF-Reference-ID-Ext ]
{ SCEF-ID }
*[ SCEF-Reference-ID-for-Deletion ]
*[ SCEF-Reference-ID-for-Deletion-Ext ]
*[ Communication-Pattern-Set ]
[ MTC-Provider-Info ]
*[ AVP ]
At least one reference ID (either in SCEF-Reference-ID or in SCEF-Reference-ID-Ext) or a reference ID for deletion (either in SCEF-Reference-ID-for-Deletion or in SCEF-Reference-ID-for-Deletion-Ext) shall be present.
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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.
8.4.26 Communication-Pattern-Set
The Communication-Pattern-Set AVP is of type Grouped, and it shall contain a set of Communication-Pattern.
AVP format
Communication-Pattern-Set ::= <AVP header: 3114 10415>
[ Periodic-Communication-Indicator ]
[ Communication-Duration-Time ]
[ Periodic-Time ]
*[ Scheduled-Communication-Time ]
[ Stationary-Indication ]
[ Reference-ID-Validity-Time ]
[ Traffic-Profile ]
[ Battery-Indicator ]
*[ AVP ]
Communication-duration-time and Periodic-Time shall be only provided when the Periodic-Communication-Indicator is set to PERIODICALLY.
If the Reference-ID-Validity-Time AVP is absent, it indicates that there is no expiration time defined for the Communication-Pattern-Set.
8.4.27 Periodic-Communication-Indicator
The Periodic-communication-indicator AVP is of type Unsigend32. The following values are defined:
PERIODICALLY (0)
ON_DEMAND (1)
8.4.28 Communication-duration-time
The Communication-duration-time AVP is of type Unsigned32 and shall provide the time in seconds of the duration of the periodic communication.
8.4.29 Periodic-time
Periodic-time AVP is of type Unsigned32 and shall provide the time in seconds of the interval for periodic communication.
8.4.30 Scheduled-communication-time
The Scheduled-communication-time AVP is of type Grouped.
AVP format
Scheduled-communication-time ::= <AVP header: 3118 10415>
[ Day-Of-Week-Mask ]
[ Time-Of-Day-Start ]
[ Time-Of-Day-End ]
*[AVP]
If Day-Of-Week-Mask is not provided this shall be interpreted as every day of the week.
If Time-Of-Day-Start is not provided, starting time shall be set to start of the day(s) indicated by Day-Of-Week-Mask.
If Time-Of-Day-End is not provided, ending time is end of the day(s) indicated by Day-Of-Week-Mask.
8.4.31 Stationary indication
The Stationary-indication AVP are of type Unsigned32.
STATIONARY_UE (0)
MOBILE_UE (1)
8.4.32 AESE-Communication-Pattern-Config-Status
The AESE-Communication-Pattern-Config-Status AVP is of type Grouped, and it shall contain the details of the outcome of Communication-Pattern handling from the HSS.
AVP format
AESE-Communication-Pattern-Config-Status ::= <AVP header: 3120 10415>
{ SCEF-Reference-ID }
[ SCEF-Reference-ID-Ext ]
[ SCEF-ID ]
[ AESE-Error-Report ]
*[AVP]
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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.
8.4.33 AESE-Error-Report
The AESE-Error-Report AVP is of type Grouped, and it contains the details of the Error occurred during handling of the Requested action for the Communication-Pattern-Set.
AVP format
AESE-Error-Report ::= <AVP header: 3121 10415>
[ Service-Result ]
*[AVP]
8.4.34 MME-Location-Information
The MME-Location-Information AVP is of type Grouped. It shall contain the information related to the user location relevant for the MME. It was originally defined in 3GPP TS 29.272 [49].
AVP format
MME-Location-Information ::= <AVP header: 1600 10415>
[ E-UTRAN-Cell-Global-Identity ]
[ Tracking-Area-Identity ]
[ Current-Location-Retrieved ]
[ Age-Of-Location-Information ]
[ User-CSG-Information ]
[ eNodeB-ID ]
[ Extended-eNodeB-ID ]
*[AVP]
8.4.35 SGSN-Location-Information
The SGSN-Location-Information AVP is of type Grouped. It shall contain the information related to the user location relevant for the SGSN. It was originally defined in 3GPP TS 29.272 [49].
AVP format
SGSN-Location-Information ::= <AVP header: 1601 10415>
[ Cell-Global-Identity ]
[ Service-Area-Identity ]
[ Routing-Area-Identity ]
[ Current-Location-Retrieved ]
[ Age-Of-Location-Information ]
[ User-CSG-Information ]
*[AVP]
8.4.36 User-Identifier
The User-Identifier AVP is of type Grouped and it contains the different identifiers used by the UE. This AVP is defined in clause 6.4.2. The AVP format for the S6t interface shall be as given below.
AVP format:
User-Identifier ::= <AVP header: 3102 10415>
[ User-Name ]
[ MSISDN ]
[ External-Identifier ]
[ Type-Of-External-Identifier ]
*[AVP]
This AVP shall contain one of the identifiers (IMSI, MSISDN or External-Identifier). The IMSI of the UE shall be included (when applicable) in the User-Name AVP.
The External-Identifier AVP may either contain the identity of an individual UE or the identity of a Group of UEs. The Type-Of-External-Identifier is used to indicate which type of identity is carried in the External-Identifier. When the Type-Of-External-Identifier is not present, it means the External-Identifier AVP contains the identity of an individual UE.
8.4.37 Service-Result
The Service-Result AVP is of type Grouped, and it contains the Error code identified during the handling of the Requested action for the Monitoring event.
AVP format:
Service-Result ::= <AVP header: 3146 10415>
[ Vendor-Id ]
[ Service-Result-Code ]
*[AVP]
If the Service-Result-Code contains an Experimental-Result-Code value defined by 3GPP, then the Vendor-Id shall be set to the value 10415. If the Service-Result-Code contains a Result-Code value defined in the Diameter base protocol by IETF (see IETF RFC 6733 [23]), then the Vendor-Id shall be absent or set to the value 0.
8.4.38 Service-Result-Code
The Service-Result-Code AVP is of type Unsigned32. This AVP shall contain either the value of an Experimental-Result-Code defined by 3GPP or the value of a Result-Code defined in Diameter base protocol by IETF (see IETF RFC 6733 [23]).
8.4.39 CIR-Flags
The CIR-Flags AVP is of type AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.39-1:
Table 8.4.39-1: CIR-Flags
|
Bit |
Name |
Description |
|
0 |
Delete all Monitoring events |
This bit shall be set if the SCEF wants to delete all Monitoring events for a subscriber stored in the HSS. |
|
1 |
Enhanced Coverage Query |
This bit shall be set if the SCEF wants to query the current settings of the Enhanced-Coverage-Restriction. |
|
2 |
IMSI Group Id retrieval |
This bit shall be set if the SCEF wants to retrieve the IMSI Group Id that corresponds to the provided External Group Identifier. |
|
3 |
Delete all Communication Pattern |
This bit shall be set if the SCEF wants to delete all Communication Pattern for a subscriber stored in the HSS. |
|
4 |
Delete all Network Parameter Configurations |
This bit shall be set if the SCEF wants to delete all Suggested Network Configuration for a subscriber stored in the HSS. |
|
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. |
||
8.4.40 Supported-Services
The Supported-Services AVP is of type Grouped and it shall contain the different bit masks representing the services supported by the HSS:
AVP format
Supported-Services ::= <AVP header: 3143 10415>
[ Supported-Monitoring-Events ]
[ Node-Type ]
*[AVP]
8.4.41 Supported-Monitoring-Events
The Supported-Monitoring-Events AVP is of type Unsigned64 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.41-1:
Table 8.4.41-1: Supported-Monitoring-Events
|
Bit |
Name |
Description |
|
0 |
UE and UICC and/or new IMSI-IMEI-SV association |
This bit shall be set if Monitoring the association of the UE and UICC and/or new IMSI-IMEI-SV association monitoring event is supported in the HSS |
|
1 |
UE-reachability |
This bit shall be set if UE reachability monitoring event is supported in the HSS/MME/SGSN |
|
2 |
Location-of-the-UE |
This bit shall be set if Location of the UE and change in location of the UE monitoring event is supported in the HSS/MME/SGSN |
|
3 |
Loss-of-connectivity |
This bit shall be set if Loss of connectivity monitoring event is supported in the HSS/MME/SGSN |
|
4 |
Communication-failure |
This bit shall be set if Communication failure monitoring event is supported in the HSS/MME/SGSN |
|
5 |
Roaming-status |
This bit shall be set if Roaming status (i.e. Roaming or No Roaming) of the UE, and change in roaming status of the UE monitoring event is supported in the HSS |
|
6 |
Availability after DDN failure |
This bit shall be set if Availability after DDN failure monitoring event is supported in the HSS/MME/SGSN |
|
7 |
Idle Status Indication |
This bit shall be set if Idle Status Indication monitoring event is supported in the HSS/MME/SGSN in addition to Availability after DDN failure and UE reachability |
|
8 |
PDN Connectivity Status |
This bit shall be set if PDN Connectivity Status monitoring event is supported in the HSS/MME/SGSN |
|
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. |
||
Absence of this AVP shall have the same meaning as all bits cleared (i.e. serving node does not support MONTE).
If RIR-flags is included in Reporting-Information-Request to indicate a change of authorized monitoring events, each bit in Supported-Monitoring-Events AVP, if cleared, shall indicate the SCEF that associated monitoring event is not authorized.
8.4.42 Reference-ID-Validity-Time
The Reference-ID-Validity-Time AVP is of type Time (see IETF RFC 6733 [23]), and contains the point of time when the CP sets associated to an SCEF-Reference-ID (in combination with an SCEF-ID) becoming invalid and shall be deleted.
8.4.43 Event-Handling
The Event-handling AVP is of type Unsigned32. The following Values are defined:
SUSPEND (0)
RESUME (1)
CANCEL (2)
8.4.44 NIDD-Authorization-Request
The NIDD-Authorization-Request AVP is of type Grouped, and it contains the details for the Authorisation of NIDD via the SCEF.
AVP format:
NIDD-Authorization-Request ::= <AVP header: 3150 10415>
[ Service-Selection ]
[ Requested-Validity-Time ]
*[AVP]
8.4.45 NIDD-Authorization-Response
The NIDD-Authorization-Response AVP is of type Grouped, and it contains the information to be provided triggered by NIDD-Authorization-Request.
AVP format:
NIDD-Authorization-Response::= <AVP header: 3151 10415>
[ MSISDN ]
[ User-Name ]
[ External-Identifier ]
[ Granted-Validity-Time ]
*[AVP]
The User-Name AVP, when present, shall contain the IMSI.
8.4.46 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [20]. This AVP allows the HSS and the SCEF over the S6t interface 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.
8.4.47 Service-Report
The Service-Report AVP is of type Grouped, and it contains the result of the handling of the Requested action for the Monitoring event, the type of node and the services it supports.
AVP format:
Service-Report ::= <AVP header: 3152 10415>
[ Service-Result ]
[ Node-Type ]
*[AVP]
8.4.48 Node-Type
The Node-Type AVP is of type Unsigned32 and shall identify the type of node sending the information. The following values are defined:
HSS (0)
MME (1)
SGSN (2)
8.4.49 Service-Selection
The Service-Selection AVP is of type of UTF8String. This AVP shall contain the APN Network Identifier (i.e. an APN without the Operator Identifier) per 3GPP TS 23.003 [11], clauses 9.1 & 9.1.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 defined in IETF RFC 5778 [21].
8.4.50 S6t-HSS-Cause
The S6t-HSS-Cause AVP is of type Unsigned32 and it contains a bitmask. The meaning of the bits is defined in table 8.4.50-1:
Table 8.4.50-1: S6t-HSS-Cause
|
Bit |
Name |
Description |
|
0 |
Absent Subscriber |
This bit, when set, indicates that the UE is not reachable at the serving node and the configuration could not be forwarded, either because there is no serving node registered in the HSS or because the subscriber is purged in the registered serving node(s). |
|
1 |
Group Event Monitoring Partially Cancel |
This bit, when set, indicates that a configured group-based event monitoring is cancelled for the member UE. |
|
NOTE: Bits not defined in this table shall be cleared by the sending node and discarded by the receiving node. |
||
8.4.51 Enhanced-Coverage-Restriction
The Enhanced-Coverage-Restriction AVP is of type Grouped and shall identify either a complete (and possibly empty) list of serving PLMNs where Enhanced Coverage shall be restricted or a complete (and possibly empty) list of serving PLMNs where Enhanced Coverage shall not be restricted.
AVP format:
Enhanced-Coverage-Restriction ::= <AVP header: 3155 10415>
[ Restricted-PLMN-List ]
[ Allowed-PLMN-List ]
*[AVP]
8.4.52 Enhanced-Coverage-Restriction-Data
The Enhanced-Coverage-Restriction-Data AVP is of type Grouped and shall identify the current visited PLMN (if any) and the current settings of Enhanced-Coverage-Restriction.
AVP format:
Enhanced-Coverage-Restriction-Data ::= <AVP header: 3156 10415>
{ Enhanced-Coverage-Restriction }
[ Visited-PLMN-Id ]
*[AVP]
8.4.53 Restricted-PLMN-List
The Restricted-PLMN-List AVP is of type Grouped and shall identify the complete set of serving PLMNs where Enhanced Coverage is restricted.
AVP format:
Restricted-PLMN-List ::= <AVP header: 3157 10415>
*[ Visited-PLMN-Id ]
*[AVP]
Absence of Visited-PLMN-Id AVPs indicates that Enhanced Coverage is allowed in all serving PLMNs.
8.4.54 Allowed-PLMN-List
The Allowed-PLMN-List AVP is of type Grouped and shall identify the complete set of serving PLMNs where Enhanced Coverage is allowed.
AVP format:
Allowed-PLMN-List ::= <AVP header: 3158 10415>
*[ Visited-PLMN-Id ]
*[AVP]
Absence of Visited-PLMN-Id AVPs indicates that Enhanced Coverage is restricted in all serving PLMNs.
8.4.55 Requested-Validity-Time
The Requested-Validity-Time AVP is of type Time (see IETF RFC 6733 [23]), and contains the point of time after which the SCEF is willing to consider a granted NIDD authorization as being implicitly revoked.
8.4.56 Granted-Validity-Time
The Granted-Validity-Time AVP is of type Time (see IETF RFC 6733 [23]), and contains the point of time after which the HSS removes a stored NIDD Authorization and after which the SCEF shall consider a granted NIDD authorization as being implicitly revoked.
A value in the past indicates that the NIDD Authorization is explicitly revoked.
8.4.57 NIDD-Authorization-Update
The NIDD-Authorization-Update AVP is of type Grouped, and it contains the information to be provided triggered by an update or revocation of the NIDD-Authorization.
AVP format:
NIDD-Authorization-Update::= <AVP header: 3161 10415>
*[ APN-Validity-Time ]
*[AVP]
8.4.58 Loss-Of-Connectivity-Reason
The Loss-Of Connectivity-Reason AVP is of type Unsigned32 and shall identify the reason why loss of connectivity is reported. The following values are defined:
UE_DETACHED_MME (0)
UE_DETACHED_SGSN (1)
MAX_DETECTION_TIME_EXPIRED_MME (2)
MAX_DETECTION_TIME_EXPIRED_SGSN (3)
UE_PURGED_MME (4)
UE_PURGED_SGSN (5)
8.4.59 Group-Reporting-Guard-Timer
The Group-Reporting-Guard-Timer AVP is of type Unsigned32. The Group Reporting Guard Timer indicates an interval in seconds after which time the HSS (at the latest) shall send aggregated Status Indications and/or event report(s) which have been detected for UEs that are part of a group.
8.4.60 CIA-Flags
The CIA-Flags AVP is of type AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.60-1:
Table 8.4.60-1: CIA-Flags
|
Bit |
Name |
Description |
|
0 |
Group-Configuration-In-Progress |
This bit is set when the HSS indicates that the HSS is processing the Group Monitoring configuration(s) and will report further status using the RIR command. |
|
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. |
||
8.4.61 Group-Report
The Group-Report AVP is of type Grouped, and it contains the information to be reported as requested by Monitoring-Event-Configuration or Suggested-Network-Configuration for a group.
VP format:
Group-Report::= <AVP header: 3165 10415>
{ SCEF-Reference-ID }
[ SCEF-Reference-ID-Ext ]
[ SCEF-ID ]
*[ Group-Report-Item ]
*[AVP]
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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.
8.4.62 Group-Report-Item
The Group-Report-Item AVP is of type Grouped, and it contains the information to be reported as requested by Monitoring-Event-Configuration or Suggested-Network-Configuration for a specific UE as part of group processing.
AVP format:
Group-Report-Item::= <AVP header: 3166 10415>
{ User-Identifier }
[ Visited-PLMN-Id ]
[ Roaming-Information ]
[ IMEI-Change ]
[ Reachability-Information ]
[ Maximum-UE-Availability-Time ]
[ EPS-Location-Information ]
[ Monitoring-Type ]
*[ Service-Report ]
[ S6t-HSS-Cause ]
[ Idle-Status-Indication ]
[ Reporting-Time-Stamp ]
[ Updated-Network-Configuration ]
*[ SCEF-Reference-ID-for-Deletion ]
*[ SCEF-Reference-ID-for-Deletion-Ext ]
[ Event-Handling ]
[ Loss-Of-Connectivity-Reason ]
*[ PDN-Connectivity-Status-Report ]
*[AVP]
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, the SCEF-Reference-ID-for-Deletion-Ext AVP shall be used insted of SCEF-Reference-ID-for-Deletion.
8.4.63 RIR-Flags
The RIR-Flags AVP is of type AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.63-1:
Table 8.4.63-1: RIR-Flags
|
Bit |
Name |
Description |
|
0 |
Group-Configuration-In-Progress |
This bit is set when the HSS indicates that the HSS is processing the Group Monitoring configuration and will report further status/reports for the group using additional RIR command(s). |
|
1 |
All-Monitoring-Events-Cancelled |
This bit is set when the HSS indicates that all existing events (if any) are cancelled, e.g. due to subscription removal |
|
2 |
Change-Of-Authorized-Monitoring-Events |
This bit is set when the HSS indicates that the SCEF authorization for one or more monitoring events has changed. |
|
3 |
All-Communication-Pattern-Cancelled |
This bit is set when the HSS indicates that all existing communication pattern (if any) are cancelled, e.g. due to subscription removal |
|
4 |
All-Suggested-Network-Configuration-Cancelled |
This bit is set when the HSS indicates that all existing Network Parameter Configurations (if any) are cancelled, e.g. due to subscription removal |
|
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. |
||
8.4.64 Type-Of-External-Identifier
The Type-Of-External-Identifier AVP is of type Unsigned32 and it shall indicate which type of identity is carried in the External-Identifier AVP. The following values are defined:
EXTERNAL-UE-IDENTIFIER-TYPE (0)
The value 0 indicates the External-Identifier AVP carries the identity of an individual UE.
EXTERNAL-GROUP-IDENTIFIER-TYPE (1)
The value 1 indicates the External-Identifier AVP carries the identity of a Group of UEs.
8.4.65 APN-Validity-Time
The APN-Validity-Time AVP is of type Grouped, and it contains the APN (within the Service-Selection AVP) and the updated validity time for the granted NIDD authorization associated to the APN.
AVP format:
APN-Validity-Time::= <AVP header:3169 10415>
{ Granted-Validity-Time }
[ Service-Selection ]
*[AVP]
Absence of Service-Selection AVP indicates that the Granted-Validity-Time applies to all granted NIDD Authorizations for the user. In this case only one APN-Validity-Time AVP shall be present within the NIDD-Authorization-Update AVP.
8.4.66 Suggested-Network-Configuration
The Suggested-Network-Configuration AVP is of type Grouped, and it shall contain the details for configuration for Suggested Network configuration.
AVP format:
Suggested-Network-Configuration::= <AVP header: 3170 10415>
{ SCEF-Reference-ID }
[ SCEF-Reference-ID-Ext ]
{ SCEF-ID }
[ Subscribed-Periodic-RAU-TAU-Timer ]
[ Active-Time ]
[ DL-Buffering-Suggested-Packet-Count ]
[ MTC-Provider-Info ]
*[ SCEF-Reference-ID-for-Deletion ]
*[ SCEF-Reference-ID-for-Deletion-Ext ]
*[AVP]
If the values of SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion are the same, no Network Parameter Configurations AVP(s) shall be present, that is, SCEF-Reference-ID-for-Deletion takes precedence. If the values of SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion are not the same, Network Parameter Configurations AVP(s) are related to SCEF-Reference-ID.
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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; 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.
8.4.67 Monitoring-Event-Report-Status
The Monitoring-Event-Report-Status AVP is of type Grouped, and it contains the result of a specific event report (identified by the pair SCEF-ID and SCEF-Reference-ID) received by the SCEF.
AVP format:
Monitoring-Event-Report-Status ::= <AVP header: 3171 10415>
{ SCEF-Reference-ID }
[ SCEF-Reference-ID-Ext ]
{ SCEF-ID }
[ Result-Code ]
[ Experimental-Result-Code ]
*[AVP]
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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.
8.4.68 PLMN-ID-Requested
The PLMN-ID-Requested AVP is of type Enumerated and it shall indicate whether the PLMN-ID value needs to be returned in the event report associated to the monitoring type "ROAMING_STATUS". The following values are defined:
TRUE (0)
The value TRUE (0) indicates that the PLMN-ID value shall be returned in the corresponding event report for "ROAMING_STATUS".
FALSE (1)
The value FALSE (1) indicates that the PLMN-ID value shall not be returned in the corresponding event report for "ROAMING_STATUS".
The default value, when this AVP is not included, is TRUE (0).
8.4.69 AdditionalIdentifiers
The AdditionalIdentifiers AVP is of type Grouped, and it shall contain External Group Identifiers.
AVP format:
AdditionalIdentifiers::= <AVP header: 3173 10415>
*[ External-Identifier ]
*[AVP]
8.4.70 NIR-Flags
The NIR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.70-1:
Table 8.4.70-1: NIR-Flags
|
Bit |
Name |
Description |
|
0 |
Incomplete Group-User-Identifier-List |
This bit is set when the SCEF indicates that the union of the Group User Identifier Lists sent in this and in previous messages is still incomplete and more segments of the list will follow within subsequent NIR commands. The bit is not set when NIR contains the last segment of the list. |
|
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. |
||
8.4.71 Reporting-Time-Stamp
The Reporting-Time-Stamp AVP is of type Time (see IETF RFC 6733 [23]), and contains the point of time when the report was generated.
8.4.72 NIA-Flags
The NIA-Flags AVP is of type AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 8.4.72-1:
Table 8.4.72-1: NIA-Flags
|
Bit |
Name |
Description |
|
0 |
Incomplete Group-User-Identifier-List |
This bit is set when the HSS indicates that the sent Group User Identifier List is incomplete and more segments of the list will follow within subsequent NIR commands. |
|
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. |
||
8.4.73 Group-User-Identifier
The Group-User-Identifier AVP is of type Grouped and it contains the External-Identifier or MSISDN and the IMSI of a user belonging to a group.
AVP format:
Group-User-Identifier ::= <AVP header: 3177 10415>
[ User-Name ]
[ MSISDN ]
[ External-Identifier ]
*[AVP]
8.4.74 MTC-Provider-Info
The MTC-Provider-Info AVP is of type Grouped and it contains the information associated to the MTC Service Provider and/or MTC Application (see 3GPP TS 23.682 [2], clause 5.6).
AVP format:
MTC-Provider-Info ::= <AVP header: 3178 10415>
[ MTC-Provider-ID ]
*[AVP]
8.4.75 MTC-Provider-ID
The MTC-Provider-ID AVP is of type UTF8String and it contains a character string representing the identity of the MTC Service Provider and/or MTC Application.
8.4.76 PDN-Connectivity-Status-Configuration
The PDN-Connectivity-Status-Configuration AVP is of type Grouped and it indicates the APN(s) for which the PDN Connectivity Status is to be monitored. If the Service-Selection AVP is included, then the monitoring applies to that specific APN; if the Service-Selection is absent, the monitoring request applies to all APNs.
AVP format:
PDN-Connectivity-Status-Configuration ::= <AVP header: 3180 10415>
[ Service-Selection ]
*[AVP]
8.4.77 PDN-Connectivity-Status-Report
The PDN-Connectivity-Status-Report AVP is of type Grouped and it contains the different parameters associated to the reporting of the PDN Connectivity Status event type.
AVP format:
PDN-Connectivity-Status-Report ::= <AVP header: 3181 10415>
{ Service-Selection }
{ PDN-Connectivity-Status-Type }
[ PDN-Type ]
[ Non-IP-PDN-Type-Indicator ]
[ Non-IP-Data-Delivery-Mechanism ]
*2 [ Served-Party-IP-Address ]
*[AVP]
Absence of PDN-Connectivity-Status-Report in Monitoring-Event-Report AVP including Monitoring-Type AVP with value PDN_CONNECTIVITY_STATUS (10) in responses (immediate report) shall indicate that none of the requested APNs are active. The AVP shall always be present in RIR command if Monitoring-Event-Report AVP includes Monitoring-Type AVP with value PDN_CONNECTIVITY_STATUS (10).
The PDN-Type AVP is defined in 3GPP TS 29.272 [14] and it shall be present when the PDN Connection is an IP connection, and it may contain the value IPv4, IPv6 or IPv4v6. The value IPv4_OR_IPv6 shall not be used for this event reporting. If PDN-Type AVP is present, then the Non-IP-PDN-Type-Indicator and Non-IP-Data-Delivery-Mechanism AVPs shall be absent.
The Non-IP-PDN-Type-Indicator AVP is defined in 3GPP TS 29.272 [14] and it indicates whether the PDN Connection is of type "Non-IP". If this AVP is present, it shall be set to TRUE and the PDN-Type AVP shall be absent.
The Non-IP-Data-Delivery-Mechanism AVP is defined in 3GPP TS 29.272 [14] and it shall be present if the Non-IP-PDN-Type-Indicator AVP is present and set to TRUE. It shall indicate whether the Non-IP data delivery is done via Point-To-Point tunnelling over the SGi interface, or via the SCEF.
NOTE: In 3GPP TS 23.682 [2], clause 5.6.3.9, the reporting of the data delivery mechanism is described in terms of a parameter called "3GPP Interface Indication"; however, the conveyance of such information inside the PDN-Connectivity-Status-Report AVP is done in the present specification in terms of the same set of AVPs used for the definition of the subscription data in 3GPP TS 29.272 [14]. The correspondence of the values of the parameter "3GPP Interface Indication" from 3GPP TS 23.682 [2] is as follows:
– "API-Connectivity" corresponds to the presence of Non-IP-Data-Delivery-Mechanism set to value SCEF-BASED-DATA-DELIVERY;
– "IP-connectivity" corresponds to the presence of PDN-Type AVP, and the absence of Non-IP-PDN-Type-Indicator and Non-IP-Data-Delivery-Mechanism AVPs;
– "Other" corresponds to the presence of Non-IP-Data-Delivery-Mechanism set to value SGi-BASED-DATA-DELIVERY.
The Served-Party-IP-Address AVP may be present 0, 1 or 2 times, and contain the IP address(es) used by the UE (if available) and, if present, they shall contain either of:
– an IPv4 address, or
– an IPv6 address/prefix, or
– both, an IPv4 address and an IPv6 address/prefix (for dual-stack UEs with PDN-Type set to "IPv4v6").
For the IPv6 prefix, the lower 64 bits of the address shall be set to zero.
8.4.78 PDN-Connectivity-Status-Type
The PDN-Connectivity-Status-Type AVP is of type Unsigned32 and it shall indicate the status of the PDN Connection being monitored. The following values are defined:
CREATED (0)
The value CREATED (0) indicates that the event corresponds to the creation of a new PDN Connection on the monitored APN.
DELETED (1)
The value DELETED (1) indicates that the event corresponds to the deletion of a PDN Connection on the monitored APN.
8.4.79 Traffic-Profile
The Traffic-Profile AVP is of type Unsigend32. The following values are defined:
SINGLE_TRANSMISSION_UL (0)
SINGLE_TRANSMISSION_DL (1)
DUAL_TRANSMISSION_UL_WITH_SUBSEQUENT_DL (2)
DUAL_TRANSMISSION_DL_WITH_SUBSEQUENT_UL (3)
MULTI_TRANSMISSION (4)
8.4.80 Updated-Network-Configuration
The Updated-Network-Configuration AVP is of type Grouped. If not included inside Group-Report-Item AVP, it shall contain only the Network Parameter Configurations which were received in a previous CIR command and have been updated due to a new CIR command. If included inside Group-Report-Item AVP, it shall contain the current values applied in the network for each group member.
AVP format:
Updated-Network-Configuration::= <AVP header: 3184 10415>
{ SCEF-ID }
[ SCEF-Reference-ID ]
[ SCEF-Reference-ID-Ext ]
*[ SCEF-Reference-ID-for-Deletion ]
*[ SCEF-Reference-ID-for-Deletion-Ext ]
[ Subscribed-Periodic-RAU-TAU-Timer ]
[ Active-Time ]
[ DL-Buffering-Suggested-Packet-Count ]
*[AVP]
At least one reference ID (either in SCEF-Reference-ID or in SCEF-Reference-ID-Ext) or a reference ID for deletion (either in SCEF-Reference-ID-for-Deletion or in SCEF-Reference-ID-for-Deletion-Ext) shall be present.
When the "Extended Reference IDs" feature is supported by the HSS and SCEF, 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.
8.4.81 Battery-Indicator
The Battery-Indicator AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits shall be as defined in table 8.4.81-1:
Table 8.4.81-1: Battery-Indicator
|
Bit |
Name |
Description |
|
0 |
NO_BATTERY |
When this bit is set it indicates that UE is not battery powered. |
|
1 |
BATTERY_REPLACEABLE_INDICATION |
When this bit is set it indicates that battery of the UE is replaceable, when this bit is not set it indicates that battery of UE is not replaceable. |
|
2 |
BATTERY_RECHARGEABLE_INDICATION |
When this bit is set it indicates that the battery of the UE is rechargeable, when this bit is not set it indicates that battery of the UE is not rechargeable. |
|
NOTE1: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. NOTE2: If bit 0 is set, bit 1 and bit 2 shall be cleared. |
||
8.4.82 SCEF-Reference-ID-Ext
The SCEF-Reference-ID-Ext AVP is of type Unsigned64 and it shall contain a 64-bit identifier provided by the SCEF, which shall be used instead of the 32-bit identifier SCEF-Reference-ID, when supported by both SCEF and HSS.
8.4.83 SCEF-Reference-ID-for-Deletion-Ext
The SCEF-Reference-ID-for-Deletion-Ext AVP is of type Unsigned64 and it shall contain a 64-bit identifier provided by the SCEF, which shall be used instead of the 32-bit identifier SCEF-Reference-ID-for-Deletion, when supported by both SCEF and HSS.
8.4.84 Exclude-Identifiers
The Exclude-Identifiers AVP is of type Grouped, and it shall contain External Group Identifiers or MSISDNs.
AVP format:
Exclude-Identifiers::= <AVP header: 3188 10415>
*[ External-Identifier ]
*[ MSISDN ]
*[AVP]
8.4.85 Include-Identifiers
The Include-Identifiers AVP is of type Grouped, and it shall contain External Group Identifiers or MSISDNs.
AVP format:
Include-Identifiers::= <AVP header: xxxx 10415>
*[ External-Identifier ]
*[ MSISDN ]
*[AVP]
Annex A (normative):
Diameter overload control mechanism