8.2.1 Handover from Trusted or Untrusted Non-3GPP IP Access with PMIPv6 on S2a/S2b to 3GPP Access

23.4023GPPArchitecture enhancements for non-3GPP accessesRelease 18TS

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

8.2.1.1 General Procedure for GTP based S5/S8 for E-UTRAN Access

The steps involved in the handover from a trusted or untrusted non-3GPP IP access to E-UTRAN connected to EPC are depicted below for both the non-roaming and roaming cases and when PMIPv6 is used on S2a or S2b. It is assumed that while the UE is served by the trusted or untrusted non-3GPP IP access, a PMIPv6 tunnel is established between the non-3GPP access network and the PDN GW in the EPC.

Figure 8.2.1.1-1: Handover from Trusted or Untrusted Non-3GPP IP Access to E-UTRAN with PMIPv6 on S2a or S2b and GTP on S5/S8 interfaces

NOTE 1: All steps outside of (A) and (B) are common for architecture variants with GTP-based S5/S8 and PMIP-based S5/S8. Procedure steps (A) and (B) for PMIP-based S5/S8 are described in clause 8.2.1.2.

NOTE 2: All steps inside of (C) are common for architecture variants with GTP-based S2b and PMIP-based S2b. Procedure for steps outside of (C) for GTP-based S2b are described in clause 8.6.1.1.

In case of 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 3GPP access is triggered, steps 2 to 16 shall be skipped and the UE shall only perform step 17 for each PDN connection that is being transferred from non-3GPP access.

– If the UE is connected only to non-3GPP access before the handover of PDN connections to 3GPP access is triggered, steps 2 to 16 shall be performed. In step 3 the UE should provide the APN corresponding to one of the PDN connections that are being transferred from non-3GPP access. If the APN is not provided, and the subscription context from HSS contains a PDN GW identity corresponding to the default APN, the MME shall use the PDN GW corresponding to the default APN as specified in TS 23.401 [4]. The UE shall then repeat step 17 for each of the remaining PDN connections that are being transferred from non-3GPP access.

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

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

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.

Both the roaming (Figure 4.2.1-2) and non-roaming (Figure 4.2.1-1) scenarios are depicted in the figure. In the roaming case, the vPCRF acts as an intermediary, sending the QoS Policy Rules Provision from the hPCRF in the HPLMN to the Serving GW in the VPLMN. The vPCRF receives the Acknowledgment from the Serving GW and forwards it to the hPCRF. In the non-roaming case, the vPCRF is not involved at all.

The steps involved in the handover are discussed below.

1) The UE uses a trusted or untrusted non-3GPP access system and is being served by PDN GW (as PMIPv6 LMA).

2) The UE discovers the E-UTRAN access and determines to transfer its current sessions (i.e. handover) from the currently used non-3GPP access system to E-UTRAN. The mechanisms that aid the UE to discover the 3GPP Access system, are specified in clause 4.8 (Network Discovery and Selection).

3) The UE sends an Attach Request to the MME with Request Type indicating "Handover" Attach. The message from the UE is routed by E-UTRAN to the MME as specified in TS 23.401 [4] (E-UTRAN). The UE should include any one of the APNs, corresponding to the PDN connections in the source non-3GPP access. The APN is provided as specified in TS 23.401 [4].

4) The MME may contact the HSS and authenticate the UE as described in TS 23.401 [4].

5) After successful authentication, the MME may perform location update procedure and subscriber data retrieval from the HSS as specified in TS 23.401 [4]. Since theRequest Type is "Handover", the PDN GW identity conveyed to the MME will be stored in PDN subscription context. The MME receives information on the PDNs the UE is connected to over the non-3GPP access in the Subscriber Data obtained from the HSS.

6) The MME selects an APN, a serving GW and PDN GW as described in TS 23.401 [4]. The MME sends a Create Session Request (including IMSI, MME Context ID (SGSN equivalent is TBD), PDN-GW address, Handover Indication, APN) message to the selected Serving GW. Since the Request Type is "Handover", a Handover Indication information is included.

7) The Serving GW sends a Create Session Request (Handover Indication) message to the PDN-GW in the VPLMN or HPLMN as described in TS 23.401 [4]. Since the MME includes Handover Indication information in Create Session Request message, the Serving GW includes this information in Create Session Request message.

