6 UE – EPC Network protocols

24.3023GPPAccess to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networksRelease 18Stage 3TS

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

6.1 General

6.2 Trusted and Untrusted Accesses

6.2.1 General

For a UE, the trust relationship of a non-3GPP IP access network is determined by the home PLMN operator. That trust relationship is indicated to the UE via the following methods:

– Pre-configured policies in the UE by the home PLMN operator.

– Dynamic indication during 3GPP-based access authentication.

For a trusted non-3GPP IP access network, the UE shall follow the access methods given in clause 6.4. For an untrusted non-3GPP IP access network, the UE shall follow the access methods given in clause 6.5.

If the dynamic trust relationship indication is received during 3GPP-based access authentication, the UE shall rely on the dynamic trust relationship indication. Otherwise the UE shall follow the pre-configured policies for a specific non-3GPP access network. If no dynamic indicator is received, and no pre-configured policy matches a specific non-3GPP access network where the UE attempts to access, the UE shall follow the procedure defined in clause 6.2.4.

6.2.2 Pre-configured policies in the UE

The following types of policies can be pre-configured on the UE by the home PLMN operator:

– Pre-configured trust relationship policies for specific non-3GPP access technologies and/or PLMNs. For example, the UE may be configured to use the procedures for trusted access networks as described in clause 6.4 as follows:

– an access network of access technology X1 from PLMN Y1 is trusted; and/or

– any access network of access technology X2 is trusted; and/or

– any access network from PLMN Y2 is trusted; and/or

– any access network is trusted.

The format of the pre-configured policies is not specified in this release of this specification.

6.2.3 Dynamic Indication

If the UE performs 3GPP-based access authentication, the 3GPP AAA server may send a trust relationship indicator of the non-3GPP access network to the UE during the EAP-AKA, EAP-AKA’ or EAP-3GPP-LimitedService based access authentication (i.e. EAP-AKA, EAP-AKA’ or EAP-3GPP-LimitedService) as specified in 3GPP TS 33.402 [15]. If non-3GPP access network is trusted, the 3GPP AAA server shall send this trust relationship indicator as specified in 3GPP TS 29.273 [17]. The indicator is sent using a AT_TRUST_IND attribute, by extending the EAP-AKA (and EAP-AKA’ and EAP-3GPP-LimitedService) protocol as specified in clause 8.2 of IETF RFC 4187 [33]. This attribute is provided in EAP-Request/AKA-Challenge or EAP- Request/AKA’-Challenge or EAP-Request/3GPP-LimitedService-Init-Info message payload respectively. The detailed coding of this attribute is described in clause 8.2.3.1.

6.2.4 No trust relationship information

If no dynamic indicator is received, and no pre-configured policies matches a specific non-3GPP access network where the UE attempts to access, the UE shall consider it as untrusted network and operate based on clause 6.5.

6.3 IP Mobility Mode Selection

6.3.1 General

The IP mobility mechanisms supported between 3GPP and non-3GPP accesses within an operator and its roaming partner’s network may be based on either:

a) Static Configuration; or

b) Dynamic Configuration.

The choice between a) and b) depends upon operators’ preferences or roaming agreement or both.

6.3.2 Static configuration of inter-access mobility mechanism

For networks deploying a single IP mobility management mechanism, the statically configured mobility mechanism can be access type or roaming agreement specific or both. The information about the mechanism to be used in such scenario is expected to be provisioned into the terminal and the network.

In static configuration, if there is a mismatch between the IP mobility mode mechanism parameters pre-configured in the network and in the UE, the UE may not be able to access the EPC. If the UE is able to access the EPC even if there is a mismatch between the IP mobility mode mechanisms, the network may not be able to provide session continuity for the UE. More details of the possible cases of mismatch between the IP mobility mode mechanism are described in the informative annex D.

If the network is configured with a static mobility mechanism and the AAA server implements protocol extensions for a dynamic IP Mobility Mode Selection (IPMS) exchange, the AAA server shall send to the UE an AT_RESULT_IND attribute during the authentication procedure as it is described in clause 6.3.3.1.2.

6.3.3 Dynamic configuration of inter-access mobility mechanism

6.3.3.0 General

Dynamic IP Mobility Mode Selection (IPMS) consists of:

– IP mobility management protocol selection between Network Based Mobility (NBM), DSMIPv6 or MIPv4; and

– Decision on IP address preservation if NBM is selected

Upon initial attachment to a non-3GPP access and upon handoff to non-3GPP accesses, the UE performs IPMS by providing an indication during network access authentication for EPC. For trusted access, the indication is provided before an IP address is allocated to the UE, while in untrusted access network, the indication is provided during IKEv2 signalling for IPSec tunnel establishment with the ePDG.

When the UE provides an explicit indication for IPMS, then the network shall provide the indication to the UE identifying the selected mobility management mechanism.

When the dynamic IP mobility mode selection is used if the UE does not receive any indication of a selected mobility protocol after the UE provided an explicit indication, it is considered as an abnormal case and the UE may not get connectivity to the EPC.

NOTE: The scenarios for mobility mode selection are described in clause 4.1.3 of 3GPP TS 23.402 [6].

6.3.3.1 IPMS indication

6.3.3.1.1 IPMS indication from UE to 3GPP AAA server

During network access authentication, UE may provide an explicit indication to the 3GPP AAA server about the supported mobility protocol by using an attribute in the EAP-AKA and EAP-AKA’ protocols, to extend these protocols as specified in clause 8.2 of IETF RFC 4187 [33]. This attribute is provided in EAP-Response/AKA-Challenge and corresponding EAP-AKA’ message payload.

The UE may provide the indication for IPMS using AT_IPMS_IND attribute in EAP-AKA or EAP-AKA’ if the UE receives the AT_RESULT_IND attribute within the EAP-Request/AKA-Challenge message, or the EAP-Request/AKA’-Challenge message (when EAP-AKA’ is used). If the UE provides the AT_IPMS_IND attribute within the EAP-Response/AKA-Challenge message payload or within the EAP-Response/AKA’-Challenge message payload (when EAP-AKA’ is used), the UE shall also provide the AT_RESULT_IND attribute within the message.

If the UE supports IPMS indication, it shall indicate support for one or more mobility protocols in AT_IPMS_IND attribute as follows:

– the UE shall indicate support for DSMIPv6 if the UE supports DSMIPv6; and

– the UE shall indicate support for MIPv4 if the UE supports MIPv4; and

– during initial attach, the UE should indicate support for NBM if the UE supports address preservation based on NBM between the access it is attaching to and all other accesses that the UE supports.; or

– upon handover, the UE shall indicate support for NBM if the UE supports address preservation based on NBM while moving from source access network to target non-3GPP access network that the UE is attaching to.

NOTE: The UE can be configured not to use IPMS indication, e.g. the UE is DSMIP capable only.

If the UE does not support any mobility protocol then the UE shall not send the AT_IPMS_IND attribute to the 3GPP AAA server.

The preference of protocol may be indicated based on the policies configured on the UE. The detailed coding of this attribute is described in clause 8.2.1.1.

6.3.3.1.2 IPMS indication from 3GPP AAA server to UE

A 3GPP AAA server supporting IPMS shall include the AT_RESULT_IND attribute within the EAP-Request/AKA-Challenge and corresponding EAP-AKA’ message payload.

If the UE provided an explicit indication as described in clause 6.3.3, the 3GPP AAA server shall inform the UE of its decision on the mobility protocol and IP preservation mode by invoking an EAP-Request/AKA-Notification dialogue when EAP-AKA is used or an EAP-Request/AKA’-Notification dialogue when EAP-AKA’ is used.

On selecting the mobility protocol based on UE indication, access network capabilities and network policies, the 3GPP AAA server shall indicate the selected protocol to the UE by using the AT_IPMS_RES attribute. If the 3GPP AAA server does not receive any indication from the UE but knows the UE’s policies allow the usage of NBM and knows the home and access network supports NBM, the network shall use NBM shall be used for providing connectivity to the UE.

If the AT_IPMS_RES attribute indicates DSMIPv6 then the UE shall follow the procedures defined in 3GPP TS 24.303 [11].

If the AT_IPMS_RES attribute indicates MIPv4 support, then the UE shall follow the procedures defined in 3GPP TS 24.304 [12].

The detailed coding of this attribute is described in clause 8.2.1.2.

6.4 Authentication and authorization for accessing EPC via a trusted non-3GPP access network

6.4.1 General

For access to the EPC via a trusted non-3GPP access network, a connection shall be established between the UE and the trusted non-3GPP access network using signalling procedures specific to the trusted non-3GPP access network, which are out of scope of this present document.

Access authentication signalling for access to the EPC shall be executed between the UE and 3GPP AAA server to ensure mutual authentication of the user and the EPC, with the exception of UEs without IMSI (see clauses 4.4.1 and 6.6.3.2) or UEs initiating emergency session but whose IMSI authentication cannot proceed. Such authentication is based on IETF protocols as specified in 3GPP TS 33.402 [15].

EAP-AKA’ is used for access authentication in the trusted access network, according to 3GPP TS 33.402 [15], clause 6.2. According to 3GPP TS 33.402 [15], clause 6.1, EAP-AKA’ can be skipped if conditions listed in clause 9.2.2.1 or conditions described in clause 13.4 of 3GPP TS 33.402 [15] are met.

If the access network does not support EAP-AKA or EAP-AKA’ and the UE considers the access network as trusted, the UE shall access to the EPC only via S2c and any authentication method (EAP-based or otherwise) can be used for access authentication as long as the criteria set in 3GPP TS 33.402 [15], clause 9.2.2.1 are met.

When the UE decides to access EPC via S2c using non-3GPP IP access, EAP-AKA authentication is performed between the UE and the PDN-GW as specified in 3GPP TS 24.303 [11] and 3GPP TS 33.402 [15].

The UE may support ERP as described in IETF RFC 6696 [71] and 3GPP TS 33.402 [15]. In this release of this specification, only the ERP Implicit Bootstrapping mode defined in IETF RFC 6696 [71] is supported.

After a UE successfully completes authentication and authorization for accessing EPC via the trusted non-3GPP access network, the UE may receive as part of an ANQP query to the access point, an ANQP-element in a protected frame with management frame protection enabled. If the ANQP-element is an Emergency Call Number ANQP-element encoded in accordance with Annex I, the UE considers the content of the Emergency Call Number field valid.

6.4.1A TWAN connection modes

As part of EAP-AKA’ authentication via TWAN or EAP-3GPP-LimitedService authentication via TWAN, the UE and the network can negotiate usage of either the single-connection mode (SCM) or the multi-connection mode (MCM) as described in 3GPP TS 23.402 [6].

NOTE: UE requesting neither SCM nor MCM acts in transparent single-connection mode (TSCM). No UE extensions are needed for TSCM.

The negotiation consists of the following steps:

a) The 3GPP AAA server indicates support of TSCM, SCM, MCM or any combination of them as described in clause 6.4.3.5.

b) The UE requests usage of SCM or MCM as described in clause 6.4.2.6.2 and clause 6.4.2.6.3, acts in TSCM or aborts the EAP authentication as described in clause 6.4.2.6.4.

c) The 3GPP AAA server either accepts or rejects the UE request as described in clause 6.4.3.5.

If EAP-AKA’ authentication is skipped during emergency call via TWAN for unauthenticated UEs and the EAP-3GPP-LimitedService authentication via TWAN is performed, the UE and the network can negotiate usage of either the single-connection mode (SCM) or the multi-connection mode (MCM) as follows:

a) The 3GPP AAA server indicates support of SCM, MCM or any combination of them as described in clause 6.4.3.5.1A.

b) The UE requests usage of SCM or MCM as described in clause 6.4.2.6.2A and clause 6.4.2.6.3A, or aborts the EAP authentication as described in clause 6.4.2.6.4.

c) The 3GPP AAA server either accepts or rejects the UE request as described in clause 6.4.3.5.

6.4.2 UE procedures

6.4.2.1 Identity Management

The user identities to be used by the UE in the authentication and authorization for accessing EPC via a trusted non-3GPP access are the Root-NAI (permanent identity), decorated NAI, Fast-Reauthentication NAI (Fast-Reauthentication Identity) and Pseudonym Identity and these identities are described in clause 4.4.

If the UE supports ERP, the identity to be used by the UE during the re-authentication procedure using ERP is the "KeyName-NAI" as described in 3GPP TS 23.003 [3].

6.4.2.1A Identity Management – emergency session

When initiating emergency session via trusted non-3GPP access, if the UE has no valid subscriber data available (USIM not available, or USIM is considered invalid by the UE), the UE shall provide its IMEI in an EAP Response/Identity message based on emergency NAI format specified in 3GPP TS 23.003 [3].

If the UE receives EAP-Request/3GPP-LimitedService-Init-Info message from the network requesting IMEI, the UE provides IMEI as specified in clause 6.4.2.7.

6.4.2.2 EAP-AKA and EAP-AKA’ based Authentication

The UE shall support EAP-AKA based authentication as specified in IETF RFC 4187 [33] and EAP-AKA’ based authentication as specified in IETF RFC 5448 [38]. 3GPP TS 33.402 [15] specifies the conditions under which one or the other of these two methods is used.

During network access authentication, the UE may provide an explicit indication for IPMS by adding an attribute in the EAP-AKA or EAP-AKA’ payload as defined in clause 6.3.3.

During network access authentication, the 3GPP AAA server may provide the ANID to the UE, see clause 6.4.2.4.

For WLAN access, after the UE has been successfully authenticated from WLAN, if the UE receives EAP-Request/AKA’-Notification dialogue with AT_NOTIFICATION attribute value 1031 "User has not subscribed to the requested service" as defined in IETF RFC 4187 [33], the UE shall not initiate the EPC access procedure to the same WLAN until switching off or the UICC containing the USIM is removed.

NOTE: Switching off and USIM change conditions are implemented taking into consideration the user experience aspect.

6.4.2.3 Full Authentication and Fast Re-authentication

The UE shall support both full authentication and fast re-authentication for EAP AKA as specified in IETF RFC 4187 [33] and for EAP-AKA’ as specified in IETF RFC 5448 [38].

Full authentication is performed to generate new keys. The initial authentication shall be a full authentication as specified in 3GPP TS 33.402 [15]. For a full authentication either the Permanent Identity or the Pseudonym Identity is used.

According to 3GPP TS 33.402 [15] the fast re-authentication procedure uses the Fast Re-authentication Identity and is used for renewing the session keys.

The Permanent Identity is based on the IMSI of the UE. The Fast Re-authentication Identity is provided to the UE by the 3GPP AAA server during the previous authentication procedure. The UE shall use the Fast Re-authentication Identity only once. A Pseudonym Identity provided to the UE by the 3GPP AAA Server during a previous authentication procedure can be reused in later authentications until the UE receives a new Pseudonym identity from the 3GPP AAA Server.

NOTE: The 3GPP AAA Server will assign a new Pseudonym Identity with a frequency dictated by operator’s policy. The allocation of new pseudonyms is required to prevent that the user’s movements are tracked by an unauthorized party.

If during an authentication request, the UE receives an EAP-Request/AKA-Identity message containing AT_PERMANENT_ID_REQ, the UE shall return the Permanent Identity in the AT_IDENTITY attribute of the EAP-Response/AKA_Identity. If the UE receives an EAP-Request/AKA’-Identity message containing AT_PERMANENT_ID_REQ, the UE shall return the Permanent Identity in the AT_IDENTITY attribute of the EAP- Response /AKA’-Identity message.

