Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.402  Word version:  18.3.0

Top   Top   Up   Prev   Next
0…   4…   4.2…   4.2.2   4.2.3   4.3…   4.4…   4.5…   4.5.7…   4.6…   4.7…   4.7.2…   4.8…   4.8.2a…   4.9…   5…   5.2…   5.4…   5.5   5.6…   5.7…   5.8…   6…   6.2…   6.3   6.4…   6.4.3…   6.5…   6.6…   6.7…   6.8…   6.10…   6.13…   6.15…   7…   7.2…   7.3   7.4…   7.5…   7.6…   7.8…   7.10…   8…   8.2.1.2   8.2.1.3…   8.2.2   8.2.3…   8.2.6…   8.3…   8.4…   8.5…   9…   9.3…   9.4…   10…   13…   16…   16.1.2…   16.1.6…   16.2…   16.2.1a…   16.3…   16.4…   16.7…   16.8…   16.10…   17…   A…   C…   E… 
8.4 Handovers with DSMIPv6 on S2c  8.4.1 Trusted or Untrusted Non-3GPP IP Access with DSMIPv6 over S2c to 3GPP Access Handover  8.4.2 3GPP Access to Trusted Non-3GPP IP Access Handover with DSMIPv6 over S2c  8.4.3 3GPP Access to Untrusted Non-3GPP IP Access Handover with DSMIPv6 over S2c 
...

 

8.4  Handovers with DSMIPv6 on S2c  p. 211

8.4.1  Trusted or Untrusted Non-3GPP IP Access with DSMIPv6 over S2c to 3GPP Access Handover  p. 211

In this scenario, the session starts in a trusted or untrusted non-3GPP access system using DSMIPv6 and subsequently, the session hands over to a 3GPP access system.
The steps involved in the handover from a trusted/untrusted non-3GPP IP access to 3GPP Access connected to EPC are depicted below when DSMIPv6 is used on S2c over non-3GPP system.
Copy of original 3GPP image for 3GPP TS 23.402, Fig. 8.4.1-1: Trusted Non-3GPP S2c (DSMIPv6) to 3GPP with S5 handover
Figure 8.4.1-1: Trusted Non-3GPP S2c (DSMIPv6) to 3GPP with S5 handover
(⇒ copy of original 3GPP image)
Up
For connectivity to multiple PDNs the following applies:
  • If 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 17 of Figure 8.2.1.1-1 for each PDN connection that is being transferred from non-3GPP access.
  • If 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 17 of Figure 8.2.1.1-1 for each of the remaining PDN connections that are being transferred from non-3GPP access.
  • Step 3 of Figure 8.4.1-1 shall be repeated for each PDN connection that is being transferred from non-3GPP access.
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.
Step 1.
The UE uses a trusted or untrusted non-3GPP access system. It has a DSMIPv6 session with the PDN-GW.
Step 2.
The UE discovers and attaches to the 3GPP access as defined in Step (C) of Figure 8.2.1.1-1, except that the IP-CAN session modification and the path switch are triggered as explained below.
Step 3.
The UE sends a BU (lifetime) to the PDN-GW to de-register its DSMIPv6 binding, as defined in RFC 5555 that was created while the UE was in non-3GPP access system. The UE shall inform the PDN-GW that the whole home prefix shall be moved. The PDN-GW responds with a BA message as defined in RFC 5555.
Any time after step 2, prior to receiving the de-registration Binding Update from the UE (i.e. BU with lifetime = 0), which is received in (step 3), the PDN-GW may de-register the DSMIPv6 binding. In this case the PDN-GW shall send a Binding Revocation Indication message to the UE.
Following the de-registration of the DSMIPv6 binding due to reception of de-registration Binding update or due to triggering Binding Revocation, the PDN-GW triggers PCEF initiated IP-CAN session modification, instead of doing it as part of the step 2, and performs path switch to forward downlink packets to the UE without any tunnelling (as the UE is on the home link).
Step 4.
This step occurs only if all PDN connections have handed over to the 3GPP access. The PCRF initiates "PCRF-initiated Gateway Control Session Termination" procedure to release the resources in the non-3GPP access. This procedure is triggered by the PCEF-Initiated IP-CAN Session Modification Procedure with the PCRF, occurring as a result of step 2.
According to RFC 4877 the security associations between the UE and the PDN-GW(s) should not be immediately deleted. As the security associations were created dynamically using IKEv2 they will be automatically deleted when they expire. The IP address used by the UE as home address is not released by the UE and the PDN-GW as a result of the deletion of such security associations if the UE remains connected to the PDN-GW. This applies also to the scenario where the UE performed the initial attach over a 3GPP access and was given a IP address, bootstrapped the DSMIPv6 over the 3GPP access, performed an handover to the non-3GPP access using S2c, and is now performing an handover towards 3GPP access and therefore returning to the Home Link.
Up

8.4.2  3GPP Access to Trusted Non-3GPP IP Access Handover with DSMIPv6 over S2c  p. 212

