Conditional Handover (CHO) & DAPS in 5G NR

1. Two Different Weaknesses, Two Different Fixes

The companion 22 Handover Overview budgets a good NR handover at about 26 ms of user-plane interruption, and the companion 23 Xn Handover shows the procedure that produces it. Both documents describe a mechanism that works. Rel-16 added CHO and DAPS not because baseline handover is broken but because it has two distinct weaknesses that no amount of parameter tuning removes, and each enhancement removes exactly one of them.

Table 1. CHO and DAPS are not two attempts at the same thing. A network that measures only mean interruption will conclude CHO does almost nothing, and a network that measures only handover failure rate will conclude DAPS does almost nothing. Both conclusions are artefacts of the metric.

One more mechanism belongs here even though it is a different release. LTM, Rel-18's L1/L2-triggered mobility, attacks both weaknesses at once by moving the switch decision out of RRC entirely: candidates are pre-configured, the switch command is a MAC CE, and execution can be RACH-less. Section 17 covers it, and §18 puts all four mechanisms on one page.

2. CHO: the Dependency It Breaks

Work through baseline handover as a sequence of things that can fail, in the order they happen, and one pattern stands out.

Table 2. Four steps, and the two that are most likely to fail are the two carried on the source link at the moment it is worst. The third row is the dominant cause of too-late handover failures.

CHO's insight is that the third row does not have to be there. Nothing forces the command to be delivered at the moment of execution. If the network sends it while the source link is still comfortable and the UE stores it, the command has already survived the link before the link gets bad. Execution then costs no signalling at all: the UE applies something it already has.

That inverts the usual trade. Baseline handover delays the command until the last useful moment so that the decision is based on fresh measurements. CHO sends the command early and moves the decision to the moment of execution instead -- and because the decision is now made by the UE against its own live measurements, it is fresher than the network's could ever be. The original short version of this document put it well: the value is not that CHO cells are more reliable, it is that the decision is made much closer to the moment of execution.

3. conditionalReconfiguration, Field by Field

All of CHO on the air interface is one optional IE inside RRCReconfiguration, and its structure is worth reading closely because the nesting is where the design lives: each candidate carries a complete stored RRCReconfiguration, including its own reconfigurationWithSync and therefore its own target cell, its own C-RNTI and its own T304.

-- TS 38.331, abridged with `...` marking omitted fields and extension
-- markers. Rel-16 suffixes retained because they are what a decoder prints.

RRCReconfiguration-v1610-IEs ::= SEQUENCE {
    otherConfig-r16              OtherConfig-r16              OPTIONAL,
    bap-Config-r16               SetupRelease { BAP-Config-r16 } OPTIONAL,
    iab-IP-AddressConfigurationList-r16  ...                   OPTIONAL,
    conditionalReconfiguration-r16  ConditionalReconfiguration-r16 OPTIONAL,
    daps-SourceRelease-r16       ENUMERATED{true}             OPTIONAL,
    ...
}

ConditionalReconfiguration-r16 ::= SEQUENCE {
    attemptCondReconfig-r16      ENUMERATED {true}            OPTIONAL,
    condReconfigToRemoveList-r16 CondReconfigToRemoveList-r16 OPTIONAL,
    condReconfigToAddModList-r16 CondReconfigToAddModList-r16 OPTIONAL,
    ...
}

CondReconfigToRemoveList-r16 ::=
    SEQUENCE (SIZE (1..maxNrofCondCells-r16)) OF CondReconfigId-r16
CondReconfigToAddModList-r16 ::=
    SEQUENCE (SIZE (1..maxNrofCondCells-r16)) OF CondReconfigToAddMod-r16

CondReconfigToAddMod-r16 ::= SEQUENCE {
    condReconfigId-r16      CondReconfigId-r16,          -- INTEGER (1..8)
    condExecutionCond-r16   SEQUENCE (SIZE (1..2)) OF MeasId  OPTIONAL,
    condRRCReconfig-r16     OCTET STRING (CONTAINING RRCReconfiguration)
                                                             OPTIONAL,
    ...
}

maxNrofCondCells-r16  INTEGER ::= 8

-- and inside each stored condRRCReconfig, the ordinary machinery:
--   masterCellGroup -> CellGroupConfig -> spCellConfig
--                   -> reconfigurationWithSync
--                      { spCellConfigCommon, newUE-Identity, t304,
--                        rach-ConfigDedicated, ... }

Listing 1. The recursion is the point: condRRCReconfig is an RRCReconfiguration, so everything the companion 22 Handover Overview says about reconfigurationWithSync applies inside each candidate, independently.

