7 SWm Description

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

7.1 Functionality

7.1.1 General

The SWm reference point is defined between the ePDG and the 3GPP AAA Server or between the ePDG and the 3GPP AAA Proxy. The definition of the reference point and its functionality is given in 3GPP TS 23.402 [3].

The SWm reference point shall be used to authenticate and authorize the UE.

The SWm reference point is also used to transport NBM related mobility parameters in a case the UE attaches to the EPC via the S2b (based on PMIPv6 or GTPv2) and SWn reference points (i.e. IP Mobility Mode Selection information).

Additionally the SWm reference point may also be used to transport DSMIPv6 related mobility parameters in case the UE attaches to the EPC using the S2c reference point. In particular, in this case the SWm reference point may be used for conveying the Home Agent IP address or FQDN from the AAA server to the ePDG for Home Agent discovery based on IKEv2 (see TS 24.303 [13]).

7.1.2 Procedures Description

7.1.2.1 Authentication and Authorization Procedures

7.1.2.1.1 General

The authentication and authorization procedure shall be used between the ePDG and 3GPP AAA Server/Proxy. When a PDN connection is activated by the UE an IKEv2 exchange shall be initiated. It shall be invoked by the ePDG, on receipt from the UE of a "tunnel establishment request" message. This shall take the form of forwarding an IKEv2 exchange with the purpose of authenticating in order to set up an IKE Security Association (SA) between the UE and the ePDG.

During the Access Authentication and Authorization procedure the ePDG may provide information on its PMIPv6 or GTPv2 capabilities to the 3GPP AAA Server. The 3GPP AAA Server may perform IP mobility mode selection between NBM or HBM as specified in clause 4.1.3.2 of 3GPP TS 23.402 [3]. The 3GPP AAA Server may provide to the ePDG an indication if either NBM or local IP address assignment shall be used. If NBM shall be used, the ePDG then decides the S2b protocol variant to use.

The User-Name AVP may contain a decorated NAI (as defined in clause 19.3.3 of 3GPP TS 23.003 [14]). In this case the 3GPP AAA Proxy shall process the decorated NAI and support routing of the Diameter request messages based on the decorated NAI as described in IETF RFC 5729 [37].

Upon a successful authorization, when NBM is used, the 3GPP AAA server shall return NBM related information back to the ePDG. This information may include the assigned PDN GW, UE IPv6 HNP and/or UE IPv4-HoA.

Upon a successful authorization, when DSMIPv6 is used, to enable HA address discovery based on IKEv2 (see TS 24.303 [13]), the 3GPP AAA server may also download PDN GW identity to the ePDG.

The PDN GW identity is a FQDN and/or IP address of the PDN GW. If a FQDN is provided, the ePDG shall derive it to IP address according to the selected mobility management protocol.

If DSMIPv6 is used, a single IKE SA is used for all PDN connections of the user. If PMIPv6 or GTPv2 is used, a separate IKE SA is created for each PDN connection of the user (refer to 3GPP TS 24.302 [26]).

Each new additional IKE SA shall be handled in a different Diameter session. In such cases, the IP mobility mode selected during the first authentication and authorization procedure is valid for all PDN connections of the user, therefore, dynamic IP mobility mode selection is not executed during the further procedures. The ePDG may select the same or different S2b protocol variant(s) towards different PDN GWs when NBM has been selected.

Based on local policies, EPC access for emergency services over an untrusted WLAN access is supported as specified in clause 4.5.7.2.1 of 3GPP TS 23.402 [3] for:

– UEs with a valid EPC subscription that are authenticated and authorized for EPC services;

– UEs that are authenticated only;

– UEs with an unauthenticated IMSI; and/or

– UICC-less UEs.

The SWm reference point shall perform authentication and authorization based on the reuse of the DER/DEA command set defined in Diameter EAP application, IETF RFC 4072 [5].

Table 7.1.2.1.1/1: Authentication and Authorization Request

Information element name

Mapping to Diameter AVP

Cat.

Description

User Identity

User-Name

M

This information element shall contain the identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes, if it contains a NAI other than an Emergency NAI for Limited Service State.

EAP payload

EAP-Payload

M

This information element shall contain the encapsulated EAP payload used for the UE – 3GPP AAA Server mutual authentication

Authentication Request Type

Auth-Request- Type

M

This information element shall indicate whether the user is to be authenticated only, authorized only or both. It shall have the value of AUTHORIZE_AUTHENTICATE.

APN

Service-Selection

C

This information element shall contain the Network Identifier part of the APN for which the UE is requesting authorization. This AVP shall be present if the ePDG has received an APN from the UE and the UE did not indicate the establishment of an emergency session in the IKEv2 signalling. This AVP shall be absent if the UE indicated the establishment of an emergency session during the IKEv2 tunnel establishment (see clause 7.2.5 of 3GPP TS 24.302 [26]).

Visited Network Identifier (See 9.2.3.1.2)

Visited-Network-Identifier

C

This information element shall contain the identifier that allows the home network to identify the Visited Network.

This AVP shall be present if the ePDG is not in the UE’s home network i.e. the UE is roaming.

Access Type

RAT-Type

C

This information element shall be present if the access type is known by the ePDG. If present, it shall contain the non-3GPP access network access technology type that is serving the UE. When not known by the ePDG, this information element should be present and, in that case, it shall take the value VIRTUAL (1).

Mobility features

MIP6-Feature-Vector

O

This AVP shall be present, if the handling of any of the flags listed here requires dynamic (i.e. per user) handling for the VPLMN-HPLMN relation of the ePDG and 3GPP AAA Server. If present, the AVP shall contain the mobility features supported by the ePDG. Flags that are not relevant in the actual relation shall be set to zero.

If dynamic IP mobility mode selection is used, the PMIP6_SUPPORTED flag and/or the GTPv2_SUPPORTED flag shall be set by the ePDG if PMIPv6 and/or GTPv2 are supported. PMIP6_SUPPORTED flag is defined in IETF RFC 5779 [2].

The MIP6_INTEGRATED flag shall be used to indicate to the 3GPP AAA server that the ePDG supports IKEv2 based Home Agent address discovery.

AAA Failure Indication

AAA-Failure-Indication

O

If present, this information element shall indicate that the request is sent after the ePDG has determined that a previously assigned 3GPP AAA Server 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 for the lifetime of the Diameter session.

UE local IP address

UE-Local-IP-Address

O

The ePDG shall include this IE based on local policy for Fixed Broadband access network interworking as specified in 3GPP TS 23.139 [39].

The ePDG may also include this IE, regardless of Fixed Broadband access network interworking.

If present, it shall contain the source IPv4 or IPv6 address of the IKE_SA_AUTH message from the UE.

Terminal Information

Terminal-Information

C

The ePDG shall include this IE and set it to the user’s Mobile Equipment Identity, if this information is available.

For an untrusted WLAN access, this grouped AVP shall contain the IMEI AVP and, if available, the Software-Version AVP.

When the RAT type is not known by the ePDG, 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

An ePDG which supports emergency services shall include this information element, with the Emergency-Indication bit set, if the UE indicated the establishment of an emergency session during the IKEv2 tunnel establishment (see clause 7.2.5 of 3GPP TS 24.302 [26]).

Table 7.1.2.1.1/2: Authentication and Authorization Answer

Information element name

Mapping to Diameter AVP

Cat.

Description

User Identity

User-Name

O

This information element, if present, shall contain the identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes, if it contains a NAI other than an Emergency NAI for Limited Service State.

EAP payload

EAP-Payload

O

If present, this information element shall contain the encapsulated EAP payload used for UE – 3GPP AAA Server mutual authentication

Master-Session-Key

EAP-Master-Session-Key

C

This IE shall contain keying material for protecting the communication between the user and the ePDG. It shall be present when Result Code is set to DIAMETER_SUCCESS.

Authentication Request Type

Auth-Request-Type

M

It shall contain the value AUTHORIZE_AUTHENTICATE. See IETF RFC 4072 [5].

Result code