If during an authentication request, the UE receives an EAP-Request/AKA-Identity message which contains AT_FULLAUTH_ID_REQ, the UE shall return the Pseudonym Identity as the AT_IDENTITY within EAP-Response/AKA_Identity message if available. If the UE receives an EAP-Request/AKA’-Identity message containing AT_FULLAUTH_ID_REQ, the UE shall return the Pseudonym Identity as the AT_IDENTITY within the EAP- Response /AKA’-Identity message if available. Otherwise the UE shall return the Permanent Identity.

If during an authentication request, the UE receives an EAP-Request/AKA-Identity message or EAP-Request/AKA’-Identity message respectively, which contains AT_ANY_ID_REQ, the UE shall return the Fast Re-authentication Identity if available as the AT_IDENTITY. Otherwise the UE shall return the Pseudonym Identity.

6.4.2.4 Handling of the Access Network Identity

6.4.2.4.1 General

The 3GPP AAA server provides the UE with the ANID in EAP signalling. The UE can also obtain the ANID by access network specific means, which are out of scope of the present document. For some access networks the ANID can also be configured into the UE and the 3GPP AAA server.

NOTE: According to 3GPP TS 33.402 [15], the ANID is used by HSS and UE to generate transformed authentication vectors and therefore the ANID needs to be identical in the HSS and in the UE. The trusted non-3GPP access network first sends the ANID to the 3GPP AAA server via the STa reference point and the 3GPP AAA server sends the ANID to HSS via the SWx reference point, see 3GPP TS 29.273 [17], and to the UE as specified in this specification.

6.4.2.4.2 ANID indication from 3GPP AAA server to UE

When the 3GPP AAA server sends an EAP Request’ or AKA-Challenge’ message to the UE, the 3GPP AAA server shall include the ANID to be used when generating transformed authentication vectors, using the AT_KDF_INPUT attribute as described in clause 8.2.2. The value and coding of this attribute is described in clause 8.1.1.

6.4.2.4.3 UE check of ANID for HRPD CDMA 2000® access networks

The UE shall apply the rules for comparison of the locally determined ANID and the one received over EAP-AKA’ as specified in IETF RFC 5448 [38]. The UE, or the user, may use the ANID as a basis for an optional decision whether the access network is authorized to serve the UE. E.g. the UE may compare the ANID against a list of preferred or barred ANIDs.

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a eHRPD network, the locally determined ANID is "HRPD". If the comparison check is successful and if either the optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; otherwise the UE shall abort the access procedure.

6.4.2.4.4 UE check of ANID for WiMAX access networks

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a WiMAX access network, the locally determined ANID is "WIMAX". If the comparison check is successful and if either the optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; otherwise the UE shall abort the access procedure.

6.4.2.4.5 UE check of ANID for WLAN access networks

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a WLAN network, the locally determined ANID is "WLAN". If the comparison check is successful and if either the optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; otherwise the UE shall abort the access procedure.

6.4.2.4.6 UE check of ANID for ETHERNET access networks

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a Ethernet network, the locally determined ANID is "ETHERNET". If the comparison check is successful and if either the optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; otherwise the UE shall abort the access procedure.

6.4.2.5 Full name for network and short name for network

When receiving the EAP-Request/AKA-Challenge message when the EAP-AKA is used or the EAP-Request/AKA’-Challenge message when the EAP-AKA’ is used, and the AT_FULL_NAME_FOR_NETWORK attribute, the AT_SHORT_NAME_FOR_NETWORK attribute or both are included, then the UE may use the contents to update appropriate information stored within the UE.

6.4.2.6 TWAN connection modes

6.4.2.6.1 General

The UE may support SCM. The UE may support MCM.

NOTE 1: The UE is allowed to support both MCM and SCM. The UE is allowed to support neither MCM nor SCM.

NOTE 2: No UE extensions are needed for TSCM.

6.4.2.6.2 Usage of single-connection mode (SCM)

If:

a) the UE supports the SCM;

b) the EAP-Request/AKA’-Challenge message includes the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1:

1) contains the message type field indicating CONNECTION_CAPABILITY; and

2) contains the item list field:

A) including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 indicating support of SCM; and

B) if the UE requests an emergency attach or an emergency handover, including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 indicating that emergency services are supported; and

c) the UE requests usage of the SCM;

then the UE:

a) shall include the AT_TWAN_CONN_MODE attribute according to clause 8.2.7.1 in the EAP-Response/AKA’-Challenge message. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the UE shall:

1) set the message type field to SCM_REQUEST; and

2) in the item list field:

A) include a CONNECTIVITY_TYPE item according to clause 8.1.4.3 indicating the requested connectivity type – PDN connection, or NSWO; and

B) if a PDN connection is requested:

i) include a ATTACHMENT_TYPE item according to clause 8.1.4.4 indicating whether an initial attach, a handover attach, an emergency attach, or an emergency handover is requested;

ii) if a PDN connection for an APN other than the default APN is requested and either an initial attach or a handover attach is requested, include an APN item according to clause 8.1.4.5 indicating the requested APN;

iii) if the initial attach or the emergency attach is requested, include a PDN_TYPE item according to clause 8.1.4.6 indicating the requested PDN type;

iv) if the handover attach or the emergency handover is requested, include a PDN_TYPE item according to clause 8.1.4.6 indicating the PDN type supported in the PDN connection to be handed over; and

v) if the UE wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the network, include a PROTOCOL_CONFIGURATION_OPTIONS item according to clause 8.1.4.9; and

b) if a PDN connection is requested, shall include the AT_RESULT_IND attribute in the EAP-Response/AKA’-Challenge message.

NOTE 1: If the UE does not include the AT_RESULT_IND attribute in the EAP-Response/AKA’-Challenge message, in case of successful authentication, then EAP-Request/AKA’-Notification message is not received and the UE is only informed about success using EAP-Success.

Upon receiving the EAP-Request/AKA’-Notification message including the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1:

– contains the message type field indicating SCM_RESPONSE; and

– contains the item list field;

the UE:

a) if the AT_NOTIFICATION attribute indicates success, shall determine the authorized connectivity type in the CONNECTIVITY_TYPE item as described in clause 8.1.4.3 included in the item list field. If the authorized connectivity type is PDN connection, the UE:

1) if the initial attach, or the handover attach is requested, shall determine the selected APN in the APN item as described in clause 8.1.4.5 included in the item list field;

2) shall determine the PDN type supported in the PDN connection in the PDN_TYPE item as described in clause 8.1.4.6 included in the item list field;

3) if a PROTOCOL_CONFIGURATION_OPTIONS item as described in clause 8.1.4.9 is included in the item list field, shall determine the protocol configuration options in the PROTOCOL_CONFIGURATION_OPTIONS item;

4) if a IPV4_ADDRESS item as described in clause 8.1.4.11 is included in the item list field, shall determine the IPv4 address allocated to the UE for the PDN connection in the IPV4_ADDRESS item;

5) if a IPV6_INTERFACE_IDENTIFIER item as described in clause 8.1.4.12 is included in the item list field, shall determine the IPv6 interface identifier allocated to the UE for the PDN connection in the IPV6_INTERFACE_IDENTIFIER item and shall use it when building the IPv6 link local address; and

6) shall determine the TWAG user plane MAC address in the TWAG_UP_MAC_ADDRESS item as described in clause 8.1.4.14 included in the item list field, and shall use the TWAG user plane MAC address for encapsulating user plane packets according to 3GPP TS 23.402 [6]; and

b) if the AT_NOTIFICATION attribute indicates failure with value 0 "General failure after authentication" or value 16384 – "General failure" as defined in IETF RFC 4187 [33] and the ACCESS_CAUSE item is included:

1) shall determine the cause of failure in the ACCESS_CAUSE item as described in clause 8.1.4.17 included the item list field:

2) if the initial attach, or the handover attach is requested, and the cause of failure is #2 "Non-3GPP access to EPC not allowed" as defined in clause 8.1.4.17, shall not retry the authentication procedure to any WLANs until switching off or the UICC containing the USIM is removed;

3) if the cause of failure is #11 "PLMN _NOT_ALLOWED" as defined in clause 8.1.4.17, shall not retry the authentication procedure from the same PLMN via WLANs according to the network selection procedures as defined in clause 5.2.2;

4) if the initial attach, or the handover attach is requested, and the cause of failure is #3 "RAT type not allowed" as defined in clause 8.1.4.17, the UE shall not retry the authentication procedure to any WLANs until switching off or the UICC containing the USIM is removed;

5) if the cause of failure is #6 "Illegal ME" as defined in clause 8.1.4.17, shall not retry the authentication procedure from the same PLMN until switching off or the UICC containing the USIM is removed; and

NOTE 2: Switching off and USIM change conditions are implemented taking into consideration the user experience aspect.

c) if the AT_NOTIFICATION attribute indicates failure as defined in bullet b) and the CAUSE item is included:

1) shall determine the cause of failure in the CAUSE item as described in clause 8.1.4.10 included the item list field;

2) if the initial attach, or the handover attach is requested, the cause of failure is #26 "Insufficient resources" and the Tw1 item is included in the item list field, shall take different actions depending on the timer value received in the Tw1 item as follows:

A) if the timer value indicates neither zero nor deactivated, shall stop timer Tw1 associated with the corresponding APN, if it is running. The UE shall start timer Tw1 (see 3GPP TS 24.244 [56]) with the value provided in the Tw1 value IE and not send another SCM_REQUEST message with the CONNECTIVITY_TYPE item indicating PDN connection and with APN item indicating the same APN until timer Tw1 expires, the timer Tw1 is stopped, or the USIM is removed;

B) if the timer value indicates that this timer is deactivated, shall not send another SCM_REQUEST message with the CONNECTIVITY_TYPE item indicating PDN connection and with APN item indicating the same APN until the UE is switched off or the USIM is removed;

C) if the timer value indicates zero, may send another SCM_REQUEST message with the CONNECTIVITY_TYPE item indicating PDN connection and with APN item indicating the same APN; and

D) if the WLAN radio is disabled when the timer Tw1 is running and if the USIM in the UE remains the same when the WLAN radio is enabled, shall behave as follows when the WLAN radio is enabled:

– let t1 be the time remaining for Tw1 timeout when the WLAN radio was disabled and let t be the time elapsed since the WLAN radio was disabled until the WLAN radio was enabled. If t1 is greater than t, then the timer shall be restarted with the value t1 – t. If t1 is equal to or less than t, then the timer need not be restarted. If the UE is not capable of determining t, then the UE shall restart the timer with the value t1;

3) if the cause of failure is #26 "Insufficient resources" and the Tw1 item is not included in the item list field, may send a SCM_REQUEST message with the CONNECTIVITY_TYPE item indicating PDN connection and with APN item indicating the same APN;

4) if the initial attach, or the handover attach is requested, and the cause of failure is #38 "Network failure" as defined in clause 8.1.4.10.2:

A) if the Tw1 item is included in the item list field, shall behave as follows:

i) if the timer value received in the Tw1 item indicates neither zero nor deactivated, shall start the Tw2 timer with the timer value provided in the Tw1 item, and shall not try again until the backoff timer expires or the UE is switched off or the UICC containing the USIM is removed;

ii) if the timer value received in the Tw1 item indicates that this timer is deactivated, shall not try again until the UE is switched off or the UICC containing the USIM is removed; and

iii) if the timer value received in the Tw1 item indicates zero, may send another SCM_REQUEST message with the CONNECTIVITY_TYPE item indicating PDN connection and with APN item indicating the same APN; and

B) if the Tw1 item is not included in the item list field, shall start an implementation specific backoff timer and not try again until the backoff timer expires or the UE is switched off or the UICC containing the USIM is removed; and

NOTE 3: Existing Tw1 item can be reused by the network to provide back off timer value to start Tw2 timer.

5) if the initial attach, or the handover attach is requested, and the cause of failure is #27 "Unknown APN" as defined in clause 8.1.4.10.2:

a) if the Tw1 item is included in the item list field, shall behave as follows:

i) if the timer value received in the Tw1 item indicates neither zero nor deactivated, shall start the Tw2 timer with the timer value provided in the Tw1 item, and shall not send another SCM_REQUEST message with the CONNECTIVITY_TYPE item indicating PDN connection and with APN item indicating the same APN to the same PLMN until the backoff timer expires or the UE is switched off or the UICC containing the USIM is removed;

ii) if the timer value received in the Tw1 item indicates that this timer is deactivated, shall not send another SCM_REQUEST message with the CONNECTIVITY_TYPE item indicating PDN connection and with APN item indicating the same APN to the same PLMN until the UE is switched off or the UICC containing the USIM is removed; and

b) if the Tw1 item is not included in the item list field, shall not retry the authentication procedure with the same WLAN for the same APN to the same PLMN until the UE is switched off or the UICC containing the USIM is removed, unless the UE has an implementation specific backoff timer. In that case, the UE shall not retry until that implementation specific timer expires.

6.4.2.6.2A Usage of single-connection mode (SCM) – emergency

If the UE needs to establish an IMS emergency session over trusted WLAN access, the UE shall:

1) if the UE already has active PDN connection, the UE shall detach first (see 3GPP TS 23.402 [6]) and then follow item 2) below to start initial attach procedure for emergency service; and

2) if the UE does not have an active PDN connection and requests usage of the SCM, the UE shall start initial attach procedure for emergency service using the procedures specified in clause 6.4.2.6.2. In addition,

a) upon receiving EAP-Request/AKA’-Challenge message:

– if the CONNECTION_MODE_CAPABILITY item in the item list field indicates support of emergency services, the UE shall respond with the EAP-Response/AKA’-Challenge message with the ATTACHMENT_TYPE item in the item list field set to "emergency attach" or "emergency handover"; or

– if the CONNECTION_MODE_CAPABILITY item in the item list field does not indicate support of emergency services, the UE shall respond with the EAP-Response/AKA’-Client-Error message as described in clause 6.4.2.6.4. The UE shall re-initiate initial attach procedure for emergency service by selecting a different WLAN supporting emergency service; or

b) upon receiving EAP-Request/3GPP-LimitedService-Init-Info message including the AT_TWAN_CONN_MODE attribute with the message type of message field indicating CONNECTION_CAPABILITY and message field contains CONNECTION_MODE_CAPABILITY item in the item list field indicating support of SCM and emergency services,

– if the UE supports the SCM and requests the usage of the SCM, the UE shall respond with the EAP-Response/3GPP-LimitedService-Init-Info message and shall include the AT_TWAN_CONN_MODE attribute with the message type field set to SCM_REQUEST and in the item list field shall:

i) include a ATTACHMENT_TYPE item indicating whether an emergency attach or emergency handover is requested;

ii) if emergency attach is requested, include a PDN_TYPE item according to clause 8.1.4.6 indicating the requested PDN type;

iii) if emergency handover attach is requested, include a PDN_TYPE item according to clause 8.1.4.6 indicating the PDN type supported in the PDN connection to be handed over; and

iv) if the UE wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the network, include a PROTOCOL_CONFIGURATION_OPTIONS item according to clause 8.1.4.9; and

c) upon receiving the EAP-Request/3GPP-LimitedService-Notif message including the AT_TWAN_CONN_MODE attribute with the message type field of the message field indicating SCM_RESPONSE and the item list field:

– the UE shall:

i) determine the PDN type supported in the PDN connection in the PDN_TYPE item as described in clause 8.1.4.6 included in the item list field;

