This is the key to mobility robustness in 5G networks

New mobile services that require low-latency and high reliability performance are emerging. While the 5G standard has been designed to address these services from the start, the evolution of 5G New Radio (NR) needs to continuously enhance the mobility robustness performance for these challenging scenarios. The main mobility enhancement specified by 3GPP in Rel-16, named “Conditional Handover (CHO)”, focuses on reducing the number of failure occurrences while a user is moving (for example, when a handover between cells fails, or when a connection fails even before a handover (HO) is triggered).

In conditional handover, instead of preparing one target cell as in the legacy case, multiple candidate target cells are prepared in advance in the network, which enables the handover command to be sent to the mobile terminal earlier than at normal handover when the radio conditions are still good, rather than when conditions start to get degraded as in legacy handover.

When received, the mobile terminal stores the command, instead of applying it immediately. In fact, the terminal only applies the stored command when a condition configured in the terminal is satisfied for one of the configured candidate target cells, and then the mobile terminal executes the handover and connects to the target node as in a normal handover.

What is handover?

Let’s go into the details of this solution. First, how is “handover” specified?

Mobility in connected mode – which is when a mobile terminal is active – is controlled by the network, assisted by the mobile terminal. The mobile terminal transmits measurement reports if the link to the serving cell is getting degraded and/or another neighboring cell in the same frequency is getting better than the serving cell.
Based on these measurement reports, the network may possibly move (i.e., hand over) the mobile terminal connection from the serving cell to that neighbor cell, so the mobile terminal will get better radio conditions and consequently a better user experience.

In 5G NR, handover is a special case of a procedure called “reconfiguration with sync”. It can happen that when the radio link becomes degraded and the mobile terminal needs to send measurement reports – the uplink link is degraded, and the reports never reach the network. Or, even if they do, the network tries to respond with a handover command that may never reach the mobile terminal (either because the downlink- is degraded and/or the handover command is so large that it requires multiple transmissions). The following figure shows when these two cases might happen:

Figure 1: Mobility-related failure. A UE (User Equipment) represents a mobile terminal in 3GPP specifications language.

Conditional handover reduces the amount of mobility-related failures

The conditional handover feature standardized in Rel-16 works like this: the mobile terminal receives a handover command and stores it (an RRCReconfiguration message prepared by a target candidate), without applying it as it would have done in legacy handover. Together with the command, the mobile terminal also receives an associated condition to be monitored. When the condition is fulfilled, the mobile terminal applies the previously stored handover command, as if the network would have just sent it, instead of first sending a measurement report (that could fail to be transmitted) and then waiting to receive the command (which may fail to be received).

The condition that defines the criteria to apply the stored handover command is based on the quality of the serving cell(s) and neighbor cells, somewhat similar to the condition that in previous releases leads the mobile terminal to transmit a measurement report when the condition is fulfilled. For example, the network can configure the wireless terminal to transmit a measurement report when a neighbor cell becomes an offset better than the serving cell, as a way to indicate to the network that a handover may be needed. In conditional handover, a similar condition can be configured, except that instead of transmitting the measurement report, the mobile terminal applies the stored message. Sending the handover command when the radio conditions are still favorable reduces the risk of failing the transmission of the measurement report and/or the reception of the handover command. It is also possible to configure two conditions for the mobile terminal and associate both to the stored command - i.e. the command is applied only if both conditions are fulfilled. To some extent, we attempt to replicate - in the mobile terminal - criteria the network would define for handover based on multiple measurement reports triggered by multiple conditions. An example could be measurement reports for different types of measurement quantities, like cell coverage represented by Radio Signal Received Power (RSRP), and quality represented by Radio Signal Received Quality (RSRQ).

Simulation results confirm these improvements, especially for terminals moving at moderate speed, where a fast and efficient legacy handover is most challenging. For example,  Figure 2, shows the number of failed handovers for different values of threshold for the condition, where each curve represents a different speed of the mobile terminal. As you can see, there’s about a 40 percent reduction in mobility failures for speeds of 15 m.s-1 (~50 km/h) regardless of the threshold values for the conditions.

Another effect we can see from the simulations is the effect of the threshold values. A higher value means that conditional handover would only be executed when the neighbor cell is much better than the serving cell, compared to a lower value, which would mean that conditional handover is executed if the neighbor cell is slightly better. Larger thresholds tend to increase chances of failure, since the mobile terminal may fail before finding a much better neighbor. Important to note here is that the results cover a certain deployment scenario and show relative gains over a legacy handover procedure (i.e. a 40 percent reduction in mobility failures). The threshold value configuration with respect to the network deployment can possibly provide larger gains.

