8 SWx Description

29.2733GPP3GPP EPS AAA interfacesEvolved Packet System (EPS)Release 18TS

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

8.1 Functionality

8.1.1 General

The SWx reference point is defined between the 3GPP AAA Server and the HSS. The description of the reference point and its functionality is given in 3GPP TS 23.402 [3].

The SWx reference point is used to authorize the UE and to transport NBM related mobility parameters when NBM is used to establish connectivity to the EPC.

The SWx is used to authenticate and authorize the UE when the S2a, S2b or S2c reference points are used to connect to EPC. This reference point is also used to update the HSS with the PDN-GW address information. Additionally, this reference point may be used to retrieve and update other mobility related parameters including static QoS profiles for non-3GPP accesses.

Additional requirements for the SWx interface can be found in clause 12 of 3GPP TS 23.402 [3].

8.1.2 Procedures Description

8.1.2.1 Authentication Procedure

8.1.2.1.1 General

This procedure is used between the 3GPP AAA Server and the HSS. The procedure is invoked by the 3GPP AAA Server when a new set of authentication information for a given subscriber is to be retrieved from an HSS. This can happen for example, when a new trusted or untrusted non 3GPP/IP access subscriber has accessed the 3GPP AAA Server for authentication or when a new set of authentication information is required for one of the subscribers already registered in the 3GPP AAA server. The procedure shall be invoked by 3GPP AAA Server when it detects that the VPLMN or access network has changed.

Table 8.1.2.1.1/1: Authentication request

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See IETF RFC 6733 [58])	M	This information element shall contain the user IMSI, formatted according to 3GPP TS 23.003 [14], clause 2.2.
Visited Network Identifier	Visited-Network-Identifier	C	This IE shall contain the identifier that allows the home network to identify the Visited Network. The 3GPP AAA Server shall include this information element when received from signalling across the SWd.
Number Authentication Items	SIP-Number-Auth-Items	M	This information element shall indicate the number of authentication vectors requested
Authentication Data	SIP-Auth-Data-Item	M	See tables 8.1.2.1.1/2 and 8.1.2.1.1/3 for the contents of this information element. The content shown in table 8.1.2.1.1/2 shall be used for a normal authentication request; the content shown in table 8.1.2.1.1/3 shall be used for an authentication request after synchronization failure.
Routing Information	Destination-Host	C	If the 3GPP AAA Server knows the HSS name, this AVP shall be present. This information is available if the 3GPP AAA Server already has the HSS name stored. The HSS name shall be obtained from the Origin-Host AVP, which is received from a previous command from the HSS or from the SLF; otherwise only the Destination-Realm is included so that it is resolved to an HSS address in an SLF-like function. Once resolved the Destination-Host AVP is included with the suitable HSS address and it is stored in the 3GPP AAA Server for further usage.
Access Network Identity	ANID	C	This IE shall contain the access network identifier used for key derivation at the HSS. (See 3GPP TS 24. 302 [26] for all possible values). This IE shall be present if the Authentication Method is EAP-AKA’.
Access Type	RAT-Type	M	This IE shall contain the radio access technology that is serving the UE. (See 3GPP TS 29.212 [23] for all possible values). When this IE is not received by the 3GPP AAA Server, neither from the ePDG nor from the non-3GPP access network, it shall take the value VIRTUAL (1).
Trust Relationship Indicator	AN-Trusted	O	When present, this AVP shall contain the 3GPP AAA Server’s decision on handling the non-3GPP access network, i.e. trusted or untrusted.
Terminal Information	Terminal-Information	O	This information element shall contain information about the user’s mobile equipment. The AVP shall be present only if received from the non-3GPP access network, in authentication and authorization request. The AVP shall be transparently forwarded by the 3GPP AAA server. (see NOTE 1)
AAA Failure Indication	AAA-Failure-Indication	O	If present, this information element shall indicate that the 3GPP AAA Server currently registered in the HSS, is unavailable.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.
NOTE 1: The Terminal-Information AVP is not present in this message for a WLAN access.

Table 8.1.2.1.1/2: Authentication Data content – request

Information element name

Mapping to Diameter AVP

Cat.

Description

Authentication Method

SIP-Authentication-Scheme

This information element shall indicate the authentication method

It shall contain one of the values EAP-AKA or EAP-AKA’. EAP-AKA is specified in IETF RFC 4187 [44] and EAP-AKA’ is specified in IETF RFC 5448 [27].

Table 8.1.2.1.1/3: Authentication Data content – request, synchronization failure

Information element name

Mapping to Diameter AVP

Cat.

Description

Authentication Method

SIP-Authentication-Scheme

This information element shall indicate the authentication method

It shall contain one of the values EAP-AKA or EAP-AKA’.

Authorization Information

SIP-Authorization

This IE shall contain the concatenation of Rand, as sent to the terminal, and auts, as received from the terminal. Rand and auts shall both be binary encoded.

Table 8.1.2.1.1/4: Authentication answer

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See I IETF RFC 6733 [58])	M	This information element shall contain the user IMSI, formatted according to 3GPP TS 23.003 [14], clause 2.2.
Number Authentication Items	SIP-Number-Auth-Items	C	This AVP shall indicate the number of authentication vectors delivered in the Authentication Data information element. It shall be present when the result is DIAMETER_SUCCESS.
Authentication Data	SIP-Auth-Data-Item	C	If the SIP-Number-Auth-Items AVP is equal to zero or it is not present, then this AVP shall not be present. See table 8.1.2.1.1/5 for the contents of this information element.
3GPP AAA Server Name	3GPP-AAA- Server-Name	C	This AVP shall contain the Diameter address of the 3GPP AAA Server. This AVP shall be sent when the user has been previously authenticated by another 3GPP AAA Server and therefore there is another 3GPP AAA Server serving the user.
Result	Result-Code / Experimental-Result	M	This IE shall contain the result of the operation. The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]). The Experimental-Result AVP shall be used for SWx errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.

Table 8.1.2.1.1/5: Authentication Data content – response

Information element name	Mapping to Diameter AVP	Cat.	Description
Item Number	SIP-Item-Number	C	This information element shall be present in a SIP-Auth-Data-Item grouped AVP in circumstances where there are multiple occurrences of SIP-Auth-Data-Item AVPs, and the order in which they should be processed is significant. In this scenario, SIP-Auth-Data-Item AVPs with a low SIP-Item-Number value should be processed before SIP-Auth-Data-Items AVPs with a high SIP-Item-Number value.
Authentication Method	SIP-AuthenticationScheme	M	This IE shall contain one of the values EAP-AKA or EAP-AKA’.
Authentication Information AKA	SIP-Authenticate	M	This IE shall contain, binary encoded, the concatenation of the authentication challenge RAND and the token AUTN. See 3GPP TS 33.203 [16] for further details about RAND and AUTN.
Authorization Information AKA	SIP-Authorization	M	This IE shall contain binary encoded, the expected response XRES. See 3GPP TS 33.203 [16] for further details about XRES.
Confidentiality Key AKA	Confidentiality-Key	M	This information element shall contain the confidentiality key CK or CK’. It shall be binary encoded.
Integrity Key AKA	Integrity-Key	M	This information element shall contain the integrity key IK or IK’. It shall be binary encoded.

8.1.2.1.2 Detailed behaviour

The HSS shall, in the following order (if there is an error in any of the steps, the HSS shall stop processing and return the corresponding error code):

1. Check that the user exists in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

2. Check that the user has non-3GPP subscription and that the user is allowed in the EPC. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTON.

3. If a Visited-Network-Identifier is present, check that the user is allowed to roam in the visited network. If the user is not allowed to roam in the visited network, Experimental-Result-Code shall be set to DIAMETER_ERROR _ROAMING_NOT_ALLOWED.

4. Check the access type. If the access type indicates any value that is restricted for the user, then the Experimental-Result-Code shall be set to DIAMETER_ERROR_RAT_TYPE_NOT_ALLOWED.

5. Based on operator’s policy, if the Trust Relationship Indicator is present and indicates any value that is restricted for the user, then the Experimental-Result-Code shall be set to DIAMETER_ERROR_TRUSTED_NON_3GPP_ACCESS_NOT_ALLOWED or DIAMETER_ERROR_UNTRUSTED_NON_3GPP_ACCESS_NOT_ALLOWED.

6. The HSS shall check if there is an existing 3GPP AAA Server already assisting the user

– If there is a 3GPP AAA Server already serving the user, the HSS shall compare the 3GPP AAA server name received in the request to the 3GPP AAA Server name stored in the HSS.

– If they are not identical and the received message contains the AAA-Failure-Indication AVP, the HSS shall remove the old 3GPP AAA Server name previously assigned for this subscriber, and store the name of the new 3GPP AAA Server that sent the request containing the AAA-Failure-Indication AVP, and continue from step 6. The HSS should attempt to notify the old 3GPP AAA Server about the new server assignment, by means of the network initiated de-registration procedure (see clause 8.1.2.2.3) indicating as reason code "NEW_SERVER_ASSIGNED".