ii) determine the protocol configuration options in the PROTOCOL_CONFIGURATION_OPTIONS item if a PROTOCOL_CONFIGURATION_OPTIONS item as described in clause 8.1.4.9 is included in the item list field;

iii) if a IPV4_ADDRESS item as described in clause 8.1.4.11 is included in the item list field, determine the IPv4 address allocated to the UE for the PDN connection in the IPV4_ADDRESS item;

iv) if a IPV6_INTERFACE_IDENTIFIER item as described in clause 8.1.4.12 is included in the item list field, determine the IPv6 interface identifier allocated to the UE for the PDN connection in the IPV6_INTERFACE_IDENTIFIER item and use it when building the IPv6 link local address; and

v) determine the TWAG user plane MAC address in the TWAG_UP_MAC_ADDRESS item as described in clause 8.1.4.14 included in the item list field, and use the TWAG user plane MAC address for encapsulating user plane packets according to 3GPP TS 23.402 [6]; and

d) if the UE had requested emergency attach or emergency handover of an emergency session, upon receiving the EAP-Request/AKA’-Notification message, if the AT_NOTIFICATION attribute indicates failure, the UE shall detach and then perform initial attach procedure for emergency service by selecting a different WLAN supporting emergency service.

6.4.2.6.3 Usage of multi-connection mode (MCM)

If:

a) the UE supports the MCM;

b) the EAP-Request/AKA’-Challenge message includes the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1:

1) contains the message type field indicating CONNECTION_CAPABILITY; and

2) contains the item list field:

A) including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 indicating support of MCM;

B) including the SUPPORTED_WLCP_TRANSPORTS item as described in clause 8.1.4.15; and

C) if the UE requests an emergency attach or an emergency handover, including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 indicating that emergency services are supported;

c) at least one WLCP transport indicated as supported in the SUPPORTED_WLCP_TRANSPORTS item is also supported by the UE; and

d) the UE requests usage of the MCM;

then the UE:

1) shall set the message type field to MCM_REQUEST; and

2) in the item list field:

A) if the UE requests an emergency attach or an emergency handover, shall include an ATTACHMENT_TYPE item according to clause 8.1.4.4 indicating whether an emergency attach, or an emergency handover is requested; and

b) shall include the AT_RESULT_IND attribute in the EAP-Response/AKA’-Challenge message.

Upon receiving the EAP-Request/AKA’-Notification message including the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 where the message field as described in clause 8.1.4.1:

– contains the message type field indicating MCM_RESPONSE; and

– contains the item list field;

the UE:

a) if the AT_NOTIFICATION attribute indicates success:

1) shall determine the NSWO authorization in the AUTHORIZATIONS item as described in clause 8.1.4.7 included in the item list field;

2) shall determine the TWAG control plane address(es) in the TWAG_CP_ADDRESS item as described in clause 8.1.4.13 included in the item list field; and

3) shall derive the WLCP key as described in Annex A.3 in 3GPP TS 33.402 [15]; and

NOTE: After receiving EAP Success message terminating the EAP procedures after successful authentication and authorization for MCM access to EPC, the UE establishes a DTLS connection with the TWAG and initiates WLCP procedures according to 3GPP TS 24.244 [56].

b) if the AT_NOTIFICATION attribute indicates failure, shall determine the cause of failure in the ACCESS_CAUSE or CAUSE item as described in clause 8.1.4.17 and 8.1.4.10 included in the item list field.

6.4.2.6.3A Usage of multi-connection mode (MCM) – emergency

If the UE needs to establish an IMS emergency session over trusted WLAN access, the UE shall:

1) if the UE already has active PDN connection:

– if the TWAN does not supports emergency service, the UE shall detach first and then follow item 2) below to start initial attach procedure for emergency service and selecting a WLAN supporting Emergency service; or

– if the connected TWAN supports emergency service, the UE shall initiate PDN connectivity establishment procedures as specified in 3GPP TS 24.244 [56].

2) if the UE does not have an active PDN connection and requests usage of the MCM, the UE shall start initial attach procedure for emergency service using the procedures specified in clause 6.4.2.6.3. In addition,

a) upon receiving EAP-Request/AKA’-Challenge message:

– if the UE supports the MCM and requests the usage of the MCM and

i) message field of the AT_TWAN_CONN_MODE attribute contains SUPPORTED_WLCP_TRANSPORTS item as described in clause 8.1.4.15; and

ii) at least one WLCP transport indicated as supported in the SUPPORTED_WLCP_TRANSPORTS item is also supported by the UE,

the UE shall respond with the EAP-Response/3GPP-LimitedService-Init-Info message and shall:

i) include the AT_TWAN_CONN_MODE attribute with the message type field set to MCM_REQUEST;

c) upon receiving the EAP-Request/3GPP-LimitedService-Notif message including the AT_TWAN_CONN_MODE attribute with the message type of message field indicating MCM_RESPONSE and the item list field:

– the UE shall:

i) determine the TWAG control plane address(es) in the TWAG_CP_ADDRESS item as described in clause 8.1.4.13 included in the item list field;

ii) derive the WLCP key as described in Annex A.3 in 3GPP TS 33.402 [15].

6.4.2.6.3B Usage of transparent single-connection mode (TSCM) – emergency

The emergency session is not supported for the UE using TSCM mode.

NOTE: If the UE in TSCM mode already has active PDN connection, the UE remains connected.

6.4.2.6.4 Network support not available

If the EAP-Request/AKA’-Challenge message does not include the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1, then only TSCM is available.

If the UE supports SCM, the UE does not support MCM, and the EAP-Request/AKA’-Challenge message includes the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1:

1) contains the message type field indicating CONNECTION_CAPABILITY; and

2) contains the item list field including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 not indicating support of SCM;

then only TSCM is available.

If the UE does not support SCM, the UE supports MCM, and the EAP-Request/AKA’-Challenge message includes the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1:

1) contains the message type field indicating CONNECTION_CAPABILITY; and

2) contains the item list field including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 not indicating support of MCM;

then only TSCM is available.

If the UE does not support SCM, the UE supports MCM, the EAP-Request/AKA’-Challenge message includes the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1:

1) contains the message type field indicating CONNECTION_CAPABILITY; and

2) contains the item list field:

A) including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 indicating support of MCM; and

B) including the SUPPORTED_WLCP_TRANSPORTS item as described in clause 8.1.4.15;

and none of the WLCP transport indicated as supported in the SUPPORTED_WLCP_TRANSPORTS item is also supported by the UE, then only TSCM is available.

If only TSCM is available:

a) if the UE does not request an emergency attach, the UE does not request an emergency handover and the UE is willing to use TSCM, the UE shall act as in TSCM; and

b) if the UE requests an emergency attach or the UE requests an emergency handover or the UE is unwilling to use TSCM, the UE shall send EAP-Response/AKA’-Client-Error message.

NOTE: In TSCM, successful EAP-AKA’ authentication triggers creation of a PDN connection to the default APN. The UE can be unwilling to use the PDN connection to the default APN e.g. because the UE needs to perform handover of a PDN connection, because the UE needs to establish a PDN connection to an APN other than the default APN, because the UE needs to establish multiple PDN connections, or because the UE has no usage for the PDN connection to the default APN and wants to avoid any possible charges related to the PDN connection to the default APN.

If the UE requests an emergency attach or an emergency handover, and the EAP-Request/AKA’-Challenge message includes the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1:

1) contains the message type field indicating CONNECTION_CAPABILITY; and

2) contains the item list field including the CONNECTION_MODE_CAPABILITY item as described in clause 8.1.4.8 not indicating support of emergency services;

then the UE shall send EAP-Response/AKA’-Client-Error message.

6.4.2.7 Mobile Equipment Identity Signalling

If the UE receives:

– an EAP-Request/AKA’-Challenge message; or

– an EAP-Request/3GPP-LimitedService-Init-Info message;

containing the AT_DEVICE_IDENTITY attribute and the Identity Type field of the received AT_DEVICE_IDENTITY attribute is set to either ‘IMEI’ or ‘IMEISV’ and the Identity Value field is empty, then if the UE’s Mobile Equipment Identity IMEI or IMEISV is available, the UE shall include IMEI or IMEISV in the AT_DEVICE_IDENTITY attribute in:

– the EAP-Response/AKA’-Challenge message; or

– the EAP-Response/3GPP-LimitedService-Init-Info message;

as follows:

– if IMEISV are available, the UE shall include IMEISV in the AT_DEVICE_IDENTITY attribute. The Identity Type field of the AT_DEVICE_IDENTITY attribute shall be set to ‘IMEISV’: and

– if IMEI is available and IMEISV is not available, the UE shall include IMEI in the AT_DEVICE_IDENTITY attribute. The Identity Type field of the AT_DEVICE_IDENTITY attribute shall be set to ‘IMEI’.

The AT_DEVICE_IDENTITY attribute shall be sent as an encrypted attribute and included in the value field of the AT_ENCR_DATA attribute as described in IETF RFC 4187 [33].

The detailed coding of the AT_DEVICE_IDENTITY attribute is described in clause 8.2.8.1.

6.4.3 3GPP AAA server procedures

6.4.3.1 Identity Management

The 3GPP AAA selects the pseudonym identity or the Fast Re-authentication Identity and returns the identity to the UE during the Authentication procedure as specified in 3GPP TS 33.402 [15]. The 3GPP AAA server shall maintain a mapping between the UE’s permanent identity and the pseudonym identity and between the UE’s permanent identity and the Fast Re-authentication Identity.

6.4.3.1A Identity Management – emergency session

Upon receiving a request from the UE for emergency session establishment, if

– IMSI is provided to the network but IMSI authentication cannot proceed or IMSI authentication has failed or the 3GPP AAA server cannot determine if authentication is successful; and

– the 3GPP AAA server is configured to accept unauthenticated emergency session over WLAN,

the 3GPP AAA server requests IMEI from the UE as specified in clause 6.4.3.6 using the EAP-Request/3GPP-LimitedService-Init-Info message.

6.4.3.2 EAP-AKA and EAP-AKA’ based Authentication

The 3GPP AAA server shall support EAP AKA based authentication as specified in IETF RFC 4187 [33] and EAP-AKA’ based authentication as specified in IETF RFC 5448 [38]. 3GPP TS 33.402 [15] specifies the conditions under which one or the other of these two methods is used. If the UE provides an explicit indication for the supported mobility protocols and the network supports multiple IP mobility mechanisms, the network shall select the protocol to be used and communicate the decision to the UE as defined in clause 6.3.3.1.2.

For WLAN access, after the UE has been successfully authenticated and the EPC access and Non-Seamless WLAN Offload are not authorized for the UE, the 3GPP AAA Server shall invoke an EAP-Request/AKA’-Notification dialogue and indicate this to the UE by using the AT_NOTIFICATION attribute value 1031 – "User has not subscribed to the requested service" as defined in IETF RFC 4187 [33].

6.4.3.3 Full authentication and Fast Re-authentication

The 3GPP AAA shall support full re-authentication and fast re-authentication as specified in IETF RFC 4187 [33].

The decision to use the fast re-authentication process is taken by the home network (i.e. the 3GPP AAA server) and is based on operator policies. If fast re-authentication is to be used, the home network shall indicate this to the UE by providing the Fast Re-authentication Identity to the UE during the authentication process.

When initiating an authentication, the home network shall indicate the type of authentication required by including either AT_PERMANENT_ID_REQ or AT_FULLAUTH_ID_REQ for Full authentication and AT_ANY_ID_REQ for Fast re-authentication in the EAP-Request/AKA_Identity message or the EAP-Request/AKA’-Identity message respectively.

The home network (i.e. the 3GPP AAA server) may upon receiving the Fast Re-authentication Identity in AT_IDENTITY, decide to proceed with the fast re-authentication or choose instead to initiate a full authentication. This decision is based on operator policies.

6.4.3.4 Full name for network and short name for network

The 3GPP AAA server may include the AT_FULL_NAME_FOR_NETWORK attribute, the AT_SHORT_NAME_FOR_NETWORK attribute or both in the EAP-Request/AKA-Challenge message when the EAP-AKA is used and in the EAP-Request/AKA’-Challenge message when the EAP-AKA’ is used.

The detailed coding of the AT_FULL_NAME_FOR_NETWORK attribute and the AT_SHORT_NAME_FOR_NETWORK is described in clause 8.2.5.

6.4.3.5 TWAN connection modes

6.4.3.5.1 General

The 3GPP AAA server may support the single-connection mode (SCM).

The 3GPP AAA server may support the multi-connection mode (MCM).

If the network supports SCM, MCM or both, the 3GPP AAA server shall include the AT_TWAN_CONN_MODE attribute according to clause 8.2.7.1 and the AT_RESULT_IND attribute in the EAP-Request/AKA’-Challenge message. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

a) set the message type field to CONNECTION_CAPABILITY; and

b) in the item list field:

1) include a CONNECTION_MODE_CAPABILITY item according to clause 8.1.4.8 indicating whether the network supports TSCM, SCM, MCM or any combination of them and indicating whether the network supports the emergency services; and

2) if the network supports MCM, include a SUPPORTED_WLCP_TRANSPORTS item according to clause 8.1.4.15 indicating WLCP transport(s) supported by the TWAG.

6.4.3.5.1A Emergency session connection mode negotiation for unauthenticated UEs

If the 3GPP AAA server is configured to accept unauthenticated emergency session over WLAN and IMEI was received or IMSI was received but IMSI authentication cannot proceed, the 3GPP AAA server shall initiate connection mode negotiation with the UE as follows:

– if the 3GPP AAA server supports SCM, MCM or both, the 3GPP AAA server shall include the AT_TWAN_CONN_MODE attribute according to clause 8.2.7.1 in the EAP-Request/3GPP-LimitedService-Init-Info message. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

a) set the message type field to CONNECTION_CAPABILITY; and

b) in the item list field:

1) include a CONNECTION_MODE_CAPABILITY item according to clause 8.1.4.8 indicating whether the network supports SCM, MCM or any combination of them, and indicating emergency service is supported; and

2) if the network supports MCM, include a SUPPORTED_WLCP_TRANSPORTS item according to clause 8.1.4.15 indicating WLCP transport(s) supported by the TWAG.

6.4.3.5.2 Usage of single-connection mode (SCM)

– the 3GPP AAA server supports SCM;

– the EAP-Response/AKA’-Challenge message includes the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1 contains the message type field indicating SCM_REQUEST; and

– the authentication was successful;

then the 3GPP AAA server:

– if the ATTACHMENT_TYPE item according to clause 8.1.4.4 indicating an emergency attach, or an emergency handover is included in the item list field of the message field, shall identify that the attach is for emergency services; and

– shall trigger the TWAN to establish the connectivity of the requested connectivity type according to 3GPP TS 23.402 [6].

If:

– the 3GPP AAA server authorizes the requested connectivity; and

– the EAP-Response/AKA’-Challenge message includes the AT_RESULT_IND attribute;

then the 3GPP AAA server shall invoke an EAP-Request/AKA’-Notification dialogue. The 3GPP AAA server shall construct the EAP-Request/AKA’-Notification message as follows:

a) indicate success in the AT_NOTIFICATION attribute; and

b) include the AT_TWAN_CONN_MODE attribute described in clause 8.2.7.1. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

1) set the message type field to SCM_RESPONSE; and

2) in the item list field:

A) include a CONNECTIVITY_TYPE item as described in clause 8.1.4.3 indicating the authorized connectivity type. Only one connectivity type is indicated; and