Since Handover Indication is included, the PDN GW should not switch the tunnel from non-3GPP IP access to 3GPP access system at this point.

8) Since Handover Indication is included, the PDN GW may execute a PCEF-Initiated IP CAN Session Modification Procedure with the PCRF as specified in TS 23.203 [19] to report e.g. change in IP-CAN type. If the UE had disconnected from the default PDN before handover then the PDN GW executes a PCEF initiated IP CAN Session Establishment procedures as described in TS 23.203 [19].

Since Handover Indication is included in step 7, the PDN GW defers any modification to the PCC Rules (due to changes received from the PCRF, if there is PCRF interaction) and still applies the existing PCC Rules for charging and policy until step 13.

Depending on the active PCC rules, the establishment of dedicated bearers for the UE may be required. The establishment of dedicated bearers in combination with the default takes place as described in Annex F of TS 23.401 [4].

NOTE 3: Depending upon the support of the piggybacking feature in the network, the dedicated bearer can be created as part of default bearer establishment or immediately afterwards.

NOTE 4: PDN GW address and Serving GW address selection is as described in the clause "GW selection" in TS 23.401 [4].

9) The PDN GW responds with a Create Session Response message to the Serving GW as described in TS 23.401 [4].The Create Session Response contains the IP address or the prefix that was assigned to the UE while it was connected to the non-3GPP IP access. It also contains the Charging Id previously assigned to the PDN connection in the non-3GPP access although the Charging Id still applies to the non-3GPP access.

10) The Serving GW returns a Create Session Response message to the MME as specified in TS 23.401 [4]. This message also includes the IP address of the UE. This message also serves as an indication to the MME that the S5 bearer setup and update has been successful. At this step the PMIPv6 or GTP tunnel(s) over S5 are established.

11) Radio and Access bearers are established at this step in the 3GPP access as specified in TS 23.401 [4].

12) The MME sends a Modify Bearer Request (eNodeB address, eNodeB TEID, Handover Indication) message to the Serving GW.

13) Since the Handover Indication is included in step 12), the Serving GW sends a Modify Bearer Request message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to 3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated EPS bearers established.

In this step, the PDN GW applies any modification to the PCC Rules received from the PCRF, if there is PCRF interaction in step 8. The Charging Id previously in use for the PDN connection in the non-3GPP access now only applies to the default bearer in use in E-UTRAN access. If dedicated bearers are created, a new Charging Id is assigned by the PGW for each of them according to TS 23.401 [4].

NOTE 5: Steps 13 and 14 are not performed if the PDNs are reconnected after handoff by the UE in step 17.

14) The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.

15) The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) message to the MME.

16) The UE sends and receives data at this point via the E-UTRAN system.

17) For connectivity to multiple PDNs, the UE establishes connectivity to each PDN that is being transferred from non-3GPP access, besides the PDN connection established in steps 3-15, by executing the UE requested PDN connectivity procedure specified in TS 23.401 [4].

18) The PDN GW shall initiate resource allocation deactivation procedure in the trusted/untrusted non-3GPP IP access as defined in clause 6.12 or clause 7.9.

8.2.1.2 Using PMIP-based S5/S8

When a Trusted or Untrusted Non-3GPP IP Access to 3GPP Access handover occurs, the following steps are performed instead of and in addition to the steps performed in the GTP-based S5/S8 case (see previous clause). In the case of PMIP-based S5/S8, a Create Session Request and Modify Bearer Request is not sent from the Serving GW to the PDN GW. Rather, the serving GW interacts with the hPCRF and PMIP messages are exchanged between the Serving GW and the PDN GW.

Figure 8.2.1.2-1: Trusted/Untrusted Non-3GPP IP Access to E-UTRAN Handover over PMIP-based S2a and using PMIP-based S5/S8

In case of 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 3GPP access is triggered, steps 2 to 16 of Figure 8.2.1.1-1 shall be skipped and the UE shall only perform step 18 of Figure 8.2.1.2-1 for each PDN connection that is being transferred from non-3GPP access.

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

