6.2 Initial Attach on S2a

23.4023GPPArchitecture enhancements for non-3GPP accessesRelease 18TS

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

6.2.1 Initial Attach Procedure with PMIPv6 on S2a and Anchoring in PDN GW

PMIPv6 specification, RFC 5213 [8], is used to setup a PMIPv6 tunnel between the trusted non-3GPP IP access and the PDN GW. In both roaming and non-roaming cases, S2a is present. It is assumed that MAG exists in the trusted non-3GPP IP access.

Figure 6.2.1-1: Initial attachment with Network-based MM mechanism over S2a for roaming, LBO and non-roaming scenarios

The optional interaction steps between the gateways and the PCRF in the procedures only occur if dynamic policy provisioning is deployed. Otherwise policy may be statically configured in the gateway.

This procedure applies to the Non-Roaming (Figure 4.2.2-1), Roaming (Figure 4.2.3-1) and Local Breakout (Figure 4.2.3-4) cases. For the Roaming and Local Breakout cases, the vPCRF forwards messages between the non-3GPP access and the hPCRF. In the Local Breakout case, the vPCRF forwards messages between the PDN GW and the hPCRF. In the Roaming and LBO cases, the 3GPP AAA Proxy serves as an intermediary between the Trusted Non-3GPP IP Access and the 3GPP AAA Server in the HPLMN. In the non-roaming case, the vPCRF is not involved at all.

This procedure is also used to establish the first PDN connection over a trusted non-3GPP access with S2a when the UE already has active PDN connections only over a 3GPP access and wishes to establish simultaneous PDN connections to different APNs over multiple accesses.

1) The initial Non-3GPP access specific L2 procedures are performed. These procedures are Non-3GPP access specific and are outside the scope of 3GPP.

2) The EAP authentication procedure is initiated and performed involving the UE, Trusted Non-3GPP IP Access and the 3GPP AAA Server. In the roaming case, there may be several AAA proxies involved. Subscription data is provided to the Trusted non-3GPP IP Access by the HSS/AAA in this step. The list of all the authorized APNs along with additional PDN GW selection information is returned to the access gateway as part of the reply from the 3GPP AAA Server to the trusted non-3GPP access as described in clause 4.5.1. The 3GPP AAA Server also returns to the trusted non-3GPP access the MN NAI to be used to identify the UE in Proxy Binding Update and Gateway Control Session Establishment messages (steps 4 and 10). If supported by Non-3GPP access network, the Attach Type is indicated to the Non-3GPP access network by the UE. The mechanism for supporting attach type is access technology specific and out of scope for 3GPP standardization. Attach Type indicates "Handover" when the UE already has active PDN connection(s) due to mobility from 3GPP access to non-3GPP access.

NOTE 1: The MN NAI returned from the 3GPP AAA Server to the trusted non-3GPP access is a permanent IMSI based MN NAI.

3) After successful authentication and authorization, the non-3GPP access specific L3 attach procedure is triggered. The UE may send requested APN to the Non-3GPP IP access in this step.

If the UE sends a requested APN in this step, the Trusted non-3GPP Access verifies that it is allowed by subscription. If the UE does not send a requested APN the Trusted non-3GPP Access uses the default APN.

The PDN Gateway selection takes place at this point as described in clause 4.5.1. This may entail an additional interaction with the Domain Name Server function in order to obtain the PDN GW address. If the PDN subscription profile returned by the 3GPP AAA Server in step 2 contains a PDN GW identity for the selected APN and the Attach Type does not indicate "Handover", the Non-3GPP access GW may request a new PDN GW as described in clause 4.5.1, e.g. to allocate a PDN GW that allows for more efficient routeing.

The UE may request the type of address (IPv4 address or IPv6 prefix or both) during this step.

If supported by the non-3GPP access, the UE may send Protocol Configuration Options in this step using access specific mechanisms. The Protocol Configuration Options provided by the UE may include the user credentials for PDN access authorization. In that case, in order to handle situations where the UE may have subscriptions to multiple PDNs, the UE should also send a requested APN to the non-3GPP IP access.

4) The Trusted non-3GPP access initiates the Gateway Control Session Establishment Procedure with the PCRF, as specified in TS 23.203 [19]. The Trusted non-3GPP access provides the information to the PCRF to correctly associate it with the IP‑CAN session to be established in step 6 and also to convey subscription related parameters to the PCRF, including the APN-AMBR (if forwarded by the trusted non-3GPP IP access) and Default Bearer QoS.