Result-Code / Experimental-Result-Code

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]) or as per in NASREQ (see IETF RFC 4005 [4].

3GPP AAA Server URI

Redirect-Host

C

This information element shall be sent if the Result-Code value is set to DIAMETER_REDIRECT_INDICATION. When the user has previously been authenticated by another 3GPP AAA Server, it shall contain the Diameter URI of the 3GPP AAA Server currently serving the user. The node receiving this IE shall behave as defined in the Diameter base protocol (see IETF RFC 6733 [58]). The command shall contain zero or more occurrences of this information element. When choosing a destination for the redirected message from multiple Redirect-Host AVPs, the receiver shall send the Diameter request to the first 3GPP AAA Server in the ordered list received in the Diameter response. If no successful response to the Diameter request is received, the receiver shall send the Diameter request to the next 3GPP AAA Server in the ordered list. This procedure shall be repeated until a successful response is received from a 3GPP AAA Server.

Mobility Capabilities

MIP6-Feature-Vector

O

This AVP shall be present if it was received in the authentication and authorization request and the authentication and authorization succeeded. It shall contain the authorized mobility features. Flags that are not relevant in the actual relation shall be set to zero.

The PMIP6_SUPPORTED flag and/or the GTPv2_SUPPORTED flag shall be set to indicate that NBM (PMIPv6 or GTPv2) is to be used. The ASSIGN_LOCAL_IP flag shall be set to indicate that a local IP address is to be assigned.

The MIP6_INTEGRATED flag shall be set if a Home Agent address is provided for IKEv2 based Home Agent address discovery. In the latter case HA information for IKEv2 discovery is provided via the APN-Configuration AVP.

APN-OI replacement

APN-OI-Replacement

C

This AVP shall indicate the domain name to replace the APN-OI in the non-roaming case or in the home routed roaming case when constructing the PDN GW FQDN upon which it needs to perform a DNS resolution. See 3GPP TS 23.003 [3]. It shall only be included if NBM is used, the Emergency-Indication bit of the Emergency-Services AVP is not set in the Authentication and Authorization Request and the Result-Code AVP is set to DIAMETER_SUCCESS.

APN and PGW Data

APN-Configuration

C

This information element shall only be sent if the Result-Code AVP is set to DIAMETER_SUCCESS and the Emergency-Indication bit of the Emergency-Services AVP is not set in the Authentication and Authorization Request.

The APN-Configuration is a grouped AVP, defined in 3GPP TS 29.272 [29]. When NBM is used, the following information elements per APN may be included:

– APN

– APN-AMBR

– Authorized 3GPP QoS Profile

– User home IP Address (if static IPv4 and/or IPv6 is allocated to the UE’s subscribed APN)

– Allowed PDN types

– PDN GW identity (if the PDN connection was active in case of HO, or if there is a static PDN GW allocated to the UE’s subscribed APN)

– PDN GW allocation type

– VPLMN Dynamic Address Allowed

– Visited Network Identifier

– Interworking-5GS-Indicator

When local IP address assignment is used, this AVP shall only be present if IKEv2 based Home Agent discovery is used and

– if the PDN connection was active in case of HO, or

– if there is static PDN GW allocated to the UE’s subscribed APN, or

– if the 3GPP AAA Server/Proxy selects the PDN GW based on the identity of the ePDG

In these cases, the following information elements shall be included:

– HA-APN (Home Agent APN as defined in 3GPP TS 23.003 [14])

– PDN GW identity

NOTE 1.

Trace information

Trace-Info

C

This AVP shall be included if the subscriber and equipment trace has been activated for the user in the HSS and signalling based activation is used to download the trace activation from the HSS to the ePDG.

Only the Trace-Data AVP shall be included to the Trace-Info AVP and

shall contain the following AVPs:

– Trace-Reference

– Trace-Depth

– Trace-Event-List, for PGW

– Trace-Collection-Entity

The following AVPs may also be included in the Trace-Data AVP:

– Trace-Interface-List, for PGW, if this AVP is not present, trace report generation is requested for all interfaces for PGW listed in 3GPP TS 32.422 [32]

– Trace-NE-Type-List, with the only allowed value being "PDN GW". If this AVP is not included, trace activation in PDN GW is required.

MSISDN

Subscription-ID

C

This AVP shall contain the MSISDN of the UE and shall be sent only if it is available.

Session time

Session-Timeout

C

If the authorization succeeded, then this IE shall contain the time this authorization is valid for.

Permanent User Identity

Mobile-Node-Identifier

C

This information element shall be present if NBM is used.

If the user is authenticated, it shall contain an AAA/HSS assigned permanent user identity (i.e. IMSI in root NAI format as defined in clause 19 of 3GPP TS 23.003 [14]) to be used by:

– the MAG in subsequent PBUs as the MN-ID identifying the user in the EPS network for PMIP based S2b,

– by the ePDG to derive the IMSI to send in subsequent Create Session Request for GTP based S2b.

For an emergency PDN connection, if the UE is UICC-less (i.e. the User Identity IE in the request contains an IMEI) or if the IMSI is not authenticated, the Permanent User Identity shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14].

If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Serving GW Address

MIP6-Agent-Info

O

This AVP shall be used only in chained S2b-S8 cases and it shall be sent only if the Result-Code AVP is set to DIAMETER_SUCCESS.

UE Charging Data

3GPP-Charging-Characteristics

O

This information element contains the type of charging method to be applied to the user (see 3GPP TS 29.061 [31]).

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 for the lifetime of the Diameter session.

WLAN Location Information

Access-Network-Info

O

If present, this IE shall contain the location information of the WLAN Access Network where the UE is attached.

WLAN Location Timestamp

User-Location-Info-Time

C

This IE should be present if the WLAN Location Information IE is present.

When present, this IE shall contain the NTP time at which the UE was last known to be in the location reported in the WLAN Location Information.

Emergency Info

Emergency-Info

C

This IE shall only be present if the Result-Code AVP is set to DIAMETER_SUCCESS. When present, it shall contain the identity of the dynamically allocated PDN-GW used for the establishment of emergency PDN connections. It shall be present for a non-roaming authenticated user, if this information was received from the HSS and if the Emergency-Services AVP is present, with the Emergency-Indication bit set, in the Authentication and Authorization Request.

UE Usage Type

UE-Usage-Type

C

This IE shall be present if this information is available in the user subscription. When present, this IE shall contain the UE Usage Type of the subscriber.

Core Network Restrictions

Core-Network-Restrictions

C

This IE shall be present if this information is available in the user subscription. When present, this IE shall contain the Core Network Restrictions of the subscriber.

NOTE 1: If a static PDN GW allocated to the UE’s subscribed APN has been received from the HSS, the 3GPP AAA Server/Proxy shall only provide the static PDN GW identity in the Authentication and Authorization Answer.

7.1.2.1.2 3GPP AAA Server Detailed Behaviour

On receipt of the DER message, the 3GPP AAA Server shall check that the user data exists in the 3GPP AAA Server. If not, the 3GPP AAA Server shall use the procedures defined for the SWx interface to obtain access authentication and authorization data.

If the HSS returns DIAMETER_ERROR_USER_UNKWNOWN, the 3GPP AAA Server shall return the same error to the ePDG.

If the HSS indicates that the user is currently being served by a different 3GPP AAA Server, the 3GPP AAA Server shall respond to the ePDG with the Result-Code set to DIAMETER_REDIRECT_INDICATION and Redirect-Host set to the Diameter URI of the 3GPP AAA Server currently serving the user (this Diameter URI shall be constructed based on the Diameter Identity included in the 3GPP-AAA-Server-Name AVP returned in the SWx authentication response from the HSS).

Otherwise, the 3GPP AAA Server shall proceed with the authentication and authorization procedure. The 3GPP AAA Server shall use the procedures defined in SWx interface to obtain authorization data from HSS.

If IMEI check is required by operator policy and the ePDG is in the HPLMN, the 3GPP AAA Server shall:

– if the IMEI(SV) is available, check the Mobile Equipment’s identity status with the EIR, using the ME Identity Check procedure (see clause 11);

– upon getting the IMEI check result from the EIR, determine whether to continue or stop the authentication and authorization procedure;

– if the IMEI(SV) is not available, determine whether to continue or stop the authentication and authorization procedure based on operator policy;

– if the 3GPP AAA Server determines that the authentication and authorization procedure shall be stopped, it shall respond to the ePDG with the Experimental-Result-Code DIAMETER_ERROR_ILLEGAL_EQUIPMENT.

Specific operator policies may be configured for emergency services, regarding whether to check the IMEI and, if the IMEI needs to be checked, whether to continue or stop the authentication and authorization procedure upon getting the IMEI check result or when the IMEI(SV) is not available.