– If they are not identical the HSS shall return the old 3GPP AAA Server to the requester 3GPP AAA Server and return an error by setting the Experimental-Result-Code to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED.

– The requester 3GPP AAA Server, upon detection of a 3GPP AAA Server name in the response assumes that the user already has a 3GPP AAA Server assigned, so makes use of Diameter redirect function to indicate the 3GPP AAA Server name where to address the authentication request.

7. The HSS shall check the request type.

– If the request indicates there is a synchronization failure, the HSS shall process AUTS as described in 3GPP TS 33.203 [16] and return the requested authentication information. The Result-Code shall be set to DIAMETER_SUCCESS.

– If the request indicates authentication, the HSS shall generate the authentication vectors for the requested authentication method, EAP-AKA or EAP-AKA’, as described in 3GPP TS 33.402 [19]. The HSS shall download Authentication-Data-Item up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. The result code shall be set to DIAMETER_SUCCESS.

– If there is no 3GPP AAA Server already serving the user, the HSS shall store the received 3GPP AAA Server name.

Exceptions to the cases specified here shall be treated by HSS as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY. No authentication information shall be returned.

Origin-Host AVP shall contain the 3GPP AAA Server identity.

8.1.2.2 Location Management Procedures

8.1.2.2.1 General

According to the requirements described in 3GPP TS 23.402 [3], SWx reference point shall enable:

– Registration of the 3GPP AAA Server serving an authorized trusted or untrusted non-3GPP access user in the HSS.

– Retrieval of charging-related information from HSS.

– Deregistration procedure between the 3GPP AAA Server and the HSS.

– Retrieval of subscriber profile from HSS.

8.1.2.2.2 UE/PDN Registration/DeRegistration Notification

8.1.2.2.2.1 General

This procedure is used between the 3GPP AAA Server and the HSS.

– To register the current 3GPP AAA Server address in the HSS for a given non-3GPP user. This procedure is invoked by the 3GPP AAA Server after a new subscriber has been authenticated by the 3GPP AAA Server.

– To de-register the current 3GPP AAA Server address in the HSS for a given non-3GPP user. This procedure is invoked when the 3GPP AAA Server removes the access information for a non-3GPP user after all sessions for the user (i.e. the STa, SWm, S6b sessions) have been terminated.

– To download the subscriber profile to the 3GPP AAA Server on demand. This procedure is invoked when for some reason the subscription profile of a subscriber is lost.

– To update the HSS with the identity and the PLMN ID of a dynamically allocated PDN GW as a result of the first PDN connection establishment associated to an APN.

– To update the HSS with the identity of the dynamically allocated PDN GW selected for the establishment of an emergency PDN connection.

Table 8.1.2.2.2.1/1: Non-3GPP IP Access Registration request

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See IETF RFC 6733 [58])	M	This information element shall contain the user IMSI and shall be formatted according to 3GPP TS 23.003 [14], clause 2.2.
Server Assignment Type	Server-Assignment-Type	M	This IE shall contain the type of procedure the 3GPP AAA Server requests in the HSS. When this IE contains REGISTRATION value, the 3GPP AAA Server requests the HSS to perform a registration of the non-3GPP user. When this IE contains USER_DEREGISTRATION / ADMINISTRATIVE_DEREGISTRATION / AUTHENTICATION_FAILURE / AUTHENTICATION_TIMEOUT, the 3GPP AAA Server requests the HSS to de-register the non-3GPP user. When this IE contains AAA_USER_DATA_REQUEST value, the 3GPP AAA Server requests the HSS to download the subscriber user profile towards the 3GPP AAA Server as part of 3GPP AAA Server initiated profile download request, but no registration is requested. When this IE contains PGW_UPDATE value, the 3GPP AAA Server requests the HSS to update the PGW identity for the non-3GPP user for an APN in the user subscription or for emergency services. Any other value shall be considered as an error case.
Routing Information	Destination-Host	C	If the 3GPP AAA Server knows the HSS name this AVP shall be present. This information is available if the 3GPP AAA Server already has the HSS name stored. The HSS name shall be obtained from the Origin-Host AVP, which is received from the HSS as part of authentication response; otherwise only the Destination-Realm is included so that it is resolved to an HSS address in an SLF-like function. Once resolved the Destination‑Host AVP shall be included with the suitable HSS address and it shall be stored in the 3GPP AAA Server for further usage.
PGW identity	MIP6-Agent-Info	C	This IE shall contain, either the identity of the dynamically allocated PDN GW, or the identity of a dynamically allocated PDN GW selected for the establishment of emergency PDN connections, and is included if the Server-Assignment-Type is set to PGW_UPDATE.
PGW PLMN ID	Visited-Network-Identifier	C	This IE shall contain the identity of the PLMN where the PDN-GW was allocated, in cases of dynamic PDN-GW assignment. It shall be present when the PGW Identity is present and does not contain an FQDN.
Context Identifier	Context-Identifier	O	For non-emergency PDN connection establishment, this parameter shall identify the APN Configuration with which the reallocated PDN GW shall be correlated, and it may be included if it is available and the Server-Assignment-Type is set to PGW_UPDATE. For emergency PDN connection establishment, this information element shall be left absent.
APN Id	Service-Selection	C	For non-emergency PDN connection establishment, this information element shall contain the Network Identifier part of the APN, and it shall be included if the Server-Assignment-Type is set to PGW_UPDATE. For emergency PDN connection establishment, this information element shall be left absent.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.
Terminal Information	Terminal-Information	C	The 3GPP AAA Server shall include this IE and set it to the user’s Mobile Equipment Identity, if this information is available, and if the Server-Assignment-Type is set to REGISTRATION. This IE shall also be present, independently of the value of the Server-Assignment-Type, if the Terminal-Information has changed from the last value previously reported to the HSS. This grouped AVP shall contain the IMEI AVP and, if available, the Software-Version AVP, for a trusted or untrusted WLAN access. When the RAT type is not known by the 3GPP AAA Server, but the UE has provided the IMEI(SV), this grouped AVP shall contain the IMEI AVP and, if available, the Software-Version AVP.
Emergency Services	Emergency-Services	C	The 3GPP AAA Server shall include this information element, and set the Emergency-Indication bit, to notify the HSS that a new PDN-GW has been selected for the establishment of an emergency PDN connection, whose identity is conveyed in the "PGW identity" IE. This IE shall only be included when the Server-Assignment-Type is set to PGW_UPDATE.

Table 8.1.2.2.2.1/2: Non-3GPP IP Access Registration response

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See IETF RFC 6733 [58])	M	This information element shall contain the user IMSI and shall be formatted according to 3GPP TS 23.003 [14], clause 2.2.
Registration result	Result-Code / Experimental-Result	M	This IE contains the result of the operation. The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]). The Experimental-Result AVP shall be used for SWx errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
User Profile	Non-3GPP-User-Data	C	This IE shall contain the relevant user profile. Clause 8.2.3.1 details the contents of the AVP. It shall be present when Server-Assignment-Type in the request is equal to AAA_USER_DATA_REQUEST or REGISTRATION and the Result-Code is equal to DIAMETER_SUCCESS.
3GPP AAA Server Name	3GPP-AAA- Server-Name	C	This AVP shall contain the Diameter address of the 3GPP AAA Server. This AVP shall be present when the user has been previously authenticated by another 3GPP AAA Server and therefore there is another 3GPP AAA Server serving the user.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.

8.1.2.2.2.2 Detailed behaviour

When a new trusted or untrusted non-3GPP IP access subscriber has been authenticated by the 3GPP AAA Server, the 3GPP AAA Server initiates the registration towards the HSS. The HSS shall, in the event of an error in any of the steps, stop processing and return the corresponding error code.

At reception of the Non-3GPP IP Access Registration, the HSS shall perform (in the following order):

1. Check that the user is known. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

2. The HSS shall check if there is an existing 3GPP AAA Server already assisting the user

– If there is a 3GPP AAA Server already serving the user, the HSS shall compare the 3GPP AAA Server name received in the request to the 3GPP AAA Server name stored in the HSS.

The requester 3GPP AAA Server, upon detection of a 3GPP AAA Server name in the response assumes that the user already has a 3GPP AAA Server assigned, so makes use of Diameter redirect function to indicate the 3GPP AAA Server name where to address the Non-3GPP IP Access Registration request.

– If they are identical but there is no APN configuration information in HSS for the user, the HSS shall return the Experimental Result Code DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTION and it shall remove the 3GPP AAA Server name previously assigned for this subscriber.

– If there is not a 3GPP AAA Server already serving the user, the HSS shall return an error, setting the Result-Code to DIAMETER_UNABLE_TO_COMPLY in the Response command.

3. After the HSS has determined that the requesting 3GPP AAA server is identical to the registered 3GPP AAA server, the HSS shall check the Server Assignment Type value received in the request:

