Definition
Handover Management is responsible for the signaling process, resource allocation, and data forwarding when the terminal moves from one cell to another while in the connected state ( RRC_CONNECTED ). Handover is network-controlled (different from reselection in idle mode). Handover types include intra-frequency, inter-frequency, and inter-system (such as LTE to 5G NR EN-DC), and the handover strategy affects drop rate, latency, and user experience.
Handover Process
- Measurement Reporting: The terminal reports the serving and neighboring cells' RSRP/RSRQ according to the measurement configuration, supporting events A1~A6, B1/B2, etc.
- Handover Decision: The source base station decides whether to perform a handover and the target cell based on measurement reports, load, SON policies, etc.
- Handover Execution: The source base station initiates a handover request (X2/Xn) to the target base station, the target allocates resources, and the terminal executes the handover.
- Data Forwarding: The source base station forwards in-transit data via X2/Xn, reducing packet loss.
Handover Types and Optimization
Intra-frequency handover is based on the A3 event (neighbor cell better than serving cell + offset); inter-frequency/inter-system requires consideration of measurement gaps and priorities. In dual connectivity (DC), secondary cell change (PSCell Change) can be performed instead of a full handover. Mobility strategies cooperate with location updates to ensure service continuity.
Typical Use Cases
Continuity of connections for IoT devices in mobile scenarios such as vehicles, logistics, and high-speed rail. SimtoLink IoT SIM cards automatically complete handovers within the operator network, and the cloud platform can monitor handover events and disconnection rates.
Handover management directly affects the connection continuity of IoT devices in mobile scenarios such as vehicles and logistics. SimtoLink IoT SIM cards automatically perform handovers within the operator network, ensuring that devices stay connected while on the move. The SimtoLink cloud platform can monitor device handover events and disconnection rates, providing connectivity quality analysis and optimization recommendations for mobile IoT customers.
An event threshold has to be read together with hysteresis
Intra-frequency handover is often triggered when a neighbor is better than the serving cell by an offset. If the offset is too small, ordinary level fluctuation triggers it. If the offset is too large, the device stays at the edge of the serving cell and then the radio link fails. Hysteresis requires that advantage to last for a while. Tuning only the threshold, and not the hysteresis, means a high-speed pass through the overlap zone never lets the measurement settle. The handover is either missed or triggered by mistake. To judge whether the parameters fit, look at handover count and radio-link failure count on one trip. Many handovers and many failures usually mean the trigger is too sensitive. Many failures and few handovers usually mean the device left too late.
Inter-frequency and inter-system handover also insert measurement gaps, and service pauses briefly inside a gap. Gaps that are too dense cut throughput. Gaps that are too sparse miss a neighbor change. Measurement configuration for a vehicle device should follow the expected speed. A stationary meter does not need gaps that dense.
After the target cell rejects, the source side must be able to return to the original bearer
When the source base station requests a handover from the target, the target may reject it because there are no radio resources, no compatible bearer, or the transport path is unreachable. After a rejection, the device should stay on the source cell and keep using the original bearer. If the source side has already stopped scheduling and never received the rejection, the device is in neither the source cell nor the target cell, and it can recover only by re-establishment. The log needs three parts: the request, the rejection, and the recovery. Without the rejection you cannot tell a full target from a request that never arrived.
Under dual connectivity, changing a secondary cell is lighter than a full handover. A failure hits the rate of the secondary leg, and the primary leg is still there. Treating a secondary-leg failure as a whole-network drop and attaching again tears down a primary connection that was still up. Module events should distinguish a primary-cell handover from a secondary-cell change.
If in-flight data is not forwarded, the application sees a short stretch of disorder
At the handover instant, downlink that was already sent to the source base station but has not reached the device, and uplink that the device already sent and the source has not delivered to the core network, need to be moved to the target over the inter-site interface. If the forwarding path is not configured, or its delay is too long, the application sees a sequence hole or a brief reordering. Reliable transport retransmits. A real-time stream loses that short stretch. To separate a forwarding problem from a coverage problem: if the level recovers after the handover and loss is only near the handover point, check inter-site forwarding first. If the level is still poor after the handover, the target cell itself is unusable.
A SimtoLink card follows the base stations through handover on the operator network. The card does not choose the target cell. If the cloud platform records every cell change as a drop, it overstates the fault. Count successful handover, re-establishment after handover, and failed re-establishment separately. A card on a logistics vehicle that re-establishes again and again on a fixed road segment means the handover zone or the target cell on that segment is at fault. Changing the card does not change the forwarding relationship between base stations.
A successful re-establishment does not mean the handover command was ever carried out
Re-establishment after a radio-link failure is the device joining again. It does not necessarily pass through the handover path of measurement, decision, target preparation, and forwarding. Re-establishment can restore the connection, but in-flight data is not forwarded the way a handover would forward it, and the application is more likely to see a hole. If a successful re-establishment is counted as a successful handover, a problem on the handover zone is hidden as an “occasional reconnect.” Count them apart. A handover command, followed by access completed on the target cell, is a handover. No handover command, and a return to connected state straight from the failure, is a re-establishment.
If re-establishments cluster on one short stretch of road, the device left the serving cell too late, or it did not return to a usable cell in time after the target rejected it. If the SimtoLink platform records only the change of cell identity, the two procedures look the same. The module side should be able to distinguish handover completion from re-establishment after a link failure. A change of identity with no failure cause cannot be used to tune the handover threshold. The threshold has to be changed from the failure type. Changing it the wrong way turns a stretch that could hand over into frequent re-establishment.