Table 3. The whole air-interface configuration. Everything else about CHO is either measurement configuration (§4) or Xn signalling (§5).

4. CondEvent A3, A5 and A4: Same Inequality, Different Consumer

CHO does not invent new measurement mathematics. A CondEvent A3 uses the same entry and leaving inequalities as the event A3 in the companion 20 Measurements and Events, with the same a3-Offset, the same hysteresis and the same timeToTrigger. What differs is who consumes the result: an ordinary A3 produces a MeasurementReport on SRB1, and a CondEvent A3 produces nothing on the air -- it satisfies a condition the UE is evaluating against its own stored candidate list.

-- TS 38.331, abridged. condTriggerConfig is a reportType alternative,
-- alongside periodical and eventTriggered.

ReportConfigNR ::= SEQUENCE {
    reportType  CHOICE {
        periodical            PeriodicalReportConfig,
        eventTriggered        EventTriggerConfig,
        reportCGI             ReportCGI,
        ...,
        reportSFTD            ReportSFTD-NR,
        condTriggerConfig-r16 CondTriggerConfig-r16,     -- CHO / CPAC
        ...
    }
}

CondTriggerConfig-r16 ::= SEQUENCE {
    condEventId  CHOICE {
        condEventA3  SEQUENCE {
            a3-Offset-r16       MeasTriggerQuantityOffset,
            hysteresis-r16      Hysteresis,
            timeToTrigger-r16   TimeToTrigger
        },
        condEventA5  SEQUENCE {
            a5-Threshold1-r16   MeasTriggerQuantity,   -- serving cell
            a5-Threshold2-r16   MeasTriggerQuantity,   -- neighbour
            hysteresis-r16      Hysteresis,
            timeToTrigger-r16   TimeToTrigger
        },
        ...,
        condEventA4-r17 SEQUENCE {
            a4-Threshold-r17    MeasTriggerQuantity,
            hysteresis-r17      Hysteresis,
            timeToTrigger-r17   TimeToTrigger
        }
    },
    ...
}

Listing 2. Note what CondTriggerConfig does not have: no reportAmount, no reportInterval, no reportQuantity, no maxReportCells. There is no report, so there is nothing to configure about one.

Table 4. The three CondEvents. The inequalities are identical to the reporting events of the same names; only Off in the A3 form comes from a3-Offset inside CondTriggerConfig rather than from an EventTriggerConfig.

5. Candidate Preparation, and What It Costs at Every Candidate

Preparation is the ordinary Xn handover preparation of the companion 23 Xn Handover, run once per candidate, with one Rel-16 addition: HANDOVER REQUEST carries a Conditional Handover Information Request IE that tells the target this is a candidate, not a commitment TS 38.423 cl. 9.1.1. The target's answer is the same HANDOVER REQUEST ACKNOWLEDGE, with the same transparent container carrying the same target-authored RRCReconfiguration. Everything the source relays to the UE is authored by the candidates.

Table 5. CHO preparation against baseline preparation. Only the first two rows are new IEs; the rest are new procedures and new timer values, which is why a Rel-15 peer cannot participate.

5.1 What is actually reserved, per candidate

Table 6. Per candidate, per UE, for the whole life of the conditional configuration. Multiply by the number of candidates and by the number of UEs in the overlap region before deciding that 8 candidates sounds generous.

6. Execution: the UE Decides, Alone

Execution is the part with no signalling in it. The UE evaluates each stored candidate's condExecutionCond at its ordinary measurement cadence; when a candidate's condition has held for its timeToTrigger, the UE selects that candidate, applies the stored condRRCReconfig, and from that instant behaves exactly as it would have on receiving a baseline handover command -- release the source, start T304, access the target TS 38.331 cl. 5.3.5.13.

1. Evaluate. For each stored condReconfigId, check every measId in its condExecutionCond. Where there are two, both must hold. Evaluation runs against the same layer-3 filtered measurements as ordinary reporting, so filterCoefficient applies here too (companion 20 Measurements and Events §6).
2. Time the condition. The entry condition must hold continuously for timeToTrigger. A CHO timeToTrigger is usually shorter than the reporting one -- 40 to 80 ms against 160 to 320 ms -- because the whole point is to execute promptly once the condition is genuinely met.
3. Select. If exactly one candidate qualifies, take it. If several qualify in the same evaluation, TS 38.331 does not mandate a rule: the choice is the UE's. Most implementations take the strongest, but you cannot rely on it, and two UE models in the same location can legitimately pick differently.
4. Apply. Apply the selected candidate's stored condRRCReconfig as if it had just arrived on SRB1. This includes its masterCellGroup, its radioBearerConfig, its masterKeyUpdate and its reconfigurationWithSync.
5. Start that candidate's T304. Each stored configuration carries its own t304 inside its own reconfigurationWithSync, and it starts now -- not at configuration time. Two candidates may carry different T304 values because they were authored by different gNBs.
6. Release the source and access the target. MAC reset, source C-RNTI discarded, retune, RACH at the selected target using the CFRA preamble that candidate allocated (companion 03 Random Access).
7. Discard everything else. On successful completion the UE releases the entire stored conditional reconfiguration -- all candidates, including the one it used. There is no residue, which is why a Rel-16 UE cannot chain one CHO execution into the next (§22).

