4G5GWorld has a new home now. Visit TelecomGrid for new stories and blogs!

LTE Handovers - Intra E-UTRAN Handover

in Blog, Handover, Intra, Intra E-UTRAN Handover, SGW, E-UTRAN, eNB, LTE, MME

Intra E-UTRAN Handover is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is unchanged. In the scenario described here Serving GW is also unchanged. The presence of IP connectivity between the Serving GW and the source eNodeB, as well as between the Serving GW and the target eNodeB is assumed.

The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation signalling in E-UTRAN.

To prepare the HO, the source eNB passes all necessary information to the target eNB (e.g. E-RAB attributes and RRC context) and UE accesses the target cell via RACH following a contention-free procedure using a dedicated RACH preamble.

The HO procedure is performed without EPC involvement, i.e. preparation messages are directly exchanged between the eNBs. The figure below shows the basic handover scenario where neither MME nor Serving Gateway changes:

Detailed explanation of above scenario is below.

  • The source eNB configures the UE measurement procedures according to the area restriction information. UE sends MEASUREMENT REPORT by the rules set by i.e. system information, specification etc.
  • Source eNB makes decision based on MEASUREMENT REPORT and RRM information to hand off UE and issues a HANDOVER REQUEST message to the target eNB passing necessary information to prepare the HO at the target side.
  • Admission Control may be performed by the target eNB dependent on the received E-RAB QoS information to increase the likelihood of a successful HO. The target eNB configures the required resources according to the received E-RAB QoS information.
  • Target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to the UE as an RRC message to perform the handover.
  • The UE receives the RRCConnectionReconfiguration message with necessary parameters (i.e. new C-RNTI, target eNB security algorithm identifiers, and optionally dedicated RACH preamble, target eNB SIBs, etc.) and is commanded by the source eNB to perform the HO.
  • The source eNB sends the SN STATUS TRANSFER message to the target eNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies (i.e. for RLC AM).
  • After receiving the RRCConnectionReconfiguration message including the mobilityControlInformation , UE performs synchronisation to target eNB and accesses the target cell via RACH.
  • The target eNB responds with UL allocation and timing advance.
  • UE sends the RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the  RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the UE.
  • The target eNB sends a PATH SWITCH message to MME to inform that the UE has changed cell.
  • The MME sends an UPDATE USER PLANE REQUEST message to the Serving Gateway.
  • The Serving Gateway switches the downlink data path to the target side. The Serving gateway sends one or more "end marker" packets on the old path to the source eNB and then can release any U-plane/TNL resources towards the source eNB.
  • Serving Gateway sends an UPDATE USER PLANE RESPONSE message to MME.
  • The MME confirms the PATH SWITCH message with the PATH SWITCH ACKNOWLEDGE message.
  • By sending UE CONTEXT RELEASE, the target eNB informs success of HO to source eNB and triggers the release of resources by the source eNB. The target eNB sends this message after the PATH SWITCH ACKNOWLEDGE message is received from the MME.
  • Upon reception of the UE CONTEXT RELEASE message, the source eNB can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.

Source : 3GPP TS 36.300

Share this