– If it indicates REGISTRATION, the HSS shall set the subscribers User Status to REGISTERED for the authenticated and authorized trusted or untrusted non-3GPP IP access subscriber, download the relevant user profile information and set the Result-Code AVP to DIAMETER_SUCCESS in the Server-Assignment-Response command. For those APNs that have been authorized as a consequence of having the Wildcard APN in the user subscription, the HSS shall include the specific APN name and associated PDN-GW identity inside the Specific-APN-Info AVP of the Wildcard APN.

– If it indicates USER_DEREGISTRATION / ADMINISTRATIVE_DEREGISTRATION / AUTHENTICATION_FAILURE / AUTHENTICATION_TIMEOUT, the HSS shall remove the 3GPP AAA Server name previously assigned for the subscriber, set the User Status for the subscriber to NOT_REGISTERED and set the Result-Code AVP to DIAMETER_SUCCESS in the Server-Assignment-Response command. The HSS shall not remove the stored dynamic PGW-ID and APN information for the subscriber.

– If it indicates AAA_USER_DATA_REQUEST, the HSS shall download the relevant user profile information to the requester 3GPP AAA Server and set the Result-Code AVP to DIAMETER_SUCCESS in the Response command.

– If it indicates PGW_UPDATE, the HSS shall check if the subscriber is registered.

If the subscriber is registered and the Emergency-Services AVP is present in the request, with the Emergency-Indication bit set, the HSS shall store the PDN GW Identity as the PDN GW used to establish emergency PDN connections by the non-3GPP access network, and update the MME with this information as specified in 3GPP TS 29.272 [29].

If the subscriber is registered and the Emergency-Indication bit of the Emergency-Services AVP is not set in the request, and there is not a static PDN GW subscribed, the HSS shall store the PGW identity and PLMN (if it is received in the command) for the non-3GPP user and the APN identified by the APN Id or by the Context Identifier if present in the request; otherwise, the HSS shall not update or delete the stored PDN GW and, for this case, shall set the result code to DIAMETER_UNABLE_TO_COMPLY.

If the APN corresponding to the PGW identity is not present in the subscription but the wild card APN is present in the subscription, the HSS shall store the new PDN GW identity and PLMN for an APN if present in the request. The HSS shall set the Result-Code AVP to DIAMETER_SUCCESS in the Server-Assignment-Response command. If the Context Identifier is included in the request, the HSS may use it to locate the APN Configuration.

If the APN corresponding to the PGW identity is not present in the subscription and the wild card APN is not present in the subscription, the HSS shall reject the request and set the Result-Code AVP to DIAMETER_UNABLE_TO_COMPLY.

If the subscriber is not registered, the HSS shall reject the request and set the Experimental-Result-Code AVP to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.

– If it indicates any other value, the Result-Code shall be set to DIAMETER_UNABLE_TO COMPLY, and no registration/de-registration or profile download procedure shall be performed.

Origin-Host AVP shall contain the 3GPP AAA Server identity.

If the subscription data received for a certain APN indicates that the APN was authorized as a consequence of having the Wildcard APN in the user subscription in HSS, then the 3GPP AAA Server shall not store this APN data beyond the lifetime of the UE sessions related to the specific APN and the 3GPP AAA Server shall delete them upon disconnection of the UE. If the PGW Identity contains an FQDN of the PDN GW, the 3GPP AAA Server shall retrieve the PGW PLMN ID from the MIP-Home-Agent-Host AVP within the MIP6-Agent-Info AVP which contains the PGW Identity.

For trusted WLAN access, if the transparent single-connection mode is used as specified in 3GPP TS 24.302 [26], the 3GPP AAA Server may be configured by local policy to not update the HSS with the PGW Identity used over TWAN for the default APN of the user (i.e. to skip the Non-3GPP IP Access Registration request with Server-Assignment-Type set to "PGW_UPDATE").

NOTE: This 3GPP AAA Server option can be used when the same APN is configured for TWAN and other access technologies in which case the network can select different PDN GWs for PDN connections to this APN. Updating the HSS with the selected PDN GW identity for Trusted WLAN access could affect PDN connections over other access technologies.

8.1.2.2.3 Network Initiated De-Registration by HSS, Administrative

8.1.2.2.3.1 General

This procedure is used between the 3GPP AAA Server and the HSS to remove a previous registration and all associated state. When the de-registration procedure is initiated by HSS, indicating that a subscription has to be removed, the 3GPP AAA Server subsequently triggers the detach procedure via the appropriate interface.

Table 8.3.2.3: Network Initiated Deregistration by HSS request

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See IETF RFC 6733 [58])	M	This information element shall contain the user IMSI and shall be formatted according to 3GPP TS 23.003 [14], clause 2.2.
Reason for de-registration	Deregistration-Reason	M	This IE shall contain the reason for the de‑registration as the HSS shall send to the 3GPP AAA server a reason for the de‑registration. The de-registration reason shall be composed of two parts: one textual message (if available) that is intended to be forwarded to the user that is de‑registered, and one reason code (see 3GPP TS 29.229 [24]) that determines the behaviour of the 3GPP AAA Server.
Routing Information	Destination-Host	M	This IE shall contain the 3GPP AAA server name that is obtained from the Origin-Host AVP, which is received from the 3GPP AAA Server,
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.

Table 8.3.2.4: Network Initiated Deregistration by HSS response

Information element name

Mapping to Diameter AVP

Cat.

Description

Result

Result-Code / Experimental-Result

This IE shall contain the Result of the operation.

The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]).

The Experimental-Result AVP shall be used for SWx errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.

Supported Features

(See 3GPP TS 29.229 [24])

Supported-Features

If present, this information element shall contain the list of features supported by the origin host.

8.1.2.2.3.2 Detailed behaviour

The HSS shall de-register the affected identity and invoke this procedure to inform the 3GPP AAA server to remove the subscribed user from the 3GPP AAA Server.

The HSS shall send in the Deregistration-Reason AVP the reason for the de-registration, composed by a textual message (if available) aimed for the user and a reason code that determines the action the 3GPP AAA server has to perform. The possible reason codes are:

– PERMANENT_TERMINATION: The non-3gpp subscription or service profile(s) has been permanently terminated or the Core Network Restrictions do not allow access to EPC anymore. The HSS shall clear the user’s 3GPP AAA Server name and set the User Status to NOT_REGISTERED. The 3GPP AAA Server should start the network initiated de-registration towards the user.

– NEW_SERVER_ASSIGNED: The HSS indicates to the 3GPP AAA Server that a new 3GPP AAA Server has been allocated to the user (e.g. because the previous assigned 3GPP AAA Server was found unavailable at a certain point). The 3GPP AAA Server shall remove all user data and session information for the user indicated in the de-registration request. The 3GPP AAA Server shall not start the network initiated de-registration towards the user.

8.1.2.3 HSS Initiated Update of User Profile

8.1.2.3.1 General

According to the requirements described in 3GPP TS 23.402 [3], 3GPP TS 32.422 [32] and 3GPP TS 23.380 [52], SWx reference point shall enable:

– Indication to 3GPP AAA Server of change of non-3GPP subscriber profile within HSS;

– Activation and deactivation of the subscriber and equipment trace in the PDN GW.

– Request of identity and location information of the access network and/or UE local time zone.

– Indication to the 3GPP AAA Server that the HSS-based P-CSCF restoration procedure for WLAN, shall be executed as described in 3GPP TS 23.380 [52] clause 5.6.

This procedure is used between the 3GPP AAA Server and the HSS. The procedure is invoked by the HSS when the subscriber profile has been modified and needs to be sent to the 3GPP AAA Server. This may happen due to a modification in the HSS.

The procedure is also invoked by the HSS to update the 3GPP AAA Server with

– the identity of a dynamically allocated PDN GW which is included in the APN-Configuration AVP in the User Profile as a result of the first PDN connection establishment associated with an APN over 3GPP access; or

– the identity of a dynamically allocated PGN GW for emergency services as a result of the establishment of an emergency PDN connection in E-UTRAN.

This procedure is mapped to the Diameter command codes Push-Profile-Request (PPR) and Push-Profile-Answer (PPA) specified in the 3GPP TS 29.229 [24]. Information element contents for these messages are shown in tables 8.1.2.3.1/1 and 8.1.2.3.1/2.

Table 8.1.2.3.1/1: User Profile Update request

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See IETF RFC 6733 [58])	M	This information element shall contain the user IMSI and shall be formatted according to 3GPP TS 23.003 [14], clause 2.2.
User profile	Non-3GPP-User-Data	M	This IE shall contain the updated user profile. Clause 8.2.3.1 details the contents of the AVP. In case of trace activation or deactivation, the Trace-Info AVP shall be included, and this may be the only AVP that is present under this grouped AVP.
Routing Information	Destination-Host	M	This IE shall contain the 3GPP AAA Server name that is obtained from the Origin-Host AVP, which is received from the 3GPP AAA Server
PPR Flags	PPR-Flags	O	This Information Element contains a bit mask. See 8.2.3.17 for the meaning of the bits.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.