B) if a PDN connection was authorized:

i) if the initial attach, or the handover attach is requested, include an APN item according to clause 8.1.4.5 indicating the APN of the authorized PDN connection;

ii) include a PDN_TYPE item according to clause 8.1.4.6 indicating the PDN type(s) selected in the authorized PDN connection;

iii) if the 3GPP AAA server wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the UE, include a PROTOCOL_CONFIGURATION_OPTIONS item according to clause 8.1.4.9;

iv) if an IPv4 address is allocated to the UE for the PDN connection, include a IPV4_ADDRESS item according to clause 8.1.4.11;

v) if an IPv6 interface identifier is allocated to the UE for the PDN connection, include a IPV6_INTERFACE_IDENTIFIER item according to clause 8.1.4.12; and

vi) include a TWAG_UP_MAC_ADDRESS item according to clause 8.1.4.14.

If the 3GPP AAA server does not authorize the requested connectivity and if:

– the attach is not for emergency session; or

– the attach is for emergency session and if the 3GPP AAA server is not configured to accept unauthenticated emergency session over WLAN,

NOTE: The case where the 3GPP AAA server does not authorize the request but is configured to accept unauthenticated emergency session over WLAN is specified in clause 6.4.3.5.2A.

then the 3GPP AAA server shall invoke an EAP-Request/AKA’-Notification dialogue. The 3GPP AAA server shall construct the EAP-Request/AKA’-Notification message as follows:

a) indicate failure in the AT_NOTIFICATION attribute; and

b) include the AT_TWAN_CONN_MODE attribute described in clause 8.2.7.1. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

1) set the message type field to SCM_RESPONSE;

2) in the item list field, include a ACCESS_CAUSE or CAUSE item according to clause 8.1.4.17 and 8.1.4.10 indicating the cause of failure;

3) if the initial attach, or the handover attach is requested, the cause of failure is #26 "Insufficient resources" and a value of backoff timer is to be provided to the UE for the PDN connection, include a Tw1 item according to clause 8.1.4.16;

3A) if the initial attach, or the handover attach is requested, the cause of failure is #38 "Network failure" or #27 "unknown APN" and a value of backoff timer is to be provided to the UE for the PDN connection, include a Tw1 item according to clause 8.1.4.16;

4) if the 3GPP AAA Server receives DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTION sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using "Non-3GPP access to EPC not allowed" value in the ACCESS_CAUSE item;

5) if the 3GPP AAA Server receives DIAMETER_ERROR_ROAMING_NOT_ALLOWED sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using "PLMN not allowed" value in the ACCESS_CAUSE item;

6) if the 3GPP AAA Server receives DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using #27 "Unknown APN" value in the CAUSE item;

7) if the 3GPP AAA Server receives DIAMETER_ERROR_RAT_TYPE_NOT_ALLOWED sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using #3 "RAT type not allowed" value in the ACCESS_CAUSE item; and

8) if the 3GPP AAA Server receives DIAMETER_UNABLE_TO_COMPLY sent by HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using #38 "Network failure" in the CAUSE item.

6.4.3.5.2A Usage of single-connection mode (SCM) – emergency

If the 3GPP AAA Server supports IMS Emergency sessions over WLAN, the 3GPP AAA server shall:

– if IMSI was received and IMSI authentication can proceed, the 3GPP AAA server invokes an EAP-Request/AKA’-Notification dialogue to indicate success or failure to the UE as described in clause 6.4.3.5.2;

– if IMSI was received but IMSI authentication cannot proceed, then

A) if the 3GPP AAA server is configured to accept unauthenticated emergency session over WLAN:

a) the 3GPP AAA server sends EAP Request/3GPP-LimitedService-Init-Info message as specified in clause 6.4.3.5.1A;

b) upon receiving the EAP-Response/3GPP-LimitedService-Init-Info message including the AT_TWAN_CONN_MODE attribute with the message type of message field indicating SCM_REQUEST and the item list field, the 3GPP AAA server shall include the AT_TWAN_CONN_MODE attribute according to clause 8.2.7.1 in the EAP-Request/3GPP-LimitedService-Notif message. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

i) set the message type field to SCM_RESPONSE; and

ii) in the item list field:

1) include the PDN type supported in the PDN connection in the PDN_TYPE item as described in clause 8.1.4.6 in the item list field;

2) include the protocol configuration options in the PROTOCOL_CONFIGURATION_OPTIONS item if a PROTOCOL_CONFIGURATION_OPTIONS item as described in clause 8.1.4.9 is in the item list field;

3) if an IPv4 address is allocated to the UE for the PDN connection, include a IPV4_ADDRESS item according to clause 8.1.4.11;

4) if an IPv6 interface identifier is allocated to the UE for the PDN connection, include a IPV6_INTERFACE_IDENTIFIER item according to clause 8.1.4.12; and

5) include a TWAG_UP_MAC_ADDRESS item according to clause 8.1.4.14; and

c) upon receiving the EAP-Response/3GPP-LimitedService-Notif message, the 3GPP AAA server shall generate the MSK using IMEI as described in clause 13.4 in 3GPP TS 33.402 [15] and send EAP Success message to the UE to allow the UE to proceed with emergency session establishment; or

B) if the 3GPP AAA server is not configured to accept unauthenticated emergency session over WLAN, the 3GPP AAA server shall reject the emergency session request and return an EAP Failure message to the UE; or

– if IMEI was received,

A) if the 3GPP AAA server is configured to accept unauthenticated emergency session over WLAN:

a), the 3GPP AAA server sends EAP Request/3GPP-LimitedService-Init-Info message to as specified in clause 6.4.3.5.1A;

i) set the message type field to SCM_RESPONSE; and

ii) in the item list field:

1) include the PDN type supported in the PDN connection in the PDN_TYPE item as described in clause 8.1.4.6 in the item list field;

2) include the protocol configuration options in the PROTOCOL_CONFIGURATION_OPTIONS item if a PROTOCOL_CONFIGURATION_OPTIONS item as described in clause 8.1.4.9 is in the item list field;

3) if an IPv4 address is allocated to the UE for the PDN connection, include a IPV4_ADDRESS item according to clause 8.1.4.11;

4) if an IPv6 interface identifier is allocated to the UE for the PDN connection, include a IPV6_INTERFACE_IDENTIFIER item according to clause 8.1.4.12; and

5) include a TWAG_UP_MAC_ADDRESS item according to clause 8.1.4.14; and

6.4.3.5.3 Usage of multi-connection mode (MCM)

If:

a) the 3GPP AAA server supports MCM;

b) if the EAP-Response/AKA’-Challenge message includes:

1) the AT_TWAN_CONN_MODE attribute as described in clause 8.2.7.1 wherein the message field as described in clause 8.1.4.1 contains the message type field indicating MCM_REQUEST; and

2) the AT_RESULT_IND attribute;

c) the 3GPP AAA server authorizes the request. If the ATTACHMENT_TYPE item according to clause 8.1.4.4 indicating an emergency attach, or an emergency handover is included in the item list field of the message field, the 3GPP AAA server shall identify that the attach is for emergency services; and

d) the authentication was successful;

then the 3GPP AAA server shall invoke an EAP-Request/AKA’-Notification dialogue. The 3GPP AAA server shall construct the EAP-Request/AKA’-Notification message as follows:

a) indicate success in the AT_NOTIFICATION attribute; and

b) include the AT_TWAN_CONN_MODE attribute according to clause 8.2.7.1. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

1) set the message type field to MCM_RESPONSE; and

2) in the item list field:

A) include an AUTHORIZATIONS item according to clause 8.1.4.7 indicating whether UE is authorized to use NSWO; and

B) include a TWAG_CP_ADDRESS item according to clause 8.1.4.13 indicating the TWAG control plane address.

If the 3GPP AAA server does not authorize the request and if

– the attach is not for emergency services; or

– the attach is for emergency services and if the 3GPP AAA server is not configured to accept unauthenticated emergency session over WLAN,

NOTE: The case where the 3GPP AAA server does not authorize the request but is configured to accept unauthenticated emergency session over WLAN is specified in clause 6.4.3.5.3A.

then the 3GPP AAA server shall invoke an EAP-Request/AKA’-Notification dialogue. The 3GPP AAA server shall construct the EAP-Request/AKA’-Notification message as follows:

a) indicate failure in the AT_NOTIFICATION attribute; and

b) include the AT_TWAN_CONN_MODE attribute described in clause 8.2.7.1. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

1) set the message type field to MCM_RESPONSE;

2) in the item list field, include a ACCESS_CAUSE or CAUSE item according to clause 8.1.4.17 and 8.1.4.10 indicating the cause of failure;

3) if the 3GPP AAA Server receives DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTION sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using "Non-3GPP access to EPC not allowed" value in the ACCESS_CAUSE item;

4) if the 3GPP AAA Server receives DIAMETER_ERROR_ROAMING_NOT_ALLOWED sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using "PLMN not allowed" value in the ACCESS_CAUSE item;

5) if the 3GPP AAA Server receives DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using #27 "Unknown APN" value in the CAUSE item;

6) if the 3GPP AAA Server receives DIAMETER_ERROR_RAT_TYPE_NOT_ALLOWED sent by the HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using #3 "RAT type not allowed" value in the ACCESS_CAUSE item; and

7) if the 3GPP AAA Server receives DIAMETER_UNABLE_TO_COMPLY sent by HSS as specified in 3GPP TS 29.273 [17], indicate this to the UE by using #38 "Network failure" in the CAUSE item.

6.4.3.5.3A Usage of multi-connection mode (MCM) – emergency

If the 3GPP AAA Server supports IMS Emergency sessions over WLAN, the 3GPP AAA server shall:

– if IMSI was received and IMSI authentication can proceed, the 3GPP AAA server invokes an EAP-Request/AKA’-Notification dialogue to indicate success to the UE as described in clause 6.4.3.5.3;

– if IMSI was received but IMSI authentication cannot proceed, then

A) if the 3GPP AAA server is configured to accept unauthenticated emergency session over WLAN:

a), the 3GPP AAA server sends EAP Request/3GPP-LimitedService-Init-Info message as specified in clause 6.4.3.5.1A;

i) set the message type field to SCM_RESPONSE; and

ii) in the item list field:

1) include the TWAG control plane address(es) in the TWAG_CP_ADDRESS item as described in clause 8.1.4.13 in the item list field; and

– if IMEI was received,

A) if the 3GPP AAA server is configured to accept unauthenticated emergency session over WLAN:

a), the 3GPP AAA server sends EAP Request/3GPP-LimitedService-Init-Info message as specified in clause 6.4.3.5.1A;

b) upon receiving the EAP-Response/3GPP-LimitedService-Init-Info message including the AT_TWAN_CONN_MODE attribute with the message type of message field indicating MCM_REQUEST and the item list field, the 3GPP AAA server shall include the AT_TWAN_CONN_MODE attribute according to clause 8.2.7.1 in the EAP-Request/3GPP-LimitedService-Notif message. In the message field according to clause 8.1.4.1 of the AT_TWAN_CONN_MODE attribute, the 3GPP AAA server shall:

i) set the message type field to MCM_RESPONSE; and

ii) in the item list field:

1) include the TWAG control plane address(es) in the TWAG_CP_ADDRESS item as described in clause 8.1.4.13 in the item list field; and

6.4.3.5.3B Usage of transparent single-connection mode (TSCM) – emergency

The emergency session is not supported for the UE using TSCM mode.

6.4.3.5.4 Network support not available

NOTE: If the network does not support a TWAN connection mode and the UE needs to request usage of the not supported TWAN connection mode, upon sending EAP-Request/AKA’-Challenge message, the network receives EAP-Response/AKA’-Client-Error message. Handling defined in IETF RFC 5448 [38] applies for the EAP-Response/AKA’-Client-Error message.

6.4.3.6 Mobile Equipment Identity Signalling

If the network supports Mobile Equipment Identity signalling over trusted WLAN, the 3GPP AAA server shall include the AT_DEVICE_IDENTITY attribute in:

– the EAP-Request/AKA’-Challenge message; or

– the EAP-Request/3GPP-LimitedService-Init-Info message;

with the Identity Type field set to either ‘IMEI’ or ‘IMEISV’ and an empty Identity Value field to request the UE to provide the Mobile Equipment Identity indicated in the Identity Type.

Upon receiving:

– the EAP-Response/AKA’-Challenge message; or

– the EAP-Response/3GPP-LimitedService-Init-Info message;

from the UE, if the AT_DEVICE_IDENTITY attribute is included and Identity Type field is set to either ‘IMEI’ or ‘IMEISV’, then the 3GPP AAA server shall forward the received Mobile Equipment Identity to the TWAN as specified in 3GPP TS 29.273 [17].

6.4.4 Multiple PDN support for trusted non-3GPP access

Connectivity to multiple PDNs via trusted non-3GPP access is supported in the EPS when the network policies, the non-3GPP access and the user subscription allow it.

NOTE 1: In 3GPP, there is a limitation to the maximum number of simultaneous PDN connections per UE caused by the number of EPS bearer identities (see clause 11.2.3.1.5 of 3GPP TS 24.007 [48]). Not complying with this limitation when accessing non-3GPP access can lead to unexpected consequences, e.g. connectivity loss in case of handover to 3GPP access. The maximum number of PDN connection via trusted non-3GPP access is independent from the maximum number of active EPS bearer contexts for 3GPP access (see clause 6.5.1A of 3GPP TS 24.301 [10]).

If the UE supports dynamic mobility management selection the UE shall use the same mobility protocol when multiple connections are established, see 3GPP TS 23.402 [6].

When the UE accesses EPC via S2a using trusted non-3GPP IP access and establishes connections to additional PDNs, the UE shall send a trigger for additional PDN connectivity specific to the non-3GPP access. The UE shall include an APN in this trigger to connect to the desired PDN. The UE shall also indicate the Attach Type to the trusted non-3GPP access during additional PDN connectivity. The Attach Type shall distinguish between Initial Attach and Handover Attach. For the multi-connection mode used via trusted WLAN access network, the PDN connection establishment procedures are specified in 3GPP TS 24.244 [56].

NOTE 2: The indication about Attach Type is non-3GPP access network specific and its coding is out of scope of this specification.

NOTE 3: The trigger for additional PDN connectivity is non-3GPP access network specific and its coding is out of scope of this specification.

When the UE accesses EPC via S2c using non-3GPP IP access, the UE shall follow the procedures described in 3GPP TS 24.303 [11] to connect to multiple PDNs.

If the UE accesses EPC via S2a using non-3GPP IP access and it is handing over from a source access network to a target non-3GPP IP access and the UE has more than one PDN connection to a given APN in the source access network, the UE shall transfer all the PDN connections for the given APN to the target trusted non-3GPP access network as specified in 3GPP TS 23.402 [6].

If multiple PDN connections to a single APN are not supported over the target trusted non-3GPP access network, only one PDN connection to the given APN shall be established in the target non-3GPP access as specified in 3GPP TS 23.402 [6]. If multiple PDN connection requests to the same APN are received but the target trusted non-3GPP access network does not support multiple PDN connections to the same APN, the network shall reject the additional PDN connection requests to the same APN received from the UE when one PDN connection to the same APN has already been established. The UE shall determine which PDN connection is re-established in the non-3GPP access based on the home address information (i.e. IPv4 address or IPv6 prefix or both) provided by the network.

