Content for  TS 23.401  Word version:  19.0.0

The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN Iu mode. At this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and source eNodeB, GTP tunnel(s) between source eNodeB, Serving-GW and PDN-GW. If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to a UTRAN cell that is not IMS voice capable.

The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, CSG ID, CSG access mode, Source to Target Transparent Container) message to the source MME to request the CN to establish resources in the target RNC, target SGSN and the Serving-GW. The bearers that will be subject to data forwarding (if any) are identified by the target SGSN in a later step (see step 7 below). When the target cell is a CSG cell or a hybrid cell, the source eNodeB shall include the CSG ID of the target cell. If the target cell is a hybrid cell, the CSG access mode shall be indicated.

The source MME determines from the 'Target RNC Identifier' IE that the type of handover is IRAT Handover to UTRAN Iu mode. The source MME selects the target SGSN as described in clause 4.3.8.4 on "SGSN Selection Function". The Source MME initiates the Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification, CSG ID, CSG Membership Indication, MM Context, PDN Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Source to Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, ISR Supported, Serving Network) message to the target SGSN. The information ISR Supported is indicated if the source MME and associated Serving-GW are capable to activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that maintains ISR for the UE when this SGSN is serving the target identified by the Target Identification. 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. RAN Cause indicates the S1AP Cause as received from source eNodeB. The old Serving Network is sent to target MME to support the target MME to resolve if Serving Network is changed. The source MME shall perform access control by checking the UE's CSG subscription when CSG ID is provided by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and the target cell is a CSG cell, the source MME shall reject the handover with an appropriate cause unless the UE has emergency bearer services. The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a CSG cell or hybrid cell. When the target cell is a hybrid cell, or if there are one or several emergency bearers and the target cell is a CSG cell, the CSG Membership Indication indicating whether the UE is a CSG member shall be included in the Forward Relocation Request message. The MM context includes information on the EPS Bearer context(s). The source MME does not include any EPS Bearer Context information for "Non-IP" bearers or for any SCEF connection. If none of the UE's EPS Bearers can be supported by the selected target SGSN, the source MME rejects the handover attempt by sending a Handover Preparation Failure (Cause) message to the Source eNodeB. The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values of an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN. 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. The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction value. If SIPTO at the Local Network is active for a PDN connection in the architecture with stand-alone GW the source MME shall include the Local Home Network ID of the source cell in the PDN Connections corresponding to the SIPTO at the Local Network PDN connection.

The target SGSN 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 SGSN selects the target Serving-GW as described under clause 4.3.8.2 on "Serving-GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, PDN-GW address(es) for user plane, PDN-GW UL TEID(s) for user plane, PDN-GW address(es) 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. The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as provided in step 7 of the execution phase, the EPS Bearer contexts which cannot be established.

The target Serving-GW allocates its local resources and returns 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 SGSN.

The target SGSN requests the target RNC to establish the radio network resources (RABs) by sending the message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), RAB to be setup list, CSG ID, CSG Membership Indication, Source RNC to Target RNC Transparent Container, Service Handover related information). If the Access Restriction is present in the MM context, the Service Handover related information shall be included by the target SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction. For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the Serving-GW Address for user plane (if Direct Tunnel is used) or the SGSN Address for user plane (if Direct Tunnel is not used), and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data in Serving-GW or SGSN respectively. Ciphering and integrity protection keys are sent to the target RNC to allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. Information that is required to be sent to the UE (either in the Relocation Command message or after the handover completion message) from RRC in the target RNC shall be included in the RRC message sent from the target RNC to the UE via the transparent container. More details are described in TS 33.401. The Target SGSN shall include the CSG ID and CSG Membership Indication when provided by the source MME in the Forward Relocation Request message. In the target RNC radio and Iu user plane resources are reserved for the accepted RABs. Cause indicates the RAN Cause as received from source MME. The Source RNC to Target RNC Transparent Container includes the value from the Source to Target Transparent Container received from the source eNodeB. If the target cell is a CSG cell, the target RNC shall verify the CSG ID provided by the target SGSN, and reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target cell is in hybrid mode, the target RNC may use the CSG Membership Indication to perform differentiated treatment for CSG and non-CSG members. If the target cell is a CSG cell, and if the CSG Membership Indication is "non member", the target RNC only accepts the emergency bearers.