In this scenario, the session starts in 3GPP access (e.g. E-UTRAN) using PMIPv6 or GTP over S5 or no S5 is used (co-located Serving-GW and PDN-GW). The session hands over to the trusted non-3GPP access system that does not use PMIPv6 where the UE will receive a different prefix than the one it was using in 3GPP access system. The UE subsequently initiates DSMIPv6 with the same PDN-GW to maintain the IP session.
Support of PCC for Trusted non-3GPP accesses is optional. The PCC interactions shown in Figure 8.4.2-1 are omitted if the Trusted non-3GPP access does not support PCC. If PCC is not supported, policy rules may be configured by other means.
In the non-roaming case, none of the optional entities in Figure 8.4.2-1 are involved.
The optional entities are involved in other cases.
  • In the roaming cases, however, the 3GPP AAA Proxy mediates all interaction between the 3GPP AAA Server in the PLMN and entities in the VPLMN and non-3GPP access.
  • Similarly, interaction between hPCRF in the HPLMN and entities in the VPLMN and non-3GPP access occurs by way of the vPCRF in the VPLMN. In both these cases, messages are relayed by the optional entities towards and from the HPLMN.
Copy of original 3GPP image for 3GPP TS 23.402, Fig. 8.4.2-1: 3GPP S5 to Trusted Non-3GPP S2c (DSMIPv6) Handover
Figure 8.4.2-1: 3GPP S5 to Trusted Non-3GPP S2c (DSMIPv6) Handover
(⇒ copy of original 3GPP image)
Up
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 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 7 to 12 shall be repeated for each PDN connection that is being transferred from 3GPP access. If not performed in 3GPP access prior to the handover, Step 6 shall also be repeated for each PDN connection that is being transferred from 3GPP access.
Other impacts related to the handover for multiple PDNs are described in clause 8.1
Step 1.
The UE uses a 3GPP access system. It has an IP address that is supported over S5 interface, this IP address will be used as a HoA over the S2c reference point.
Step 2.
At this point the UE decides to initiate non-3GPP access procedure. The decision is based on any number of reasons e.g. local policies of the UE.
Step 3.
The UE shall perform access authentication and authorization in the non-3GPP access system as defined by TS 33.402 unless the conditions in TS 33.402 are met that allow to skip this procedure. In the roaming case signalling may be routed via a 3GPP AAA Proxy in the VPLMN. As part of the AAA exchange for network access authentication, the 3GPP AAA Server and/or the 3GPP AAA Proxy may return to the non-3GPP access system a set of home/visited operator's policies to be enforced on the usage of local IP address, or IPv6 prefix, allocated by the access system upon successful authentication.
Step 4.
The L3 connection is established between the UE and the Trusted Non-3GPP Access system. As a result of this procedure, an IPv4 address or an IPv6 address/prefix is also assigned to the UE by the access system (i.e. a Local IP address that will be used as a Care-of Address for DSMIPv6 over the S2c reference point).
Step 5.
The Trusted non-3GPP IP Access initiates a Gateway Control Session Establishment Procedure with the PCRF as specified in TS 23.203.
Based e.g. on the UE identity and user profile, operator's policies and the IP-CAN type, the PCRF decides on the QoS policy rules and completes the GW control session establishment towards the access gateway (5b)
In the roaming case, PCC signalling is sent via a vPCRF server in the VPLMN
Step 6.
If bootstrapping was not performed prior to the handover defined here, the UE may discover PDN-GW address using MIPv6 bootstrapping procedures defined in clause 4.5.2. If the PDN-GW discovered by the UE upon MIPv6 bootstrapping is different from the PDN-GW that was in use on the 3GPP access, a PDN-GW reallocation as per steps 2-3 in clause 6.10 is performed. The target PDN-GW that is communicated to the UE as part of the reallocation procedure must be exactly the PDN-GW that was serving the UE while on the 3GPP access.
Step 7.
The UE sends a DSMIPv6 BU message to the PDN-GW to register its CoA, the CoA is the local IP address allocated in step 4. The UE shall inform the PDN-GW that the whole home prefix shall be moved.
Step 8.
If PCC is supported, the PDN-GW executes a PCEF-Initiated IP-CAN Session Modification Procedure with the PCRF as specified in TS 23.203.
In the roaming case, PCC signalling is sent via a vPCRF server in the VPLMN.
Step 9.
The PDN-GW sends the MIP Binding Ack to the UE. Since this step is triggered by the Binding Update message from the UE in step 7, it can occur after step 7 and does not need to wait for step 8.
The PDN-GW may send message 9 before the procedure in step message 8 is complete.
Step 10.
The PCRF initiates the Gateway Control and QoS Rules Provision Procedure specified in TS 23.203 by sending a message with the information of mobility protocol tunnelling encapsulation header to the Trusted non-3GPP IP Access. In case the QoS rules have changed, the updated QoS rules shall also be included in this message.
Step 11.
The UE continues with IP service using the same IP address in step 1.
Step 12.
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 clause 5.4.4.1 of TS 23.401.
Up