NOTE 4: The protocol details of the PDN connection reject procedure is non-3GPP access network specific and its coding is outside the scope of this specification. For the multi-connection mode used via trusted WLAN access network, the protocol details of the PDN connection reject procedure is specified in 3GPP TS 24.244 [56]

NOTE 5: When UE supporting IP address preservation for NBM with multiple PDN connections to the same APN hands over to the non-3GPP access network, the UE can, as an implementation option, prioritise the re-establishment for a particular PDN connection before re-establishing the remaining PDN connections. The way a UE prioritizes a particular PDN connection is non-3GPP access network specific and its coding is out of scope of this specification. Another implementation option can be to send multiple re-establishment requests concurrently.

NOTE 6: Any unsuccessful re-establishment of any of the multiple PDN connections to the same APN can be managed in an implementation specific manner avoiding UE making repeated re-establishment attempts to the network.

If the UE did not handover all the PDN connections for a given APN to the target trusted non-3GPP access network, the network may disconnect the remaining PDN connections for that given APN after an implementation dependent time.

6.5 Authentication and authorization for accessing EPC via an untrusted non-3GPP access network

6.5.1 General

In order to attach to the evolved packet core network (EPC) via untrusted non-3GPP IP access, the UE first needs to be configured with a local IP address from the untrusted non-3GPP access network.

During the attach to the untrusted non-3GPP access, the operator of the non-3GPP access network may optionally require to perform a 3GPP based access authentication as specified in 3GPP TS 33.402 [15].

Once the UE is configured with a local IP address, the UE shall select the Evolved Packet Data Gateway (ePDG) as described in clause 7.2.1 and shall initiate the IPsec tunnel establishment procedure as described in clause 7.2.2. During these steps authentication and authorization for access to EPC shall be performed.

6.5.2 Full authentication and authorization

6.5.2.1 General

During the establishment of the IPSec tunnel between the UE and the ePDG, 3GPP based authentication signalling for untrusted non-3GPP access to the EPC shall be exchanged between the UE and the 3GPP AAA server in the EPC to ensure mutual authentication of the user and the EPC.

Authorization of EPC access shall be performed by the 3GPP AAA server upon successful user authentication.

The access authentication signalling between the UE, ePDG and the 3GPP AAA server shall be based on EAP-AKA as specified in IETF RFC 4187 [33] and is further detailed in 3GPP TS 33.402 [15], 3GPP TS 29.273 [17] and procedural descriptions in clauses 6.5.2.2, 6.5.2.4 and 6.5.2.3.

6.5.2.2 UE procedures

6.5.2.2.1 General

When accessing the EPC via the ePDG, the UE shall exchange EAP-AKA signalling with the 3GPP AAA server as specified in 3GPP TS 33.402 [15].

NOTE: the EAP payload exchanged between UE and 3GPP AAA server is transported within the IKEv2 messages exchanged with ePDG as described in clause 7.2.2.

After the UE has been successfully authenticated, if the UE receives EAP-Request/AKA-Notification dialogue with AT_NOTIFICATION attribute value 1031 – "User has not subscribed to the requested service" as defined in IETF RFC 4187 [33], the UE shall not initiate the EPC access procedure to same ePDG until switching off or the UICC containing the USIM is removed.

NOTE: Swittching off and USIM change conditions are implemented taking into consideration the user experience aspect.

6.5.2.2.2 EAP AKA

6.5.2.2.2.1 Identity management

The support of user identity privacy as defined in IETF RFC 4187 [33] and based on temporary identity is mandatory for the UE.

As defined in 3GPP TS 33.402 [15], the UE sends the user identity (in the IDi payload) in the first message of the IKE_AUTH phase. The user identity sent by the UE in the IDi payload depends on the presence of the temporary identity as defined in IETF RFC 4187 [33]:

– If valid fast re-authentication identity is available, the UE shall use the fast re-authentication NAI;

– Otherwise if valid pseudonym is available, the UE shall use the pseudonym NAI;

– Otherwise the UE shall use the permanent IMSI-based or IMEI-based NAI.

The temporary identities shall be in the form of a NAI, as specified in 3GPP TS 23.003 [3] clause 19. The permanent identity shall be in the form of a NAI in which username is derived from IMSI or IMEI as defined in 3GPP TS 23.003 [3]. IETF RFC 4187 [33] defines the leading digits to identify the authentication mechanism. The leading digit defined for EAP-AKA authentication shall be used in the NAI for both the temporary identities and the permanent identity.

The UE after successful EAP authentication may store the new temporary identity(ies) received in AT_ENCR_DATA attribute together with the fast re-authentication parameters (new master key, transient EAP keys and counter value) in the non-volatile memory of the UE or in the USIM as specified in 3GPP TS 31.102 [45]. In this later case the pseudonym is stored in the "Pseudonym" data file and the fast re-authentication identity, new master key, transient EAP keys and counter value in the "Re-authentication identity" data file.

If no new temporary identity was received in AT_ENCR_DATA attribute of a successful EAP authentication, the stored temporary identity becomes invalid and the UE shall not send this temporary identity at the next EAP authentication. In case the temporary identity is stored in the USIM, the UE shall set the username of the corresponding temporary identity field to the "deleted" value (hexadecimal value FF) to indicate that this temporary identity is invalid as specified in 3GPP TS 23.003 [3].

6.5.2.2.2.2 Protected result indications

The UE shall support protected result indications (i.e. MAC protected) as specified in IETF RFC 4187 [33].

6.5.2.3 3GPP AAA server procedures

6.5.2.3.1 General

During the authentication of the UE for accessing the EPC via the ePDG, the 3GPP AAA server shall initiate EAP-AKA based authentication with the UE as specified in 3GPP TS 33.402 [15].

After the UE has been successfully authenticated and the EPC access is not authorized for the UE, the 3GPP AAA Server shall invoke an EAP-Request/AKA-Notification dialogue and indicate this to the UE by using the AT_NOTIFICATION attribute value 1031 – "User has not subscribed to the requested service" as defined in IETF RFC 4187 [33].

6.5.2.3.2 EAP-AKA

6.5.2.3.2.1 Identity management

The support of user identity privacy is mandatory for the 3GPP AAA server. The usage of this feature depends on operator’s policies.

If user identity privacy is used, the 3GPP AAA server shall send new encrypted temporary identity (pseudonym and/ or fast re-authentication identity) to the UE in every EAP authentication procedure. The 3GPP AAA selects the pseudonym identity or the Fast Re-authentication Identity and returns the identity to the UE during the Authentication procedure as specified in 3GPP TS 33.402 [15]. The 3GPP AAA server shall maintain a mapping between the UE’s permanent identity and the pseudonym identity and between the UE’s permanent identity and the Fast Re-authentication Identity.

6.5.2.3.2.2 EAP AKA based authentication

The 3GPP AAA server shall support EAP AKA based authentication as specified in IETF RFC 4187 [33].

6.5.2.3.2.3 Fast re-authentication

The 3GPP AAA server shall support fast re-authentication as specified in the IETF RFC 4187 [33]. Fast re-authentication should be enabled in the 3GPP AAA server. The decision of using fast re-authentication is taken in the 3GPP AAA server depending on operator’s policies. The 3GPP AAA server indicates to the UE the decision of using fast re-authentication by means of sending the fast re-authentication identity in the EAP authentication procedure (i.e. in EAP-Request/AKA/Challenge or EAP‑Request/AKA-re-authentication). When the 3GPP AAA server sends a fast re-authentication identity to the UE, the 3GPP AAA server shall also include a pseudonym when allowed by the IETF RFC 4187 [33]. In this way, the UE retains a pseudonym if the 3GPP AAA server defers to full authentication.

6.5.2.3.2.4 Protected result indications

The 3GPP AAA server should support protected result indications (i.e. MAC protected) for EAP AKA as specified in IETF RFC 4187 [33]. The usage of this feature depends on operator’s policies.

6.5.2.4 ePDG procedures

During the authentication of the UE for accessing the EPC via the ePDG, the ePDG shall initiate EAP-AKA based authentication between the UE and the 3GPP AAA server as specified in 3GPP TS 33.402 [15]. The ePDG shall extract the EAP messages received from the UE over IKEv2, and send them to the 3GPP AAA Server and shall send the EAP message received from the 3GPP AAA Server to the UE over IKEv2 messages as defined in 3GPP TS 33.402 [15].

At the reception of the first message of the IKE_AUTH phase from the UE, indicating to the ePDG that the UE wants to use EAP over IKEv2 (i.e. AUTH parameter absent), the ePDG sends the Authentication and Authorization request to the 3GPP AAA server including the EAP_resp/Identity in the EAP payload, with the User Identity retrieved from the IDi payload and the APN information retrieved from the IDr payload of the incoming message from the UE.

6.5.3 Multiple PDN support for untrusted non-3GPP access network

Connectivity to multiple PDNs via untrusted non-3GPP access is supported in the EPS when the network policies, the non-3GPP access and the user subscription allow it.

NOTE 1: In 3GPP, there is a limitation to the maximum number of simultaneous PDN connections per UE caused by the number of EPS bearer identities (see clause 11.2.3.1.5 of 3GPP TS 24.007 [48]) or by the number of PDU session IDs (see clause 11.2.3.1b of 3GPP TS 24.007 [48]). Not complying with this limitation when accessing non-3GPP access can lead to unexpected consequences, e.g. connectivity loss in case of handover to 3GPP access. The maximum number of PDN connection via untrusted non-3GPP access is independent from the maximum number of active EPS bearer contexts for 3GPP access (see clause 6.5.1A of 3GPP TS 24.301 [10]).

If the UE supports dynamic mobility management selection the UE shall use the same mobility protocol when multiple connections are established, see 3GPP TS 23.402 [6].

When the UE accesses EPC via S2b using untrusted non-3GPP IP access, and the UE establishes additional PDN connections, the UE shall establish a new IPSec tunnel with the same ePDG for each PDN connection. For each tunnel establishment procedure, the UE shall indicate to the ePDG an APN to the desired PDN and an attach type indication as specified in clause 7.2.2. When establishing an additional PDN connection, the UE shall not indicate the INITIAL_CONTACT notification.

NOTE 2: When using the S2b interface to establish an additional PDN connection, the new IPSec tunnel establishment includes a new IKEv2 authentication and security association establishment as specified in clause 7.2.2.

When the UE accesses EPC via S2c using untrusted non-3GPP IP access, the UE shall follow the procedures described in 3GPP TS 24.303 [11] when establishing multiple PDN connections. For multiple PDN connections, the UE shall establish only one IPsec tunnel to the ePDG.

If the UE had more than one PDN connection to a given APN in the source access network and the UE is performing a handover to a target untrusted non-3GPP access network via an ePDG that supports accessing an EPC via S2b-interface, the UE shall transfer all the PDN connections for the given APN to the target untrusted non-3GPP access network as specified in 3GPP TS 23.402 [6].

If multiple PDN connections to a single APN are not supported over the target untrusted non-3GPP access network, only one PDN connection to that given APN shall be established in the target non-3GPP access network as specified in 3GPP TS 23.402 [6] if NBM is used. The UE, if supporting IP address preservation for NBM, shall include the home address information during the tunnel establishment procedure as specified in clause 7.2.2. If multiple PDN connection requests to the same APN are received but the network does not support multiple PDN connections to the same APN, the ePDG shall reject the additional PDN connection requests to the same APN received from the UE as described in clause 7.4.1, in the following circumstances:

– when one PDN connection to the same APN has already been established;

– only after the network has successfully established one PDN connection in the case that the additional PDN connections requests were received prior to the successful establishment of a single PDN connection.

In the above cases, the UE shall determine which PDN connection is re-established in the non-3GPP access based on the home address information provided by the network.

The UE behaviour, when PDN connection re-establishment is rejected by the network during handover to the untrusted non-3GPP access network, is described in sublause 7.2.2.

NOTE 3: When a UE supporting IP address preservation for NBM with multiple PDN connections to the same APN hands over to the non-3GPP access network, the UE can, as an implementation option, prioritise the re-establisment for a particular PDN connection before re-establishing the remaining PDN connections. The UE indicates the prioritised PDN connection by including both the APN in the IDr payload and the home address information in the Handover Attach indicator as specified in clause 7.2.2. Another implementation option can be to send multiple re-establishment requests concurrently.

If the UE did not handover all the PDN connections for a given APN to the target untrusted non-3GPP access network, the source network may disconnect the remaining PDN connections for that given APN after an implementation dependent time.

6.6 UE – 3GPP EPC (cdma2000^® HRPD Access)

6.6.1 General

3GPP2 X.S0057 [20] defines the interworking architecture for access to the EPC via cdma2000^® HRPD access networks. In particular, 3GPP2 X.S0057 [20] describes support for a UE using the cdma2000^® HRPD air interface to access the EPC architecture defined in 3GPP TS 23.402 [6] by:

– specifying the use of the interface between the 3GPP2 HRPD Serving Gateway (HSGW) and the PDN Gateway (P-GW) in the EPC by referencing 3GPP TS 29.275 [18], when the HSGW supports UEs accessing EPC via S2a;

– specifying the use of the interface across the S101 reference point between the eAN/PCF in the 3GPP2 HRPD access network and the MME in the EPC by referencing 3GPP TS 29.276 [19];

– specifying the use of the user plane interface across the S103 reference point between the EPC Serving Gateway (S-GW) and the HSGW by referencing 3GPP TS 29.276 [19]; and

– describing the internal functions and responsibilities of the HSGW.

3GPP2 C.S0087 [21] defines the signalling requirements and procedures for UEs accessing the EPC via 3GPP2 HRPD access networks using the cdma2000^® HRPD air interface. In particular, 3GPP2 C.S0087 [21]:

– defines the signalling extensions to the cdma2000^® HRPD air interface defined in 3GPP2 C.S0024 [23] necessary to support interworking with the EPC and E-UTRAN; and

– defines the UE and eAN/PCF procedures and signalling formats to support bidirectional handoff between E-UTRAN and cdma2000^® HRPD.

6.6.2 Non-emergency case

6.6.2.1 General

Clauses 6.6.2.2 through 6.6.2.7 describe the particular requirements for access to the EPC via a cdma2000^® HRPD access network in support of non-emergency accesses and services.

6.6.2.2 UE identities

The UE and network shall use the root NAI as specified in 3GPP TS 23.003 [3] for EPC access authentication when the UE obtains service via a cdma2000^® HRPD access network connected to an EPC in the UE’s HPLMN.

Additionally, the UE and network shall use the Fast-Reauthentication NAI and the Pseudonym Identity as described in clause 4.4.

6.6.2.3 cdma2000^® HRPD access network identity

The access network identity is described in 3GPP TS 23.003 [3] and in clause 6.4.2.4 of this specification. For a cdma2000^® HRPD network, the value and encoding of the access network identity is described in clause 8.1.1. The 3GPP AAA server, HSS, and any visited network AAA proxy shall use the access network identity during EAP-AKA’ authentication procedures (see 3GPP TS 33.402 [15]).

6.6.2.4 PLMN system selection

The UE shall rely on information provisioned by the home operator to facilitate the PLMN system selection process described in 3GPP TS 23.122 [4].

6.6.2.5 Trusted and untrusted accesses

The UE shall determine the trust relationship for access to the EPC via a cdma2000^® HRPD access network as described in clause 4.1.

6.6.2.6 IP mobility mode selection

The UE and network shall perform IP mobility mode selection as described in clauses 6.3.3.1 and 6.4.3.2

