8.3 Handover from 3GPP access to Trusted Non-3GPP IP Access with MIPv4 FACoA on S2a

23.4023GPPArchitecture enhancements for non-3GPP accessesRelease 18TS

Figure 8.3-1: 3GPP IP Access to Non-3GPP IP access Handover over MIPv4-based S2a

In case of connectivity to multiple PDNs the following applies:

– If the UE is connected to both 3GPP access and trusted non-3GPP access before the handover of PDN connections to trusted non-3GPP access is triggered, steps 2 to 5 shall be skipped.

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

– Steps 6 to 14 shall be repeated for each PDN connection that is being transferred from 3GPP access.

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

The steps involved in the handover from 3GPP Access connected to the EPC to trusted non-3GPP IP access are depicted below for the case of non-roaming, roaming with home routed traffic, roaming with local breakout and roaming with anchoring in the Serving Gateway in the VPLMN. It is assumed that while the UE is served by the 3GPP Access, a PMIPv6 or GTP tunnel is established between the S‑GW and the PDN GW in the evolved packet core.

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 event that triggers Authentication and Authorization in step 3 or step 6 between the Trusted Non-3GPP IP Access and the 3GPP AAA Server, or whether this step occurs at all, depends on the specific access technology.

1) The UE is connected in the 3GPP Access and has a PMIPv6 or GTP tunnel on the S5 interface.

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

3) The UE performs access authentication and authorization in the non-3GPP access system as defined by TS 33.402 [45]. The 3GPP AAA server authenticates and authorizes the UE for access in the trusted non-3GPP system. As part of the authentication and authorization procedure, the 3GPP AAA server obtains the PDN-GW identity from the HSS and it returns the same PDN-GW identity to the trusted non-3GPP access system at this step (upon successful authentication and authorization).

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

5) 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.

6) The UE sends a Registration Request (RRQ) (MN-NAI, lifetime) message as defined in RFC 5944 [12] to the FA as specified in RFC 5944 [12]. 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 FA uses the PDN GW address as received in step 3. The UE then receives the IP address of the PDN Gateway in step 11 as part of the RRP message. The UE should then include the PDN Gateway address in the Home Agent address field of subsequent RRQ messages.

7) The Trusted non‑3GPP access initiates the Gateway Control Session Establishment Procedure with the PCRF. The Trusted non‑3GPP access provides the information to the PCRF to correctly associate it with the IP‑CAN session and also to convey subscription related parameters to the PCRF. If the Trusted Non-3GPP access supports UE/NW bearer control mode, the PCRF provides all the QoS rules required for the Trusted Non-3GPP access to perform the bearer binding.

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

9) 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 authentication and 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.

10) The PDN GW allocates an IP address for the UE. The PDN GW initiates the IP CAN Session Modification Procedure with the PCRF, as specified in TS 23.203 [19]. The PDN GW provides information to the PCRF that the IP-CAN type has changed and the PCRF responds to the PDN GW with PCC rules and event triggers.

NOTE: When the PDN GW receives the RRQ 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.

11) The PDN GW sends a Registration Reply (RRP) (MN-NAI, Home Address, Home Agent Address) message as defined in RFC 5944 [12] to the FA.

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

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

14) The PDN GW shall initiate the PDN GW Initiated PDN Disconnection procedure in 3GPP access as defined in clause 5.6.2.2 or the PDN GW Initiated Bearer Deactivation procedure as defined in TS 23.401 [4], clause 5.4.4.1.