5) The MAG function of Trusted Non-3GPP IP Access sends a Proxy Binding Update (MN-NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, Charging Characteristics, Additional Parameters) message to PDN GW. The MN NAI identifies the UE. The Lifetime field must be set to a nonzero value. Access Technology Type is set to a value matching the characteristics of the non-3GPP access. The MAG creates and includes a PDN connection identity if the MAG supports multiple PDN connections to a single APN. Handover Indicator is set to indicate attachment over a new interface as the UE has provided Attach Type indicating "Initial" attach. The Additional Parameters include the Protocol Configuration Options provided by the UE in step 3 and may also include other information. The MAG requests the IP address types (IPv4 address and/or IPv6 Home Network Prefix) based on requested IP address types and subscription profile in the same way as the PDN type is selected during the E‑UTRAN Initial Attach in TS 23.401 [4]. If the PDN requires an additional authentication and authorization with an external AAA Server, the PDN GW performs such an additional authentication and authorization at the reception of the Proxy Binding Update.

NOTE 2: Any time after initiation of Step 4, Step 5 can be initiated by MAG.

6) The PDN GW initiates the IP‑CAN Session Establishment Procedure with the PCRF, as specified in TS 23.203 [19]. The PDN GW provides information to the PCRF used to identify the session and associate Gateway Control Sessions established in step 4 correctly. The PCRF creates IP‑CAN session related information and responds to the PDN GW with PCC rules and event triggers. If available, the PCRF may modify the APN-AMBR and provides the APN-AMBR and Default Bearer QoS to the PDN GW in the response message.

7) The selected PDN GW informs the 3GPP AAA Server of its PDN GW identity and the APN corresponding to the UE’s PDN Connection. The message includes information that identifies the PLMN in which the PDN GW is located. This information is registered in the HSS as described in clause 12. The PDN GW shall only use the APN-AMBR and Default Bearer QoS received from the 3GPP AAA server in this step if these parameters have not been received in step 6.

8) The PDN GW processes the proxy binding update and creates a binding cache entry for the UE. The PDN GW allocates IP address(es) for the UE. The PDN GW then sends a Proxy Binding Acknowledgement (MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, charging ID, Additional Parameters) message to the MAG function in Trusted Non-3GPP IP Access, including the IP address(es) allocated for the UE. The UE Address Info includes one or more IP addresses. The Lifetime indicates the duration of the binding. If the corresponding Proxy Binding Update contains the PDN connection identity, the PDN GW shall acknowledge if multiple PDN connections to the given APN are supported. The Charging ID is assigned for the PDN connection for charging correlation purposes. The Additional Parameters may include Protocol Configuration Options and other information.

NOTE 3: If UE requests for both IPv4 and IPv6 addresses, both are allocated. If the PDN GW operator dictates the use of IPv4 addressing only or IPv6 addressing only for this APN, the PDN GW shall allocate only IPv4 address or only IPv6 prefix to the UE. If the UE requests for only IPv4 or IPv6 address only one address is allocated accordingly.

NOTE 4: The MAG learns from the PBA whether the PDN GW supports multiple PDN connections to the same APN or not.

9) The PMIPv6 tunnel is set up between the Trusted Non-3GPP IP Access and the PDN GW.

10) The PCRF may update the QoS rules in the trusted non-3GPP access by initiating the GW Control Session Modification Procedure, as specified in TS 23.203 [19].

11) L3 attach procedure is completed via non-3GPP access specific trigger. IP connectivity between the UE and the PDN GW is set for uplink and downlink directions. At this step the IP address information is provided to the UE. Unless already known from step 3, the Non-3GPP IP access should indicate the connected PDN identity (APN) to the UE. If supported by the non-3GPP access, the Protocol Configuration Options provided by the PDN GW in step 8 are returned to the UE in this step using access specific mechanisms.

6.2.2 Void

6.2.3 Initial Attach procedure with MIPv4 FACoA on S2a and Anchoring in PDN-GW

MIPv4, RFC 5944 [12] is used to setup a MIP tunnel between the Trusted non-3GPP IP Access and the PDN GW. It is assumed that a Foreign Agent (FA) is located in the Trusted non-3GPP IP Access.

Figure 6.2.3-1: Initial attachment when MIPv4 FACoA mode MM mechanism is used over S2a

When the Attach procedure occurs in the Non-Roaming case (Figure 4.2.2-1), the vPCRF is not involved. The optional interaction steps between the gateways and the PCRF in the procedures only occur if dynamic policy provisioning is deployed. Otherwise policy may be statically configured with the gateway.