6.6.2.7 Authentication and authorization for accessing EPC

The UE and 3GPP AAA server shall perform authentication and authorization procedures for access to the EPC as defined in 3GPP TS 33.402 [15].

6.6.3 Emergency case

6.6.3.1 General

Clauses 6.6.3.2 through 6.6.3.3 describe the particular requirements for access to the EPC via a cdma2000^® HRPD access network in support of an emergency session in course of handover from E-UTRAN to HRPD.

In this release of the specification no emergency session related handling other than the handover of an emergency session from E-UTRAN to an cdma2000^® HRPD access network supporting access S-GW or PDN GW via S2a-interface is specified.

6.6.3.2 UE identities

When the UE obtains emergency services via a cdma2000^® HRPD access network connected to an EPC in the UE’s HPLMN, then the UE and the network shall use the NAI for EPC access authentication as follows:

– if IMSI is available and authenticated , then the UE and the network shall use the root NAI;

– if IMSI is not available or unauthenticated, then the emergency NAI shall be used.

Additionally, the UE and the network shall use the Fast-Reauthentication NAI and the Pseudonym Identity as described in clause 4.4.1.

6.6.3.3 Authentication and authorization for accessing EPC

If IMSI is available, then the authentication and authorization procedures via STa are executed if the local regulation and network operator option requires authenticating the UE.

If the authentication and authorization procedures fail, then it depends on local regulation and network operator option to allow or reject the emergency services for the UE.

If IMSI is not available, the authentication and authorization procedures via STa are not executed.

6.7 UE – 3GPP EPC (WiMAX Access)

6.7.1 General

The WiMAX system and its access network subsystem are described within WiMAX Forum Network Architecture Release 1.0 version 1.2 – Stage 2 [24]. The protocol architecture and signalling of the WiMAX system is specified in WiMAX Forum Network Architecture Release 1.0 version 1.2 – Stage 3 [25]. This protocol architecture and signalling supports the air interface defined in WiMAX Forum Mobile System Profile Release 1.0 Approved Specification Revision 1.4.0 [26] which specifies selected profiles of IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Cor1-2005 [27].

6.7.2 Non-emergency case

6.7.2.1 General

Clauses 6.7.2.2 through 6.7.2.7 describe the particular requirements for access to the EPC via a WiMAX access network in support of non-emergency accesses and services.

6.7.2.2 UE identities

The UE and network shall use the root NAI as specified in 3GPP TS 23.003 [3] for EPC access authentication when the UE obtains service via a WiMAX access network connected to an EPC in the UE’s HPLMN.

Additionally, the UE and network shall use the Fast-Reauthentication NAI and the Pseudonym Identity as described in clause 4.4.

6.7.2.3 WiMAX access network identity

The access network identity is described in 3GPP TS 23.003 [3] and in clause 6.4.2.4 of this specification. For a WiMAX network, the value and encoding of the access network identity is described in clause 8.1.1. The 3GPP AAA server, HSS, and any visited network AAA proxy shall use the access network identity during EAP-AKA authentication procedures (see 3GPP TS 33.402 [15]).

6.7.2.4 Selection of the Network Service Provider

The UE shall use WIMAX-specific procedures described in WiMAX Forum Network Architecture Release 1.0 version 1.2 – Stage 3 [25] to discover and select the highest priority Network Service Provider (NSP) which is available and allowable.

6.7.2.5 Trusted and untrusted accesses

The UE shall determine the trust relationship for access to the EPC via a WiMAX access network as described in clause 4.1.

6.7.2.6 IP mobility mode selection

The UE and network shall perform IP mobility mode selection as described in clauses 6.3.3.1 and 6.4.3.2.

6.7.2.7 Authentication and authorization for accessing EPC

NOTE: In line with 3GPP TS 33.402 [15], in this present specification, no particular security provisions are specified for interworking between WiMAX and EPS. Any access specific security procedures for WiMAX as a non-3GPP access network to EPC will be in accordance with WiMAX Forum Network Architecture Release 1.0 version 1.2 – Stage 3 [25] and WiMAX Forum Mobile System Profile Release 1.0 Approved Specification Revision 1.4.0 [26].

6.7.3 Emergency case

NOTE: Procedures for handling emergency accesses or services are not specificed within this release of the specification

6.8 Communication over the S14

6.8.1 General

In order to assist the UE with performing access network discovery and selection, ANDSF provides a set of information to the UE. This information contains:

– the access network discovery and selection information to assist the UE with selecting the access network;

– ISMP to control and assist the UE with performing the inter-system change;

– ISRP information to control and assist a UE with selecting the access network to be used for routing different IP flows over different access networks, establishing PDN connections and identifying IP flows applicable for non-seamless WLAN offload;

– IARP information to control and assist a UE with selecting a prioritised APN which is associated with an existing PDN connection for routing different IP flows. The IARP provided by ANDSF can also include information for identifying IP flows applicable for non-seamless WLAN offload.

– WLAN Selection Policy to assist the UE with selecting the WLAN access network;

– Home Network Preference information to assists the UE in selecting a WLAN and a service provider for 3GPP-based authentication over WLAN;

– Visited Network Preference information to assist the UE in selecting a WLAN and a service provider for 3GPP-based authentication over WLAN when the UE is roaming in a V-PLMN; or

– Rule selection information to assist the roaming UE with selecting the active ANDSF rules to be used.

The ANDSF can provide ISRP rules to a UE independently of the UE’s support for IFOM, MAPCON, NSWO, RAT differentiation in ISRP or RAN-assisted WLAN interworking. Handling of ISRP nodes unsupported by the UE is described in in 3GPP TS 24.312 [13].

The ANDSF can provide IARP rules to a UE independently of the UE’s support for NSWO, Inter-APN routing or RAN-assisted WLAN interworking. Handling of IARP nodes unsupported by the UE is described in in 3GPP TS 24.312 [13].

This set of information can either be provisioned in the UE by the home operator, or provided to the UE by the ANDSF over the S14 reference point via pull or push mechanisms as defined in 3GPP TS 23.402 [6] by means of the access network discovery and selection procedures as described in clause 6.8.2. While roaming, the UE can receive a set of information from H-ANDSF or V-ANDSF or both. The V-ANDSF shall not provide any IARP or rule selection information to a roaming UE. If the roaming UE receives any IARP or rule selection information delivered by a V-ANDSF then the roaming UE shall ignore it.

The UE, located in the home PLMN, needs to discover the H-ANDSF by means of the discovery procedure as described in clause 6.8.2.2.1. The UE, located in the visited PLMN, needs to discover the H-ANDSF or V-ANDSF or both by means of the discovery procedure as described in clause 6.8.2.2.1.

Through push mechanisms the ANDSF can provide assistance information to the UE e.g. if the UE has previously used pull based ANDSF procedure or if OMA-DM bootstrapping is used as described in clause 6.8.2.2.1A. Through pull mechanisms the UE can send a request to the ANDSF in order to get assistance information for access network discovery and selection.

ANDSF shall comply with local, national and regional requirements regarding the privacy and confidentiality of location information.

NOTE: The regulation and legislations of the home operator of the ANDSF server determines whether the ANDSF server can store the user’s location information.

If the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2, then the access stratum layer of the 3GPP access can provide RAN assistance parameters and corresponding (E-)UTRAN measurements which are used in accordance with the ANDSF MO defined in 3GPP TS 24.312 [13].

6.8.2 Interaction with the Access Network Discovery and Selection Function

6.8.2.1 General

The S14 interface enables IP level communication between the UE and ANDSF. The protocols supported by the S14 interface are realized above the IP level. Both pull and push mechanisms may be supported for communication between the UE and the ANDSF. A combination of pull and push mechanisms may also be supported. The communication security over the S14 interface is specified in 3GPP TS 33.402 [15].

The UE, located in a home PLMN, can communicate securely with the H-ANDSF. The UE, located in a visited PLMN, can communicate securely with H-ANDSF or V-ANDSF or both.

The information is transferred between the UE and ANDSF using OMA DM as defined in OMA-ERELD-DM-V1_2 [39] with the management object as specified in 3GPP TS 24.312 [13].

6.8.2.2 UE procedures

6.8.2.2.1 UE discovering the ANDSF

The IP address of the H-ANDSF can be configured in the UE by the home operator.

When the UE is in its HPLMN or equivalent HPLMN, the UE may use DNS lookup as specified in IETF RFC 1035 [35] or DHCP query as specified in IETF RFC 6153 [37] to discover the IP address of the H-ANDSF. If the UE implements DHCP query, the preference between DNS lookup and DHCP query is UE implementation dependent. .

When the UE is in a visited PLMN, the UE shall use DNS lookup to discover the IP address of the ANDSF.

When performing a DNS lookup resolution for ANDSF, the UE shall apply the following procedures:

– For the H-ANDSF discovery, the UE shall build a Fully Qualified Domain Name (FQDN) that shall be set to the ANFSF-SN FQDN as defined in 3GPP TS 23.003 [3] for the DNS request and select the IP address of the H-ANDSF included in the DNS response message.

– For the V-ANDSF discovery, the V-ANDSF IP address by which the UE can contact the V-ANDSF is obtained by the UE through a DNS lookup by name as specified in IETF RFC 1035 [35]. The QNAME shall be set to the ANDSF-SN FQDN and included in the DNS Request as defined in 3GPP TS 23.003 [3], and select the IP address of the V-ANDSF included in the DNS response message.

6.8.2.2.1A ANDSF communication security

According to 3GPP TS 33.402 [15], for the pull model, the UE and ANDSF shall use PSK TLS with GBA based shared key-based mutual authentication to establish a secure connection between UE and ANDSF as specified by clause 5.4 of 3GPP TS 33.222 [44].

According to 3GPP TS 33.402 [15], for the push model, the UE and ANDSF shall use PSK TLS with GBA push based shared key-based mutual authentication to establish a secure connection between the UE and the ANDSF as specified by clause 5.1 of 3GPP TS 33.223 [47].

In accordance with 3GPP TS 29.109 [43], the BSF shall provide either the UE’s IMSI or IMPI to NAF, ie the ANDSF server.

OMA-DM’s application level authentication mechanism does not need to be used with ANDSF, since mutual security association is already established on transport level using PSK-TLS as specified in 3GPP TS 33.402 [15]. According to OMA-ERELD-DM-V1_2 [39], however, each Managed Object (MO) shall have an access control list (ACL) that lists authorized OMA DM servers. In order to comply with OMA-ERELD-DM-V1_2 [39], the ANDSF-SN FQDN shall be used as server name in the ACL list.

If the UE does not support the ANDSF security mechanism as specified in 3GPP TS 33.402 [15], or if the operator does not implement the GAA bootstrap framework specified in 3GPP TS 33.220 [42], appropriate communication security can be established with the ANDSF using OMA-DM’s bootstrap, secure http (https) mechanism and WAP Push according to OMA-ERELD-DM-V1_2 [39].

6.8.2.2.2 Role of UE for Push model

The UE shall implement the push model of ANDSF in accordance with OMA-ERELD-DM-V1_2 [39] using WAP Push, which is applicable for 3GPP access networks only.

If the UE operates according to the GAA bootstrap framework specified in 3GPP TS 33.220 [42] and if the UE supports GBA Push as specified in 3GPP TS 33.223 [47], the UE shall accept the SMS as a valid ANDSF notification SMS if:

– the notification SMS contains valid GBA Push Information (GPI) as specified in 3GPP TS 24.109 [52],

– the X-WAP-Application-ID field (Push Application ID) in the WSP header indicates ANDSF,

– the WSP payload contains only the header part defined in 3GPP TS 24.109 [52] and the GPI parameter without any additional identifiers and

– the NAF FQDN in GPI conforms to the ANDSF-SN specified in 3GPP TS 23.003 [3].

The short code for the X-WAP-Application-ID is specified in clause 8.1.3.

If the UE operates according to OMA DM bootstrap procedures as specified in OMA DM Enabler Release v.1.2, see OMA-ERELD-DM v1_2 [39], the UE shall accept the SMS as a valid ANDSF notification SMS if it contains an OMA DM General Package #0 message according to OMA-ERELD-DM v1_2 [39].

In the push model of communication, if the UE receives a valid ANDSF notification SMS from the ANDSF, the UE shall establish a secure data connection using the information received in the notification SMS.

If the UE receives an invalid ANDSF notification SMS it shall be ignored by the UE.

Upon establishing a secure connection between the UE and ANDSF, the UE may be provided with updated ISMP, ISRP, IARP, WLANSP and information about available access networks. The list of the information is described in clause 6.8.1 and 6.8.2.3.3 and the correspondent ANDSF MO is defined in 3GPP TS 24.312 [13].

6.8.2.2.3 Role of UE for Pull model

In the pull model of communication, the UE sends a query to ANDSF to retrieve or update inter-system mobility policy or information about available access networks in its vicinity or inter-APN routing policy or any combination of them. A UE supporting IFOM, MAPCON, NSWO or any combination of these may also request ISRP. A UE may request IARP. The UE will wait for an implementation dependent time for an answer from the ANDSF. If ANDSF does not respond within that time, further action by the UE is implementation dependent. The UE may provide to ANDSF the UE’s location information including, if available, the location parameters (for example, cell identities or the MAC address of the WLAN AP) associated with the Radio Access Networks the UE has discovered in its current location at the time the UE sends a query to ANDSF; the format of the location information is described as UE_Location in ANDSF MO defined in 3GPP TS 24.312 [13].

After communicating with ANDSF, the UE may be provided with updatedISMP, ISRP, IARP, WLANSP and information about available access networks. The list of the information is described in clause 6.8.1 and 6.8.2.3.3 and the correspondent ANDSF MO is defined in 3GPP TS 24.312 [13].

The UE may start Pull model communication with ANDSF based upon the information previously received from the ANDSF (e.g. based on the value of UpdatePolicy leaf defined in 3GPP TS 24.312 [13]). The UE capable of IFOM, MAPCON, or non-seamless WLAN offload (or any combination of these capabilities) can have all these capabilities disabled and have no ISRP. If the UE enables one (or more) of these capabilities, the UE may start Pull model communication with ANDSF. The UE capable of IFOM, MAPCON, or non-seamless WLAN offload (or any combination of these capabilities) can have one (or more) of these capabilities enabled and have no ISMP. If the UE disables all these capabilities, the UE may start Pull model communication with ANDSF. If the UE has no IARP, the UE may start Pull model communication with ANDSF.

NOTE: Mechanisms to limit the frequency of queries transmission from the UE to the ANDSF are implementation dependant.

6.8.2.2.4 UE using information provided by ANDSF

6.8.2.2.4.1 General

ANDSF may provide various types of information to the UE, including access network discovery information, WLAN selection information, ePDG configuration information, inter-system mobility policy, the inter-system routing policies and the inter-APN routing policies. The UE may retain and use this ANDSF information until new or updated information is received.

Network detection and selection shall take into account the access network specific requirements and the UE’s local policy, e.g. user preference settings, access history, etc, along with the information provided by the ANDSF when discovering and selecting an access network. The local policy and the information provided by the ANDSF shall be used by the UE in an implementation dependent way to limit the undesired alternating between access systems, e.g. ping-pong type of inter-system changes. However, the use of such information from the ANDSF shall not be in contradiction to functions specified in 3GPP TS 23.122 [4], 3GPP TS 25.304 [14] and 3GPP TS 36.304 [16].