The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message Relocation Request Acknowledge (Target RNC to Source RNC Transparent Container, RABs setup list, RABs failed to setup list). Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to receive downlink GTP PDUs from the Serving-GW, or Target SGSN if Direct Tunnel is not used, for the accepted RABs. Each RABs setup list is defined by a Transport Layer Address, which is the target RNC Address for user data, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data. Any EPS Bearer contexts for which a RAB was not established are maintained in the target SGSN and the UE. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure.

If 'Indirect Forwarding' and relocation of Serving-GW apply and Direct Tunnel is used the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (Target RNC Address and TEID(s) for DL data forwarding) to the Serving-GW. If 'Indirect Forwarding' and relocation of Serving-GW apply and Direct Tunnel is not used, then the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (SGSN Address 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.

The Serving-GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving-GW Address(es) and Serving-GW DL TEID(s) for data forwarding) message to the target SGSN.

The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, Cause, RAB Setup Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic Data Forwarding, Serving-GW change indication) to the source MME. Serving-GW change indication indicates a new Serving-GW has been selected. The Target to Source Transparent Container contains the value from the Target RNC to Source RNC Transparent Container received from the target RNC. The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint for data forwarding in target system, and it is set as follows:

• If 'Direct Forwarding' applies, or if 'Indirect Forwarding' and no relocation of Serving-GW apply and Direct Tunnel is used, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the addresses and GTP-U tunnel endpoint parameters to the Target RNC received in step 5a.
• If 'Indirect Forwarding' and relocation of Serving-GW apply, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the addresses and DL GTP-U tunnel endpoint parameters to the Serving-GW received in step 6. This is independent from using Direct Tunnel or not.
• If 'Indirect Forwarding' applies and Direct Tunnel is not used and relocation of Serving-GW does not apply, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target SGSN.

If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)), EPS Bearer ID(s)) to the Serving-GW used for indirect 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.

The Serving-GW returns the forwarding 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.

The source MME completes the preparation phase towards source eNodeB by sending the message Handover Command (Target to Source Transparent Container, E-RABs to Release List, Bearers Subject to Data Forwarding List). The "Bearers Subject to Data forwarding list" IE may be included in the message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from target side in the preparation phase (Step 7 of the preparation phase) when 'Direct Forwarding' applies, or the parameters received in Step 8a of the preparation phase when 'Indirect Forwarding' applies. The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding List". The data forwarding may go directly to target RNC or alternatively go via the Serving-GW if so decided by source MME and or/ target SGSN in the preparation phase.

The source eNodeB will give a command to the UE to handover to the target access network via the message HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are described in TS 36.300. Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, the UE shall associate its bearer IDs to the respective RABs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data.

If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT usage data to report, the eNodeB sends the RAN Usage data report message (Secondary RAT usage data) to the MME. Since the handover is an inter-RAT handover, the MME continues with the Secondary RAT usage data reporting procedure as in clause 5.7A.3. The reporting procedure in clause 5.7A.3 is only performed if PGW secondary RAT usage reporting is active.

The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the parameters provided in the message delivered in step 2. The procedure is the same as in step 6 and 8 in clause 5.2.2.2 of TS 43.129 with the additional function of association of the received RABs and existing Bearer Id related to the particular NSAPI. The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in the target RNC.

When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC shall send the Relocation Complete message to the target SGSN. The purpose of the Relocation Complete procedure is to indicate by the target RNC the completion of the relocation from the source E-UTRAN to the RNC. After the reception of the Relocation Complete message the target SGSN shall be prepared to receive data from the target RNC. Each uplink N-PDU received by the target SGSN is forwarded directly to the Serving-GW. For SIPTO at the Local Network with stand-alone GW architecture, the target RNC shall include the Local Home Network ID of the target cell in the Relocation Complete message.