– Step 19 of Figure 8.2.1.2-1 shall be repeated for each PDN connection that is being transferred from non-3GPP access.

The steps in 18 of Figure 8.2.1.2-1 can occur in parallel for each PDN. Other impacts related to the handover for multiple PDNs are described in clause 8.1.

This procedure supports the home routed (Figure 4.2.2.1), roaming (Figure 4.2.3-1) and Local breakout (Figure 4.2.3-4) case. The Serving GW establishes a Gateway Control Session with the PCRF in the HPLMN. In the case of the roaming or local breakout scenario, the Serving GW interacts with the hPCRF by way of the vPCRF. The signalling takes place through the vPCRF in the VPLMN. In the case of Local Breakout, the PDN GW in the VPLMN exchanges messages with the vPCRF. The vPCRF then exchanges messages with the hPCRF in the HPLMN.

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

The steps shown in (Alt A) and (Alt B) are mutually exclusive in this procedure, i.e. either steps A.2‑A.5 are executed or steps B.1‑B.3. In order to execute the alternative (Alt B), the IP Address(es) of the UE needs to be available after step A.1. The IP Address(es) of the UE is received in step A.1, if dynamic policy provisioning is deployed. If multiple PDN connections to same APN are supported by the Serving GW, (Alt A) shall be used in this procedure.

In case the IP address(es) of the UE is available after step A1, (Alt B) provides lower jitter for dual radio handovers. In case the IP address(es) of the UE is not available after step A1, (Alt A) shall be used.

A.1) The Serving GW initiates a Gateway Control Session Establishment Procedure with the PCRF as specified in TS 23.203 [19] to obtain the rules required for the Serving GW to perform the bearer binding for all the active sessions the UE may establish as a result of the handover procedure.

If the updated QoS rules require establishment of dedicated bearer for the UE, the establishment of those bearers take place before step B1. The establishment of dedicated bearers in combination with the default takes place as described in Annex F of TS 23.401 [4].

A.2) The Serving GW sends a PMIPv6 Proxy Binding Update (MN NAI, Lifetime, Access Technology Type, Handover Indicator, IP Address Requested, APN, GRE Key for downlink traffic, Additional Parameters) message to the PDN GW. The MN NAI identifies the UE. The Lifetime field must be set to a non-zero value in the case of a registration. Access Technology Type is set to indicate 3GPP access to EPS. The Serving GW includes request for IPv4 Home Address and/or IPv6 Home Network Prefix as specified in step C.2 of clause 5.2. The APN may be necessary to differentiate the intended PDN from the other PDNs supported by the same PDN GW. The Serving GW includes the EPS bearer identity of the default bearer received from the MME if multiple PDN connections to the same APN are supported. The optional Additional Parameters may contain information, for example, protocol configuration options.

A.3) The PDN GW executes a PCEF-Initiated IP-CAN Session Modification Procedure with the PCRF as specified in TS 23.203 [19] to obtain the rules required for the PDN GW to function as the PCEF for all the active IP sessions the UE has established with new IP-CAN type.

A.4) The PDN GW responds with a Proxy Binding Ack (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 returns the IP Address assigned to the UE. IP address allocation by the PDN-GW is as specified in clause 4.7.1. If the PDN GW sends the DHCPv4 Address Allocation Procedure Indication in the Proxy Binding Acknowledgement message, the UE IPv4 address assigned by the PDN GW is not provided as part of the default bearer activation procedures to the UE. In this case, the Serving GW does not forward the IPv4 address assigned by the PDN GW to the MME, but sets the PDN Address to 0.0.0.0 in the message to the MME. If the corresponding Proxy Binding Update contains the EPS bearer identity, the PDN GW shall acknowledge if multiple PDN connections to the given APN are supported. The optional Additional Parameter information element may contain other information, including for example Protocol Configuration Options. The Serving GW acts as the MAG (in terms of PMIPv6). Since this step is triggered by the Proxy Binding Update message from the Serving GW in step A.2, it can occur after step A.2 and does not need to wait for step A.3.

The Charging Id provided by the PGW is the Charging Id previously assigned to the PDN connection for the non-3GPP access.

NOTE 1: PDN GW address selection is as described in TS 23.401 [4].

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

Steps between A and B.1 are described in clause 8.2.1.1.

B.1-B.3) Corresponds to steps A.2 – A.4, respectively.