If the 3GPP AAA Server receives a request message not related to any existing session and is able to recognize that the ePDG included the AAA-Failure-Indication AVP in the request, the 3GPP AAA Server shall also include the AAA-Failure-Indication AVP over the SWx interface, while retrieving the access authentication and authorization data from the HSS.

If the user does not have non-3GPP access subscription, then 3GPP AAA Server shall respond to the ePDG with Experimental-Result-Code DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTION.

If a Visited- Network-Identifier is present in the request and if the user is not allowed to roam in the visited network, then the 3GPP AAA Server shall return Experimental-Result-Code set to DIAMETER_ERROR_ROAMING_NOT_ALLOWED.

If the user is not allowed to use the current access type, then the 3GPP AAA Server shall return Experimental-Result-Code set to DIAMETER_ERROR_RAT_TYPE_NOT_ALLOWED.

Otherwise the 3GPP AAA Server shall run EAP-AKA as specified in 3GPP TS 33.402 [19]. Exceptions to the cases specified here shall be treated by 3GPP AAA Server as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY and, therefore, no authentication information shall be returned.

Upon receiving the authentication and authorization request from the ePDG, the 3GPP AAA Server marks the trust relationship as "untrusted" with the User Identity. If the 3GPP AAA Server detects that an S6b session already exists for this UE and the S6b session was established as a result of an authentication request for DSMIPv6, the 3GPP AAA Server shall send the trust relationship to the PDN GW as specified in clause 9.1.2.5.

Once authentication is successfully completed, the 3GPP AAA Server shall perform the following authorization checking (if there is an error in any of the steps, the 3GPP AAA Server shall stop processing and return the corresponding error code):

1) Check if the user is barred to use the non 3GPP Access. If it is so, then the Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED

2) Check whether the user is barred to use the subscribed APNs. If it is so, Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED.

3) if the Emergency-Indication bit of the Emergency-Services AVP is not set in the Authentication and Authorization Request, check if there was request for an APN received. If not, the default APN of the user is selected to be used during the actual authentication and authorization procedure.

4) if the Emergency-Indication bit of the Emergency-Services AVP is not set in the Authentication and Authorization Request, check if user has a subscription for the requested APN or for the wildcard APN. If not, Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION

5) If present, check the flags of the received MIP6-Feature-Vector AVP: The evaluation of the flags is executed only in the first authentication and authorization procedure for the user after an initial attach or handover, in all the subsequent procedures, the AAA Server shall insert the same values.

– If the MIP6-INTEGRATED flag is set and the 3GPP AAA server has authorized IKEv2 Home Agent assignment, the 3GPP AAA server shall include the Home Agent addresses in the APN-Configuration AVP in the response and the MIP6-Feature-Vector AVP with the MIP6-INTEGRATED flag set. In this case, the 3GPP AAA Sever may select the Home Agent based on the identity of the ePDG as included in the Origin-Host AVP in the authentication and authorization request if no static PDN GW identity is received from the HSS. If the HA assignment via IKEv2 is not used, the MIP6-Feature-Vector AVP with the MIP6-INTEGRATED flag not set shall be sent.

– The PMIP6_SUPPORTED and/or GTPv2_SUPPORTED flag indicates to the 3GPP AAA server whether the ePDG supports NBM or not. As specified in 3GPP TS 23.402 [3], based on the information it has regarding the UE (see 3GPP TS 24.302 [26]), local/home network capabilities and local/home network policies, the 3GPP AAA server may perform mobility mode selection. If the 3GPP AAA server decides that NBM should be used, the PMIP6_SUPPORTED and GTPv2_SUPPORTED flags shall be set in the response to indicate the NBM support of the UE to the ePDG. If only the PMIP6_SUPPORTED or the GTPv2_SUPPORTED flag is present in the response, the ePDG shall assume that this also indicates the NBM support of the UE to the ePDG and the ePDG may select any S2b protocol variant (PMIPv6 or GTPv2). If the 3GPP AAA server decides that a local IP address should be assigned, the ASSIGN_LOCAL_IP flag shall be set in the response to indicate to the ePDG that a local IP address should be assigned.

NOTE 1: When selecting DSMIPv6, the AAA server assumes that the ePDG has the capability to assign a local IP address to the UE.

– The 3GPP AAA server shall not set the PMIP6_SUPPORTED/GTPv2_SUPPORTED and ASSIGN_LOCAL_IP flags both at the same time in the response.

Upon successful authentication and authorization, the Result-Code shall be set to DIAMETER_SUCCESS and:

– if the Emergency-Indication bit of the Emergency-Services AVP was not set in the Authentication and Authorization Request, the 3GPP AAA Server shall return user data relevant to the APN as received from the HSS. If the requested APN received from UE is authorized by the wildcard APN, the 3GPP AAA Server shall include the wildcard APN in the Service-Selection AVP of the APN-Configuration AVP;

– if the Emergency-Services AVP was present, with the Emergency-Indication bit set, in the Authentication and Authorization Request, the 3GPP AAA Server shall include the Emergency Info IE if this information was received from the HSS and the user is not roaming.

Exceptions to the cases specified here shall be treated by 3GPP AAA Server as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY and, therefore, no authorization information shall be returned.

For Fixed Broadband access network interworking as specified in 3GPP TS 23.139 [39], the 3GPP AAA server shall determine if the UE is connected via a BBF-defined WLAN access according to the UE local IP address in UE-Local-IP-Address AVP from the ePDG. If the UE is connected via a BBF-defined WLAN access, the 3GPP AAA server shall perform the enabling UE reflective QoS function as specified in 3GPP TS 24.139 [43].

The 3GPP AAA Server shall interpret the receipt of the Emergency-Services AVP, with the Emergency-Indication bit set, as an indication that the UE requests to access the EPC for emergency services.

The 3GPP AAA Server shall give preferential treatment to UEs which access the EPC for emergency services, e.g. in scenarios including network overload.

If the 3GPP AAA Server has WLAN Location Information about the UE, the 3GPP AAA Server shall provide it to the ePDG, along with the WLAN Location Timestamp if available (see clause 4.1.2.1.2).

If the 3GPP AAA Server supports IMS Emergency sessions over WLAN (see clause 4.5.7.2 of 3GPP TS 23.402 [3]), the 3GPP AAA Server shall proceed as specified above, but with the following modifications, for an Emergency Attach:

1) if the UE does not have an IMSI:

– if local policies allow emergency sessions for all UEs, the 3GPP AAA Server shall skip the procedures defined for the SWx interface to obtain access authentication and authorization data, skip the authorization checkings and authorize the UE to access to EPC for emergency services. The Permanent User Identity IE in the answer shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14];

– otherwise the 3GPP AAA Server shall reject the request with the Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN.

2) if the UE has an IMSI but the IMSI is not authenticated:

– if local policies allow emergency sessions for unauthenticated UEs with an IMSI, the 3GPP AAA Server shall skip the procedures defined for the SWx interface to obtain access authorization data, shall skip the authorization checkings and shall return an answer with the DIAMETER_ERROR_USER_UNKWNOWN Result-Code to the ePDG to request the UE to provide its IMEI as specified in clause 13.3 of 3GPP TS 33.402 [19].

NOTE 2: According to the procedure specified in clause 7.4.4 of 3GPP TS 24.302 [26], this results in an ePDG, that is configured to support unauthenticated emergency session over WLAN and Mobile Equipment Identity signalling over untrusted WLAN, to query the UE’s IMSI and to initiate a new Authentication and Authorization procedure with the same parameters as provided in the first Authentication and Authorization Request but with the addition of the UE’s IMEI in the Terminal-Information AVP.

If the Authentication and Authorization Request also included the UE’s IMEI (i.e. new authentication and authorization procedure after the ePDG queried the UE), the 3GPP AAA Server shall authorize the UE to access to EPC for emergency services. The Permanent User Identity IE in the answer shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14];

– otherwise the 3GPP AAA Server shall reject the request with the Experimental-Result-Code set as specified for authentication failures in this clause.

3) if the UE has an authenticated IMSI but the UE is not authorized to access the EPC:

– if local policies allow emergency sessions for any authenticated UE, the 3GPP AAA Server shall authorize the UE to access to EPC for emergency services;

– otherwise the 3GPP AAA Server shall reject the request with the Experimental-Result-Code set as specified for authorization failures in this clause.

7.1.2.1.3 3GPP AAA Proxy Detailed Behaviour

The 3GPP AAA Proxy shall be required to handle roaming cases in which the ePDG is in the VPLMN. The 3GPP AAA Proxy shall act as a stateful proxy with the following additions.