Table 8.1.2.3.1/2: User Profile Update response

Information element name	Mapping to Diameter AVP	Cat.	Description
Result	Result-Code / Experimental-Result	M	This IE shall contain the result of the operation. The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]). The Experimental-Result AVP shall be used for SWx errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Access Network Information	Access-Network-Info	O	If present, this IE shall contain the identity and location information of the access network where the UE is attached.
Local Time Zone	Local-Time-Zone	O	If present, this IE shall contain the time zone of the location in the access network where the UE is attached.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.

8.1.2.3.2 HSS Detailed behaviour

The HSS shall make use of this procedure to update the relevant user profile in the 3GPP AAA server (e.g. change of subscription data or change of the identity of a dynamically allocated PDN GW associated with an APN), or activate / deactivate subscriber and equipment trace in the PDN GW.

The HSS shall make use of this procedure to request the identity, location information and UE local time zone of the access network where the UE is currently attached. In this case, the HSS shall set the Access-Network-Info-Request and/or the UE-Local-Time-Zone-Request bits in the PPR-Flags AVP; if the HSS sends this command for the only purpose of requesting access network information or the local time zone of the UE (i.e., the user profile is not actually modified), the Non-3GPP-User-Data shall be included in the command as an empty AVP. The HSS shall only invoke this procedure if the 3GPP AAA Server has indicated support for the corresponding feature (see clause 8.2.3.16).

The HSS shall make use of this procedure to request to the 3GPP AAA Server the execution of the HSS-based P-CSCF restoration procedure, as described in 3GPP TS 23.380 [52] clause 5.4 if the 3GPP AAA Server indicated the support of this procedure in an earlier command to the HSS. In this case, the HSS shall set the "P-CSCF Restoration Request" bit in the PPR Flags and the procedure shall only be used for the purpose of the P-CSCF restoration for WLAN; then, the Non-3GPP-User-Data AVP shall be included as an empty AVP. .

The HSS shall make use of this procedure to update the identity of a dynamically allocated PDN GW for emergency services in the 3GPP AAA server, if the 3GPP AAA Server indicated the support of the Emergency Services Continuity feature in an earlier command to the HSS.

8.1.2.3.3 3GPP AAA Server Detailed behaviour

When the HSS-initiated user profile update procedure is successful, the 3GPP AAA Server shall overwrite entirely, for the subscriber identity indicated in the request, the currently stored user profile data with the information received from the HSS, if at least one APN-Configuration AVP is included in the Non-3GPP-User-Data AVP received from HSS. If no APN-Configurations are included in the Non-3GPP-User-Data AVP, the 3GPP AAA Server shall only update the currently stored user profile data with the new received data from the HSS.

If the HSS-initiated user profile update procedure is not successful, the 3GPP AAA Server shall not modify the stored user profile.

After a successful user profile download, the 3GPP AAA Server shall initiate re-authentication procedure as described in clause 7.2.2.4 if the subscriber has previously been authenticated and authorized to untrusted non-3GPP access. If the subscriber has previously been authenticated and authorized to trusted non-3GPP IP Access then the 3GPP AAA Server shall initiate a re-authorization procedure as described in clause 5.1.2.3.

As multiple authorization sessions may exist for the user (see clause 7.1.2.1), the 3GPP AAA Server shall examine the need to execute re-authorization for each of these sessions, and may execute the multiple re-authorization procedures in parallel. In case the user’s non-3GPP subscription has been deleted or the user’s APN has been barred, the re-authorization shall be executed in all ongoing user related authorization sessions. Otherwise, the re-authorization procedure shall be invoked for the authorization sessions for which at least one of the following conditions is fulfilled:

– The user’s subscribed APN has been deleted from the HSS.

– The APN configuration data has been previously downloaded to the ePDG and the new version of APN configuration received from HSS reflects a modification in these data.

Following a successful download of subscription and equipment trace data, the 3GPP AAA Server shall forward the trace data by initiating reauthorization towards all PDN GWs that have an active authorization session.

When the UE is attached to a Trusted WLAN, if the HSS has invoked the User Profile Update procedure by setting the Access-Network-Info-Request and/or UE-Local-Time-Zone-Request bits in the PPR-Flags, the 3GPP AAA Server shall initiate a re-authorization procedure towards the TWAN by setting the Re-Auth–Request-Type to AUTHORIZE_ONLY; the TWAN shall send the identification, location information of the Access Point where the UE is attached and the local time zone of the UE, in the subsequent authorization request (AAR command) that follows the re-authorization request/answer exchange (RAR/RAA). If the 3GPP AAA Server determines that the UE is not currently attached to a Trusted WLAN, it shall not initiate any re-authorization procedure towards the access network, and it shall not include any network access information or UE local time zone in the response to the HSS.

NOTE: The 3GPP AAA Server cannot answer the Push Profile Request received from the HSS until the AAR command has ben received from the TWAN, since it needs to receive the information from the access network, before sending back the Push Profile Answer to the HSS.

If the 3GPP AAA Server receives the Push-Profile-Request command with an empty Non-3GPP-User-Data AVP, but some other action is indicated by setting any of the bits in the PPR-Flags AVP, the 3GPP AAA Server shall ignore the Non-3GPP-User-Data AVP, i.e., it shall not apply any changes to the stored user profile.

When the PPR Flags are received with the "P-CSCF Restoration Request" bit set, if an IMS PDN connection is established via a trusted or untrusted WLAN access for which the PGW has indicated the support of the P-CSCF restoration feature in an earlier command, the 3GPP AAA Server shall execute the HSS-based P-CSCF restoration for WLAN procedure, as described in 3GPP TS 23.380 [52] clause 5.6. Otherwise, the 3GPP AAA Server does not execute the HSS-based P-CSCF restoration for WLAN procedure.

Table 8.1.2.3.3/1 details the valid result codes that the 3GPP AAA Server can return in the response.

Table 8.1.2.3.3/1: User profile response valid result codes

Result-Code AVP value	Condition
DIAMETER_SUCCESS	The request succeeded.
DIAMETER_ERROR_USER_UNKNOWN	The request failed because the user is not found in 3GPP AAA Server.
DIAMETER_UNABLE_TO_COMPLY	The request failed.

8.1.2.4 Fault Recovery Procedures

8.1.2.4.1 HSS Reset Indication

8.1.2.4.1.1 General

This procedure is used by the HSS to indicate to the 3GPP AAA Server that it has restarted, and the registration data and the dynamic data stored for a set of users may have been lost.

This procedure is mapped to the Diameter command codes Push-Profile-Request (PPR) and Push-Profile-Answer (PPA) specified in the 3GPP TS 29.229 [24]. Information Element contents for these messages are shown in tables 8.1.2.4.1.1/1 and 8.1.2.4.1.1/2.

Table 8.1.2.4.1.1/1: HSS Reset Indication Request

Information element name	Mapping to Diameter AVP	Cat.	Description
User List	User-Name (See IETF RFC 6733 [58])	M	This information element shall indicate the users affected by the HSS restart. It shall contain either: – The string "*", if all users are affected by the restart – The leading digits of the IMSI series of the set of users affected by the restart.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.
PPR Flags	PPR-Flags	M	This Information Element contains a bit mask. See 8.2.3.17 for the meaning of the bits. The HSS shall set the Reset-Indication bit when sending PPR to the 3GPP AAA Server.

Table 8.1.2.4.1.1/2: HSS Reset Indication Response

Information element name

Mapping to Diameter AVP

Cat.

Description

Result

Result-Code / Experimental-Result

This IE shall contain the result of the operation.

The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]).

The Experimental-Result AVP shall be used for SWx errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.

Supported Features

(See 3GPP TS 29.229 [24])

Supported-Features

If present, this information element shall contain the list of features supported by the origin host.

8.1.2.4.1.2 HSS Detailed behaviour

The HSS shall use this procedure to indicate to the 3GPP AAA Server about a restart event, affecting a set of users, for whom their registration data and dynamic data may have been lost. The HSS shall only send this command if the 3GPP AAA Server has indicated support for the "HSS Restoration" feature. In this case, the HSS shall set the Reset-Indication bit in the PPR-Flags AVP in the PPR command.

NOTE: If there are multiple 3GPP AAA Servers deployed in the HPLMN, and the HSS is configured (in an implementation-specific manner) in such a way that it can determine that a certain 3GPP AAA Server does not contain any of the users affected by the restart, it can skip sending the PPR command to that specific 3GPP AAA Server.

8.1.2.4.1.3 3GPP AAA Server Detailed behaviour

If the 3GPP AAA Server supports the "HSS Restoration" feature, it shall answer with a successful result to the PPR command, and it shall mark those users affected by the HSS restart as "pending to be restored in HSS".

The 3GPP AAA Server shall use the HSS Identity received in the Origin-Host AVP (by comparing it with the value stored after a successful MAA command) and may make use of the received "User List" Information Element in order to determine which subscriber records are impacted, if any. If the 3GPP AAA Server determines that there are no subscribers affected by the HSS restart, it shall answer with a successful result to the HSS.

