Evolved Handovers: EV-DO and LTE

One key feature of any mobile communication system is to provide a mobility mechanism for mobiles to do fast and seamless switching between serving cells. There are many different handover mechanisms for achieving this goal. They include soft handover, which is mostly used for voice services, and hard handover, which is designed for data services. Hard handovers can be further classified as network-controlled handovers and mobile-based handovers. The interesting thing is if you look at the basic handover or handoff procedures I will explain in the next, you may feel a long-time debate on which entity , base stations or mobiles, should control handover or handoff.

Traditionally there is no standardized direct connection between two BTS's, even they both belong to the same BSC. Therefore, there usually are a long outage for a mobile do hard handover. For example, the default forward traffic channel MAC handover scheme of CDMA2000 EV-DO Rev. 0 usually results in 100~200ms outage. In order to minimize this outage for some delay-sensitive services, EV-DO Rev. A specially provides a new uplink channel,  DSC (Data Source Control) channel, for mobile to indicate early knowledge of its upcoming handover. When a mobile starts a handover in EV-DO Rev. A network, it sends a forward cell switch indication, a new DSC, to a target BTS for a duration of DSCLength. Meanwhile, it is still receiving data from its current serving BTS until this mobile performs a DRCCover change to the target BTS.  DRCCover is used by the mobile to specify its best serving BTS. During this moment, the queue transfer will be completed from the source BTS to the target BTS.

In LTE Release 8, things changed a little bit. A X2 connection between base stations, eNodeBs, is standardized and it is assumed to always exist as long as they belong to the same pooling area defined by a MME. The basic procedure for a LTE mobile to do handover becomes that the mobile sends Measurement Reports back to its current serving eNodeB and its serving eNodeB decides if to perform a handover and selects a target eNodeB. Source eNodeB then issues a Handover Request message to target eNodeB and passes necessary information. After target eNodeB accepts the request, it will prepare for it and acknowledge it after the preparation is done. As soon as source eNodeB receives Handover Request Acknowledge message, both a handover command and data forwarding are transmitted.

However, story doesn't stop here. Since a LTE mobile starts its handover when the radio link it sees from its serving eNodeB isn't very good, there is a possibility that it detects a radio link failure and can't successfully decode the handover command. In this case, it starts a RLF (Radio Link Failure) timer. Upon the expiration of RLF timer, the mobile searches for a good target eNodeB and tries to re-establish its connection with the target eNodeB while remain in connected state. During the period before a successful connection to eNobeB, source eNodeB will notice the changes and communicate with target eNodeBs through X2 interface to ensure the L1/L2 handover. If the re-connection failed, the mobile will switch from connected state to idle state and do a NAS recovery after that.

Wait a minute ... there is more.  Usually RLF timer is optimized to be several hundred ms. This means the delay of RLF timer based handover can be relatively long. If the mobile can send re-connection request to target eNodeB before RLF timer expires and target eNodeB can request handover from source eNodeB instead of waiting, the handover delay can be reduced accordingly. In this case, the handover sounds more like to be mobile-initiated or mobile-based.