Handover

There can be many different scenario (combination) of Handover with Carrier Aggregation. I will start with the simplest case, but recently I am seeing various requirement to reduce the number of steps for Handover (e.g, PCC handover and adding SCC in a single RRC Connection Reconfiguration etc). The four cases below differ only in how much of that work is packed into one message. The last section on this page says what 36.331 allows, because the specification settles the question the fourth case leaves open.

Every diagram on this page uses the same six lifelines. Four of them are cells, eNB_PCC1, eNB_SCC1, eNB_PCC2 and eNB_SCC2, and the two on the right are the UE seen from each of its two carriers, UE_PCC and UE_SCC. A solid blue arrow is an RRC message, a dashed blue arrow is a MAC control element, and a green horizontal line marks a carrier that is carrying data.

Case 1 : Remove SCC before Handover, then HO for PCC, then Add SCC

Probably one of the simplest case of scenario we can think of would be as follows (By 'the simplest case', I mean it is the simplest in logic (the easiest to understand/implement), it didn't mean that it is the simplest in terms of the number of protocol sequence. Actually, it requires the longest steps in terms of protocol sequence). As you see here, just PCC has been changed as final result of Handover. In this scenario, Network remove SCC first before Handover and perform PCC handover and then add SCC again.

The sequence below is the longest of the four. Nothing is combined: the secondary carrier is deactivated and released, the handover runs on its own, and only then is a secondary carrier added again.

Handover sequence with the SCC removed first, then PCC handover, then the SCC added again, twelve steps

< Case 1 : twelve steps, nothing combined >

Two round trips precede the handover : step (2) is the MAC CE that deactivates SCC1, and steps (3) and (4) are the reconfiguration that releases it and the UE's complete. The handover message itself is step (5).

Carrier aggregation is off for most of the sequence : the green line at step (1) reaches UE_SCC, and the next one that does is step (12). Everything between runs on one carrier.

The orange marker at step (8) is where the handover ends : it sits between eNB_PCC2 and UE_PCC, after the RACH procedure at (6) and the reconfiguration complete at (7).

Adding the carrier back costs three more steps : the reconfiguration at (9), the complete at (10) and the activation MAC CE at (11).

Case 2 : Remove SCC and Handover for PCC in single step, then Add SCC

The first saving comes from putting two instructions in one message. The handover and the release of the secondary carrier travel together, which removes one reconfiguration and one complete from the exchange.

The sequence below is the shorter one. Read it against the diagram above, because the only difference is at the start.

Handover sequence with the SCC release carried in the handover message, ten steps

< Case 2 : ten steps, release and handover combined >

Step (3) carries both instructions : the label on that arrow reads RRC Connection Reconfiguration for Handover to PCC2 and Release SCC1, where Case 1 needed steps (3), (4) and (5) to say the same thing.

The saving is two steps, not one : the release reconfiguration and its complete both disappear, so the sequence runs to (10) rather than (12).

The tail is unchanged : the RACH procedure, the reconfiguration complete, the orange marker, the add and the activation MAC CE all appear in the same order as in the diagram above.

Step 3 - RRC Connection Reconfiguration for Handover to PCC2 and Release SCC1

The decode below is that combined message. Two branches carry the whole of it: mobilityControlInfo near the top, which is what makes the message a handover, and sCellToReleaseList-r10 at the very bottom.

The block below is decoder output, not specification text. It records one message as one network sent it, and no value in it has been corrected against a later release.

        c1: rrcConnectionReconfiguration (4)
            rrcConnectionReconfiguration
                rrc-TransactionIdentifier: 0
                criticalExtensions: c1 (0)
                    c1: rrcConnectionReconfiguration-r8 (0)
                        rrcConnectionReconfiguration-r8
                            mobilityControlInfo
                                targetPhysCellId: 10 // Physical Cell ID of PCC2 
                                carrierFreq
                                    dl-CarrierFreq: 2300 // DL Channel Number of PCC2 
                                carrierBandwidth
                                    dl-Bandwidth: n50 // Bandwidth of PCC2 
                                t304: ms1000 (5)
                                newUE-Identity: 1032 [bit length 16, 0001 0000  0011 0010 decimal value 4146]
                                radioResourceConfigCommon
                                    prach-Config
                                        rootSequenceIndex: 64
                                        prach-ConfigInfo
                                            prach-ConfigIndex: 3
                                            ...0 .... highSpeedFlag: False
                                            zeroCorrelationZoneConfig: 2
                                            prach-FreqOffset: 19
                                    pusch-ConfigCommon
                                        pusch-ConfigBasic
                                            n-SB: 1
                                            hoppingMode: interSubFrame (0)
                                            pusch-HoppingOffset: 0
                                            .0.. .... enable64QAM: False
                                        ul-ReferenceSignalsPUSCH
                                            ..0. .... groupHoppingEnabled: False
                                            groupAssignmentPUSCH: 0
                                            0... .... sequenceHoppingEnabled: False
                                            cyclicShift: 0
                                    pucch-ConfigCommon
                                        deltaPUCCH-Shift: ds2 (1)
                                        nRB-CQI: 4
                                        nCS-AN: 6
                                        n1PUCCH-AN: 0
                                    ul-CyclicPrefixLength: len1 (0)
                                rach-ConfigDedicated
                                    ra-PreambleIndex: 63
                                    ra-PRACH-MaskIndex: 0
                            radioResourceConfigDedicated
                                physicalConfigDedicated
                                    pusch-ConfigDedicated
                                        betaOffset-ACK-Index: 9
                                        betaOffset-RI-Index: 6
                                        betaOffset-CQI-Index: 6
                                    antennaInfo: explicitValue (0)
                                        explicitValue
                                            transmissionMode: tm1 (0)
                                            ue-TransmitAntennaSelection: release (0)
                                                release: NULL
                                    schedulingRequestConfig: setup (1)
                                        setup
                                            sr-PUCCH-ResourceIndex: 41
                                            sr-ConfigIndex: 27
                                            dsr-TransMax: n32 (3)
                            securityConfigHO
                                handoverType: intraLTE (0)
                                    intraLTE
                                        .... 0... keyChangeIndicator: False
                                        nextHopChainingCount: 0
                            nonCriticalExtension
                                nonCriticalExtension
                                    nonCriticalExtension
                                        sCellToReleaseList-r10: 1 item
                                            Item 0
                                                SCellIndex-r10: 1 // Serving Cell Index of SCC1

mobilityControlInfo names the target and the timer : targetPhysCellId is 10, dl-CarrierFreq is 2300 and dl-Bandwidth is n50, and t304 is ms1000. 36.331 gives t304 the values ms50 through ms10000, and index 5 of that list is ms1000, which is what the decoder printed.

The whole common configuration travels with it : radioResourceConfigCommon carries prach-Config, pusch-ConfigCommon and pucch-ConfigCommon for the target cell, because the UE has never read that cell's system information.

rach-ConfigDedicated is what makes the handover contention free : ra-PreambleIndex is 63 and ra-PRACH-MaskIndex is 0, so the UE has a preamble of its own for the RACH procedure the diagram shows at step (4).

The release sits three extensions deep : sCellToReleaseList-r10 is reached through three nested nonCriticalExtension levels, because the field was added in Release 10 to a message that existed in Release 8.

The list names the cell by index and nothing else : SCellIndex-r10 is 1, which is the serving cell index the network gave SCC1 when it added it.

Step 7 - RRC Connection Reconfiguration for adding SCC1

The decode below is the message that adds the secondary carrier back. It carries no mobilityControlInfo, so it is an ordinary reconfiguration rather than a handover.

A second capture, again left exactly as it was recorded.

       c1: rrcConnectionReconfiguration (4)
            rrcConnectionReconfiguration
                rrc-TransactionIdentifier: 0
                criticalExtensions: c1 (0)
                    c1: rrcConnectionReconfiguration-r8 (0)
                        rrcConnectionReconfiguration-r8
                            radioResourceConfigDedicated
                                mac-MainConfig: explicitValue (0)
                                    explicitValue
                                        timeAlignmentTimerDedicated: infinity (7)
                                        mac-MainConfig-v1020
                                physicalConfigDedicated
                                    cqi-ReportConfig-r10
                                        cqi-ReportAperiodic-r10: release
                                        nomPDSCH-RS-EPRE-Offset: 0dB (0)
                                    pucch-ConfigDedicated-v1020
                                        pucch-Format-r10: channelSelection-r10 (1)
                                            channelSelection-r10
                                                n1PUCCH-AN-CS-r10: setup (1)
                                                    setup
                                                        n1PUCCH-AN-CS-List-r10: 2 items
                                                            Item 0
                                                                N1PUCCH-AN-CS-r10: 4 items
                                                                    Item 0
                                                                        N1PUCCH-AN-CS-r10 item: 101
                                                                    Item 1
                                                                        N1PUCCH-AN-CS-r10 item: 102
                                                                    Item 2
                                                                        N1PUCCH-AN-CS-r10 item: 103
                                                                    Item 3
                                                                        N1PUCCH-AN-CS-r10 item: 104
                                                            Item 1
                                                                N1PUCCH-AN-CS-r10: 4 items
                                                                    Item 0
                                                                        N1PUCCH-AN-CS-r10 item: 105
                                                                    Item 1
                                                                        N1PUCCH-AN-CS-r10 item: 106
                                                                    Item 2
                                                                        N1PUCCH-AN-CS-r10 item: 107
                                                                    Item 3
                                                                        N1PUCCH-AN-CS-r10 item: 108
                            nonCriticalExtension
                                nonCriticalExtension
                                    nonCriticalExtension
                                        sCellToAddModList-r10: 1 item
                                            Item 0
                                                SCellToAddMod-r10
                                                    sCellIndex-r10: 1
                                                    cellIdentification-r10
                                                        physCellId-r10: 400
                                                        dl-CarrierFreq-r10: 5790
                                                    radioResourceConfigCommonSCell-r10
                                                        nonUL-Configuration-r10
                                                            dl-Bandwidth-r10: n50 (3)
                                                            antennaInfoCommon-r10
                                                                antennaPortsCount: an1 (0)
                                                            phich-Config-r10
                                                                phich-Duration: normal (0)
                                                                phich-Resource: oneSixth (0)
                                                            pdsch-ConfigCommon-r10
                                                                referenceSignalPower: 18dBm
                                                                p-b: 1
                                                    radioResourceConfigDedicatedSCell-r10
                                                        physicalConfigDedicatedSCell-r10
                                                            nonUL-Configuration-r10
                                                                antennaInfo-r10
                                                                    transmissionMode-r10: tm1 (0)
                                                                    ue-TransmitAntennaSelection: release (0)
                                                                        release: NULL
                                                                pdsch-ConfigDedicated-r10
                                                                    p-a: dB0

The uplink control channel is configured first : pucch-ConfigDedicated-v1020 sets pucch-Format-r10 to channelSelection-r10 and supplies two lists of four resource indices each, 101 to 104 and 105 to 108.

That configuration belongs to the PCell, not the new carrier : the acknowledgement for both carriers is sent on the PCell, so adding a second carrier means giving the PCell more PUCCH resources.

sCellToAddModList-r10 identifies the cell in two ways : sCellIndex-r10 is 1, physCellId-r10 is 400 and dl-CarrierFreq-r10 is 5790. Later messages name the cell by the index, and the other two are what the UE tunes to.

The cell arrives downlink only : radioResourceConfigCommonSCell-r10 carries nonUL-Configuration-r10 and no uplink block, so this secondary carrier receives and never transmits.

The added cell is not active yet : nothing in this message activates it, which is why the diagram above needs the MAC CE at step (9).

Case 3 : Remove SCC before Handover, then Handover for PCC and Add SCC in a single step

The second saving merges a different pair. The release keeps its own message, and the handover instead carries the instruction that adds a secondary carrier at the target.

The sequence below is ten steps again, but the pair it merges is a different pair. Compare the label on step (5) with the label on step (3) of the Case 2 diagram.

Handover sequence with the SCC release separate and the SCC addition carried in the handover message, ten steps

< Case 3 : ten steps, handover and addition combined >

Step (5) carries the addition : its label reads RRC Connection Reconfiguration for Handover to PCC2 and adding SCC, so the secondary carrier is configured before the UE has even reached the target cell.

The release is still on its own : steps (3) and (4) are the release reconfiguration and its complete, exactly as in the Case 1 diagram.

No add message follows the handover : after the orange marker at step (8) the only thing left is the activation MAC CE at (9), because the carrier was already configured.

The added carrier arrives with a full common configuration : an sCellToAddModList-r10 entry inside a handover message still carries cellIdentification-r10 and radioResourceConfigCommonSCell-r10, because the UE has never read that cell's system information.

The one carrier gap is still there : between step (4) and step (5) the UE has released SCC1 and not yet reached PCC2, which is the same gap Case 1 has and a shorter one.

The saving does not remove the activation : the carrier is configured at step (5) and still deactivated when the handover ends, so the MAC CE at step (9) is unavoidable.

Case 4 : Remove SCC, HO for PCC, Add SCC all in single step

Personally I haven't seen any real implementation for this case and haven't confirmed in 3GPP specification in detail, but just by logical point of view we can think of following scenario as well.

The sequence below merges both pairs at once. It is the shortest of the four, and the one the paragraph above is unsure about.

Handover sequence with release, handover and addition all in one message, eight steps

< Case 4 : eight steps, all three combined >

Step (3) carries three instructions : its label reads RRC Connection Reconfiguration for Releasing SCC1, HO, Adding SCC2, so one message releases the old secondary carrier, moves the primary and configures a new secondary.

Eight steps is four fewer than Case 1 : both the release exchange and the add exchange are gone, and what remains is the handover itself plus the activation.

The new secondary carrier is at the target : the green line at step (8) reaches eNB_SCC2 rather than eNB_SCC1, so the aggregation after the handover uses a different cell from the one before it.

The two secondary carriers are never configured together : SCC1 is released and SCC2 added by the same message, so the UE holds one or the other and never both.

A serving cell index can be reused in that message : clause 5.3.5.4 performs the release before the addition, so SCC2 may take the index SCC1 was using.

The new carrier belongs to the target, not the source : the added entry gives a physCellId-r10 and a dl-CarrierFreq-r10 for a cell the UE has not been aggregating with. That is what separates this case from Case 2.

What 36.331 says about these four cases

The fourth case is the one the page leaves open, and 36.331 answers it directly. The handover procedure in the specification handles both lists itself, so a single message may release one secondary carrier and add another while it moves the primary.

The handover procedure reads both lists : clause 5.3.5.4 of 36.331 v19.3.0 says the UE performs SCell release if the received RRCConnectionReconfiguration includes the sCellToReleaseList. It performs SCell addition or modification if the message includes the sCellToAddModList. Both sentences sit inside the handover clause.

The order is release first : the release sentence comes before the addition sentence in the clause, so a message that reuses a serving cell index is unambiguous.

An added cell starts deactivated unless told otherwise : the same clause handles each SCell other than the PSCell. The UE takes the state from sCellState when the message carries it, and treats the cell as deactivated when it does not. That is why every diagram above still ends with an activation MAC CE.

sCellState is a Release 15 field : it is an ENUMERATED of activated and dormant, so a later network can hand a carrier over in a state that none of the four diagrams can draw.

mobilityControlInfo has not changed shape : 36.331 v19.3.0 still opens it with targetPhysCellId, then carrierFreq, carrierBandwidth, additionalSpectrumEmission, t304 and newUE-Identity, which is the order the capture above prints.

The target frequency is optional : carrierFreq is marked Cond HO-toEUTRA2, and clause 5.3.5.4 says the UE takes the source PCell frequency when the field is absent. The capture above supplies it, because the handover crosses frequencies.

Two later handover types are missing from this page : Release 16 added conditional handover and DAPS handover. In the first, condReconfigurationToApply-r16 carries a whole RRCConnectionReconfiguration as an OCTET STRING, which the UE applies when a trigger condition is met. In the second, daps-HO lets the UE keep the source cell during the handover.

Reference

One specification settles every question this page raises. It was resolved at v19.3.0, which is the latest published version at the time of writing.

3GPP TS 36.331 v19.3.0, E-UTRA Radio Resource Control protocol specification. Clause 5.3.5.4 for the handover procedure, clause 5.3.5.9 for conditional reconfiguration, and the MobilityControlInfo, SCellToAddMod-r10 and CondReconfigurationAddMod-r16 information elements.