8.2.7 3GPP Access to Non-3GPP IP Access Handover with PMIPv6 on S2a/b for Chained PMIP-based S8

23.4023GPPArchitecture enhancements for non-3GPP accessesRelease 18TS

The steps involved in the handover from a 3GPP access to a trusted or non-trusted non-3GPP IP access connected to EPC are depicted below for roaming cases with chained S2a/b and PMIP-based S8.

Figure 8.2.7-1: Handover from 3GPP IP Access to Trusted or Untrusted Non-3GPP Access with chained S2a/b and PMIP-based S8

For connectivity to multiple PDNs the following applies:

– If the UE is connected to both 3GPP access and non-3GPP access before the handover of PDN connections to non-3GPP access is triggered, steps 2 to 11 shall be skipped and the UE shall only perform step 12 for each PDN connection that is being transferred from 3GPP access.

– If the UE is connected only to 3GPP access before the handover of PDN connections to non-3GPP access is triggered, steps 2 to 11 shall be performed. In step 3 the UE shall provide an APN corresponding to one of the PDN connections that are being transferred from 3GPP access. The UE shall then repeat step 12 for each of the remaining PDN connections that are being transferred from 3GPP access.

– Step 13 shall be repeated for each PDN connection that is being transferred from 3GPP access.

Step 12 can occur in parallel for each PDN. Other impacts related to the handover for multiple PDNs are described in clause 8.1.

Steps 3 and 4 do not apply in case of handover from a 3GPP access to an untrusted non-3GPP access.

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

NOTE 1: The procedure applies both for the case where a new Serving GW is selected during attach on 3GPP access, or for the case where the Serving GW is not changed.

1) The UE is connected to the PDN via a 3GPP Access and has a PMIPv6 tunnel on the S8 interface.

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

3) After successful authentication and authorization, the L3 attach procedure in the trusted non-3GPP access is triggered as described in step 4 of clause 8.2.2.

4) The trusted non-3GPP access initiates a Gateway Control Session Establishment Procedure with the PCRF as described in step 5 of clause 8.2.2.

5) 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. Handover Indicator is set to indicate handoff between two different interfaces of the UE. The MAG creates and includes a PDN connection identity if the MAG supports multiple PDN connections to a single APN. The Additional Parameters may include Protocol Configuration Options and other information.

NOTE 2: When multiple PDN connections to a single APN are supported, the MN-ID, the APN and the PDN connection identity indentify the PDN connection within the Trusted Non-3GPP access network.

6) 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 3) to the PDN 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 3: 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.

7A) The PDN GW initiates the PCEF-Initiated IP-CAN Session Modification Procedure with the hPCRF to update the rules in the PDN GW, as specified in TS 23.203 [19].

7B) The PDN GW informs the 3GPP AAA Server of its PDN GW identity and the APN corresponding to the UE’s PDN Connection and obtains authorization information from the 3GPP AAA Server. The message includes information that identifies the PLMN in which the PDN GW is located. The 3GPP AAA Server may update the information registered in the HSS as described in clause 12.

8) The PDN GW processes the proxy binding update and creates a binding cache entry for the PMIPv6 tunnel towards the Serving GW. The PDN GW responds with a Proxy Binding Acknowledgement (MN‑NAI, Lifetime, UE Address Info, GRE key for uplink traffic, 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 a PDN connection identity, the PDN GW shall acknowledge if the PDN GW supports multiple PDN connections to a single APN. The Additional Parameters may include Protocol Configuration Options and other information. The Additional Parameters may include Protocol Configuration Options and other information.

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

NOTE 5: When the PDN GW receives the Proxy Binding Update and the the PS bearers corresponding to the PDN connection being handed over are suspended, then the PDN GW considers the bearers of the PDN connection being handed over as resumed and performs the handover.

9) 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 8) to the MAG function of Trusted Non-3GPP IP Access or ePDG.

10) The handover attach procedure is completed as described in step 9 of clause 8.2.2 (for trusted non-3GPP access) and steps 7‑8 of clause 8.2.3 (for untrusted non-3GPP access).

11) The UE is connected to the PDN via the non-3GPP access system. PDN connectivity is achieved through concatenated PMIPv6 tunnels between the trusted non-3GPP access or ePDG and the Serving GW, and between the Serving GW and the PDN GW.

12) For connectivity to multiple PDNs, the UE establishes connectivity to each PDN that is being transferred from 3GPP access, besides the PDN connection established in steps 2-11, by executing the UE-initiated Connectivity to Additional PDN procedure specified in clause 6.8.1.2, that applies to both trusted and untrusted non-3GPP accesses.

13) In case a new Serving GW has been selected during the attach on the non-3GPP access, the PDN GW triggers the bearer release in the 3GPP access using the PDN GW initiated Bearer Deactivation procedure. Otherwise, the Serving GW triggers the bearer release in the 3GPP Access using the Serving GW initiated Bearer Deactivation procedure. The 3GPP access resources associated with the PDN address are released if existing.