7.1 Introduction

29.2723GPPEvolved Packet System (EPS)Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocolRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1.1 Use of Diameter base protocol

The Diameter base protocol as specified in IETF RFC 6733 [61] 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.

7.1.2 Securing Diameter Messages

For secure transport of Diameter messages, see 3GPP TS 33.210 [16].

If there are no intermediate Diameter Agent networks located between the visited PLMN and the home PLMN, the HSS or the first Diameter Agent located in the home PLMN which has direct connection with the serving network is required to check that the realm contained in the Origin-Realm AVP in the request from the serving network corresponds to the right serving network.

If there are intermediate Diameter Agent networks located between the visited PLMN and home PLMN, the first Diameter Agent which has direct connection with the serving network is required to check that the realm contained in the Origin-Realm AVP in the request from the serving network corresponds to the right serving network.

NOTE 1: How to do the above check is implementation specific, e.g. it may be done by checking if the IP addresses of the serving network nodes match with the realm received in the Origin-Realm AVP in the request.

NOTE 2: Network configurations where a (potential) visited PLMN acts as intermediate Diameter Agent network are not allowed.

NOTE 3: In the case there are intermediate Diameter Agent networks, the home network has to trust these intermediate Diameter agent networks to do the check and other hop by hop security check. This trust is usually substantiated by contracts since there are no remote technical means to verify if the checks were actually performed.

7.1.3 Accounting functionality

Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the S6a, S6d, S13 and S13′ interfaces.

7.1.4 Use of sessions

Between the MME and the HSS and between the SGSN and the HSS and between the MME and the EIR, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server.

The Diameter base protocol specified in IETF RFC 6733 [61] 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 [61]. 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.

7.1.5 Transport protocol

Diameter messages over the S6a, S6d, S13, S13′, S7a and S7d interfaces shall make use of SCTP IETF RFC 4960 [14].

7.1.6 Routing considerations

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.

If an MME or SGSN knows the address/name of the HSS for a certain user, and the associated home network domain name, both the Destination-Realm and Destination-Host AVPs shall be present in the request.

NOTE: When sending a ULR command for a certain user due to HSS restoration procedure (i.e, after the MME/SGSN have received a Reset command from the HSS), the MME or the SGSN might consider the stored address/name of the HSS for the user to be invalid and hence not known.

If an MME or SGSN knows only the home network domain name for a certain user, the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node.

If an MME or SGSN knows only the identity of the user, the home network domain name shall be derived from the user’s IMSI (MNC and MCC values) to construct the EPC Home Network Realm/Domain, as indicated in 3GPP TS 23.003 [3], clause 19.2, and use it as Destination-Realm.

Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an MME or SGSN.

The address/name of the EIR shall be locally configured in the MME.

Requests initiated by the HSS towards an MME or SGSN shall include both Destination-Host and Destination-Realm AVPs.

The HSS obtains the Destination-Host AVP to use in requests towards an MME or SGSN, from the Origin-Host AVP received in previous requests from the MME or SGSN. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the HSS. The Origin-Host AVP received in requests from the MME may contain a Diameter identity of the MME encoded as specified in clause 19.4.2.4 of 3GPP TS 23.003 [3]. The Origin-Host AVP received in requests from the SGSN may contain a Diameter identity of the SGSN encoded as specified in clause 19.4.2.6 of 3GPP TS 23.003 [3].

The HSS obtains the Destination-Realm AVP to use in requests towards an MME or SGSN, from the Origin-Realm AVP received in previous requests from the MME or SGSN. The Origin-Realm AVP in the requests received by the HSS in roaming cases, should contain the domain name of the network to which the MME or the SGSN belongs, encoded as specified in clause 19.2 of 3GPP TS 23.003 [3].

The 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 defined in this specification, it shall be ignored by the receiving node, and it shall not be used for routing purposes.

7.1.7 Advertising Application Support

The HSS, MME, SGSN and EIR shall advertise support of the Diameter S6a/S6d and/or S13/S13′ 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 [61].

7.1.8 Diameter Application Identifier

This clause specifies three Diameter applications: The S6a/S6d interface application, the S13/S13′ interface application, and the S7a/S7d interface application.

The S6a/S6d interface application allows a Diameter server and a Diameter client:

– to exchange location information;

– to authorize a user to access the EPS;

– to exchange authentication information;

– to download and handle changes in the subscriber data stored in the server.

The S6a/S6d 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 S6a/S6d interface application is 16777251 (allocated by IANA).

The S13/S13′ interface application allows a Diameter server and a Diameter client:

– to check the validity of the ME Identity.

The S13/S13′ 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 S13/S13′ interface application is 16777252 (allocated by IANA).

The S7a/S7d interface application allows a Diameter server and a Diameter client:

– to authorize a user to access CSGs identified in the CSS while roaming;

– to download and handle changes in CSG subscriber data stored in the CSS.

The S7a/S7d 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 S7a/S7d interface application is 16777308 (allocated by IANA).

7.1.9 Use of the Supported-Features AVP

When new functionality is introduced on the S6a/S6d interfaces, it should be defined as optional. If backwards incompatible changes can not 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 S6a/S6d interfaces is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [9].

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 [9], 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 specificaion, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another.

The Table 7.3.10/1 defines the features applicable to the S6a/S6d interfaces for the feature list with a Feature-List-ID of 1. The Table 7.3.10/2 defines the features applicable to the S6a/S6d interfaces for the feature list with a Feature-List-ID of 2.

NOTE 1: If the support of a feature by the receiver is required in order for the receiver to be able to correctly process the request command, then the feature is included in the Supported-Features AVP and the M-bit of the Supported-Features AVP has to be set in the request command, according to 3GPP TS 29.229 [9] clause 7.2.1.

NOTE 2: Currently none of the features that can be included in the Supported-Features AVP of the ULR command requires that the HSS supports them to successfully process the ULR command. For this reason the MME or SGSN does not need to set the M-bit of the Supported-Features AVP in the ULR command. This corresponds to the exception to the general rule requiring the setting of the M-bit of the Supported-Features AVP in a request described in 3GPP TS 29.229 [9] clause 7.2.1. Setting the M-bit of the Supported-Features AVP in the ULR command will mean that, if any of the features is not supported, the HSS will reject the ULR command as according to 3GPP TS 29.229 [9] clause 7.2.1.