8.4.3  3GPP Access to Untrusted Non-3GPP IP Access Handover with DSMIPv6 over S2c  p. 214

In this scenario, the session starts in 3GPP access (e.g. E-UTRAN) using either GTP or PMIPv6 is used over S5, or no S5 is used (co-located Serving-GW and PDN-GW). ). In the roaming case instead of S5, S8 is used. The session hands over to an untrusted non-3GPP access system that does not use PMIPv6 where the UE will receive a different prefix from the ePDG than the one it was using in 3GPP access system The UE subsequently initiates DSMIPv6 with the its PDN-GW to maintain the IP session.
Support of PCC for Untrusted non-3GPP accesses is optional. The PCC interactions shown in Figure 8.4.3-1 are omitted if the Untrusted non-3GPP access does not support PCC. If PCC is not supported, policy rules may be configured by other means.
In the non-roaming case, none of the optional entities in Figure 8.4.3-1 are involved.
The optional entities are involved in other cases.
  • In the roaming cases, however, the 3GPP AAA Proxy mediates all interaction between the 3GPP AAA Server in the PLMN and entities in the VPLMN and non-3GPP access.
  • Similarly, interaction between hPCRF in the HPLMN and entities in the VPLMN and non-3GPP access occurs by way of the vPCRF in the VPLMN. In both these cases, messages are relayed by the optional entities towards and from the HPLMN.
Copy of original 3GPP image for 3GPP TS 23.402, Fig. 8.4.3-1: 3GPP Access to Untrusted Non-3GPP IP Access with S2c (DSMIPv6) Handover
Figure 8.4.3-1: 3GPP Access to Untrusted Non-3GPP IP Access with S2c (DSMIPv6) Handover
(⇒ copy of original 3GPP image)
Up
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 untrusted non-3GPP access is triggered, steps 2 to 4 shall be skipped.
  • If the UE is connected only to 3GPP access before the handover of PDN connections to untrusted non-3GPP access is triggered, steps 2 to 4 shall be performed.
  • Steps 6 to 10 shall be repeated for each PDN connection that is being transferred from 3GPP access. If not performed in 3GPP access prior to the handover, Step 5 shall also be repeated for each PDN connection that is being transferred from 3GPP access.
Other impacts related to the handover for multiple PDN-GWs are described in clause 8.1
Step 1.
The UE uses a 3GPP access system. It has an IP address that is supported over S5 interface, this IP address will be used as a HoA over the S2c reference point.
Step 2.
At this point the UE decides to initiate non-3GPP access procedure. The decision is based on any number of reasons e.g. local policies of the UE.
Step 3.
Access authentication procedure between UE and the 3GPP EPC may be performed as defined by TS 33.402.
Step 4.
The IKEv2 tunnel establishment procedure is started by the UE. The UE may indicate in a notification part of the IKEv2 authentication request that it supports MOBIKE. The ePDG IP address to which the UE needs to form IPsec tunnel is discovered via DNS query as specified in clause 4.5.4. After the UE is authenticated, UE is also authorized for access to the APN. The procedure is as described in TS 33.402.
Step 5.
The ePDG sends the final IKEv2 message with the assigned IP address in IKEv2 Configuration payloads. The IKEv2 procedure is completed and the IPSEC tunnel is set-up. In this procedure, the assigned IP address is an IPv4 address or an IPv6 prefix assigned to the UE by the ePDG and the assigned IP address that will be used as a Care-of Address for DSMIPv6 over the S2c reference point.
Step 6.
If bootstrapping was not performed prior to the handover defined here, the UE may discover PDN-GW address using DSMIPv6 bootstrapping procedures defined in clause 4.5.2. If the PDN-GW discovered by the UE upon MIPv6 bootstrapping is different from the PDN-GW that was in use on the 3GPP access, a PDN-GW reallocation as per steps 2-3 in clause 6.10 is performed. The target PDN-GW that is communicated to the UE as part of the reallocation procedure must be exactly the PDN-GW that was serving the UE while on the 3GPP access.
Step 7.
The UE sends a DSMIPv6 BU message to the PDN-GW to register its CoA. The UE shall inform the PDN-GW that the whole home prefix shall be moved.
Step 8.
If PCC is supported, the PDN-GW executes a PCEF-Initiated IP-CAN Session Modification Procedure with the PCRF as specified in TS 23.203 to obtain the rules required for the PDN-GW in the VPLMN or HPLMN to function as the PCEF for all the active sessions the UE has established with the new IP-CAN type as a result of the handover procedure.
Step 9.
The PDN-GW sends the DSMIPv6 Binding Ack to the UE. Since this step is triggered by the Binding Update message from the UE in step 6, it can occur after step 6 and does not need to wait for step 7.
The PDN-GW may send message 8 before the procedure in step 8 is complete.
Step 10.
The UE continues with IP service using the same IP address in step 1.
Step 11.
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 clause 5.4.4.1 of TS 23.401.
Up

Up   Top   ToC