If IMEI check is required by operator policy and the ePDG is in the VPLMN, the 3GPP AAA Proxy shall:

– if the IMEI(SV) is available, check the Mobile Equipment’s identity status with the EIR, using the ME Identity Check procedure (see clause 11);

– upon getting the IMEI check result from the EIR, determine whether to continue or stop the authentication and authorization procedure;

– if the IMEI(SV) is not available, determine whether to continue or stop the authentication and authorization procedure based on operator policy;

– if the 3GPP AAA Proxy determines that the authentication and authorization procedure shall be stopped, it shall:

– respond to the ePDG with the Experimental-Result-Code DIAMETER_ERROR_ILLEGAL_EQUIPMENT, and

– send a SWm Session Termination Request towards the 3GPP AAA Server (see clause 7.1.2.3).

Specific operator policies may be configured for emergency services, regarding whether to check the IMEI and, if the IMEI needs to be checked, whether to continue or stop the authentication and authorization procedure upon getting the IMEI check result or when the IMEI(SV) is not available.

On receipt of the first authentication and authorization request, the 3GPP AAA Proxy shall check locally configured information whether users from the HPLMN are allowed to activate a PDN connection from the non-3GPP access network via this (V)PLMN. If not, the Experimental-Result-Code shall be set to DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the authentication response shall be sent to the ePDG.

On receipt of the authentication and authorization answer that completes a successful authentication, the 3GPP AAA Proxy

– may check locally configured information about using the chained S8-S2b option towards the given HPLMN. If chaining is required, the 3GPP AAA Proxy shall select a Serving GW from its network configuration database and shall include the Serving GW address in the response.

– shall check locally configured information for the maximum allowed static QoS parameters valid for visitors from the given HPLMN and modify the QoS parameters received from the 3GPP AAA Server, to enforce the policy limitations.

– shall record the state of the connection (i.e. Authorization Successful).

– may select the Home Agent based on the identity of the ePDG as included in the Origin-Host AVP in the authentication and authorization request if IKEv2 based Home Agent discovery is used and VPLMN Dynamic Address Allowed AVP is received. In this case, the 3GPP AAA proxy shall include the Home Agent addresses in the APN-Configuration AVP in the response and the MIP6-Feature-Vector AVP with the MIP6-INTEGRATED flag set if no static PDN GW identity is received from the 3GPP AAA Server.

7.1.2.1.4 ePDG Detailed Behaviour

The ePDG shall initiate a new authentication and authorization procedure for each new IKE_SA. Each IKE_SA shall be handled in a different session.

The ePDG shall set flags signalling its capabilities to the same value in all authentication and authorization procedure for the same user (include the same MIP6-Feature-Vector). During the second and further authentication and authorization procedures, the ePDG shall discard the flag values received from the AAA Server and reuse the values received during the first procedure executed for the user.

An ePDG which supports emergency services shall include the Emergency-Services AVP, with the Emergency-Indication bit set, if the UE indicated the establishment of an emergency session during the IKEv2 tunnel establishment (see clause 7.2.5 of 3GPP TS 24.302 [26]).

For PMIPv6/GTPv2 based S2b, when receiving a Serving GW address in an authentication response, the ePDG shall check, whether it has already a Serving GW address stored for the user.

– If it has no Serving GW address available, it shall store the received value and use it as LMA address when creating PMIP bindings.

– If it has already a stored Serving GW address value, it shall ignore the received SGW-Address AVP.

NOTE 1: In case of untrusted access, there is an authentication session started for all PDN connection setup requests of a user. These sessions may invoke different 3GPP AAA Proxies, which in turn may assign different Serving GWs to the user. The ePDG behaviour ensures that in spite of this possibility, the same Serving GW is used for all PDN connections of the user.

NOTE 2: The ePDG knows if NBM is used or if a local IP address is assigned based on the flags in the MIP6-Feature-Vector or based on preconfigured information. If the PMIP6_SUPPORTED and/or the GTPv2_SUPPORTED flag are set in the MIP6-Feature-Vector received from the 3GPP AAA Server, the ePDG knows that NBM is used.

For PMIPv6/GTPv2 based S2b and a PDN connection other than for emergency services, the ePDG shall utilize the downloaded APN configuration data to authorize the UE requested home address types: IPv4 home address and/or IPv6 home network prefix.

For GTPv2 based S2b and a PDN connection for emergency services, the ePDG shall ignore APN configuration data received from the 3GPP AAA Server and shall use its Emergency Configuration Data to determine the APN to be associated with the emergency PDN connection and possibly the PGW to use (see clause 4.5.7.2 of 3GPP TS 23.402 [3]). During a handover of an emergency PDN connection to an untrusted WLAN access, the ePDG shall use the PGW identified in the Emergency Info IE if this information is received from the 3GPP AAA Server, the user is a non-roaming authenticated user and the ePDG is configured to use a dynamic PGW for emergency services for such users.

The ePDG may use the Visited_Network_Identifier to determine the S2b protocol type (PMIPv6 or GTPv2). The ePDG may be configured with the S2b protocol variant(s) on a per HPLMN granularity, or may retrieve information regarding the S2b protocol variants supported by the PDN GW (PMIPv6 or/and GTPv2) from the Domain Name Service Function as described in 3GPP TS 29.303[34]. If the ePDG supports Dedicated Core Networks and received the UE-Usage-Type from the 3GPP AAA Server, the ePDG shall select the PGW as specified in clause 5.8 of 3GPP TS 29.303 [34].

The ePDG shall select a combined PGW/SMF for PDN connections that may be subject to mobility to 5GS, e.g. for UEs supporting N1 mode (see 3GPP TS 24.302 [26]) and not restricted to interworking with 5GS by user subscription (see "5GC" bit within Core-Network-Restrictions AVP and Interworking-5GS-Indicator AVP specified) as specified in clause 5.12.3 of 3GPP TS 29.303 [34].

If GTPv2 is used on S2b and if the Trace-Info AVP including Trace-Data has been received in the authorization response, the ePDG shall send a GTPv2 Trace Session Activation message (see 3GPP TS 29.274 [38]) to the PGW to start a trace session for the user.

If DSMIPv6 is used and if ePDG has received the PGW identity in form of the FQDN from the 3GPP AAA server, then the ePDG may obtain the IP address of the Home Agent functionality of that PGW as described in 3GPP TS 29.303 [34].

If the ePDG determines that a previously assigned 3GPP AAA Sever is unavailable, it may attempt to send a new authentication and authorization request to an alternate 3GPP AAA Server. If the ePDG receives from this new server a redirect indication towards the former server (due to the HSS having stored the former 3GPP AAA Server identity), it shall terminate all previously existing sessions and PDN connections for that user, and it shall re-send again the request towards the new server, but it shall include the AAA-Failure-Indication AVP in the new request.

The ePDG shall give preferential treatment to UEs which access the EPC for emergency services, e.g. in scenarios including network overload.

The ePDG shall store the WLAN Location Information associated with the UE when it receives such information from the 3GPP AAA Server.

If IMEI check is required by operator policy, the ePDG shall be configured to retrieve the IMEI(SV) from the UE (as specified in 3GPP TS 23.402 [26]) during the authentication and authorization procedure.

If the ePDG supports IMS Emergency sessions over WLAN (see clause 4.5.7.2 of 3GPP TS 23.402 [3]) and if local policies in the ePDG allows unauthenticated emergency sessions, the ePDG shall proceed during an Emergency Attach for a UE without a UICC or with an unauthenticated IMSI as specified above with the following modifications:

1) If the UE is UICC-less, the User Identity IE in the Authentication and Authorization Request shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14].

2) If the User Identity IE does not contain an IMEI (i.e. the UE has an IMSI), the ePDG shall request the IMEI from the UE as specified in clause 13.3 of 3GPP TS 33.402 [19] and clause 7.4.4 of 3GPP TS 24.302 [26] and include the IMEI in the Terminal-Information AVP in the next Authentication and Authorization Request message.

The Authentication and Authorization Request in step 8 of clause 13.3 of 3GPP TS 33.402 [19] (i.e. after querying the UE’s IMSI) shall contain the same parameters as provided in the first Authentication and Authorization Request (step 3) but with the addition of the IMEI in the Terminal-Information AVP.