8.1.2.4.2 HSS Restoration

8.1.2.4.2.1 General

This procedure is used by the 3GPP AAA Server to restore in the HSS the registration data and the dynamic data for a certain user. The 3GPP AAA Sever shall use this procedure only after having received a previous indication from HSS of a restart event affecting that user.

This procedure is mapped to the Diameter command codes Server-Assignment-Request (SAR) and Server-Assignment-Answer (SAA) specified in the 3GPP TS 29.229 [24]. Information element contents for these messages are shown in tables 8.1.2.4.2.1/1 and 8.1.2.4.2.1/2.

Table 8.1.2.4.2.1/1: HSS Restoration Request

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See IETF RFC 6733 [58])	M	This information element shall contain the IMSI of the user, for whom the registration data and dynamic data is being restored in HSS, and it shall be formatted according to 3GPP TS 23.003 [14], clause 2.2.
Server Assignment Type	Server-Assignment-Type	M	This IE shall contain the value "RESTORATION".
Active APN	Active-APN	C	This Information Element, if present, contains the list of active APNs stored by the 3GPP AAA Server for this user, including the identity of the PDN GW assigned to each APN. For the explicitly subscribed APNs, the following information shall be present: – Context-Identifier: context id of subscribed APN in use – Service-Selection: name of subscribed APN in use – MIP6-Agent-Info: including PDN GW identity in use for subscribed APN – Visited-Network-Identifier: identifies the PLMN where the PDN GW was allocated For the Wildcard APN, the following information shall be present: – Context-Identifier: context id of the Wildcard APN – Specific-APN-Info: list of APN-in use and related PDN GW identity when the subscribed APN is the wildcard APN
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.

Table 8.1.2.4.2.1/2: HSS Restoration Response

Information element name	Mapping to Diameter AVP	Cat.	Description
IMSI	User-Name (See IETF RFC 6733 [58])	M	This information element shall contain the user IMSI and shall be formatted according to 3GPP TS 23.003 [14], clause 2.2.
Registration result	Result-Code / Experimental-Result	M	This IE contains the result of the operation. The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]). The Experimental-Result AVP shall be used for SWx errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host.

8.1.2.4.2.2 HSS Detailed behaviour

Upon receipt of the SAR command, if the HSS supports the "HSS Restoration" feature, and the user’s IMSI is known, the HSS shall update the registration data (from the Origin-Host AVP received in the 3GPP AAA Server command) and dynamic data of the user (included in the "Active APN" Information Element), and answer with a successful result.

8.1.2.4.2.3 3GPP AAA Server Detailed behaviour

The 3GPP AAA Server shall use this command to update the HSS with the registration data and dynamic data it has for a user affected by the HSS restart, identified by the "User List" IE received previously in the PPR command, and marked in the 3GPP AAA Server as "pending to be restored in HSS". The 3GPP AAA Server shall only make use of this procedure in the HSS has indicated support for the "HSS Restoration" feature.

The 3GPP AAA Server shall invoke the SAR command towards the HSS, after having received further interactions over other reference points (S6b, STa, SWm …) for a user marked as "pending to be restored in HSS".

Once the 3GPP AAA Server receives confirmation from HSS, in the SAA command, that the user has been successfully restored in the HSS, via the "HSS Restoration Response" command, it shall clear the "pending to be restored in HSS" flag for that user.

8.2 Protocol Specification

8.2.1 General

The SWx reference point shall be Diameter based. This is defined as an IETF vendor specific Diameter application, where the Vendor ID is 3GPP. The Application Id used shall be 16777265.

8.2.2 Commands

8.2.2.1 Authentication Procedure

The Multimedia-Authentication-Request (MAR) command, indicated by the Command-Code field set to 303 and the ‘R’ bit set in the Command Flags field, is sent by the 3GPP AAA Server to the HSS in order to request security information. This corresponds to clause 8.1.2.1.

Message Format

< Multimedia-Auth-Request > ::= < Diameter Header: 303, REQ, PXY, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ User-Name }

[ RAT-Type ]

[ AN-Trusted ]

[ ANID ]

[ Visited-Network-Identifier]

[ Terminal-Information ]

{ SIP-Auth-Data-Item }

{ SIP-Number-Auth-Items }

[AAA-Failure-Indication ]

[ OC-Supported-Features ]

*[ Supported-Features ]

…

*[ AVP ]

The Multimedia-Authentication-Answer (MAA) command, indicated by the Command-Code field set to 303 and the ‘R’ bit cleared in the Command Flags field, is sent by a server in response to the Multimedia-Authentication-Request command. The Result-Code or Experimental-Result AVP may contain one of the values defined in clause 6.2 of 3GPP TS 29.229 [24] in addition to the values defined in IETF RFC 6733 [58].

Message Format

< Multimedia-Auth-Answer > ::= < Diameter Header: 303, PXY, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ User-Name}

[ SIP-Number-Auth-Items ]

*[ SIP-Auth-Data-Item ]

[ 3GPP-AAA-Server-Name ]

[ OC-Supported-Features ]

[ OC-OLR ] ]

*[ Load ]

*[ Supported-Features ]

…

*[ AVP ]

NOTE: As the Diameter commands described in this specification have been defined based on the former specification of the Diameter base protocol, the Vendor-Specific-Application-Id AVP is still listed as a required AVP (an AVP indicated as {AVP}) in the command code format specifications defined in this specification to avoid backward compatibility issues, even if the use of this AVP has been deprecated in the new specification of the Diameter base protocol (IETF RFC 6733 [58]).

8.2.2.2 HSS Initiated Update of User Profile Procedure

The Push-Profile-Request (PPR) command, indicated by the Command-Code field set to 305 and the ‘R’ bit set in the Command Flags field, is sent by the HSS to the 3GPP AAA Server in order to update the subscription data whenever a modification has occurred in the subscription data; this corresponds to clause 8.1.2.3. This command is also sent by HSS to indicate a restart event to the 3GPP AAA Server, so the registration data and the dynamic data previously stored in HSS can be restored; this corresponds to clause 8.1.2.4.1.

Message Format

< Push-Profile-Request > ::= < Diameter Header: 305, REQ, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Host }

{ Destination-Realm }

{ User-Name }

[ Non-3GPP-User-Data ]

[ PPR-Flags ]

*[ Supported-Features ]

…

*[ AVP ]

The Push-Profile-Answer (PPA) command, indicated by the Command-Code field set to 305 and the ‘R’ bit cleared in the Command Flags field, is sent by the HSS in response to the Push-Profile-Request command. The Result-Code or Experimental-Result AVP may contain one of the values defined in clause 6.2 of 3GPP TS 29.229 [24] in addition to the values defined in IETF RFC 6733 [58].

Message Format

< Push-Profile-Answer > ::= < Diameter Header: 305, PXY, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ Access-Network-Info ]

[ Local-Time-Zone ]

*[ Supported-Features ]

…

*[ AVP ]

8.2.2.3 Non-3GPP IP Access Registration Procedure

The Server-Assignment-Request (SAR) command, indicated by the Command-Code field set to 301 and the ‘R’ bit set in the Command Flags field, is sent by the 3GPP AAA Server to the HSS; this corresponds to clause 8.1.2.2.2. This command is also sent by the 3GPP AAA Server to restore the registration data and the dynamic data previously stored in HSS, which may have been lost after a restart; this corresponds to clause 8.1.2.4.2.

Message Format

< Server-Assignment-Request > ::= < Diameter Header: 301, REQ, PXY, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ Destination-Host ]

{ Destination-Realm }

[ Service-Selection ]

[ Context-Identifier ]

[ MIP6-Agent-Info ]

[ Visited-Network-Identifier ]

{ User-Name}

{ Server-Assignment-Type }

*[ Active-APN ]

[ OC-Supported-Features ]

*[ Supported-Features ]

[ Terminal-Information ]

[ Emergency-Services ]

…

*[ AVP ]

The Server-Assignment-Answer (SAA) command, indicated by the Command-Code field set to 301 and the ‘R’ bit cleared in the Command Flags field, is sent by the HSS to the 3GPP AAA Server to confirm the registration, de‑registration, user profile download or restoration procedure. The Result-Code or Experimental-Result AVP may contain one of the values defined in clause 6.2 of 3GPP TS 29.229 [24] in addition to the values defined in IETF RFC 6733 [58].

Message Format

< Server-Assignment-Answer > ::= < Diameter Header: 301, PXY, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ User-Name}

[ Non-3GPP-User-Data ]

[ 3GPP-AAA-Server-Name ]

[ OC-Supported-Features ]

[ OC-OLR ] ]

*[ Load ]

*[ Supported-Features ]

…

*[ AVP ]

8.2.2.4 Network Initiated De-Registration by HSS Procedure

The Registration-Termination-Request (RTR) command, indicated by the Command-Code field set to 304 and the "R" bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in order to request the de-registration of a user. This corresponds to clause 8.1.2.2.3.