If the UE is roaming in a VPLMN, the UE may receive Inter-system mobility policies or Access network discovery information or ISRP or combinations of these from H-ANDSF or V-ANDSF or both. The UE may also receive the IARP from H-ANDSF. If IARP is received from V-ANDSF, the UE shall ignore it. The UE may also receive WLAN selection information including WLAN Selection Policy (WLANSP) from H-ANDSF or V-ANDSF or both, rule selection information, and Home Network Preference information from H-ANDSF. The UE may receive Visited Network Preference information from V-ANDSF. The UE may also receive ePDG configuration information from H-ANDSF. The formats of the above information are defined in 3GPP TS 24.312 [13].

The maximum number of sets of Inter-system mobility polices or Access network discovery information or ISRP or IARP or combinations of these that the UE may keep is implementation dependent. However, the UE shall retain at least one set of Inter-system mobility policies and one set of Access network discovery information from the same ANDSF. In addition, a UE supporting IFOM, MAPCON, or non-seamless WLAN offload shall retain at least one ISRP rule from the same ANDSF. Additionally, a UE shall retain at least one set of IARP received from the H-ANDSF.

If a UE supporting IFOM, MAPCON, or non-seamless WLAN offload (or any combination of these featureshas ISMP and ISRP available, and if the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2, then ISRP shall be used for the routing of IP traffic. The relation between ISRP and user preferences is described in clause 5.4.2.

For a UE with IFOM, MAPCON or non-seamless WLAN offload (or any combination of these capabilities) enabled, if ISMP, ISRP and IARP are available, and if the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2, then IARP and ISRP shall be used. In this case, the UE shall first apply IARP followed by ISRP as follows:

– If non-seamless WLAN offload is selected by IARP then the IP flow is routed to the non-seamless WLAN offload and ISRP shall not be used for the routing of IP traffic.

– If a certain APN is selected by IARP then the IP flow is routed to the PDN connections corresponding to this APN. If there is a ForFlowBased ISRP rule matching the IP flow after the APN is selected, then the UE shall use the ForFlowBased ISRP rule matching the IP flow to select the access for this IP flow.

– If neither certain APN nor non-seamless WLAN offload is selected by IARP or one or more APNs are restricted by the IARP for routing the IP flow, then ISRP shall be used for the routing of IP traffic. When one or more APNs are restricted by the IARP, if a rule for NSWO is matched in the active ISRP rule that restricts the use of the selected WLAN (or any WLAN) for routing the IP flow, then the UE selects a not restricted APN to route the IP flow.

The relation between IARP and user preferences is described in clause 5.4.2.

For a UE not supporting any of IFOM, MAPCON or non-seamless offload capabilities or with all those capabilities disabled, if ISMP and ISRP are available, and if the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2, the ISMP shall be used.

For a UE not supporting any of IFOM, MAPCON capabilities or with all those capabilities disabled, if ISMP, ISRP and IARP are available, and if the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2, the IARP and ISMP shall be used. In this case, the UE shall firstly apply ISMP followed by IARP as follows:

– If the 3GPP access is selected by ISMP policy, then the UE shall use the active IARP rule to determine if the IP flow is routed to the PDN connection corresponding to a certain APN. The non-seamless WLAN offload policy, defined in the IARP, shall not be used for routing of IP traffic; and

– If the WLAN access is selected by ISMP policy, then the UE shall use the active IARP rule to determine if the IP flow is routed to the PDN connection corresponding to a certain APN or using the non-seamless WLAN offload.

This information shall be deleted if there is a change of USIM. This information may be deleted when UE is switched off.

If the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2, irrespective of whether any rule in ANDSF policies is ‘active’ or not, the UE shall periodically re-evaluate ANDSF policies. The value of the periodic re-evaluation timer is implementation dependant. The additional trigger for (re‑)evaluating rules is that the ‘active’ rule becomes invalid (conditions no longer fulfilled), or other manufacturer specific trigger. When the UE receives ANDSF information it shall re-evaluate the available rules along with the new information.

6.8.2.2.4.2 Use of Inter-system Mobility Policy

This clause applies if the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2.

If more than one set of Inter-system mobility policies is available in the UE, the UE shall only use one set of Inter-system mobility policies at any one time.

When the UE is roaming and receives Inter-system Mobility Policies from both H-ANDSF and V-ANDSF, the set of Inter-system Mobility Policies used by the UE is selected as follows:

– If there is rule selection information provisioned in the UE by the H-ANDSF, and if the RPLMN identity is equal to one of the VPLMNs included in the visited PLMNs with preferred rules, the set of Inter-system Mobility Policies from V-ANDSF is selected by the UE.

If the preferred access technology according to the Inter-system Mobility Policy is WLAN access technology, and if there is no WLANs matching the WLANSP rule(s) from the V-ANDSF, the set of of Inter-system Mobility Policies from H-ANDSF is selected by the UE. However, if at least one WLAN matching one or more groups of selection criteria in the VPLMN’s WLANSP rule becomes available, the UE should re-use the WLANSP policies and Inter-system Mobility Policies from V-ANDSF.

– If there is rule selection information provisioned in the UE by the H-ANDSF, and if the RPLMN identity is not equal to any of the VPLMNs included in the visited PLMNs with preferred rules, the set of Inter-system Policies from H-ANDSF is selected by the UE.

If the preferred access technology according to the Inter-system Mobility Policy is WLAN access technology, and if there is no WLANs matching the WLANSP rule(s) from the H-ANDSF, the set of of Inter-system Mobility Policies from V-ANDSF is selected by the UE. However, if at least one WLAN matching one or more groups of selection criteria in the HPLMN’s WLANSP rule becomes available, the UE should re-use the WLANSP policies and Inter-system Mobility Policies from H-ANDSF.

NOTE: How frequently the UE performs the discovery and reselection procedure depends on the UE implementation.

The Inter-system Mobility Policy with the highest priority among the set of Inter-system Mobility Policies selected above is selected as the active Inter-system Mobility Policy. A UE uses the ISMP to decide if the most preferred available WLAN based on the WLANSP rule has higher priority than the 3GPP RAT. If so, the UE shall connect to EPC via WLAN access. Otherwise, the UE shall connect to EPC via 3GPP access. The prioritized list of WLAN in the active ISMP rule shall not be used for WLAN selection.

When applying the Inter-system mobility policy the following requirements apply:-

– the requirements on periodic network reselection as described in clause 5.3.4 of the present specification;

– the PLMN selection rules specified in 3GPP TS 23.122 [4] and in clause 5.2.3.2;

– the selection rules specified in 3GPP2 C.P0016-D [23a]; and

– the 3GPP RAT selection, cell selection and reselection rules specified in 3GPP TS 25.304 [14], 3GPP TS 36.304 [16] and 3GPP TS 45.008 [16a].

6.8.2.2.4.3 Use of Access Network Discovery Information

The UE may use the received Access network discovery information of both the H-ANSDF and V-ANDSF for network discovery and detection. The Access network discovery information received from:-

a) the H-ANDSF provides guidance for the UE on access networks that have connectivity to the HPLMN or equivalent HPLMNs or both; and

b) the V-ANDSF provides guidance for the UE on access networks that have connectivity to the corresponding VPLMN or equivalent PLMNs or both.

6.8.2.2.4.4 Use of Inter-System Routing Policies

This clause applies if the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2.

A UE supporting IFOM, MAPCON, or non-seamless WLAN offload (or any combination of these features) shall use the ISRP if available.

A UE supporting IFOM uses the ISRP to:

– select an access technology or an access network or both for routing user plane traffic matching specific IP flows on a specific or any APN identified in the ISRP. 3GPP RATs can be prioritized with respect to WLAN access but this prioritization does not influence 3GPP RAT selection; WLAN access networks can be prioritized with respect to 3GPP RATs but those WLANs do not influence WLAN selection; and

– decide if an access technology or access network or both are restricted for a specific IP flows on a specific or any APN identified in the ISRP.

A UE supporting MAPCON uses the ISRP to:

– select an access technology or an access network or both for routing user plane traffic matching a specific APN or any APN identified in the ISRP. 3GPP RATs can be prioritized with respect to WLAN access but this prioritization does not influence 3GPP RAT selection; WLAN access networks can be prioritized with respect to 3GPP RATs but those WLANs do not influence WLAN selection; and

– decide if an access technology or an access network or both are restricted for a specific APN or any APN identified in the ISRP.

NOTE: After selecting WLAN access for routing user plane traffic by this prioritised list of access technologies, a UE can use an implementation dependent way to prevent the traffic from being routed back to the original RAT again in a short period of time to avoid ping-pong behaviour.

A UE supporting non-seamless WLAN offload uses the ISRP to:

– select a WLAN access network for routing, without traversing the EPC, user plane traffic matching specific IP flows for a specific APN or any APN identified in the ISRP; WLAN access networks defined in routing rule do not influence WLAN selection; and

– decide if the selected WLAN access network is restricted for routing, without traversing the EPC, a specific IP flows for a specific APN or any APN identified in the ISRP. If not, the selected WLAN can be used to perform NSWO.

When the UE supporting IFOM identifies an access technology or an access network or both over which an IP flow can be routed based on the ISRP, the UE shall apply the IFOM procedures specified in 3GPP TS 24.303 [11] to move an on-going IP flow from the source access technology or access network to the identified access technology or access network, if required.

If more than one set of ISRP is available in the UE, the UE shall only use one ISRP at any one time.

When the UE is roaming and receives Inter-system Routing Policies from both H-ANDSF and V-ANDSF, the set of Inter-system Routing Policies used by the UE is selected as follows:

– If there is rule selection information provisioned in the UE by the H-ANDSF, and if the RPLMN identity is equal to one of the VPLMNs included in the visited PLMNs with preferred rules, the set of Inter-system Routing Policies fromV-ANDSF is selected by the UE.

If there is no WLANs matching the WLANSP rule(s) from the V-ANDSF, the set of Inter-system Routing Policy from the H-ANDSF is re-selected. However, if at least one WLAN matching one or more groups of selection criteria in the WLANSP rule of the VPLMN becomes available, the UE should re-use the WLANSP policies and Inter-system Routing Policies from V-ANDSF.

If there is no WLANs matching the WLANSP rule(s) from the H-ANDSF, the set of Inter-system Routing Policy from the V-ANDSF is be re-selected. However, if at least one WLAN matching one or more groups of selection criteria in the WLANSP rule of the HPLMN becomes available, the UE should re-use the WLANSP policies and Inter-system Routing Policies from H-ANDSF.

NOTE: How frequently the UE performs the discovery and reselection procedure depends on the UE implementation.

The Inter-system Routing Policy with the highest priority among the set of Inter-system Routing Policies selected above is selected as the active Inter-system Routing Policy.

The UE shall periodically re-evaluate the flow distribution rules of the ‘active’ ISRP rule. The value of the periodic re-evaluation timer is implementation dependant.

6.8.2.2.4.5 Use of Inter-APN Routing Policies

The UE shall use the IARP for APN if available.

The UE shall use the IARP for non-seamless WLAN offload if available, and the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2.

A UE uses the IARP to:

– select an APN or non-seamless WLAN offload for routing user plane traffic matching specific IP flows; and

– decide if an APN or non-seamless WLAN offload is restricted for routing a specific IP flows.

An IARP for APN can be applied only when it steers IP traffic to an existing (i.e. already established) PDN connection. Also, the scenario where multiple PDN connections via the same access network are associated with the same APN is not specified in the present document.

When applying IARP the same requirements defined for inter-system mobility policy in clause 6.8.2.2.4.2 applies with the exception that the UE shall apply IARP provided by the H-ANDSF.

If no valid IARP present, then Inter-APN routing policy configuration is UE implementation dependent.

6.8.2.2.4.6 Use of WLAN selection information

The UE uses the WLAN selection information provided by ANDSF to determine the selected WLAN and the selected service provider.

The UE first uses WLAN Selection Policy (WLANSP) and the visited PLMNs with preferred rules to determine the active WLANSP rule. When roaming, if the UE is configured to prefer WLAN selection rules provided by the HPLMN, WLANSP provided by HPLMN is used. Otherwise, WLANSP provided by VPLMN is used. The UE selects the highest priority and valid WLANSP rule as the active WLANSP rule.

During power-up, while the UE has not registered to any PLMN, the UE shall use WLANSP provided by the HPLMN as valid.

The UE determines the selected WLAN(s) as specified in clause 5.1.3.2. If there are no selected WLANs according to active WLANSP rule of the VPLMN/HPLMN, then the UE uses the WLANSP policies from the HPLMN/VPLMN as active WLANSP rule. However, if at least one WLAN that matches one or more groups of selection criteria in the WLANSP rule of the VPLMN or the /HPLMN becomes available, the UE should re-use the WLANSP policies from the VPLMN or the HPLMN as active WLANSP rule.

NOTE: How frequently the UE performs the discovery and reselection procedure depends on the UE implementation.

Home Network Preference information and Visited Network Preference information can be configured in the ANDSF MO to assist the UE in selecting a service provider over the selected WLAN(s) and constructing an appropriate NAI when attempting authentication with the selected service provider.

The UE uses the list of selected WLANs and the Home Network Preference information (or the Visited Network Preference information if available and if the UE is roaming) to select a WLAN service provider as specified in clause 5.2.3.2.

6.8.2.2.4.7 Use of ePDG information

If the UE accesses EPC via the ePDG, the UE shall use the ePDG configuration information during the tunnel establishment procedure to determine the home operator preference on ePDG connection as described in clause 7.2.1.

6.8.2.2.4.8 Use of LWA co-existence Information

The H-ANDSF can configure the LWA co-existence information about the preference between the WLANSP, ISRP and IARP for NSWO rules, on the one hand, and the LWA/RCLWI/LWIP procedures defined in the RAN, on the other hand, according to TS 23.402 [6]. The LWA co-existence information is configured in the ANDSF/HomeNetworkPreference/RanMobilitySetUsed node.

If the UE:

– has not selected a WLAN according to the WLANSP rules or user preferences, including when the UE has not selected any WLAN; or

– has selected a WLAN according to the WLANSP rules and is connected to a PLMN/WLAN combination configured in the ANDSF/HomeNetworkPreference/RanMobilitySetUsed node,

the UE shall use the WLAN mobility set (see 3GPP TS 36.300 [70]) and ignore the WLANSP, ISRP and IARP for NSWO rules. In order to apply the WLAN mobility set, the UE may disconnect from the WLAN it is currently connected to and connect to a WLAN identified by the RAN-configured WLAN mobility set.

If the UE:

– has selected a WLAN according to the WLANSP rules and is not connected to a PLMN/WLAN combination configured in the ANDSF/HomeNetworkPreference/RanMobilitySetUsed node; or

– has selected a WLAN based on user preferences,

the UE shall ignore the WLAN mobility set and apply the WLANSP, ISRP and IARP for NSWO rules.

6.8.2.3 ANDSF procedures

6.8.2.3.1 General

Both the H-ANDSF and the V-ANDSF can provide information about inter-system mobility policy or information about available access networks in the vicinity of the UE or ISRP for the UE or combinations of these. The H-ANDSF may also provide IARP for the UE. The V-ANDSF shall not provide any IARP to a roaming UE. The inter-system mobility policies may be organized in a hierarchy and a priority order among multiple policies may determine which policy has the highest priority. The policies may indicate preference of one access network over another or may restrict inter-system mobility to a particular access network under certain conditions. The ANDSF may also specify validity conditions which indicate when a policy is valid. Such conditions may be based on time duration, location, RAN validity condition. The ANDSF may limit the information provided to the UE. This can be based on UE’s current location, UE capabilities other than the capability of routing IP traffic simultaneously over multiple radio access interfaces (e.g. IFOM capability or MAPCON capability or non-seamless WLAN offload capability), etc. How the ANDSF decides how much information to provide to the UE is dependent on network implementation.