Figure 2: Simulation results showing Handover failure reduction with CHO

On the network side, the serving node can prepare one or more target “candidate” cells , as it’s not certain if the mobile terminal will access a specific target cell. The conditional handover preparation procedure(s) has some similarities with the handover preparation procedure, and the outcome is the creation of a handover command (i.e. an RRCReconfigurationmessage containing  the target’s configuration), except that the target node does not expect the mobile terminal to access it immediately, and in some cases, not even to access it at all.

The best case scenario is that the mobile terminal will execute the handover in only one of the prepared cells. The node hosting this cell needs to inform the source node that the mobile terminal successfully performed the handover in its cell, so that the source node can cancel the resources reserved by the remaining target candidate nodes. Additionally, the time between the handover preparation (and therefore the resource reservation) being unknown, the source node is also able to release the reserved resources before the mobile terminal executes the handover.

Figure 3: Conditional Handover configuration and execution

The trade-offs

If multiple cells need to be prepared to further increase robustness, and in the best case scenario the mobile terminal accesses one of them, a set of resources would need to be reserved while the UE is monitoring the condition and does not perform the handover. The network therefore needs to carefully select the target candidate and keep the number of target candidate cells to a reasonable amount, especially in a resource constrained scenario like in a high load.

Another aspect to be carefully considered is the user plane design. Standardization supports two approaches: early data forwarding and late data forwarding. In early data forwarding, data is forwarded during the preparation phase and the main benefit is to enable similar interruption performance as legacy, while increasing robustness. In that solution, the complexity increases with the number of target candidates and the time it takes until the handover is actually performed. Late data forwarding is a simpler alternative, when data starts to be forwarded by the serving node when the UE accesses the target cell. The benefit is that the serving node only forwards data to a single neighbor node, even if multiple have been prepared, and forwarding only starts after the UE accesses a target cell, after the condition is fulfilled.

Performing a handover instead of re-establishments in case of failure

Another benefit of conditional handover is the fact that the mobile terminal has handover commands stored for multiple cells, which reduces interruption time even if a failure occurs. It works like this: while the mobile terminal is monitoring the conditions, a failure may be detected. In Rel-15, the terminal would perform cell selection (i.e., select a neighboring cell to connect to, without the help of the network) and continue with a re-establishment procedure. However, with the introduction of conditional handover, when the same type of failure  is detected (e.g. a radio link failure or handover failure), the terminal can prioritize a cell for which it has a stored handover command and, instead of performing re-establishment, it performs a conditional handover, which reduces the interruption time and the signaling over the air interface. A link to more reading about reducing mobility interruption time in 5G networks can be found at the end of the post.

The framework for conditional handover is mainly specified in the Radio Resource Control (RRC) specifications (TS 38.331) and in Xn interface specifications (TS 38.423) and is made generic so it can be further enhanced for other types of conditional reconfiguration(s). For example, conditional PSCell change in case of dual-connectivity is also supported in Rel-16, borrowing most of the functionalities defined for conditional handover. A summarized version can be found in the 3GPP document TS 38.300, available for download from this 3GPP archive.

The conditional handover story for 5G NR is not ending in Rel-16. Discussions in 3GPP included other interesting enhancements that could be further studied and introduced, such as:

• Conditional PScell addition (to be standardized in Rel-17, as part of MR-DC enhancements)
• Suspension of conditional handover configurations so that an RRC_INACTIVE UE can resume these configurations when transitioning to RRC_CONNECTED. In Rel-16 the UE deletes the conditional handover configurations when entering RRC_INACTIVE or RRC_IDLE. Read more about inactive state in our blog post about how we set a new standard for reduced latency of devices
• Possibility to configure conditional handover during Resume procedure, so the network does not need to use an additional round trip time to configure conditional handover for a UE entering RRC_CONNECTED
• Transmission of measurements from the wireless terminal to the network when conditional handover is being executed, so the network can efficient setup carrier aggregation and/or dual connectivity

Explore more

Find out more about 3GPP release 16 and 17:

• Read our Ericsson Technology Review article on the 5G New Radio evolution
• Take a look at key innovation areas of 3GPP Rel-17
• Read our blog post on reducing mobility interruption time in 5G networks