Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   4.2.2…   4.3…   4.3.6…   4.3.8…   4.3.12…   4.3.16…   4.3.20…   4.3.25…   4.4…   4.6…   4.7…   5…   5.1.2…   5.3…   5.3.2…   5.3.3…   5.3.3.2   5.3.3.3…   5.3.4…   5.3.4B…   5.3.5…   5.3.8…   5.3.9…   5.4…   5.4.4…   5.5…   5.5.1.2…   5.5.2…   5.5.2.2…   5.5.2.3…   5.5.2.4…   5.6…   5.7.3…   5.7A…   5.10   5.11…   5.19…   D…   D.3…   D.3.4   D.3.5   D.3.6   D.3.7…   D.3.8…   E   F…   J…   K…   L…   M…

 

5.5.2.4  GERAN A/Gb mode to E-UTRAN Inter RAT handoverp. 309

5.5.2.4.1  Generalp. 309
The procedure is based on Packet-switched handover for GERAN A/Gb mode, defined in TS 43.129.
Pre-conditions:
  • The UE is in READY state (GERAN A/Gb mode);
  • The UE has at least one PDP/EPS Bearer Context established;
  • The BSS must support PFM, Packet Flow Management, procedures.
5.5.2.4.2  Preparation phasep. 310
Reproduction of 3GPP TS 23.401, Fig. 5.5.2.4.2-1: GERAN A/Gb mode to E-UTRAN inter RAT HO, preparation phase
Up
Step 1.
The source access system, Source BSS, decides to initiate an Inter-RAT Handover to the E-UTRAN. At this point both uplink and downlink user data is transmitted via the following: Bearers between UE and Source BSS, BSSGP PFC tunnel(s) between source BSS and source SGSN, GTP tunnel(s) between Source SGSN, Serving-GW and PDN-GW.
Step 2.
The source BSS sends the message PS handover Required (TLLI, Cause, Source Cell Identifier, Target eNodeB Identifier, Source eNodeB to Target eNodeB Transparent Container and active PFCs list) to Source SGSN to request the CN to establish resources in the Target eNodeB, Target MME and the Serving-GW.
Step 3.
The Source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT PS Handover to E-UTRAN. The Source SGSN selects the Target MME as described in clause 4.3.8.3 on "MME Selection Function". The Source SGSN initiates the Handover resource allocation procedure by sending message Forward Relocation Request (IMSI, Target Identification, MM Context, PDN Connections, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, Source to Target Transparent Container, RAN Cause, Packet Flow ID, SNDCP XID parameters, LLC XID parameters, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, ISR Supported, Serving Network) to the target MME. When ISR is activated the message should be sent to the MME that maintains ISR for the UE when this MME is serving the target identified by the Target Identification. If indicated, the information ISR Supported indicates that the source SGSN and associated Serving-GW are capable to activate ISR for the UE. This message includes all PDN Connections active in the source system and for each PDN Connection includes the associated APN, the address and the uplink tunnel endpoint parameters of the Serving-GW for control plane, and a list of EPS Bearer Contexts established in the source system. The EPS Bearer Contexts indicate the PFIs and the XID parameters related to those EPS Bearer Contexts, and the uplink Tunnel endpoint parameters of the Serving-GW. The old Serving Network is sent to target MME to support the target MME to resolve if Serving Network is changed. In network sharing scenarios Serving Network denotes the serving core network.
The RAN Cause includes the value from the Cause IE received from the source BSS. Source to Target Transparent Container includes the value from the Source eNodeB to Target eNodeB Transparent Container received from the source BSS.
The MM context includes information on the EPS Bearer context(s). If none of the UE's EPS Bearers can be supported by the selected target MME, the source SGSN rejects the handover attempt by sending a PS Handover Required Negative Acknowledge (Cause) message to the Source BSS.
Prioritization of EPS Bearer Contexts is performed by the target core network node.
The MME establishes the EPS bearer(s) in the prioritized order. The MME deactivates, as provided in step 8 of the execution phase, the EPS bearers which cannot be established.
The MM context contains security related information, e.g. supported ciphering algorithms as described in TS 29.274. Handling of security keys is described in TS 33.401.
For the EPS Bearer Context with traffic class equals 'Background', the source SGSN shall indicate via the Activity Status Indicator IE that radio bearers shall be established on the target side.
The target MME shall determine the Maximum APN restriction based on the APN Restriction of each bearer context received in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction value.
Step 4.
The target MME determines if the Serving-GW is to be relocated, e.g. due to PLMN change. If the Serving-GW is to be relocated, the target MME selects the target Serving-GW as described under clause 4.3.8.2 on "Serving-GW selection function". The target MME sends a Create Session Request message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, PDN-GW address(es) for user plane, PDN-GW UL TEID(s) for user plane, PDN-GW address for control plane, and PDN-GW TEID(s) for control plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the target Serving-GW. The Protocol Type over S5/S8 is provided to Serving-GW which protocol should be used over S5/S8 interface.
Step 4a.
The target Serving-GW allocates its local resources and returns them in a Create Session Response (Serving-GW address(es) for user plane, Serving-GW UL TEID(s) for user plane, Serving-GW Address for control plane, Serving-GW TEID for control plane) message to the target MME.
Step 5.
The Target MME will request the Target eNodeB to establish the Bearer(s) by sending the message Handover Request (UE Identifier, S1AP Cause, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), EPS Bearers to be setup list, Source to Target Transparent Container, Handover Restriction List). The Target MME ignores any Activity Status Indicator within an EPS Bearer Context and requests the eNodeB to allocate resources for all EPS Bearer Contexts received from the source side. The S1AP Cause includes the value from the RAN Cause IE received from the source SGSN. The target eNodeB shall ignore it if the number of radio bearers in the Source to Target Transparent container does not comply with the number of bearers requested by the MME and allocate bearers as requested by the MME. Handover Restriction List is sent if it is available in the Target MME; it is described in clause 4.3.5.7.
For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information such as ID, bearer parameters, Transport Layer Address, "Data forwarding not possible" indication, and S1 Transport Association. The Transport Layer Address is the Serving-GW Address for user data, and the S1 Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. "Data forwarding not possible" indication shall be included if the target MME decides the corresponding bearer will not be subject to data forwarding.
The ciphering and integrity protection keys will be sent transparently from the target eNodeB to the UE in the Target to Source Transparent Container, and in the message PS Handover Command from source BSS to the UE. This will then allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. More details are described in TS 33.401.
Step 5a.
The Target eNodeB allocates the request resources and returns the applicable parameters to the Target MME in the message Handover Request Acknowledge (Target to Source Transparent Container, S1AP Cause, EPS Bearers setup list, EPS Bearers failed to setup list). Upon sending the Handover Request Acknowledge message the target eNodeB shall be prepared to receive downlink GTP PDUs from the Serving-GW for the accepted EPS bearers.
Step 6.
If 'Indirect Forwarding' and relocation of Serving-GW apply, the target MME sends a Create Indirect Data Forwarding Tunnel Request message (Target eNodeB Address(es) and TEID(s) for DL data forwarding) to the Serving-GW.
Indirect forwarding may be performed via a Serving-GW which is different from the Serving-GW used as the anchor point for the UE.
Step 6a.
The Serving-GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving-GW Address(es) and DL TEID(s) for data forwarding) message to the target MME.
Step 7.
The Target MME sends the message Forward Relocation Response (Cause, List of Set Up PFCs, MME Tunnel Endpoint Identifier for Control Plane, RAN Cause, MME Address for control plane, Target to Source Transparent Container, Address(es) and TEID(s) for Data Forwarding, Serving-GW change indication) to the Source SGSN. Serving-GW change indication indicates whether a new Serving-GW has been selected. The RAN Cause includes the value from the S1AP Cause IE received from the target eNodeB. The Target to Source Transparent Container includes the value from the Target to Source Transparent Container received from the target eNodeB.
If 'Direct Forwarding' applies or if 'Indirect Forwarding' but no relocation of Serving-GW applies, then the IEs 'Address(es) and TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the eNodeB received in step 5a. If 'Indirect Forwarding' and relocation of Serving-GW apply the IEs 'Address(es) and TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the Serving-GW received in step 6a.
Step 8.
If 'Indirect Forwarding' applies, the source SGSN shall send the message Create Indirect Data Forwarding Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving-GW used for indirect packet forwarding.
Indirect forwarding may be performed via a Serving-GW which is different from the Serving-GW used as the anchor point for the UE.
Step 8a.
The Serving-GW returns the forwarding user plane parameters by sending the message Create Indirect Data Forwarding Tunnel Response (Cause, Serving-GW Address(es) and TEID(s) for Data Forwarding). If the Serving-GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving-GW Address(es) and TEID(s) will not be included in the message.
Up
5.5.2.4.3  Execution phasep. 313
Reproduction of 3GPP TS 23.401, Fig. 5.5.2.4.3-1: GERAN A/Gb mode to E-UTRAN Inter RAT HO, execution phase
Up
The source SGSN continues to receive downlink and uplink user plane PDUs.
When source SGSN receives the Forward Relocation Response message it may start downlink N-PDU relay and duplication to the target eNodeB (for Direct Forwarding) or via the Serving-GW (for Indirect Forwarding), and the target eNodeB may start blind transmission of downlink user data towards the UE over the allocated radio channels.
Step 1.
The Source SGSN completes the preparation phase towards Source BSS by sending the message PS HO Required Acknowledge (TLLI, List of Set Up PFCs, Target RNC to Source BSS Transparent Container, Cause). This message includes all PFIs that could be established on the Target side. The Cause includes the value from the RAN Cause IE received from the target MME. The Target RNC to Source BSS Transparent Container includes the value from the Target to Source Transparent Container received from the target MME.
Before sending the PS Handover Required Acknowledge message, the source SGSN may suspend downlink data transfer for any EPS Bearer contexts.
Before sending the PS Handover Command message to the UE the source BSS, may try to empty the downlink BSS buffer for any BSS PFCs.
Step 2.
The Source BSS will command the UE to handover to the target eNodeB via the message PS Handover Command. The access system specific message to UE includes a transparent container including radio aspect parameters that the Target eNodeB has set-up in the preparation phase.
Step 3.
Void.
Step 4.
The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB.
Step 5.
When the UE has got access to Target eNodeB it sends the message HO to E-UTRAN Complete.
The UE shall implicitly derive the EPS bearers for which an E-RAB was not established from the PS Handover Command and deactivate them locally without an explicit NAS message at this step.
Step 6.
When the UE has successfully accessed the Target eNodeB, the Target eNodeB informs the Target MME by sending the message Handover Notify (TAI+ECGI). As a separate activity the Target eNodeB retrieves the UE E-UTRA capability information using the procedure for UE Radio Capability Handling (see clause 5.11.2).
If Dual Connectivity is activated for the UE, the PSCell ID shall be included in the Handover Notify message.
Step 7.
Then the Target MME knows that the UE has arrived to the target side and Target MME informs the Source SGSN by sending the Forward Relocation Complete Notification (ISR Activated, Serving-GW change) message. If indicated, ISR Activated indicates to the source SGSN that it shall maintain the UE's contexts and activate ISR, which is only possible when the S-GW is not changed. The Source SGSN shall also acknowledge that information. When the Forward Relocation Complete Notification message has been received and there is no longer any need for the SGSN to forward data, the SGSN stops data forwarding. A timer in source SGSN is started to supervise when resources in the Source Serving-GW (for Serving-GW relocation) shall be released.
Upon receipt of the Forward Relocation Complete Acknowledge message the target MME starts a timer if the target MME applies indirect forwarding.
Step 8.
The Target MME will now complete the Handover procedure by informing the Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) that the Target MME is now responsible for all the EPS bearers the UE have established. This is performed in the message Modify Bearer Request (Cause, MME Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), MME Address for Control Plane, eNodeB Address(es) and TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated, User Location Information, PSCell ID) per PDN connection. As it is a mobility from GERAN, if the target MME supports location information change reporting, the target MME shall include the User Location Information (according to the supported granularity) in the Modify Bearer Request, regardless of whether location information change reporting had been requested in the previous RAT by the PDN-GW. If the PDN-GW requested User CSG information (determined from the UE context), the MME also includes the User CSG Information IE in this message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. If the Serving-GW is not relocated but the Serving Network has changed or if the MME has not received any old Serving Network information from the old SGSN, the MME includes the new Serving Network IE in this message. If indicated, ISR Activated indicates that ISR is activated, which is only possible when the S-GW was not changed. When the Modify Bearer Request does not indicate ISR Activated and S-GW is not changed, the S-GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the S-GW reserved. If the MME has received PSCell ID in step 6, it shall include it in Modify Bearer Request.
The MME releases the non-accepted dedicated bearers by triggering the bearer release procedure as specified in clause 5.4.4.2. If the Serving-GW receives a DL packet for a non-accepted bearer, the Serving-GW drops the DL packet and does not send a Downlink Data Notification to the MME.
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are other PDN connections active, the MME shall handle it in the same way as if all bearers of a PDN connection have not been accepted. The MME releases these PDN connections by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3.
Step 9.
The Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) informs the PDN-GW(s) the change of, for example, for Serving-GW relocation or the RAT type, that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection. The S-GW also includes User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 8. Serving Network should be included if it is received in step 8 or in step 4 in clause 5.5.2.4.2. For Serving-GW relocation, the Serving-GW allocates DL TEIDs on S5/S8 even for non-accepted bearers and PDN Charging Pause Support Indication shall be included. The PDN-GW must acknowledge the request with the message Modify Bearer Response (Charging Id, MSISDN, PDN Charging Pause Enabled Indication (if PDN-GW has chosen to enable the function), etc.) to the Serving-GW. If location information change reporting is required and supported in the target MME, the PDN-GW shall provide MS Info Change Reporting Action in the Modify Bearer Response.
If PCC infrastructure is used, the PDN-GW informs the PCRF about the change of, for example, the RAT type.
If the Serving-GW is relocated, the PDN-GW shall send one or more "end marker" packets on the old path immediately after switching the path in order to assist the reordering function in the target eNodeB. The source Serving-GW shall forward the "end marker" packets to the source SGSN.
Step 10.
The Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) acknowledges the user plane switch to the Target MME via the message Modify Bearer Response (Cause, Serving-GW Tunnel Endpoint Identifier for Control Plane, Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) Address for Control Plane, Protocol Configuration Options, MS Info Change Reporting Action). At this stage the user plane path is established for all bearers between the UE, Target eNodeB, Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) and PDN-GW.
If the Serving-GW does not change, the Serving-GW shall send one or more "end marker" packets on the old path immediately after switching the path in order to assist the reordering function in the target eNodeB.
Step 11.
When the timer at the source SGSN started in step 7 expires the Source SGSN will clean-up all its resources towards Source BSS by performing the BSS Packet Flow Delete procedure.
Step 12.
The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for tracking area update" applies.
The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer context(s) by handover messages and therefore the target MME performs only a subset of the TA update procedure, specifically it excludes the context transfer procedures between source SGSN and target MME.
If the Subscription Data received from the HSS (during the TAU in step 12) contains information that is necessary for the E-UTRAN to be aware of (e.g. a restriction in the UE's permission to use NR as a secondary RAT, Unlicensed Spectrum in the form of LAA/LWA/LWIP/NR-U (as specified in clause 4.3.30) or a combination of them), or an existing UE context in the MME indicates that the UE is not permitted to use NR as a secondary RAT, Unlicensed Spectrum or a combination of them and the MME has not provided this information to the target eNodeB during step 5 of the handover preparation phase, then the MME sends an updated Handover Restriction List in the Downlink NAS Transport message that it sends to E-UTRAN. If the UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in TAU Accept message.
Step 13.
When the timer at the source SGSN started in step 7 expires and if the source SGSN received the Serving-GW change indication in the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the Source Serving-GW. The operation Indication flag is not set, that indicates to the Source Serving-GW that the Source Serving-GW shall not initiate a delete procedure towards the PDN-GW. The Source Serving-GW acknowledges with Delete Session Response (Cause) messages. If ISR has been activated before this procedure, the cause indicates to the Source S-GW that the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.
Step 14.
If indirect forwarding was used then the expiry of the timer at source SGSN started at step 7 triggers the source SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary resources used for indirect forwarding.
Step 15.
If indirect forwarding was used and the Serving-GW is relocated, then the expiry of the timer at target MME started at step 6 triggers the target MME to send a Delete Indirect Data Forwarding Tunnel Request message to the target S-GW to release temporary resources used for indirect forwarding.
Up
5.5.2.4.4  GERAN A/Gb mode to E-UTRAN Inter RAT handover rejectp. 316
The Target eNodeB may reject the use of the Handover procedure if none of the requested EPS bearers in the Handover Request message could be established. In this case no UE context is established in the target MME/eNodeB and no resources are allocated. The UE remains in the Source BSS/SGSN.
Reproduction of 3GPP TS 23.401, Fig. 5.5.2.4.4-1: GERAN A/Gb mode to E-UTRAN inter RAT HO reject
Up
Step 1.
Steps 1 to 5 in the flow are identical to the ones in clause 5.5.2.4.2.
Step 6.
If the Target eNodeB fails to allocate any resources for any of the requested EPS Bearers it sends a Handover Failure (Cause) message to the Target MME. When the Target MME receives the Handover Failure message from Target eNodeB the Target MME clears any reserved resources for this UE.
Step 7.
This step is only performed for Serving-GW relocation, i.e. if Steps 4/4a have been performed. The Target MME deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving-GW. The Target Serving-GW acknowledges with Delete Session Response (Cause) messages.
Step 8.
The Target MME sends the Forward Relocation Response (Cause) message to the Source SGSN.
Step 9.
When the Source SGSN receives the Forward Relocation Response message it send a PS Handover Required Negative Acknowledge (Cause) message to the Source BSS.
Up

5.5.2.5  Inter RAT handover Cancelp. 316

5.5.2.5.1  Generalp. 316
Instead of completing the handover procedure, the source RAN node (eNodeB, RNC or BSS) may at any time during the handover procedure, up to the time when a handover command message is sent to the UE cancel the handover. The reason for cancelling may be e.g. due to a timer expiration or due to other events within the source RAN node and is initiated by sending a handover cancel PDU to the source EPC node (MME or SGSN).
A handover cancel PDU shall also be sent by the source RAN node after a handover command message is sent to the UE for the case where the handover fails and the UE returns to the old cell or radio contact with the UE is lost. This is done in order to release the resources reserved for the Handover in the target system.
Up
5.5.2.5.2  Source RAN to Target RAN Inter RAT handover Cancelp. 317
Reproduction of 3GPP TS 23.401, Fig. 5.5.2.5.2-1: Inter RAT handover Cancel
Up
Step 1.
The source RAN decides to cancel the previously requested relocation of Handover resources. This may be due to not enough accepted bearers, UE returned to source cell or any other reason.
Step 2.
The source RAN sends a Cancel message with a Cause to the source EPC node (SGSN or MME). If the source RAN is:
  1. BSS the message sent is PS Handover Cancel (Cause),
  2. RNC the message sent is Relocation Cancel (Cause), or
  3. eNodeB the message sent is Handover Cancel (Cause).
Step 3.
The source EPC node terminates the relocation towards the target side by sending a Relocation Cancel Request (IMSI) message to the target EPC node. The Source EPC node also resumes operation on the resources in the source side.
Step 4.
The target EPC node triggers the release of resources in the target RAN and also releases its own resources allocated for this handover.
Step 5.
This step is only performed for Serving-GW relocation. The Target EPC node deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving-GW. The Target Serving-GW acknowledges with Delete Session Response (Cause) messages.
Step 6.
The target EPC node acknowledge the release of all resources on the target side by returning a Relocation Cancel Response (Cause) message to the source EPC node.
Step 7.
The source EPC node returns a Cancel acknowledge message to the source RAN. If the source RAN is:
  1. BSS there will be no acknowledge message sent to the source BSS,
  2. RNC the message sent is Relocation Cancel Acknowledge (Cause), or
  3. eNodeB the message sent is Handover Cancel Acknowledge (Cause).
Step 8.
If indirect forwarding tunnel is setup during handover preparation then cancellation of handover triggers the source MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary resources used for indirect forwarding.
Step 9.
If indirect forwarding tunnel is setup during handover preparation and serving GW is relocated then cancellation of handover triggers the target MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary resources used for indirect forwarding.
Up

Up   Top   ToC