NOTE 3: The IMEI cannot be signalled to the 3GPP AAA Server in the first Authentication and Authorization Request sent to the 3GPP AAA Server, since the ePDG requests the IMEI to the UE in the first IKE_AUTH_Response message after getting the first Authentication and Authorization Answer from the 3GPP AAA Server.

NOTE 4: The Authentication and Authorization Requests in steps 3 and 8 of clause 13.3 of 3GPP TS 33.402 [19] are handled independently from each other by the 3GPP AAA Server.

3) If the Permanent User Identity IE in the answer contains an IMEI based NAI but the User Identity IE in the request did not contain an IMEI based NAI, the ePDG shall derive that the IMSI was not authenticated and proceed accordingly with the setup of the Emergency PDN connection over S2b (see 3GPP TS 29.274 [38]).

7.1.2.2 Authorization Procedures

7.1.2.2.1 General

This procedure shall be used between the ePDG and 3GPP AAA Server and Proxy. It shall be invoked by the ePDG, upon receipt of a valid Re-Authorization Request message from the 3GPP AAA Server (see clause 7.1.2.5). It may also be initiated by the ePDG, when the ePDG detects a change of the outer IP address of the UE, to:

– update the 3GPP AAA Server with the new UE local IP address; and

– retrieve the most up to date WLAN Location Information stored at the 3GPP AAA Server, when the 3GPP AAA server has sent WLAN Location Information during the initial Authentication and Authorization procedure (see clause 4.5.7.2.8 of 3GPP TS 23.402 [3]).

This procedure shall be used by the ePDG to update the previously provided authorization parameters. This may happen due to a modification of the subscriber profile in the HSS (for example, removal of a specific APN associated with the subscriber, or change of the identity of a dynamically allocated PDN GW, see clause 8.1.2.3).

This procedure is mapped to the Diameter command codes AA-Request (AAR) and AA-Answer (AAA) specified in RFC 4005 [4]. Information element contents for these messages are shown in tables 7.1.2.2.1/1 and 7.1.2.2.1/2.

Table 7.1.2.2.1/1: SWm Authorization Request

Information element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

M

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Request Type

Auth-Request -Type

M

This information element shall contain the type of request. It shall have the value AUTHORIZE_ONLY.

AAR Flags

AAR-Flags

O

This IE contains a bit mask. See 7.2.3.5 for the meaning of the bits.

This IE may be present and indicate that the ePDG requests to retrieve the most up to date WLAN Location Information of the UE, if the ePDG received the WLAN Location Information during the initial Authentication and Authorization procedure.

UE local IP address

UE-Local-IP-Address

C

This IE shall be present if the ePDG provided the UE Local IP address in the initial Authentication and Authorization Request and the UE Local IP address has changed.

Table 7.1.2.2.1/2: SWm Authorization Answer

Information element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

M

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15], and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Request Type

Auth-Request -Type

M

It shall contain the value AUTHORIZE_ONLY. See IETF RFC 4072 [5].

Registration Result

Result-Code/ Experimental Result Code

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]) or as per in NASREQ (see IETF RFC 4005 [4]).

UE IPv4 Home Address

PMIP6-IPv4-Home-Address

O

If the authorization succeeded, and the user has an IPv4-HoA statically defined as part of his profile data, then this IE may be present. It shall contain the IPv4-HoA allocated and assigned to the UE.

APN-OI replacement

APN-OI-Replacement

C

This AVP shall indicate the domain name to replace the APN-OI in the non-roaming case or in the home routed roaming case when constructing the PDN GW FQDN upon which it needs to perform a DNS resolution. See 3GPP TS 23.003 [3]. It shall only be included if NBM is used, the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Request, and the Result-Code AVP is set to DIAMETER_SUCCESS.

APN and PGW Data

APN-Configuration

C

This information element shall only be sent if the Result-Code AVP is set to DIAMETER_SUCCESS and the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Request.

APN-Configuration is a grouped AVP, defined in 3GPP TS 29.272 [29]. When NBM is used, the following information elements per APN may be included:

– APN

– APN-AMBR

– Authorized 3GPP QoS profile

– Statically allocated User IP Address (IPv4 and/or IPv6)

– Allowed PDN types

– PDN GW identity

– PDN GW allocation type

– VPLMN Dynamic Address Allowed

– Visited Network Identifier

When local IP address assignment is used, this AVP shall only be present if IKEv2 based Home Agent discovery is used and

– if the PDN connection was active in case of HO, or

– if there is static PDN GW allocated to the UE’s subscribed APN.

In these cases, the following information elements shall be included:

– HA-APN (Home Agent APN as defined in 3GPP TS 23.003 [14])

– PDN GW identity

Trace information

Trace-Info

C

This AVP shall be included if the subscriber and equipment trace has been activated for the user in the HSS and signalling based activation is used to download the trace activation from the HSS to the ePDG.

Only the Trace-Data AVP shall be included if trace activation is requested. Only the Trace-Reference AVP shall be included if trace deactivation is requested.

If the Trace-Data AVP is included, it shall contain the following AVPs:

– Trace-Reference

– Trace-Depth

– Trace-Event-List, for PGW

– Trace-Collection-Entity

The following AVPs may also be included in the Trace-Data AVP:

– Trace-Interface-List, for PGW, if this AVP is not present, trace report generation is requested for all interfaces for PGW listed in 3GPP TS 32.422 [32]

– Trace-NE-Type-List, with the only allowed value being "PDN GW". If this AVP is not included, trace activation in PDN GW is required.

MSISDN

Subscription-ID

C

This AVP shall contain the MSISDN of the UE and shall be sent only if it is available.

UE Charging Data

3GPP-Charging-Characteristics

O

If present, this information element shall contain the type of charging method to be applied to the user (see 3GPP TS 29.061 [31]).

Session time

Session-Timeout

C

If the authorization succeeded, then this IE shall contain the time this authorization is valid for.

WLAN Location Information

Access-Network-Info

O

If present, this IE shall contain the location information of the WLAN Access Network where the UE is attached.

WLAN Location Timestamp

User-Location-Info-Time

C

This IE should be present if the WLAN Location Information IE is present.

When present, this IE shall contain the NTP time at which the UE was last known to be in the location reported in the WLAN Location Information.

7.1.2.2.2 3GPP AAA Server Detailed Behaviour

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

1) Check that the user exists in the 3GPP AAA Server. The check shall be based on Diameter Session-id and User Name. If the Session-Id included in the request does not correspond with any active session, or if an active session is found but it does not belong to the user identified by the User Name parameter, Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

2) If the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Request, check whether the user is allowed to access the APN. If not, Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED.

3) The Result-Code shall be set to DIAMETER_SUCCESS and, if the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Request, the 3GPP AAA Server shall return user data relevant to the APN as received from the HSS.

4) If the WLAN-Location-Info-Request bit is set to 1 in the AAR-Flags AVP and if the 3GPP AAA Server knows the WLAN Location Information of the UE, the 3GPP AAA Server shall provide it to the ePDG, along with the WLAN Location Timestamp if available (see clause 4.1.2.1.2).

If the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Request, once the Authentication and Authorization procedure successfully finishes, the 3GPP AAA Server shall download, together with authentication data, the list of authorized APNs and the authorized mobility protocols in the authentication and authorization response from the HSS (see SWx procedure in Clause 8.1.2.1).

Exceptions to the cases specified here shall be treated by 3GPP AAA Server as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY and, therefore, no authorization information shall be returned.

If the 3GPP AAA Server answers with DIAMETER_AUTHORIZATION_REJECTED, it shall terminate locally the associated SWm Diameter session.

7.1.2.2.3 3GPP AAA Proxy Detailed Behaviour

The 3GPP AAA Proxy shall be required to handle roaming cases in which the ePDG is in the VPLMN. The 3GPP AAA Proxy shall act as a stateful proxy, with the following extensions.

On receipt of the authorization answer, the 3GPP AAA Proxy:

– Shall check locally configured information for the maximum allowed static QoS parameters valid for visitors from the given HPLMN and modify the QoS parameters received from the 3GPP AAA Server, to enforce the policy limitations.

– Shall record the state of the connection (i.e. Authorization Successful).

If the 3GPP AAA Proxy receives a DIAMETER_AUTHORIZATION_REJECTED response from the 3GPP AAA Server, it shall forward it to the ePDG, and terminate locally the associated SWm Diameter session.

7.1.2.2.4 ePDG Detailed Behaviour

