Content for  TS 23.401  Word version:  19.0.0

The source eNodeB decides to initiate a 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.

The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, Source to Target Transparent Container) message to the source MME to request the CN to establish resources in the target RNC and the target SGSN. The bearers that will be subject to data forwarding (if any) are identified by the new SGSN in a later step (see step 5 below).

The old MME sends a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target Identification, RAN Transparent Container, RANAP Cause, GCSI) to the new SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used, the old MME may have multiple new Gn/Gp SGSNs for each relocation target in a pool area, in which case the old MME will select one of them to become the new Gn/Gp SGSN, as specified in TS 23.236. PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the Serving-GW and the new SGSN send uplink packets). At the same time a timer is started on the MM and PDP contexts in the old MME (see Routing Area Update procedure in clause "Location Management Procedures (Iu mode)"). The old MME does not set any GCSI flag as the MME has no GPRS CAMEL Subscription Information. The S1AP Cause received from eNodeB is indicated as RANAP Cause. The Source to Target Transparent Container received from eNodeB is indicated as RAN Transparent Container. The MM context includes information on the EPS Bearer context(s). The old MME does not include any EPS Bearer Context information for "Non-IP" bearers, or for any SCEF connection, or for "Ethernet" bearers. If none of the MS's EPS Bearers can be supported by the selected new SGSN, the old MME rejects the handover attempt by sending a Handover Preparation Failure (Cause) message to the Source eNodeB.

The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, Source RNC To Target RNC Transparent Container, RAB To Be Setup) to the target RNC. 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. SGSN shall not establish RABs for PDP contexts with maximum bitrate for uplink and downlink of 0 kbit/s. The list of RABs requested by the new SGSN may differ from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent container. The target RNC should not establish the RABs (as identified from the Source-RNC to target RNC transparent container, Service Handover related information) that did not exist in the source RNC prior to the relocation. 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 SGSN Address for user data, and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to establish Direct Tunnel unless it has received a 'set' GCSI flag from the old SGSN. If the new SGSN decides to establish Direct Tunnel, it provides to the target RNC the GGSN's Address for User Plane and TEID for Uplink data. 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. After all the necessary resources for accepted RABs including the Iu user plane are successfully allocated, the target RNC shall send the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent Container, RABs Setup, RABs Failed To Setup) to the new SGSN. Each RAB to be setup 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. The transparent container contains all radio-related information that the MS needs for the handover, i.e. a complete RRC message (e.g., Physical Channel Reconfiguration in UTRAN case, or Handover From UTRAN, or Handover Command in GERAN Iu mode case) to be sent transparently via CN and source SRNC to the MS. For each RAB to be set up, the target RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN. Step 5.

If 'Indirect Forwarding' applies the source MME sends a Create Indirect Data Forwarding Tunnel Request message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Target RNC Address and TEID(s) for DL user plane) to the Serving-GW.

The Serving-GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving-GW DL TEID(s)) message to the source MME. If the Serving-GW doesn't support data forwarding, an appropriate cause value shall be returned.

The source MME completes the preparation phase towards source eNodeB by sending the message Handover Command (Target to Source Transparent Container, Bearers Subject to Data Forwarding List, S1AP Cause). "Bearers Subject to Data forwarding list" 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 5) in the case of direct forwarding or received from the Serving-GW in the preparation phase (Step 7) in the case of indirect forwarding. RANAP Cause as received from new SGSN is indicated as S1AP Cause. RAN Transparent Container as received from new SGSN is indicated as Target to Source Transparent Container.

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

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 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. Step 12. Step 13. Step 14. Step 15. A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving-GW shall be released. 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. Step 16. The PDN-GW shall include a Charging Id to be used at the SGSN as the Charging Id for reporting usage for this PDP context. The PDN-GW shall include the Charging Id in the offline charging data.

After the MS has finished the reconfiguration procedure and if the new Routing Area Identification is different from the old one or if the MS' TIN indicates "GUTI", the MS initiates the Routing Area Update procedure. See clause "Location Management Procedures (Iu mode)". For a MS supporting CIoT EPS Optimisations, the MS uses the PDP context status information in the RAU Accept to identify any non-transferred bearers that it shall locally release.

When the timer started in step 15 expires, the source MME deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication, Secondary RAT usage data) messages to the Serving-GW because the new SGSN is a Gn/Gp SGSN, which is derived from using GTPv1 for relocation signalling between new Gn/Gp SGSN and old MME. The new Gn/Gp SGSN does not signal any Serving-GW change. The operation Indication flag is not set, that indicates to the Serving-GW that the Serving-GW shall not initiate a delete procedure towards the PDN-GW. Secondary RAT usage data was included if it was received in step 11a. The Source Serving-GW acknowledges with Delete Session Response (Cause) messages. If ISR is activated the cause indicates to the old S-GW that the old 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 resources for indirect forwarding have been allocated then these are released. When the timer started in step 15 expires, the source MME sends a Release Resources message to the source eNodeB. When the Release Resources message has been received and there is no longer any need for the eNodeB to forward data, the source eNodeB releases its resources.