7. Cancellation, the Remove List, and Stale Candidates

A prepared candidate that is never used has to be dismantled in two places: at the UE, where the stored configuration would otherwise keep being evaluated, and at the candidate gNB, where the context and the reserved resources of §5.1 sit idle. The two are separate mechanisms and either can be skipped.

Table 7. Four clean-up paths. Only the second is automatic and reliable; the first and third are things a source gNB has to remember to do, and the fourth is a timer measured in seconds.

There is also a genuinely benign version of the same signature. A UE that stops at the edge of a coverage overlap and stays there will hold its candidates for as long as it is stationary, and none of them is stale in any meaningful sense. Distinguishing the two requires looking at whether the candidate's measurements are still plausible, which is why implementations refresh condReconfigToAddModList periodically rather than configuring once and forgetting.

8. Late Data Forwarding and EARLY STATUS TRANSFER

Here is CHO's real cost, and it is a user-plane cost rather than a signalling one. In a baseline Xn handover the source knows the target because it chose the target, so it can send SN STATUS TRANSFER and start forwarding within a millisecond or two of transmitting the handover command (companion 23 Xn Handover §11 and §12). In CHO the source does not know which candidate the UE picked until the candidate tells it. Everything downstream of that knowledge is late.

Table 8. The same procedure, one piece of missing knowledge, and a measurably worse user plane. This is the trade CHO makes for its robustness.

8.1 What EARLY STATUS TRANSFER is for

Ordinary SN STATUS TRANSFER has a hard ordering constraint: it conveys the next downlink PDCP SN the source would have assigned, which means the source must have stopped assigning them. It cannot be sent early without stopping the downlink early, which would lengthen the interruption for nothing. Rel-16 breaks that coupling with a separate class 2 procedure TS 38.423 cl. 8.2.

Table 9. EARLY STATUS TRANSFER, abridged. The Rel-17 DL discarding stage is the one that makes the message useful for DAPS as well as for CHO.

9. CHO Failure Handling, and Trying Another Candidate

Once the UE has executed, the failure handling is ordinary handover failure handling: T304 expires, the UE reverts to the source configuration if it can and initiates RRC re-establishment (companion 22 Handover Overview §8, companion 16 RLM and RLF). CHO adds one thing to that path, and it is the most valuable single line of configuration in the feature.

With attemptCondReconfig set, a UE that is performing RRC re-establishment and whose cell selection lands on a cell that is the target of one of its stored candidates applies that stored condRRCReconfig directly, instead of sending RRCReestablishmentRequest TS 38.331 cl. 5.3.5.13. It skips the whole re-establishment exchange -- no request, no RRCReestablishment with a fresh NCC, no RRCReestablishmentComplete, no SRB1-only intermediate state, no context fetch over Xn.

Table 10. Four recoveries in descending order of desirability. The first exists only for CHO, and the gap between it and the second is the reason attemptCondReconfig is worth setting even in deployments that never see a CHO failure.

9.1 Timers around CHO and DAPS

Table 11. Timers that matter to these two features. Only T304 and the PDCP timers are specified with ranges in TS 38.331; the XnAP timers are implementation choices that TS 38.423 names but does not bound.

10. DAPS: Removing the Interruption Instead of the Risk

DAPS starts from a different complaint. Suppose every handover succeeded first time, every command arrived, every target admitted every bearer. There would still be an interval -- about 26 ms in the budget of the companion 22 Handover Overview -- in which the UE has released the source and cannot yet be scheduled at the target. That interval is inherent to break-before-make, and no amount of robustness work removes it, because it is not a failure. It is the design.

Two thirds of it is not radio, either. Ten milliseconds is the UE's RRC processing allowance and five is the mean wait for a PRACH occasion. A faster physical layer does not help. The only way to remove the interval is to not have it: keep the source link up and receiving while the target link is established, and switch when the target is demonstrably working. That is make-before-break, and DAPS is its implementation.

Table 12. The two patterns. Every row after the first follows from it: keeping the source means keeping a second MAC, a second RLC, and a PDCP entity that has to cope with two sources of the same bearer.