Then the target SGSN knows that the UE has arrived to the target side and target SGSN informs the source MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving-GW change) message. If indicated, ISR Activated indicates to the source MME that it shall maintain the UE's context and that it shall activate ISR, which is only possible when the S-GW is not changed. The source MME will also acknowledge that information. A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving-GW (for Serving-GW relocation) shall be released. When the timer expires and ISR Activated is not indicated by the target SGSN the source MME releases all bearer resources of the UE. If Serving-GW change is indicated and this timer expires the source MME 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. 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. Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the target SGSN allocated S-GW resources for indirect forwarding. For all bearers that were not included in the Forward Relocation Request message sent in step 3, the MME now releases them by sending a Delete Bearer Command to the SGW, or, the appropriate message to the SCEF.

The target SGSN 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 SGSN is now responsible for all the EPS Bearer Contexts the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is used) and RAT type, ISR Activated) per PDN connection. As it is a mobility from E-UTRAN, if the target SGSN supports location information change reporting, the target SGSN 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 SGSN also includes the User CSG Information IE in this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. If Serving-GW is not relocated but the Serving Network has changed or if the SGSN has not received any old Serving Network information from the old MME, the SGSN includes the new Serving Network IE in this message. In network sharing scenarios Serving Network denotes the serving core network. If indicated, the information ISR Activated indicates that ISR is activated, which is only possible when the S-GW is 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. The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context deactivation procedure. 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 SGSN.

The Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) may inform 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 7. Serving Network should be included if it is received in step 7 or in step 4 in clause 5.5.2.1.2. For Serving-GW relocation, the Serving-GW allocates DL TEIDs on S5/S8 even for non-accepted bearers and may include the PDN Charging Pause Support Indication. The PDN-GW must acknowledge the request with the message Modify Bearer Response. In the case of Serving-GW relocation, the PDN-GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, PDN Charging Pause Enabled Indication (if PDN-GW has chosen to enable the function), etc.) message to the Serving-GW. The MSISDN is included if the PDN-GW has it stored in its UE context. If location information change reporting is required and supported in the target SGSN, 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. The source Serving-GW shall forwards the "end marker" packets to the source eNodeB.

The Serving-GW (for Serving-GW relocation this will be the Target Serving-GW) acknowledges the user plane switch to the target SGSN via the message Modify Bearer Response (Cause, Serving-GW Tunnel Endpoint Identifier for Control Plane, 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 EPS Bearer contexts between the UE, target RNC, target SGSN if Direct Tunnel is not used, 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.

When the UE recognises that its current Routing Area is not registered with the network, or when the UE's TIN indicates "GUTI", the UE initiates a Routing Area Update procedure with the target SGSN informing it that the UE is located in a new routing area. It is RAN functionality to provide the PMM-CONNECTED UE with Routing Area information. The target SGSN 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 SGSN performs only a subset of the RAU procedure, specifically it excludes the context transfer procedures between source MME and target SGSN. For a UE supporting CIoT EPS Optimisations, the UE uses the bearer status information in the RAU Accept to identify any non-transferred bearers that it shall locally release.

When the timer started at step 6 expires, the source MME sends a Release Resources message to the Source eNodeB. The Source eNodeB releases its resources related to the UE. When the timer started in step 6 expires and if the source MME 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, Secondary RAT usage data) 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. Secondary RAT usage data is included if it was received in step 3. 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.

If indirect forwarding was used then the expiry of the timer at source MME started at step 6 triggers the source MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary resources used for indirect forwarding.

If indirect forwarding was used and the Serving-GW is relocated, then the expiry of the timer at target SGSN started at step 6 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the target S-GW to release temporary resources used for indirect forwarding.

The Step 1 to 5 in the flow are identical to the ones in clause 5.5.2.1.2.

If the Target RNC fails to allocate any resources for any of the requested RABs it sends a Relocation Failure (Cause) message to the Target SGSN. When the Target SGSN receives the Relocation Failure message from Target RNC the Target SGSN clears any reserved resources for this UE.

This step is only performed for Serving-GW relocation, i.e. if Steps 4/4a have been performed. The Target SGSN 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.

The Target SGSN sends the Forward Relocation Response (Cause) message to the Source MME.

When the Source MME receives the Forward Relocation Response message it send a Handover Preparation Failure (Cause) message to the Source eNodeB.