6.8.2.3.2 Role of ANDSF for Push model

If there is no existing valid PSK TLS connection between the UE and ANDSF, the ANDSF, not implementing GBA Push, may send a notification SMS to the UE, without establishing a data connection with the UE.

If there is no existing valid PSK TLS connection between the UE and ANDSF, the ANDSF, implementing GBA Push, shall send a message via SMS to the UE to establish a secure connection between the UE and ANDSF. The contents of the message shall contain a GBA Push Information as specified in 3GPP TS 33.223 [47].

After a secure connection is established according to clause 6.8.2.2.1A, or if there is a valid PSK TLS connection between the UE and ANDSF, the ANDSF shall use the connection to provision ANDSF information to the UE.

6.8.2.3.3 Role of ANDSF for Pull model

When the UE connects to an ANDSF, the ANDSF may provide the UE with ISMP, ISRP, IARP, WLANSP or information related to available access networks in the vicinity of the UE, or combinations of these. In case of information about available access networks, the ANDSF provides the following information about each available access network in the form of a list containing:

1) Type of Access network (e.g. WLAN, WiMAX);

2) Location of Access Network (e.g. 3GPP location, WLAN location);

3) Access Network specific information (e.g WLAN information, WiMAX information); and

4) Operator differentiated text field (if supported, e.g. if WNDS MO defined in 3GPP TS 24.312 [13] is used).

The detailed list of information is described in 3GPP TS 24.312 [13].

6.9 Handling of Protocol Configuration Options information

The Protocol Configuration Options (PCO) information element is specified in 3GPP TS 24.008 [46].

The support of PCOs is optional for the UE and the non-3GPP access network.

Except for the trusted WLAN access, the content syntax of PCOs for the non-3GPP access UE and non-3GPP access network is access network specific and not in the scope of 3GPP, but if PCO is supported, the UE and the PDN-GW shall handle the PCO contents in accordance with 3GPP TS 24.008 [46].

PCO information is exchanged between the UE and the PDN-GW, see 3GPP TS 23.402 [6], 3GPP TS 29.274 [50] and 3GPP TS 29.275 [18]. Except for the trusted WLAN access, the specification of PCO signalling in the non-3GPP access network is access network specific and not in the scope of 3GPP.

When the UE access EPC via trusted WLAN access network,

– if SCM is used, the PCO is supported as described in clause 6.4.2.6, 3GPP TS 29.274 [50] and 3GPP TS 29.275 [18];

– if MCM is used, the PCO is supported as described in 3GPP TS 24.244 [56], 3GPP TS 29.274 [50] and 3GPP TS 29.275 [18];and

– if TSCM is used, the PCO is not supported by the UE.

6.10 Integration with access stratum layer of 3GPP access

6.10.1 General

The clause describes the additional procedures for integration with access stratum layer of 3GPP access.

If the RAN assistance information is supported by the UE and the E-UTRAN or UTRAN, the E-UTRAN or UTRAN can provide RAN assistance information to the UE as described in 3GPP TS 25.331 [14A] and 3GPP TS 36.331 [16B].

6.10.2 Selection of control of WLAN access selection and traffic routing

The WLAN access selection and traffic routing can be controlled either by ANDSF rules or by RAN rules.

The ANDSF rules control the WLAN access selection and traffic routing if:

a) the UE has ANDSF rules but no RAN rules; or

b) the UE has both ANDSF rules and RAN rules; and:

1) the UE is not capable to simultaneously route IP traffic to both 3GPP access and WLAN; and:

A) the UE is not roaming and the UE has at least one ISMP rule from HPLMN;

B) the UE is roaming in a VPLMN contained in the visited PLMNs with preferred rules and the UE has at least one ISMP rule from VPLMN; or

C) the UE is roaming in a VPLMN not contained in the visited PLMNs with preferred rules and the UE has at least one ISMP rule from HPLMN; or

2) the UE is capable to simultaneously route IP traffic to both 3GPP access and WLAN; and:

A) the UE is not roaming and the UE has an valid ISRP rule from HPLMN;

B) the UE is roaming in a VPLMN contained in the visited PLMNs with preferred rules and the UE has a valid ISRP rule from VPLMN; or

C) the UE is roaming in a VPLMN not contained in the visited PLMNs with preferred rules and the UE has a valid ISRP rule from HPLMN.

The RAN rules control the WLAN access selection and traffic routing if:

a) the UE has RAN rules but no ANDSF rules; or

b) the UE has both ANDSF rules and RAN rules; and:

1) the UE is not capable to simultaneously route IP traffic to both 3GPP access and WLAN; and:

A) the UE is not roaming and the UE has no ISMP rules from HPLMN;

B) the UE is roaming in a VPLMN contained in the visited PLMNs with preferred rules and the UE has no ISMP rules from VPLMN; or

C) the UE is roaming in a VPLMN not contained in the visited PLMNs with preferred rules and the UE has no ISMP rules from HPLMN; or

2) the UE is capable to simultaneously route IP traffic to both 3GPP access and WLAN, and:

A) the UE is not roaming and the UE has no valid ISRP rule from HPLMN;

B) the UE is roaming in a VPLMN contained in the visited PLMNs with preferred rules and the UE has no valid ISRP rule from VPLMN; or

C) the UE is roaming in a VPLMN not contained in the visited PLMNs with preferred rules and the UE has no valid ISRP rule from HPLMN.

6.10.3 Additional procedures when WLAN access selection and traffic routing is controlled by ANDSF rules

If the ANDSF rules control the WLAN access selection and traffic routing as described in clause 6.10.2, the access stratum layer of the 3GPP access provides the received RAN assistance parameters to this layer and the UE shall store the RAN assistance parameters and then use the RAN assistance information together with ANDSF rules specified in 3GPP TS 24.312 [13] and measurements results to make traffic routing decisions to move traffic to WLAN or to E-UTRAN or UTRAN by:

– comparing the received RAN assistance thresholds with corresponding measurement results; and

– comparing the received OPI value with the provisioned OPI value provided by the ANDSF.

The following thresholds can be used for traffic routing from E-UTRAN or UTRAN to WLAN:

– ThreshServingOffloadWLANLowP;

– ThreshServingOffloadWLANLowQ;

– ThreshChUtilWLANLow;

– ThreshBackhRateDLWLANHigh;

– ThreshBackhRateULWLANHigh; and

– ThreshBeaconRSSIWLANHigh.

The following thresholds can be used for traffic routing from WLAN to E-UTRAN or UTRAN:

– ThreshServingOffloadWLANHighP;

– ThreshServingOffloadWLANHighQ;

– ThreshChUtilWLANHigh;

– ThreshBackhRateDLWLANLow;

– ThreshBackhRateULWLANLow; and

– ThreshBeaconRSSIWLANLow.

Offload Preference Indication (OPI) parameter can be used for traffic routing in both directions, from E-UTRAN or UTRAN to WLAN or from WLAN to E-UTRAN or UTRAN.

6.10.4 Additional procedures when WLAN access selection and traffic routing is controlled by RAN rules

This clause applies if the RAN rules control the WLAN access selection and traffic routing as described in clause 6.10.2.

The access stratum layer of the 3GPP access can provide:

1) move-traffic-to-WLAN indication, along with list of WLAN identifiers. An entry in the list of the WLAN identifiers consists of SSID, BSSID, HESSID, or any combination of them; and

2) move-traffic-from-WLAN indication.

The user preferences take precedence over the indications provided by the access stratum layer of the 3GPP access.

NOTE 1: Handling of the move-traffic-from-WLAN indication and the move-traffic-to-WLAN indication for a multi-access PDN connection where the network-initiated NBIFOM mode is the selected NBIFOM mode, is specified in 3GPP TS 24.161 [69].

Upon:

– receiving move-traffic-to-WLAN indication, along with the list of the WLAN identifiers, if the user preferences are not present; or

– establishment of a new PDN connection in 3GPP access, if the PDN connection is an offloadable PDN connection, the access stratum indicated move-traffic-to-WLAN, the access stratum has not indicated the move-traffic-from-WLAN indication after indicating of the move-traffic-to-WLAN indication and the user preferences are not present;

and:

– the UE is capable to simultaneously route IP traffic to both 3GPP access and WLAN and has at least one PDN connection which is not a multi-access PDN connection or where the UE-initiated NBIFOM mode is the selected NBIFOM mode as specified in 3GPP TS 24.161 [69]; or

– the UE is not capable to simultaneously route IP traffic to both 3GPP access and WLAN, and all the PDN connections of the UE in 3GPP access are offloadable PDN connections;

the UE:

a) shall perform the procedure in clause 5.1.3.2.3 and in clause 5.2.3.2 to select the selected WLAN and the NAI for authentication;

b) if not authenticated yet with the selected WLAN using the NAI for authentication in clause 6.4, shall authenticate with the selected WLAN using the NAI for authentication in clause 6.4. During authentication, if the selected WLAN is a trusted WLAN, SCM is supported by both UE and network, MCM is not supported by UE, network or both, and if:

– the UE is not capable to simultaneously route IP traffic to both 3GPP access and WLAN, and the UE has only one PDN connection;

shall handover one PDN connection:

– which is an offloadable PDN connection; and

– which is not a multi-access PDN connection or where the UE-initiated NBIFOM mode is the selected NBIFOM mode as specified in 3GPP TS 24.161 [69];

from 3GPP access to the WLAN access using procedures in clause 6.4.2.6.2;

NOTE 2: When the UE already has one PDN connection established via WLAN in SCM, and if move-traffic-to-WLAN indication is received, it is up to the UE implementation to determine whether to offload a PDN connection from 3GPP access to WLAN. In that case, it is also up to the UE implementation to determine which one of the offloadable PDN connections will be offloaded.

c) if the selected WLAN is a trusted WLAN, and MCM is supported by both UE and network, shall handover all the PDN connections:

– which are offloadable PDN connections; and

– which are not a multi-access PDN connection or where the UE-initiated NBIFOM mode is the selected NBIFOM mode as specified in 3GPP TS 24.161 [69];

from 3GPP access to the WLAN access using procedures of 3GPP TS 24.244 [56];

d) if the selected WLAN is an untrusted WLAN, and if the UE supports access to EPC via untrusted WLAN, shall handover all the PDN connections:

– which are offloadable PDN connections; and

– which are not a multi-access PDN connection or where the UE-initiated NBIFOM mode is the selected NBIFOM mode as specified in 3GPP TS 24.161 [69];

from 3GPP access to the WLAN access using procedures in clause 7.2.1 and clause 7.2.2; and

e) if the UE has a valid IARP rule for APN, shall use the IARP for APN using the procedures in clause 6.8.2.2.4.5.

Upon receiving move-traffic-from-WLAN indication, and if the user preferences are not present, the UE shall handover all the PDN connections:

– established in (or previously handed over to) WLAN access; and

– which are not a multi-access PDN connection or where the UE-initiated NBIFOM mode is the selected NBIFOM mode as specified in 3GPP TS 24.161 [69];

from WLAN access to the 3GPP access using procedures in 3GPP TS 24.301 [10].

6.1 General

6.2 Trusted and Untrusted Accesses

6.2.1 General

6.2.2 Pre-configured policies in the UE

6.2.3 Dynamic Indication

6.2.4 No trust relationship information

6.3 IP Mobility Mode Selection

6.3.1 General

6.3.2 Static configuration of inter-access mobility mechanism

6.3.3 Dynamic configuration of inter-access mobility mechanism

6.3.3.0 General

6.3.3.1 IPMS indication

6.3.3.1.1 IPMS indication from UE to 3GPP AAA server

6.3.3.1.2 IPMS indication from 3GPP AAA server to UE

6.4 Authentication and authorization for accessing EPC via a trusted non-3GPP access network

6.4.1 General

6.4.1A TWAN connection modes

6.4.2 UE procedures

6.4.2.1 Identity Management

6.4.2.1A Identity Management – emergency session

6.4.2.2 EAP-AKA and EAP-AKA’ based Authentication

6.4.2.3 Full Authentication and Fast Re-authentication

6.4.2.4 Handling of the Access Network Identity

6.4.2.4.1 General

6.4.2.4.2 ANID indication from 3GPP AAA server to UE

6.4.2.4.3 UE check of ANID for HRPD CDMA 2000® access networks

6.4.2.4.4 UE check of ANID for WiMAX access networks

6.4.2.4.5 UE check of ANID for WLAN access networks

6.4.2.4.6 UE check of ANID for ETHERNET access networks

6.4.2.5 Full name for network and short name for network

6.4.2.6 TWAN connection modes

6.4.2.6.1 General

6.4.2.6.2 Usage of single-connection mode (SCM)

6.4.2.6.2A Usage of single-connection mode (SCM) – emergency

6.4.2.6.3 Usage of multi-connection mode (MCM)

6.4.2.6.3A Usage of multi-connection mode (MCM) – emergency

6.4.2.6.3B Usage of transparent single-connection mode (TSCM) – emergency

6.4.2.6.4 Network support not available

6.4.2.7 Mobile Equipment Identity Signalling

6.4.3 3GPP AAA server procedures

6.4.3.1 Identity Management

6.4.3.1A Identity Management – emergency session

6.4.3.2 EAP-AKA and EAP-AKA’ based Authentication

6.4.3.3 Full authentication and Fast Re-authentication

6.4.3.4 Full name for network and short name for network

6.4.3.5 TWAN connection modes

6.4.3.5.1 General

6.4.3.5.1A Emergency session connection mode negotiation for unauthenticated UEs

6.4.3.5.2 Usage of single-connection mode (SCM)

6.4.3.5.2A Usage of single-connection mode (SCM) – emergency

6.4.3.5.3 Usage of multi-connection mode (MCM)

6.4.3.5.3A Usage of multi-connection mode (MCM) – emergency

6.4.3.5.3B Usage of transparent single-connection mode (TSCM) – emergency

6.4.3.5.4 Network support not available

6.4.3.6 Mobile Equipment Identity Signalling

6.4.4 Multiple PDN support for trusted non-3GPP access

6.5 Authentication and authorization for accessing EPC via an untrusted non-3GPP access network

6.5.1 General

6.5.2 Full authentication and authorization

6.5.2.1 General

6.5.2.2 UE procedures

6.5.2.2.1 General

6.5.2.2.2 EAP AKA

6.5.2.3 3GPP AAA server procedures

6.5.2.3.1 General

6.5.2.3.2 EAP-AKA

6.5.2.4 ePDG procedures

6.5.3 Multiple PDN support for untrusted non-3GPP access network

6.6 UE – 3GPP EPC (cdma2000® HRPD Access)

6.6.1 General

6.6.2 Non-emergency case

6.6.2.1 General

6.6.2.2 UE identities

6.6.2.3 cdma2000® HRPD access network identity

6.6.2.4 PLMN system selection

6.6.2.5 Trusted and untrusted accesses

6.6.2.6 IP mobility mode selection

6.6.2.7 Authentication and authorization for accessing EPC

6.6.3 Emergency case

6.6.3.1 General

6.6 UE – 3GPP EPC (cdma2000^® HRPD Access)

6.6.2.3 cdma2000^® HRPD access network identity