Upon receipt of a valid Re-Authorization Request message from the 3GPP AAA Server, the ePDG shall initiate the authorization procedure after successfully completing the authentication of the user. The ePDG shall initiate a separate authorization session for each IKE_SA of the user. When initiated by the ePDG to retrieve the most up to date WLAN Location Information stored at the 3GPP AAA Server, the ePDG shall initiate the authorization procedure for one IKE_SA of the user.

If NBM is used, at successful completion of the procedure, the ePDG shall store the APN configuration data received from the 3GPP AAA Server. The ePDG shall utilize these data to authorize the requested home address types: IPv4 home address and/or IPv6 home network prefix.

NOTE: The user will be allowed to create PDN connections only to the subscribed APNs and use the address types that are allowed by the subscribed PDN types.

Upon receiving the authorization response:

– If NBM is used and if any other Result-Code than DIAMETER_SUCCESS was received in the response, the ePDG shall release the corresponding PDN connection (PMIPv6 binding or GTPv2 tunnel) and IKE_SA of the user, and terminate locally the associated SWm Diameter session.

– If DSMIPv6 is used,

– If any other Result-Code than DIAMETER_SUCCESS was received, the ePDG shall release the corresponding IKE_SA of the user, and terminate locally the associated SWm Diameter session.

– If the Result-Code DIAMETER_SUCCESS was received in the response, the ePDG shall update the previously provided authorization parameters.

NOTE: The ePDG knows if NBM is used or if a local IP address is assigned based on the flags in the MIP6-Feature-Vector received during the initial authentication and authorization procedure or based on preconfigured information. If the PMIP6_SUPPORTED and/or the GTPv2_SUPPORTED flag are set in the MIP6-Feature-Vector received from the 3GPP AAA Server, the ePDG knows that NBM is used.

If GTPv2 is used on S2b and if the Trace-Info AVP including Trace-Data has been received in the authorization response, the ePDG shall send a GTPv2 Trace Session Activation message (see 3GPP TS 29.274 [38]) to the PGW to start a trace session for the user. If the Trace-Info AVP including Trace-Reference (directly under the Trace-Info) has been received in the authorization response, the ePDG shall send a GTPv2 Trace Session Deactivation message to the PGW to stop the ongoing trace session, identified by the Trace-Reference. For details, see 3GPP TS 32.422 [32].

If DSMIPv6 is used and if ePDG has received the PGW identity in form of the FQDN from the 3GPP AAA server, then the ePDG may obtain the IP address of the Home Agent functionality of that PGW as described in 3GPP TS 29.303 [34].

The ePDG shall store the WLAN Location Information associated with the UE when it receives such information from the 3GPP AAA Server. The ePDG shall delete any stored WLAN Location Information associated with the UE when it receives from the 3GPP AAA Server an Authorization Answer not including any WLAN Location Information and the WLAN-Location-Info-Request bit was set to 1 in the AAR-Flags AVP.

7.1.2.3 ePDG Initiated Session Termination Procedures

7.1.2.3.1 General

The SWm reference point allows the ePDG to inform the 3GPP AAA Server/Proxy about the termination of an IKE_SA between UE and ePDG, and that therefore the mobility session established on the ePDG for all associated PDN connections are to be removed.

The SWm Session Termination Request procedure shall be initiated by the ePDG to the 3GPP AAA Server which shall remove associated non-3GPP Access information. The AAA Server shall then return the SWm Session Termination Answer containing the result of the operation. These procedures are based on the reuse of Diameter STR and STA commands as specified in IETF RFC 6733 [58].

Table 7.1.2.3.1/1: SWm Session Termination Request

Information Element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

M

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Termination Cause

Termination-Cause

M

This information element shall contain the reason for the disconnection.

Table 7.1.2.3.1/2: SWm Session Termination Answer

Information Element name

Mapping to Diameter AVP

Cat.

Description

Result

Result-Code

M

This IE shall contain the result of the operation.

7.1.2.3.2 3GPP AAA Server Detailed Behavior

Upon reception of the Session Termination Request message from the ePDG, the 3GPP AAA Server shall check that there is an ongoing session associated to the two parameters received (Session-Id and User-Name).

If an active session is found and it belongs to the user identified by the User-Name parameter, the 3GPP AAA Server shall release the session resources associated to the specified session and a Session Termination Response shall be sent to the ePDG, indicating DIAMETER_SUCCESS.

Otherwise, the 3GPP AAA Server returns a Session Termination Response with the Diameter Error DIAMETER_UNKNOWN_SESSION_ID.

7.1.2.3.3 3GPP AAA Proxy Detailed Behavior

The 3GPP AAA Proxy is required to handle roaming cases in which the ePDG is located in the VPLMN. The 3GPP AAA Proxy shall act as a stateful proxy.

On receipt of the Session Termination Request message from the ePDG, the 3GPP AAA Proxy shall route the message to the 3GPP AAA Server.

On receipt of the Session Termination Answer message from the 3GPP AAA Server, the 3GPP AAA Proxy shall route the message to the ePDG, and it shall release any local resources associated to the specified session only if the result code is set to DIAMETER_SUCCESS.

7.1.2.4 3GPP AAA Server Initiated Session Termination Procedures

7.1.2.4.1 General

The SWm reference point shall allow the 3GPP AAA Server to request the termination of an IKE_SA between UE and ePDG, and therefore the termination of all mobility session established for all associated PDN connections.

If the user has several accesses (IKE_SA) active at an ePDG, a separate Session Termination procedure shall be initiated for each of them.

The procedure shall be initiated by the 3GPP AAA Server. This procedure is based on the reuse of NASREQ IETF RFC 4005 [4] ASR, ASA, STR and STA commands.

Table 7.1.2.4.1/1: SWm Abort Session Request

Information Element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

M

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Auth-Session-State

Auth-Session-State

O

If present, this information element indicates to the ePDG whether the 3GPP AAA Server requires an STR message.

Table 7.1.2.4.1/2: SWm Abort Session Answer

Information Element name

Mapping to Diameter AVP

Cat.

Description

Result

Result-Code

M

This IE shall contain the result of the operation.

Table 7.1.2.4.1/3: SWm Session Termination Request

Information element name

Mapping to Diameter AVP

Cat.

Description

Termination-Cause

Termination-Cause

M

This information element shall contain the reason why the session was terminated. It shall be set to "DIAMETER_ADMINISTRATIVE" to indicate that the session was terminated in response to an ASR message.

Table 7.1.2.4.1/4: SWm Session Termination Answer

Information element name

Mapping to Diameter AVP

Cat.

Description

Result-Code

Result-Code

M

This IE shall contain the result of the operation.

7.1.2.4.2 3GPP AAA Server Detailed Behaviour

The 3GPP AAA Server shall make use of this procedure to instruct the ePDG to terminate the IKE_SA between UE and ePDG.

In the DSMIPv6 case, the 3GPP AAA Server shall initiate first the detach procedure over the S6b reference point towards the PDN GW. When this process has finalized, the 3GPP AAA Server can initiate the termination of the IKE_SA towards the ePDG.

The 3GPP AAA Server shall include the Auth-Session-State AVP in the ASR command with a value of NO_STATE_MAINTAINED if it does not require a STR from the ePDG. If it does require a STR from the ePDG, the 3GPP AAA Server shall either omit the Auth-Session-State AVP from the ASR command or include the Auth-Session-State AVP in the ASR command with a value of STATE_MAINTAINED.

On receipt of the ASR command, the ePDG shall check if there is an ongoing session associated with the received Session-Id. If an active session is found and it belongs to the user identified by the User-Name parameter, the ePDG shall terminate the associated IKE_SA between UE and ePDG and return an ASA to the 3GPP AAA Server with the Result-Code to DIAMETER_SUCCESS. Otherwise, the ePDG shall return an ASA to the 3GPP AAA Server with the Result-Code set to DIAMETER_UNKNOWN_SESSION_ID.

On receipt of the ASA with a Result-Code of DIAMETER_SUCCESS, the 3GPP AAA Server shall release any local resources associated with the specified session.

If required by the 3GPP AAA Server, the ePDG shall send an STR with the Termination-Cause set to DIAMETER_ADMINISTRATIVE. The 3GPP AAA Server shall set the Result-Code to DIAMETER_SUCCESS and return the STA command to the ePDG.

7.1.2.4.3 3GPP AAA Proxy Detailed Behaviour

When the 3GPP AAA Proxy receives the ASR from the 3GPP AAA Server it shall route the request to the ePDG.