This procedure is also used to establish the first PDN connection over a trusted non-3GPP access with MIPv4 FACoA on S2a when the UE already has active PDN connections only over a 3GPP access and wishes to establish simultaneous PDN connections to different APNs over multiple accesses.

The event that triggers Authentication and Authorization in step 2 between the Trusted Non-3GPP IP Access and the 3GPP AAA Server, depends on the specific access technology.

1) The initial Non-3GPP access specific L2 procedure and Non-3GPP access specific authentication procedures may be performed. These procedures are outside the scope of 3GPP.

2) The EAP-based authentication procedure for trusted non-3GPP access networks between UE and the 3GPP EPC shall be performed as defined by TS 33.402 [45]. The PDN Gateway information is returned as part of the reply from the 3GPP AAA Server to the FA in the trusted non-3GPP access as described in clause 4.5.1. The Attach Type is indicated to the Non-3GPP access network by the UE as described in the step 2 of clause 6.2.1.

3) The UE may send an Agent Solicitation (AS) RFC 5944 [12] message. Specification of this message is out of the scope of 3GPP.

4) The FA in the Trusted Non-3GPP IP Access sends a Foreign Agent Advertisement (FAA) RFC 5944 [12] message to the UE. The FAA message includes the Care-of Address (CoA) of the Foreign Agent function in the FA. Specification of this message is out of the scope of 3GPP.

5) The UE sends a Registration Request (RRQ) (MN-NAI, lifetime, APN) message to the FA as specified in RFC 5944 [12]. The MN NAI identifies the UE. Reverse Tunnelling shall be requested. This ensures that all traffic will go through the PDN GW. The RRQ message shall include the NAI-Extension RFC 2794 [34]. The UE may not indicate a specific Home Agent address in the RRQ message, in which case the PDN Gateway/Home Agent is selected by the FA as per step 2. The UE then receives the IP address of the PDN Gateway in step 13 as part of the Registration Reply (RRP) message. The UE should then include the PDN Gateway address in the Home Agent address field of subsequent RRQ messages. Subscription data is provided to the Trusted non-3GPP IP Access by the HSS/AAA in this step. The UE may request connectivity to a specific PDN by using an APN as specified in RFC 5446 [39]. If the UE provides an APN the FA verifies that it is allowed by subscription. If the UE does not provide an APN the FA establishes connectivity with the default PDN. The PDN Gateway selection takes place at this point as described in clause 4.5.1. This may entail an additional name resolution step.

6) The Trusted non-3GPP access initiates the Gateway Control Session Establishment Procedure with the PCRF, as specified in TS 23.203 [19]. The Trusted non-3GPP access provides the information to the PCRF to correctly associate it with the IP‑CAN session to be established in Step 9 and also to convey subscription related parameters to the PCRF, including the APN-AMBR (if forwarded by the trusted non-3GPP IP access) and Default Bearer QoS.

7) The FA processes the message according to RFC 5944 [12] and forwards a corresponding RRQ (MN-NAI, APN) message to the PDN GW.

8) The selected PDN GW obtains Authentication and Authorization information from the 3GPP AAA/HSS.

9) The PDN GW allocates an IP address for the UE. The PDN GW initiates the IP‑CAN Session Establishment Procedure with the PCRF, as specified in TS 23.203 [19]. The PDN GW provides information to the PCRF used to identify the session and associate Gateway Control Sessions established in step 6 correctly. The PCRF creates IP‑CAN session related information and responds to the PDN GW with PCC rules and event triggers.

10) The selected PDN GW informs the 3GPP AAA Server of the PDN GW identity and the APN corresponding to the UE’s PDN Connection. The message includes information that identifies the PLMN in which the PDN GW is located. This information is registered in the HSS as described in clause 12.

11) The PDN GW sends a RRP (MN-NAI, Home Address, Home Agent Address, Lifetime) as defined in RFC 5944 [12] to the FA. The Home Address includes UE Home IP address, the Home Agent Address contains the IP address of Home Agent. The Lifetime indicates the duration of the binding.

12) In case the QoS rules have changed, the PCRF updates the QoS rules in the Trusted non-3GPP access by initiating the GW Control Session Modification Procedure, as specified in TS 23.203 [19].

13) The FA processes the RRP (MN-NAI, Home Address, Home Agent Address) according to RFC 5944 [12] and sends a corresponding RRP message to the UE.

14) IP connectivity from the UE to the PDN GW is now setup. A MIPv4 tunnel is established between the FA in the Trusted Non-3GPP IP Access and the PDN GW.

6.2.4 Initial Attach Procedure with PMIPv6 on S2a and Chained S2a and PMIP-based S8