Steps between B.1 and 18 are described in clause 8.2.1.1.

18) For connectivity to multiple PDNs, the UE establishes connectivity to each PDN that is being transferred from non-3GPP access, besides the PDN connection established in the steps above, by executing the UE requested PDN connectivity procedure specified in clause 5.6.1.

19) The PDN GW shall initiate resource allocation deactivation procedure in the trusted/untrusted non-3GPP IP access as defined in clause 6.12 or clause 7.9.

8.2.1.3 General Procedure for GTP-based S5/S8 for UTRAN/GERAN

The steps involved in the handover from a trusted/untrusted non-3GPP IP access to UTRAN/GERAN connected to EPC are depicted below for both the non-roaming and roaming cases and when PMIPv6 is used on S2a or S2b. It is assumed that while the UE is served by the trusted/untrusted non-3GPP IP access, a PMIPv6 tunnel is established between the non-3GPP access network and the PDN GW in the EPC.

NOTE 1: This procedure is applicable to S4-SGSN only.

Figure 8.2.1.3-1: Handover from Trusted/untrusted Non-3GPP IP Access to UTRAN/GERAN with PMIP on S2a and GTP based S5/S8

NOTE 2: All steps outside of (A) and (B) are common for architecture variants with GTP based S5/S8 and PMIP based S5/S8. Procedure steps (A) and (B) for PMIP based S5/S8 are described in clause 8.2.1.4.

NOTE 3: All steps in (D) are common for architecture variants with GTP based S2b and PMIP based S2b. Procedures for steps outside of (D) for GTP based S2b are described in clause 8.6.1.2.

In case of 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 3GPP access is triggered, steps 2 to 6 shall be skipped.

– If the UE is connected only to non-3GPP access before the handover of PDN connections to 3GPP access is triggered, steps 2 to 6 shall be performed.

– The steps in (C) shall be repeated for each PDN connection that is being transferred from non-3GPP access.

The steps in (C) can occur in parallel for each PDN.

The steps involved in the handover are described below.

1. The UE uses a trusted/untrusted non-3GPP access system and is being served by PDN GW (as PMIPv6 LMA).

2. The UE discovers the 3GPP Access system (UTRAN or GERAN) and determines to transfer its current sessions (i.e. handover) from the currently used non-3GPP access system to the discovered 3GPP Access system. The mechanisms that aid the UE to discover the 3GPP Access system, are specified in clause 4.8 (Network Discovery and Selection).

3. The UE sends an Attach Request to the SGSN. The message from the UE is routed by 3GPP Access to the SGSN as specified in clause 6.5 of TS 23.060 [21].

4. The SGSN may contact the HSS and authenticate the UE as described in TS 23.060 [21].

5. The SGSN may perform location update procedure and subscriber data retrieval from the HSS as specified in TS 23.060 [21]. PDN GW identity information is part of the subscriber data.

6. The SGSN sends the Attach Accept request to the UE to indicate the completion of the attach procedure as defined in TS 23.060 [21].

7. The UE initiate at this stage this establishment of the primary PDP context as defined in clause 9.2.2 of TS 23.060 [21].

8. The SGSN selects a Serving GW as described in TS 23.060 [21] and sends Create Session Request (Handover indication, and other parameters described in TS 23.060 [21]) message to the selected Serving GW.

9. The Serving GW sends a Create Session Request message to the PDN-GW as described in TS 23.060 [21]. The PDN GW should not switch the tunnel from non-3GPP IP access to 3GPP access system at this point.

10. The PDN GW may execute a PCEF-Initiated IP CAN Session Modification Procedure with the PCRF as specified in TS 23.203 [19] to report e.g. change in IP-CAN type.

Since the PDN GW does not switch the tunnel in step 9, it defers any modification to the PCC Rules (due to changes received from the PCRF, if there is PCRF interaction) and still applies the existing PCC Rules for charging and policy until step 14.

Depending on the active PCC rules, the establishment of dedicated bearers for the UE may be required.

NOTE 4: PDN GW address and Serving GW address selection is as described in the clause "GW selection" in TS 23.401 [4].