If the 3GPP AAA Proxy requires an STR but the 3GPP AAA Server does not, the 3GPP AAA Proxy may override the value of the Auth-Session-State in the ASR and set it to STATE_MAINTAINED. In this case, the 3GPP AAA Proxy shall not forward the STR received from the ePDG onto the 3GPP AAA Server and shall return an STA command to the ePDG with the Result-Code set to DIAMETER_SUCCESS. The 3GPP AAA Proxy shall not override the value of the Auth-Session-State AVP under any other circumstances.

On receipt of the ASA message with Diameter Result Code set to DIAMETER_SUCCESS, the 3GPP AAA Proxy shall route the successful response to the 3GPP AAA Server and shall release any local resources associated with the session.

When the 3GPP AAA Proxy receives the STR from ePDG, it shall route the request to the 3GPP AAA Server. On receipt of the STA message, the 3GPP AAA Proxy shall route the response to the ePDG.

7.1.2.5 Authorization Information Update Procedures

7.1.2.5.1 General

This procedure shall be used between the 3GPP AAA Server and the ePDG for the purpose of modifying the previously provided authorization parameters. This may happen due to a modification of the subscriber profile in the HSS (for example change of the identity of a dynamically allocated PDN GW, see clause 8.1.2.3).

This procedure shall be performed in two steps:

– The 3GPP AAA Server shall issue an unsolicited re-authorization request towards the ePDG. Upon receipt of such a request, the ePDG shall respond to the request and indicate the disposition of the request. This procedure is based on the Diameter commands Re-Auth-Request and Re-Auth-Answer specified in IETF RFC 6733 [58]. Information element contents for these messages shall be as shown in tables 7.1.2.5.1/1 and 7.1.2.5.1/2.

– Upon receiving the re-authorization request, the ePDG shall immediately invoke the authorization procedure specified in 7.1.2.2 for the session indicated in the request. This procedure is based on the Diameter commands AA-Request (AAR) and AA-Answer (AAA) specified in IETF RFC 4005 [4]. Information element contents for these messages are shown in tables 7.1.2.2.1/1 and 7.1.2.2.1/2.

Table 7.1.2.5.1/1: SWm Authorization Information Update Request

Information Element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

M

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Re-Auth Request Type

Re-Auth-Request-Type

M

This IE shall define whether the user is to be authorized only or authenticated and authorized. AUTHORIZE_ONLY shall be set in this case.

Routing Information

Destination-Host

M

This information element shall be obtained from the Origin-Host AVP, which was included in a previous command received from the trusted non-3GPP access.

Table 7.1.2.5.1/2: SWm Authorization Information Update Answer

Information Element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

M

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Result

Result-Code

M

This IE shall contain the result of the operation.

7.1.2.5.2 3GPP AAA Server Detailed Behaviour

The 3GPP AAA server shall make use of the re-authorization procedure defined in the Diameter base protocol, IETF RFC 6733 [58] to indicate that relevant service authorization information shall be updated in the ePDG.

7.1.2.5.3 ePDG Detailed Behaviour

Upon receipt of the Re-authorization Request message from the 3GPP AAA Server or the 3GPP AAA Proxy, the ePDG shall check that there is an ongoing session associated to any of the parameters received in the message (identified by the Session-Id AVP and the User-Name AVP).

If an active session is found, the ePDG shall initiate an authorization procedure for the session identified by the Session-Id AVP and the User-Name AVP and a Re-authorization Answer message shall be sent to the 3GPP AAA Server or the 3GPP AAA Proxy with the Result-Code indicating DIAMETER_SUCCESS. This new authorization procedure shall be performed as described in clause 7.1.2.2.

If the Session-Id included in the request does not correspond with any active session, or if an active session is found but it does not belong to the user identified by the User Name parameter, then an Re-authorization Answer message shall be sent to the 3GPP AAA Server or the 3GPP AAA Proxy with the Result-Code indicating DIAMETER_UNKNOWN_SESSION_ID.

Exceptions to the cases specified here shall be treated by ePDG as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY and, therefore, no authorization procedure shall be initiated.

Table 7.1.2.5.3/1 details the valid result codes that the ePDG can return in the response.

Table 7.1.2.5.3/1: Re-authorization Answer valid result codes

Result-Code AVP value

Condition

DIAMETER_SUCCESS

The request succeeded.

DIAMETER_UNKNOWN_SESSION_ID

The request failed because the user is not found in ePDG.

DIAMETER_UNABLE_TO_COMPLY

The request failed.

7.2 Protocol Specification

7.2.1 General

The SWm reference point shall be based on Diameter, as defined in IETF RFC 6733 [58] and contain the following additions and extensions:

– IETF RFC 4005 [4], which defines a Diameter protocol application used for Authentication, Authorization and Accounting (AAA) services in the Network Access Server (NAS) environment.

– IETF RFC 4072 [5], which provides a Diameter application to support the transport of EAP (IETF RFC 3748 [8]) frames over Diameter.

– IETF RFC 5779 [2], which defines a Diameter extensions and application for PMIPv6 MAG to AAA and LMA to AAA interfaces.

– IETF RFC 5447 [6], which defines Diameter extensions for Mobile IPv6 NAS to AAA interface.

In the case of an untrusted non-3GPP IP access, the MAG to 3GPP AAA server or the MAG to 3GPP AAA proxy communication shall use the MAG to AAA interface functionality defined in IETF RFC 5779 [2] and the NAS to AAA interface functionality defined in IETF RFC 5447 [6].

The Diameter application for the SWm reference point shall use the Diameter Application Id with value 16777264.

7.2.2 Commands

7.2.2.1 Commands for SWm Authentication and Authorization Procedures

7.2.2.1.1 Diameter-EAP-Request (DER) Command

The Diameter-EAP-Request (DER) command, indicated by the Command-Code field set to 268 and the "R" bit set in the Command Flags field, is sent from a ePDG to a 3GPP AAA Server/Proxy. The ABNF is based on the one in IETF RFC 5779 [2].

< Diameter-EAP-Request > ::= < Diameter Header: 268, REQ, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Request-Type }

{ EAP-Payload }

[ User-Name ]

[ RAT-Type ]

[ Service-Selection ]

[ MIP6-Feature-Vector ]

[ QoS-Capability ]

[ Visited-Network-Identifier ]

[ AAA-Failure-Indication ]

*[ Supported-Features ]

[ UE-Local-IP-Address ]

[ OC-Supported-Features ]

[ Terminal-Information ]

[ Emergency- Services ]

*[ AVP ]

7.2.2.1.2 Diameter-EAP-Answer (DEA) Command

The Diameter-EAP-Answer (DER) command, indicated by the Command-Code field set to 268 and the "R" bit cleared in the Command Flags field, is sent from a 3GPP AAA Server/Proxy to the ePDG. The ABNF is based on the one in IETF RFC 5779 [2].

< Diameter-EAP-Answer > ::= < Diameter Header: 268, PXY, 16777264>

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Auth-Request-Type }

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ EAP-Payload ]

[ User-Name ]

[ EAP-Master-Session-Key ]

[ APN-OI-Replacement ]

[ APN-Configuration ]

[ MIP6-Feature-Vector ]

[ Mobile-Node-Identifier ]

[ Trace-Info ]

[ Subscription-ID ]

[ Session-Timeout ]

[ MIP6-Agent-Info ]

[ 3GPP-Charging-Characteristics ]

*[ Redirect-Host ]

*[ Supported-Features ]

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

[ Access-Network-Info ]

[ User-Location-Info-Time ]

[ UE-Usage-Type ][ Emergency-Info ]

[ Core-Network-Restrictions ]

*[ AVP ]

7.2.2.1.3 Diameter-AA-Request (AAR) Command

The AA-Request (AAR) command, indicated by the Command-Code field set to 265 and the "R" bit set in the Command Flags field, is sent from a ePDG to a 3GPP AAA Server/Proxy.

<AA-Request> ::= < Diameter Header: 265, REQ, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Request-Type }

[ User-Name ]

[ OC-Supported-Features ]

[ AAR-Flags ]

[ UE-Local-IP-Address ]

*[ AVP ]

7.2.2.1.4 Diameter-AA-Answer (AAA) Command

The AA-Answer (AAA) command, indicated by the Command-Code field set to 265 and the "R" bit cleared in the Command Flags field, is sent from 3GPP AAA Server/Proxy to a ePDG.