Message Format

<Registration-Termination-Request> ::= < Diameter Header: 304, REQ, PXY, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Host }

{ Destination-Realm }

{ User-Name }

{ Deregistration-Reason }

*[ Supported-Features ]

…

*[ AVP ]

The Registration-Termination-Answer (RTA) command, indicated by the Command-Code field set to 304 and the "R" bit cleared in the Command Flags field, is sent by a client in response to the Registration-Termination-Request command. The Result-Code or Experimental-Result AVP may contain one of the values defined in clause 6.2 of 3GPP TS 29.229 [24] in addition to the values defined in IETF RFC 6733 [58].

Message Format

<Registration-Termination-Answer> ::= < Diameter Header: 304, PXY, 16777265 >

< Session-Id >

[ DRMP ]

{ Vendor-Specific-Application-Id }

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

*[ Supported-Features ]

…

*[ AVP ]

8.2.3 Information Elements

8.2.3.0 General

The following table describes the Diameter AVPs defined for the SWx interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted.

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.2.3.0/1: Diameter SWx AVPs

				AVP Flag rules
Attribute Name	AVP Code	Clause defined	Value Type	Must	May	Should not	Must not
Non-3GPP-User-Data	1500	8.2.3.1	Grouped	M,V			P
Non-3GPP-IP-Access	1501	8.2.3.3	Enumerated	M,V			P
Non-3GPP-IP-Access-APN	1502	8.2.3.4	Enumerated	M,V			P
ANID	1504	5.2.3.7	UTF8String	M,V			P
Trace-Info	1505	8.2.3.13	Grouped	V			M,P
PPR-Flags	1508	8.2.3.17	Unsigned32	V			M,P
TWAN-Default-APN-Context-Id	1512	8.2.3.18	Unsigned32	V			M,P
TWAN-Access-Info	1510	8.2.3.19	Grouped	V			M,P
Access-Authorization-Flags	1511	8.2.3.20	Unsigned32	V			M,P
WLAN-Identifier	1509	5.2.3.18	Grouped	V			M,P
Service-Selection	493	5.2.3.5	UTF8String	M			V,P
AAA-Failure-Indication	1518	8.2.3.21	Unsigned32	V			M,P
Access-Network-Info	1524	5.2.3.24	Grouped	V			M,P
3GPP-AAA-Server-Name	318	8.2.3.24	DiameterIdentity	M, V			P
ERP-Authorization	1541	8.2.3.27	Unsigned32	V			M,P
AN-Trusted	1503	5.2.3.9	Enumerated	V			M,P
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 ETF RFC 6733 [58]. 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 describes the Diameter AVPs re-used by the SWx interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within SWx. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol (see IETF RFC 6733 [58]), do not need to be supported.

Table 8.2.3.0/2: SWx re-used Diameter AVPs

Attribute Name	Reference	Comments
User-Name	ETF RFC 6733 [58]
Session-Timeout	ETF RFC 6733 [58]
Subscription-ID	IETF RFC 4006 [20]
MIP6-Agent-Info	IETF RFC 5447 [6]
MIP6-Feature-Vector	IETF RFC 5447 [6]
Service-Selection	IETF RFC 5778 [11]
3GPP-Charging-Characteristics	3GPP TS 29.061 [31]
RAT-Type	3GPP TS 29.212 [23]
Visited-Network-Identifier	3GPP TS 29.229 [24]
SIP-Number-Auth-Items	3GPP TS 29.229 [24]
SIP-Item-Number	3GPP TS 29.229 [24]
SIP-Auth-Data-Item	3GPP TS 29.229 [24]
SIP-Authentication-Scheme	3GPP TS 29.229 [24]
SIP-Authenticate	3GPP TS 29.229 [24]
SIP-Authorization	3GPP TS 29.229 [24]
Confidentiality-Key	3GPP TS 29.229 [24]
Integrity-Key	3GPP TS 29.229 [24]
Server-Assignment-Type	3GPP TS 29.229 [24]
Deregistration-Reason	3GPP TS 29.229 [24]
Supported-Features	3GPP TS 29.229 [24]
Feature-List-ID	3GPP TS 29.229 [24]
Feature-List	3GPP TS 29.229 [24]
APN-Configuration	3GPP TS 29.272 [29]
Context-Identifier	3GPP TS 29.272 [29]
Terminal-Information	3GPP TS 29.272 [29]
AMBR	3GPP TS 29.272 [29]
APN-OI-Replacement	3GPP TS 29.272 [29]
Trace-Reference	3GPP TS 29.272 [29]
Trace-Data	3GPP TS 29.272 [29]
Active-APN	3GPP TS 29.272 [29]
BSSID	3GPP TS 32.299 [30]
Location-Information	IETF RFC 5580 [46]
Location-Data	IETF RFC 5580 [46]
Operator-Name	IETF RFC 5580 [46]
Local-Time-Zone	3GPP TS 29.272 [29]
OC-Supported-Features	IETF RFC 7683 [47]	See clause 8.2.3.22	Must not set
OC-OLR	IETF RFC 7683 [47]	See clause 8.2.3.23	Must not set
DRMP	IETF RFC 7944 [53]	See clause 8.2.3.25	Must not set
Emergency-Info	3GPP TS 29.272 [29]
Load	IETF RFC 8583 [54]	See clause 8.2.3.26	Must not set
UE-Usage-Type	3GPP TS 29.272 [29]
Core-Network-Restrictions	3GPP TS 29.272 [29]
NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit.

Only those AVP initially defined in this reference point or AVP with values initially defined in this reference point and for this procedure are described in the following clauses.

8.2.3.1 Non-3GPP-User-Data

The Non-3GPP-User-Data AVP is of type Grouped. It contains the information related to the user profile relevant for EPS.

AVP format:

Non-3GPP-User-Data ::= < AVP Header: 1500 10415 >

[ Subscription-ID ]

[ Non-3GPP-IP-Access ]

[ Non-3GPP-IP-Access-APN ]

*[ RAT-Type ]

[ Session-Timeout ]

[ MIP6-Feature-Vector ]

[ AMBR ]

[ 3GPP-Charging-Characteristics ]

[ Context-Identifier ]

[ APN-OI-Replacement ]

*[ APN-Configuration ]

[ Trace-Info ]

[ TWAN-Default-APN-Context-Id ]

*[ TWAN-Access-Info]

[ UE-Usage-Type ]

[ Emergency-Info ]

[ ERP-Authorization ]

[ Core-Network-Restrictions ]

*[ AVP ]

The Subscription-ID, if present in this grouped AVP, shall contain either an MSISDN (if this identity is present in the subscription), or an External Identifier (if the subscriber does not have an MSISDN identity but has an External Identifier in the subscription).

The AMBR included in this grouped AVP shall include the AMBR associated to the user’s subscription (UE-AMBR).

The APN-OI-Replacement included in this grouped AVP shall include the UE level APN-OI-Replacement associated to the user’s subscription. This APN-OI-Replacement has lower priority than APN level APN-OI-Replacement that is included in the APN-Configuration AVP.

The Non-3GPP-User-Data AVP shall only contain APN-Configuration AVP(s) configured in the user subscription with an IP PDN type.

The Context-Identifier in this grouped AVP shall identify the user’s default APN configuration. The TWAN-Default-APN-Context-Id AVP identifies the default APN configuration for EPC access over Trusted WLAN. This AVP shall be present if the default APN configuration for EPC access over Trusted WLAN differs from the default APN configuration for 3GPP access and other non-3GPP accesses. This AVP may be present otherwise.

The RAT-Type AVP(s) shall include the access technology type(s) not allowed for the user as specified in clause 2.13.126 of 3GPP TS 23.008 [49].

The Emergency-Info AVP shall contain the identity of the PDN-GW used for the establishment of emergency PDN connections.

The MIP6-Feature-Vector may provide HSM and/or NBM authorization information (see clause 8.2.3.28).

For the conditions specified in clause 8.1.2.3.2, the Non-3GPP-User-Data AVP shall be empty, i.e. not include any AVP.

If the Non-3GPP-User-Data AVP is not empty, the Non-3GPP-IP-Acess AVP, the Non-3GPP-IP-Access-APN AVP, the Context-Identifier AVP and at least one item of the APN-Configuration AVP shall always be included, except when the Non-3GPP-User-Data AVP is used for downloading trace activation or deactivation information on the SWx interface, for an already registered user, or when the Non-3GPP-User-Data is used for downloading the Emergency-Info. In those specific cases, the Trace-Info AVP, or respectively the Emergency-Info AVP, shall be included and the presence of any further AVPs is optional.

8.2.3.2 Subscription-ID

The Subscription-ID AVP is of type Grouped and indicates the user identity to be used for charging purposes. It is defined in the IETF RFC 4006 [20]. EPC shall make use only of the MSISDN and External Identifier values.

When the identity to be conveyed is an MSISDN, the AVP Subscription-Id-Type shall be set to value "END_USER_E164".