11. The PDN GW responds with a Create Session Response message to the Serving GW as described in TS 23.060 [21].The Create Session Response contains the IP address or the prefix that was assigned to the UE while it was connected to the non-3GPP IP access. It also contains the Charging Id previously assigned to the PDN connection in the non-3GPP access although the Charging Id still applies to the non-3GPP access.

12. The Serving GW returns a Create Session Response message to the SGSN as specified in TS 23.060 [21]. This message also includes the IP address of the UE. This message also serves as an indication to the SGSN that the S5 bearer setup and update has been successful.

13. The rest of the PDP context establishment as specified in TS 23.060 [21] is completed here.

NOTE 5: The S4-SGSN sends a Modify Bearer Request message to the Serving GW including the Handover Indication flag to inform Serving GW when PDP context establishment has been completed.

14.The Serving GW sends a Modify Bearer Request message to the PDN GW in the VPLMN or the HPLMN including the Handover Indication flag that prompts the PDN GW to tunnel packets from non 3GPP IP access to 3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated EPS bearers established. In case of non-roaming or roaming with home routed traffic this message is sent to the PDN GW in the HPLMN. In case of local breakout traffic the message is sent to the PDN GW in the VPLMN.

In this step, the PDN GW applies any modification to the PCC Rules received from the PCRF, if there is PCRF interaction in step 10. The Charging Id previously in use for the PDN connection in the non-3GPP access now only applies to the default bearer in use in GERAN/UTRAN access. If dedicated bearers are created, a new Charging Id is assigned by the PGW for each of them according to TS 23.401 [4].

15. The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.

16. The UE sends and receives data at this point via the 3GPP access system.

17. The PDN GW shall initiate resource allocation deactivation procedure in the trusted/untrusted non-3GPP IP access as defined in clause 6.12 or clause 7.9.

8.2.1.4 Using PMIP-based S5/S8

When a Trusted/untrusted Non-3GPP IP Access to UTRAN/GERAN handover occurs, the following steps are performed instead of and in addition to the steps performed in the GTP based S5/S8 case (see previous clause). In the case of PMIP based S5/S8, a Create Session Request and Modify Bearer Request is not sent from the Serving GW to the PDN GW. Rather, the serving GW interacts with the hPCRF and PMIP messages are exchanged between the Serving GW and the PDN GW.

Figure 8.2.1.4-1: Trusted/untrusted Non-3GPP IP Access to GERAN/UTRAN over PMIP-based S2a and using PMIP-based S5/S8

In case of 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 3GPP access is triggered, the procedure as per Figure 8.2.1.3-1 before step 7 shall be skipped.

– If the UE is connected only to non-3GPP access before the handover of PDN connections to 3GPP access is triggered, the procedure as per Figure 8.2.1.3-1 before step 7 shall be performed.

– The steps in (C) shall be repeated for each PDN connection that is being transferred from non-3GPP access.

The steps in (C) can occur in parallel for each PDN.

This procedure supports the home routed (Figure 4.2.2-1), roaming (Figure 4.2.3-1) and Local breakout (Figure 4.2.3-4) case. The Serving GW establishes a Gateway Control Session with the PCRF in the HPLMN. In the case of the roaming or local breakout scenario, the Serving GW interacts with the hPCRF by way of the vPCRF. The signalling takes place through the vPCRF in the VPLMN. In the case of Local Breakout, the PDN GW in the VPLMN exchanges messages with the vPCRF. The vPCRF then exchanges messages with the hPCRF in the HPLMN.

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

The steps shown in (Alt A) and (Alt B) are mutually exclusive in this procedure, i.e. either steps A.2-A.5 are executed or steps B.1‑B.3. In order to execute the alternative (Alt B), the IP Address(es) of the UE needs to be available after step A.1. The IP Address(es) of the UE is received in step A.1, if dynamic policy provisioning is deployed. If multiple PDN connections to same APN are supported by the Serving GW, (Alt A) shall be used in this procedure.

If the updated PCC rules require establishment of dedicated bearer for the UE, the establishment of those bearers take place before step B.1.

The description of steps A.1 to A.4 and B.1 to B.3 are the same as in clause 8.2.1.2.