<AA-Answer> ::= < Diameter Header: 265, REQ, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Auth-Request-Type }

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ User-Name ]

[ APN-OI-Replacement ]

[ APN-Configuration ]

[ Trace-Info ]

[ Subscription-ID ]

[ 3GPP-Charging-Characteristics ]

[ Session-Timeout ]

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

[ Access-Network-Info ]

[ User-Location-Info-Time ]

*[ AVP ]

7.2.2.2 Commands for ePDG Initiated Session Termination

7.2.2.2.1 Session-Termination-Request (STR) Command

The Session-Termination-Request (STR) command, indicated by the Command-Code field set to 275 and the "R" bit set in the Command Flags field, is sent from a ePDG to a 3GPP AAA Server/Proxy. The ABNF is based on the one in IETF RFC 6733 [58], and is defined as follows:

< Session-Termination-Request > ::= < Diameter Header: 275, REQ, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Application-Id }

{ Termination-Cause }

[ User-Name ]

[ OC-Supported-Features ]

*[ AVP ]

7.2.2.2.2 Session-Termination-Answer (STA) Command

The Session-Termination-Answer (STA) command, indicated by the Command-Code field set to 275 and the "R" bit clear in the Command Flags field, is sent from a 3GPP AAA Server/Proxy to a ePDG. The ABNF is based on the one in IETF RFC 6733 [58], and is defined as follows:

< Session-Termination-Answer > ::= < Diameter Header: 275, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

*[ AVP ]

7.2.2.3 Commands for 3GPP AAA Server Initiated Session Termination

7.2.2.3.1 Abort-Session-Request (ASR) Command

The Abort-Session-Request (ASR) command shall be indicated by the Command-Code field set to 274 and the "R" bit set in the Command Flags field, and shall be sent from a 3GPP AAA Server/Proxy to an ePDG. The ABNF is based on that in IETF RFC 4005 [4].

< Abort-Session-Request > ::= < Diameter Header: 274, REQ, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

[ User-Name ]

[ Auth-Session-State ]

*[ AVP ]

7.2.2.3.2 Abort-Session-Answer (ASA) Command

The Abort-Session-Answer (ASA) command shall be indicated by the Command-Code field set to 274 and the "R" bit cleared in the Command Flags field, and shall be sent from a ePDG to a 3GPP AAA Server/Proxy. The ABNF is based on that in IETF RFC 4005 [4].

< Abort-Session-Answer > ::= < Diameter Header: 274, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

*[ AVP ]

7.2.2.3.3 Session-Termination-Request (STR) Command

The Session-Termination-Request (STR) command, indicated by the Command-Code field set to 275 and the "R" bit set in the Command Flags field, is sent from an ePDG to a 3GPP AAA Server/Proxy. The Command Code value and ABNF are re-used from the IETF RFC 6733 [58] Session-Termination-Request command.

<Session-Termination-Request> ::= < Diameter Header: 275, REQ, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Application-Id }

{ Termination-Cause }

[ User-Name ]

[ OC-Supported-Features ]

*[ AVP ]

7.2.2.3.4 Session-Termination-Answer (STA) Command

The Session-Termination-Answer (STA) command, indicated by the Command-Code field set to 275 and the "R" bit cleared in the Command Flags field, is sent from a 3GPP AAA Server/Proxy to an ePDG. The Command Code value and ABNF are re-used from the IETF RFC 6733 [58] Session-Termination-Answer command.

<Session-Termination-Answer> ::= < Diameter Header: 275, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

*[ AVP ]

7.2.2.4 Commands for Authorization Information Update

7.2.2.4.1 Re-Auth-Request (RAR) Command

The Re-Auth-Request (RAR) command shall be indicated by the Command-Code field set to 258 and the "R" bit set in the Command Flags field, and shall be sent from a 3GPP AAA Server/Proxy to a ePDG. The ABNF is based on the one in IETF RFC 4005 [4] and is defined as follows.

< Re-Auth-Request > ::= < Diameter Header: 258, REQ, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

{ Re-Auth-Request-Type }

[ User-Name ]

*[ AVP ]

7.2.2.4.2 Re-Auth-Answer (RAA) Command

The Re-Auth-Answer (RAA) command shall be indicated by the Command-Code field set to 258 and the "R" bit cleared in the Command Flags field, and shall be sent from a ePDG to a 3GPP AAA Server/Proxy. The ABNF is based on the one in IETF RFC 4005 [4] and is defined as follows.

< Re-Auth-Answer > ::= < Diameter Header: 258, PXY, 16777264 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ User-Name ]

*[ AVP ]

7.2.3 Information Elements

7.2.3.1 General

The following table describes the Diameter AVPs defined for the SWm interface protocol for untrusted non-3GPP access, 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 7.2.3.1/1: Diameter SWm AVPs

AVP Flag rules

Attribute Name

AVP Code

Clause defined

Value Type

Must

May

Should not

Must not

APN-Configuration

1430

8.2.3.7

Grouped

M,V

P

Mobile-Node-Identifier

506

5.2.3.2

OctetString

M

V,P

MIP6-Feature-Vector

124

5.2.3.3

Unsigned64

M

V,P

QoS-Capability

578

9.2.3.2.4

Grouped

M

V,P

RAT-Type

1032

5.2.3.6

Enumerated

M,V

P

Visited-Network-Identifier

600

9.2.3.1.2

OctetString

M,V

P

Trace-Info

1505

8.2.3.1.3

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

Emergency- Services

1538

7.2.3.4

Unsigned32

V

M,P

Access-Network-Info

1526

5.2.3.24

Grouped

V

M,P

AAR-Flags

1539

7.2.3.5

Unsigned32

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 IETF 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 SWm interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within SWm. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol defined in IETF RFC 6733 [58], do not need to be supported.

Table 7.2.3.1/2: SWm re-used Diameter AVPs

Attribute Name

Reference

Comments

M-bit

Auth-Request-Type

IETF RFC 6733 [58]

Subscription-ID

IETF RFC 4006 [20]

EAP-Master-Session-Key

IETF RFC 4072 [5]

EAP-Payload

IETF RFC 4072 [5]

Re-Auth-Request-Type

IETF RFC 6733 [58]

Session-Timeout

IETF RFC 6733 [58]

User-Name

IETF RFC 6733 [58]

MIP6-Agent-Info

IETF RFC 5447 [6]

APN-OI-Replacement

3GPP TS 29.272 [29]

Terminal-Information

3GPP TS 29.272 [29]

Supported-Features

3GPP TS 29.229 [24]

Feature-List-ID

3GPP TS 29.229 [24]

See clause 7.2.3.2

Feature-List

3GPP TS 29.229 [24]

See clause 7.2.3.3

3GPP-Charging-Characteristics

3GPP TS 29.061 [31]

UE-Local-IP-Address

3GPP TS 29.212 [23]

OC-Supported-Features

IETF RFC 7683 [47]

See clause 8.2.3.22

OC-OLR

IETF RFC 7683 [47]

See clause 8.2.3.23

User-Location-Info-Time

3GPP TS 29.212 [23]

See clause 5.3.101

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 and for this procedure are described in the following clauses.

7.2.3.2 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 SWm application.

7.2.3.3 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 SWm application.

NOTE: There are no SWm features defined for this release.

7.2.3.4 Emergency-Services

The Emergency-Services AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.2.3.4/1:

Table 7.2.3.4/1: Emergency-Services

Bit

Name

Description

0

Emergency-Indication

This bit, when set, indicates a request to establish a PDN connection for emergency services.

NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver.

7.2.3.5 AAR-Flags

The AAR-Flags AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.2.3.5/1:

Table 7.2.3.5/1: AAR-Flags

Bit

Name

Description

0

WLAN-Location-Info-Request

This bit, when set, indicates an ePDG request to retrieve the most up to date WLAN Location Information of the UE stored at the 3GPP AAA Server.

NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver.

7.2.4 Session Handling

The Diameter protocol between the ePDG and the 3GPP AAA Server or the 3GPP AAA Proxy shall always keep the session state, and use the same Session-Id parameter for the lifetime of each Diameter session.

A Diameter session shall identify

– a PDN Connection of a given user, if NBM is used

– a user, if DSMIPv6 is used.

In order to indicate that the session state is to be maintained, the Diameter client and server shall not include the Auth-Session-State AVP, either in the request or in the response messages (see IETF RFC 6733 [58]).