This clause defines the initial attach procedure for the PMIP-based S8/S2a chaining. This procedure also applies to the initial attach for PMIP-based S8/S2b chaining.

Figure 6.2.4-1: Initial attachment for chained PMIP-based S8-S2a/b roaming scenarios

1) The attach initiation on the trusted or untrusted non-3GPP access is performed as described in steps 1‑4 of clause 6.2.1 (for trusted non-3GPP access) and step 1 of clause 7.2.1 (for untrusted non-3GPP access). As part of the authentication procedure, the 3GPP AAA proxy obtains the PDN GW selection information from the HSS/AAA as described in clause 4.5.1, and performs Serving GW selection as described in clause 4.5.3. 3GPP AAA proxy provides both PDN GW selection information and Serving GW identity to the MAG function of the trusted non-3GPP access or ePDG. Then the MAG function performs the PDN GW selection. If PCC is deployed, the MAG function of the Trusted Non-3GPP IP access is notified to interact with the PCRF when it is PMIP-based chained case.

2) The MAG function of Trusted Non-3GPP IP Access or ePDG sends a Proxy Binding Update (MN-NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, PDN GW address, Additional Parameters) message to the Serving GW in the VPLMN. The MN NAI identifies the UE. The Lifetime field must be set to a nonzero value, indicating registration. Access Technology Type is set to a value matching the characteristics of the non-3GPP access. The MAG creates and includes a PDN connection identity if the MAG supports multiple PDN connections to a single APN. Handover Indicator is set to indicate attachment over a new interface. The MAG requests the IP address types (IPv4 address and/or IPv6 Home Network Prefix) based on requested IP address types and subscription profile in the same way as the PDN type is selected during the E‑UTRAN Initial Attach in TS 23.401 [4]. The Additional Parameters may include Protocol Configuration Options and other information.

3) The Serving GW sends a corresponding Proxy Binding Update (MN-NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, Additional Parameters) message (as in step 2) to the PDN GW. The GRE key for downlink traffic is allocated by the Serving GW. If the MAG included the PDN connection identity in the Proxy Binding Update of the previous step and the Serving GW supports multiple PDN connections to a single APN then the Serving GW forwards the PDN connection identity to the PDN GW.

NOTE 1: In this Release of the specification, the Serving GW uses the right protocol to connect with the PDN GW based on the pre-configured information on itself in case the selected Serving GW supporting both PMIP and GTP.

4) The PDN GW initiates the PCEF-initiated IP CAN Session Establishment Procedure with the hPCRF, as specified in TS 23.203 [19].

5) The selected PDN GW informs the 3GPP AAA Server of the PDN GW identity. The message includes information that identifies the PLMN in which the PDN GW is located. The 3GPP AAA Server then conveys this information to the HSS for the UE.

6) The PDN GW processes the proxy binding update and allocates IP address(es) for the UE. The PDN GW creates a binding cache entry for the PMIPv6 tunnel towards the Serving GW and sends a Proxy Binding Acknowledgement (MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, Charging ID, Additional Parameters) message to the Serving GW. The MN NAI is identical to the MN NAI sent in the Proxy Binding Update. The Lifetime indicates the duration the binding will remain valid. The UE Address Info includes one or more IP addresses. If the corresponding Proxy Binding Update contains the PDN connection identity, the PDN GW shall acknowledge if multiple PDN connections to the given APN are supported. The Charging ID is assigned for the PDN connection for charging correlation purposes. The Additional Parameters may include Protocol Configuration Options and other information.

NOTE 2: If UE requests for both IPv4 and IPv6 addresses, both are allocated. If the UE requests for only IPv4 or IPv6 address only one address is allocated accordingly.

NOTE 3: The MAG learns from the PBA whether the PDN GW supports multiple PDN connection to the same APN or not.

7) The Serving GW processes the proxy binding acknowledgement and creates a binding cache entry for the PMIPv6 tunnel towards the MAG function in the trusted non-3GPP access or ePDG. At this point, the Serving GW also establishes the internal forwarding state for the concatenation of the PMIPv6 tunnels. The Serving GW then sends a corresponding Proxy Binding Acknowledgement (MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, Charging ID, Additional Parameters) message (as in step 7) to the MAG function of Trusted Non-3GPP IP Access or ePDG. The GRE key for uplink traffic is allocated by the Serving GW. The Charging ID is assigned for the PDN connection for charging correlation purposes.

8) The attach procedure is completed as described in steps 10‑11 of clause 6.2.1 (for trusted non-3GPP access) and steps 6‑8 of clause 7.2.1 (for untrusted non-3GPP access).