When the identity to be conveyed is an External Identifier, the AVP Subscription-Id-Type shall be set to value "END_USER_NAI".

Then AVP Subscription-Id-Data, with type UTF8String, shall contain the identity of the user.

AVP format:

Subscription-Id ::= < AVP Header: 443 >

[ Subscription-Id-Type ]

[ Subscription-Id-Data ]

8.2.3.3 Non-3GPP-IP-Access

The Non-3GPP-IP-Access AVP (AVP code 1501) is of type Enumerated, and allows operators to determine if the subscriber is barred from using the non-3GPP access network. The following values are defined:

NON_3GPP_SUBSCRIPTION_ALLOWED (0)

The subscriber has non-3GPP subscription and is authorized to use the non-3GPP access network.

NON_3GPP_SUBSCRIPTION_BARRED (1)

The subscriber is barred from using the non-3GPP access network.

8.2.3.4 Non-3GPP-IP-Access-APN

The Non-3GPP-IP-Access-APN AVP (AVP code 1502) is of type Enumerated, and allows operator to disable all APNs for a subscriber at one time. The following values are defined:

Non_3GPP_APNS_ENABLE (0)

Enable all APNs for a subscriber.

Non_3GPP_APNS_DISABLE (1)

Disable all APNs for a subscriber

8.2.3.5 RAT-Type

The RAT-Type AVP (AVP code 1032) is of type Enumerated. The encoding of the AVP is specified in 3GPP TS 29.212 [23].

8.2.3.6 Session-Timeout

The Session-Timeout AVP is of type Unsigned32. It is defined in IETF RFC 6733 [58] and indicates the maximum period for a session measured in seconds. This AVP is used for re-authentication purposes. If this field is not used, the non-3GPP Access Node will apply default time intervals.

8.2.3.7 APN-Configuration

The APN-Configuration AVP is of type Grouped AVP and is defined in 3GPP TS 29.272 [29].

The following AVPs defined in the APN-Configuration AVP in 3GPP TS 29.272 [29] are not applicable to Non-3GPP accesses and therefore need not be included in the APN-Configuration AVP over the SWx, SWd, SWm, STa and S6b reference points:

– LIPA-Permission AVP

– Restoration-Priority AVP

– SIPTO-Local-Network-Permission AVP

– WLAN-offloadability AVP

– Non-IP-PDN-Type-Indicator AVP

– Non-IP-Data-Delivery-Mechanism AVP

– SCEF-ID AVP

– SCEF-Realm AVP

– Preferred-Data-Mode AVP

8.2.3.8 ANID

The ANID AVP is defined in clause 5.2.3.7.

8.2.3.9 SIP-Auth-Data-Item

The SIP-Auth-Data-Item AVP is defined in 3GPP TS 29.229 [24]. The optional AVPs that are needed in SWx reference point are included in the ABNF representation below.

AVP format:

SIP-Auth-Data-Item ::= < AVP Header: 612 10415 >

[ SIP-Item-Number ]

[ SIP-Authentication-Scheme ]

[ SIP-Authenticate ]

[ SIP-Authorization ]

[ Confidentiality-Key ]

[ Integrity-Key ]

*[ AVP ]

8.2.3.10 Confidentiality-Key

The Confidentiality-Key AVP is defined in 3GPP TS 29.229 [24]. It is of type OctetString, and contains the Confidentiality Key (CK’) or, after key derivation using the Access Network Identifier, the Confidentiality Key (CK’). For the 3GPP AAA server it is transparent whether the value received corresponds to CK or CK’.

8.2.3.11 Integrity-Key

The Integrity-Key AVP is defined in 3GPP TS 29.229 [24]. It is of type OctetString, and contains the Integrity Key (IK) or, after key derivation using the Access Network Identifier, the Integrity Key (IK’). For the 3GPP AAA server it is transparent whether the value received corresponds to IK or IK’.

8.2.3.12 Server-Assignment-Type AVP

The Server-Assignment-Type AVP is defined in 3GPP TS 29.229 [24] and it is of type Enumerated, and indicates the type of server update being performed in a Server-Assignment-Request operation. As part of the SWx protocol specification, the following values are additionally defined:

AAA_USER_DATA_REQUEST (12)

This value is used to request the non-3GPP user profile data from the 3GPP AAA Server to the HSS.

PGW_UPDATE (13)

This value is used to store, update or delete the PDN-GW Identity in the HSS, as requested from the 3GPP AAA Server.

RESTORATION (14)

This value is used to store in the HSS registration data and dynamic data that may have been potentially lost after a restart event.

8.2.3.13 Trace-Info

The Trace-Info AVP is of type Grouped. This AVP shall contain the information related to subscriber and equipment trace function and the required action, i.e. activation of deactivation

AVP format

Trace-Info ::= < AVP header: 1505 10415>

[Trace-Data]

[Trace-Reference]

*[AVP]

Either the Trace-Data or the Trace-Reference AVP shall be included. When trace activation is needed, Trace-Data AVP shall be included, while the trace deactivation request shall be signalled by including the Trace-Reference directly under the Trace-Info. The Trace-Reference AVP is of type OctetString. The Diameter AVP is defined in 3GPP TS 29.272 [29].

8.2.3.14 Trace-Data

The Trace-Data AVP is of type Grouped. The Diameter AVP is defined in 3GPP TS 29.272 [29].

8.2.3.15 Feature-List-ID AVP

The syntax of this AVP is defined in 3GPP TS 29.229 [24]. For this release, the Feature-List-ID AVP value shall be set to 1 for the SWx application.

8.2.3.16 Feature-List AVP

The syntax of this AVP is defined in 3GPP TS 29.229 [24]. A null value indicates that there is no feature used by the SWx application. The meaning of the bits shall be as defined in table 8.2.3.16/1.

Table 8.2.3.16/1: Features of Feature-List-ID 1 used in SWx

Feature bit	Feature	M/O	Description
0	HSS Restoration	O	HSS Restoration This feature is applicable for the MAR/MAA, PPR/PPA and SAR/SAA command pairs. If the 3GPP AAA Server does not indicate support for this feature in a former MAR or SAR command, the HSS shall not send a PPR command to indicate a restart event to the 3GPP AAA Server.
1	Access-Network-Information-Retrieval	O	Access Network Information Retrieval This feature is applicable for the MAR/MAA and PPR/PPA and SAR/SAA command pairs. If the 3GPP AAA Server does not indicate support for this feature in a former MAR or SAR command, the HSS shall not send a PPR command to request access network information from the 3GPP AAA Server.
2	UE Local Time Zone Retrieval	O	UE Local Time Zone Retrieval This feature is applicable for the MAR/MAA and PPR/PPA and SAR/SAA command pairs. If the 3GPP AAA Server does not indicate support for this feature in a former MAR or SAR command, the HSS shall not send a PPR command to request the local time zone of the UE from the 3GPP AAA Server.
3	P-CSCF Restoration for WLAN	O	Support of P-CSCF Restoration for WLAN This feature is applicable to the MAR/MAA and PPR/PPA and SAR/SAA command pairs over the SWx interface, when the 3GPP AAA Server supports the execution of the P-CSCF restoration procedures for WLAN as described in 3GPP TS 23.380 [52] clause 5.6. If the 3GPP AAA Server does not indicate support of this feature in a former MAR or SAR command, the HSS shall not send a PPR command requesting the execution of HSS-based P-CSCF restoration procedures for WLAN,
4	Emergency Services Continuity	O	Support of Emergency Services Continuity This feature is applicable to the PPR/PPA and SAR/SAA command pairs over the SWx interface, when the HSS and the 3GPP AAA Server support the continuity of emergency services upon mobility between 3GPP and WLAN accesses, as specified in clause 4.5.7.2 of 3GPP TS 23.402 [3]. If the 3GPP AAA Server does not indicate support of this feature in a former SAR command, the HSS shall not include the Emergency Info in a SAA command and shall not send a PPR command to update the Emergency Info. If the HSS does not indicate support of this feature in a former SAA command (e.g. during the registration of the non-3GPP user), the 3GPP AAA Server shall not send a SAR command to update the Emergency Info. If the HSS supports this feature on SWx, it shall also support the Emergency Service Continuity feature on S6a, see 3GPP TS 29.272 [29].
5	ERP	O	Support of EAP Reauthentication Protocol This feature is applicable to the MAR/MAA and PPR/PPA command pairs over the SWx interface. If the 3GPP AAA Server does not indicate support of this feature in a former MAR command, the HSS shall not include ERP authorization data in the subscription profile, and it shall not send subsequent PPR commands to update the ERP authorization status of this user. If the HSS does not indicate support of this feature in the MAA command, the 3GPP AAA Server shall not expect the reception of explicit authorization of ERP in the subscription profile, and may allow/disallow ERP for all subscribers, according to local policy.
6	Dedicated Core Networks	O	Support of Dedicated Core Networks This feature is applicable to the SAR/SAA and PPR/PPA command pairs over the SWx interface. If the 3GPP AAA Server does not indicate support of this feature in the SAR command, the HSS shall not send DCN-related subscription data (e.g., UE Usage Type) in SAA, and shall not send subsequent PPR commands when such subscription data are updated. If the 3GPP AAA Server does not indicate support of this feature in the PPA command and the HSS has already sent DCN-related subscription data in PPR, the HSS may store this indication and not send further updates related to DCN subscription data.
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. M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O"). Description: A clear textual description of the feature.

Features that are not indicated in the Supported-Features AVPs within a given application message shall not be used to construct that message.

8.2.3.17 PPR-Flags

The PPR-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.2.3.17/1:

Table 8.2.3.17/1: PPR-Flags

Bit	Name	Description
0	Reset-Indication	This bit, when set, indicates that the HSS has undergone a restart event and the registration data and dynamic data needs to be restored, if available at the 3GPP AAA Server.
1	Access-Network-Info-Request	This bit, when set, indicates that the HSS requests the 3GPP AAA Server the identity and location information of the access network where the UE is currently attached.
2	UE-Local-Time-Zone-Request	This bit, when set, indicates that the HSS requests the 3GPP AAA Server the time zone of the location in the access network where the UE is attached.
3	P-CSCF Restoration Request	This bit, when set, indicates to the 3GPP AAA Server that the HSS requests the execution of the HSS-based P-CSCF restoration procedures for WLAN, as described in 3GPP TS 23.380 [52] clause 5.6.
NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving 3GPP AAA Server.

8.2.3.18 TWAN-Default-APN-Context-Id

The TWAN-Default-APN-Context-Id AVP is of the type Unsigned32 and shall identify the context identifier of the subscriber’s default APN to be used for Trusted WLAN access to EPC over S2a.

Note: The default APN for Trusted WLAN access to EPC over S2a can differ from the default APN for 3GPP and other non-3GPP accesses.

8.2.3.19 TWAN-Access-Info

The TWAN-Access-Info AVP is of type Grouped.

If no WLAN-Identifier AVP is included in the TWAN-Access-Info AVP, the allowed access methods shall apply to any arbitrary Trusted WLAN. See clause 5.1.2.1.2.

If the Access-Authorization-Flags AVP is not present in the TWAN-Access-Info AVP, EPC access and Non-Seamless WLAN Offload shall be considered to be not allowed.

A specific Trusted-WLAN shall appear in at most one TWAN-Access-Info AVP.

There shall be at most one TWAN-Access-Info AVP not including any WLAN-Identifier.

AVP Format:

TWAN-Access-Info::= < AVP Header: 1510 10415 >

[ Access-Authorization-Flags ]

[ WLAN-Identifier ]

*[ AVP ]

8.2.3.20 Access-Authorization-Flags

The Access-Authorization-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.2.3.20/1:

Table 8.2.3.20/1: Access-Authorization-Flags

Bit	Name	Description
0	EPC-Access-Authorization	This bit, when set, indicates that the UE is allowed to access the EPC when connected via Trusted WLAN access. This flag, when not set, indicates that the UE is not allowed to access EPC when connected via Trusted WLAN access.
1	NSWO-Access-Authorization	This bit, when set, indicates that the UE is allowed Non-Seamless WLAN Offload access via Trusted WLAN access. This flag, when not set, indicates that the UE is not allowed to Non-Seamless WLAN Offload via Trusted WLAN access.
NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving 3GPP AAA Server.

NOTE: UE is allowed to access the EPC when connected via Trusted WLAN access only if the Non-3GPP-IP-Access-APN AVP does not disable all APNs and the EPC-Access-Authorization bit is set.

8.2.3.21 AAA-Failure-Indication

The AAA-Failure-Indication AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 8.2.3.21/1:

Table 8.2.3.21/1: AAA-Failure-Indication

Bit	Name	Description
0	AAA Failure	This bit, when set, indicates that a previously assigned 3GPP AAA Server is unavailable.
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver.

8.2.3.22 OC-Supported-Features

The OC-Supported-Features AVP is of type Grouped and it is defined in IETF RFC 7683 [47]. This AVP is used to support Diameter overload control mechanism, see Annex B for more information.

8.2.3.23 OC-OLR

The OC-OLR AVP is of type Grouped and it is defined in IETF RFC 7683 [47]. This AVP is used to support Diameter overload control mechanism, see Annex B for more information.

8.2.3.24 3GPP-AAA-Server-Name

The 3GPP-AAA-Server-Name AVP is of type DiameterIdentity, and defines the Diameter address of the 3GPP AAA Server node.

8.2.3.25 DRMP

The DRMP AVP is of type Enumerated and is defined in IETF RFC 7944 [53]. This AVP allows the 3GPP functional entities 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.2.3.26 Load

The Load AVP is of type Grouped and it is defined in IETF RFC 8583 [54]. This AVP is used to support Diameter load control mechanism, see Annex E for more information.

8.2.3.27 ERP-Authorization

The ERP-Authorization AVP is of type Unsigned32 and it indicates whether the subscriber is authorized, or not, to make use of the EAP Reauthentication Protocol. The following values are defined:

ERP_NOT_AUTHORIZED (0)

ERP_AUTHORIZED (1)

8.2.3.28 MIP6-Feature-Vector

The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and contains a 64 bit flags field of the mobile IP capabilities authorized by the HSS.

The following capabilities are defined for the SWx interface:

– MIP6_INTEGRATED (0x0000000000000001)
This flag means that DSMIPv6 is authorized.

– PMIP6_SUPPORTED (0x0000010000000000)
This flag means that NBM is authorized.

– MIP4_SUPPORTED (0x0000100000000000)
This flag means that MIPv4 is authorized.

– GTPv2_SUPPORTED (0x0000400000000000)
This flag means that NBM is authorized.

NBM shall be considered as authorized if at least one of the PMIP6_SUPPORTED and GTPv2_SUPPORTED flag is set.

NOTE: The selection of the protocol variant (GTPv2 or PMIPv6) on S2a/S2b is determined solely by the TWAN/ePDG. It does not matter whether the HSS sets the PMIP6_SUPPORTED and/or GTPv2_SUPPORTED flags to authorize NBM.

Based on operator policy, the 3GPP AAA Server may also authorize the use of NBM, irrespective of the presence or content of the MIP6-Feature-Vector AVP in the Non-3GPP User Data.

8.2.4 Session Handling

The Diameter protocol between the 3GPP AAA Server and the HSS shall not keep the session state and each Diameter request/response interaction shall be transported over a different diameter session which is implicitly terminated.

In order to indicate that session state shall not be maintained, the diameter client and server shall include the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 [58]. 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.3 User identity to HSS resolution

The User identity to HSS resolution mechanism enables the 3GPP AAA server to find the identity of the HSS that holds the subscriber data for a given user identity when multiple and separately addressable HSSs have been deployed by the network operator. The resolution mechanism is not required in networks that utilise a single HSS or when a 3GPP AAA server is configured to use pre-defined HSS address/identity.

This User identity to HSS resolution mechanism may rely on routing capabilitites 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. If this Diameter based implementation is selected by the Home network operator, the principles described below shall apply.

In networks where more than one independently addressable HSS are utilized by a network operator, and the 3GPP AAA server is not configured to use pre-defined HSS address/identity, each 3GPP AAA server shall be configured with the address/identity of the Diameter Agent (Redirect Agent or Proxy Agent) implementing this resolution mechanism.

To get the HSS identity that holds the subscriber data for a given user identity, the 3GPP AAA server shall send the Diameter request normally destined to the HSS to a pre-configured address/identity of a Diameter agent supporting the User identity to HSS resolution mechanism.

– If this Diameter request is received by a Diameter Redirect Agent, the Diameter Redirect Agent shall determine the HSS identity based on the provided user identity and sends to the 3GPP AAA server a notification of redirection towards the HSS identity, in response to the Diameter request. Multiple HSS identities may be included in the response from the Diameter Redirect Agent, as specified in IETF RFC 6733 [58]. In such a case, the 3GPP AAA server shall send the Diameter request to the first HSS identity in the ordered list received in the Diameter response from the Diameter Redirect Agent. If no successful response to the Diameter request is received, the 3GPP AAA server shall send a Diameter request to the next HSS identity in the ordered list. This procedure shall be repeated until a successful response from an HSS is received.

– If this Diameter request is received by a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the HSS identity based on the provided user identity and – if the Diameter load control mechanism is supported (see IETF RFC 8583 [54]) – optionally also based on previously received load values from Load AVPs of type HOST. The Diameter Proxy Agent shall then forward the Diameter request directly to the determined HSS. The 3GPP AAA server shall determine the HSS identity from the response to the Diameter request received from the HSS.

After the User identity to HSS resolution, the 3GPP AAA server shall store the HSS identity/name/Realm and shall use it in further Diameter requests associated to the same user dentity.

NOTE: Alternatives to the user identity to HSS resolution Diameter based implementation are outside the scope of this specification.