Carrier Aggregation (DL & UL) in 5G NR

1. Why Carrier Aggregation Exists, and Why Not One Wide Carrier

The obvious question first. If a UE can be given 273 PRBs on a 100 MHz carrier and the operator holds 200 MHz, why not simply define a 200 MHz carrier and be done with it? The answer is a stack of constraints that have nothing to do with the air interface being incapable, and everything to do with spectrum, radio hardware and the licences that were actually won at auction.

Table 1. Six reasons a wide single carrier is not an option, and what CA substitutes for each. Only the first is a specification limit; the rest are facts about the world that the specification has to accommodate.

So CA exists because spectrum arrives in pieces. But the reason it is hard is different, and it is the theme of this document: aggregating carriers forces a set of decisions about which cell owns control. Exactly one cell carries the PUCCH that acknowledges everything (or exactly two, if a second PUCCH group is configured). Exactly one cell issues the grants for any given carrier. Exactly one cell can declare radio link failure. Exactly one cell can be relied on to be there, because every other cell is allowed to be asleep. Those decisions are made in RRC configuration, enforced in MAC, and almost never visible in throughput counters -- which is why a CA problem in the field is nearly always a control-plane or activation-latency problem wearing a throughput problem's clothes.

1.1 What triggers CA, and when

CA is not established at connection setup. A UE arrives on one cell through Random Access, completes RRC setup, reports its capabilities, and only then can SCells be configured. The sequence, and the decisions along it, are:

1. Capability. The UE's UE-NR-Capability lists band combinations. Nothing outside that list may be configured. See the companion 26 UE Capability, which owns the feature-set machinery.
2. Measurement. The network needs to know the candidate SCell frequencies are actually receivable at this UE. Either a measurement on the SCell frequency (a measObject for it, reported through an A4 or A1 event) or, for a co-sited carrier in the same band, an inference from the PCell measurement. See the companion 20 Measurements and Events.
3. Decision. A scheduler-internal threshold: buffer occupancy above some level, or a sustained PCell utilisation, or simply a policy of adding SCells to every UE that supports them.
4. Configuration. RRCReconfiguration with sCellToAddModList (§6). The SCell now exists and is deactivated.
5. Activation. An SCell Activation/Deactivation MAC CE (§7). This is the step that costs tens of milliseconds and the step most often blamed on the wrong thing.
6. Use. Only once the UE has settled AGC, acquired time and frequency tracking, and produced a CSI report can the scheduler put a sensible MCS on the new carrier. Until then the carrier is configured, activated, and worth nothing.

2. The Cell Taxonomy, Precisely

Six terms, routinely used as if two or three of them were synonyms. They are not, and the differences decide what happens when things break. The distinction that matters most: some of these terms exist under carrier aggregation, and some exist only under dual connectivity.

Table 2. The taxonomy as a table. Note that three of the eight entries are roles or groupings rather than cells, which is the root of most of the confusion.

For what a cell means to RRC -- what state the UE is in, what context exists where -- see the companion 14 RRC States. For the dual connectivity case, where all of PSCell, SCG and the second MAC entity come into play, see the companion 28 NSA Attach Process, which walks an EN-DC establishment end to end. This document is about the CA case: one cell group, one MAC entity, one scheduler, one RRC connection.

3. CA Types and Spectrum Arrangement

Three arrangements, distinguished by where the carriers sit relative to each other. The distinction is not academic: it decides how many transceiver chains the UE needs, how much spectrum is lost to guard bands, whether one timing advance serves all carriers, and what the band combination string looks like in the capability message.

Table 3. The three CA types. The RF column is why a UE's supported band combination list is shorter than the arithmetic of its band support suggests -- each combination is a distinct hardware claim, not a software one.

3.1 Guard bands and nominal channel spacing

A 100 MHz NR channel at 30 kHz SCS carries 273 PRBs. Those PRBs occupy 273 x 12 x 30 kHz = 98.28 MHz, so 1.72 MHz of the channel is guard band -- 0.86 MHz at each edge, against a specified minimum of 845 kHz TS 38.101-1 Table 5.3.3-1. Two such channels placed side by side at a centre spacing of exactly 100 MHz therefore leave 1.72 MHz of unused spectrum between the two PRB grids, which is nearly twice what either carrier needs on that side.

Intra-band contiguous CA is allowed to do better. The nominal channel spacing for adjacent aggregated carriers TS 38.101-1 cl. 5.4.1.2 is smaller than the sum of the half-bandwidths, because the two carriers' inner guard bands overlap and only one of them is actually needed: the neighbour is not an unrelated emitter, it is the same transmitter. Squeezing the spacing does not give either carrier more PRBs -- 273 is 273 -- it gives back roughly 0.9 MHz of spectrum at the outer edge of the pair, which matters when the operator's holding is fixed and a third carrier is trying to fit. §19.3 carries the arithmetic through.

3.2 What the arrangement does not change

Worth stating explicitly, because it is where intuition misleads. The arrangement changes RF, spectrum efficiency and timing. It does not change any of the protocol machinery in the rest of this document. An intra-band contiguous SCell is configured with the same SCellConfig, activated with the same MAC CE, made dormant the same way and scheduled with the same DCI as an inter-band SCell three gigahertz away. MAC and RRC do not know or care where the carrier is. Only the UE's RF, the TAG assignment and the band combination check care.

4. Carrier Limits, Bandwidth Classes and Band Combinations

NR supports up to 16 component carriers per direction, which is the number that gets quoted and the number that almost never appears in the field. The limits, in ascending order of how much they actually bind:

Table 4. Six limits on how much CA a UE can do, ordered by how often each is the one that actually stops you.

4.1 CA bandwidth classes

A CA bandwidth class is a letter that binds together, for one band, the maximum number of component carriers and the range of aggregated channel bandwidth. Class A is a single carrier. Class C is the familiar two-carrier intra-band case with an aggregated channel bandwidth in the 100-200 MHz range -- which is exactly the 2 x 100 MHz n78 configuration used as the running example in this document. Higher letters add carriers and widen the aggregate. The exact boundaries are per-band and change release to release, so read them from the current TS 38.101-1 clause 5.3A table rather than from memory.

The reason to care is that the class letter is not documentation -- it is part of the identifier the UE and the network exchange. A band combination is written band-by-band with a class letter appended, and the string is the contract:

Table 5. Band combination strings and what each one commits the UE to. The A/C distinction between the second and third rows is the difference between two hardware designs, not a naming detail.

4.2 The indirection that actually decides what a UE can do

Reading the supported band combination list is not enough, and this is where CA capability analysis goes wrong. Each entry in supportedBandCombinationList names a featureSetCombination by index. That index points into a featureSetCombinations list, which is a matrix of feature-set identifiers -- one per band per direction. Each of those identifiers points into featureSetsDownlink / featureSetsUplink, and those point at per-CC feature sets. The answer to "can this UE do 256QAM with four layers on the second n78 carrier of this combination?" is at the bottom of four levels of indirection, and it can legitimately differ between two combinations that contain the same bands.

The network's side of the contract is that it must not configure anything outside the list. It generally does not check very hard. §17 covers what happens when it configures a combination the UE never claimed: the UE is entitled to reject the reconfiguration, and different UEs reject it in usefully different ways.

5. Mixed Numerology and Bandwidth Parts Across Carriers

Component carriers do not have to share a subcarrier spacing. A UE can be configured with a 15 kHz FDD carrier in n28, a 30 kHz TDD carrier in n78 and a 120 kHz carrier in n258, all at once, and this is not an exotic case -- it is the normal consequence of layering bands whose channel bandwidths and delay spreads are different. The companion 02 Radio Frame Structure document covers numerology itself; what matters here is why mixing is allowed and what it costs.

5.1 Why mixing works: the boundaries are nested

It works because NR numerologies are powers of two apart and share a common frame timing. A radio frame is 10 ms and a subframe is 1 ms at every numerology, and a slot is 1 ms / 2^mu. So every 15 kHz slot boundary is also a 30 kHz slot boundary, a 60 kHz slot boundary and a 120 kHz slot boundary; the boundaries never drift and never need realigning. Two carriers in the same timing advance group also share SFN and subframe alignment, so a slot index on one carrier maps deterministically onto a slot index on the other.

Concretely: 1, 2, 4 and 8 slots per subframe at 15, 30, 60 and 120 kHz. A 15 kHz slot boundary coincides with every second 30 kHz boundary and every eighth 120 kHz boundary, always, with no accumulating error. That nesting is what makes mixed-numerology CA possible at all -- without it, a grant sent on one carrier could not name a slot on another.

5.2 The cost: the scheduler has to do arithmetic

The cost lands on cross-carrier scheduling (§9). When a grant is sent on a carrier with numerology mu_PDCCH and schedules data on a carrier with numerology mu_PDSCH, the slot offset in the DCI cannot simply be added: it has to be interpreted in the scheduled carrier's numerology after scaling the PDCCH slot index across TS 38.214 cl. 5.1.2.1.

PDSCH slot  =  floor( n * 2^mu_PDSCH / 2^mu_PDCCH )  +  K0
PUSCH slot  =  floor( n * 2^mu_PUSCH / 2^mu_PDCCH )  +  K2

  n         the slot on the scheduling cell that carried the PDCCH
  mu_PDCCH  numerology of the scheduling cell
  mu_PDSCH  numerology of the scheduled cell
  K0, K2    slot offsets from the time-domain resource allocation,
            expressed in the SCHEDULED cell's slots

The other cost is UE processing time. Cross-carrier scheduling across a numerology boundary raises the minimum PDCCH-to-PDSCH and PDCCH-to-PUSCH offsets the UE can honour, because it has to finish decoding a grant in one timebase and act in another. Vendors handle this by never using aggressive K0 or K2 values across a numerology boundary, which quietly costs latency on exactly the carrier that was added for capacity.

5.3 Bandwidth parts are per carrier

Each serving cell carries its own bandwidth part configuration: up to four dedicated downlink BWPs and four uplink BWPs alongside the initial BWP, with one active downlink BWP and one active uplink BWP per serving cell at a time. There is no such thing as a BWP that spans carriers. A UE with three SCells has three independent BWP state machines running, each with its own bwp-InactivityTimer, its own defaultDownlinkBWP-Id and its own DCI bandwidth-part-indicator field. The companion 02 Radio Frame Structure document has the BWP grid.

Where BWP switching and SCell state interact, the interaction is not obvious:

• On activation, the UE makes firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id the active BWPs of that SCell. An activated SCell does not resume on whatever BWP it was on when it was last deactivated -- it always starts from the configured first-active BWP. If that BWP is narrow, the first grants on the newly activated carrier are narrow too, whatever the buffer looks like.
• On deactivation, the BWP state is simply gone. A deactivated cell has no active BWP.
• Dormancy is implemented as a BWP switch (§8): the SCell's active downlink BWP becomes dormantBWP-Id, a BWP on which the UE does not monitor PDCCH. The cell is still activated, so its tracking loops and its CSI machinery survive -- which is the entire point of dormancy.
• bwp-InactivityTimer expiry falls back to defaultDownlinkBWP-Id, or to the initial BWP if no default is configured. Configure a dormant BWP and a default BWP that fight each other and you get an SCell oscillating between two narrow BWPs while the scheduler wonders why its grants keep shrinking.

6. SCell Configuration and Delta Semantics

SCells are added, modified and released through CellGroupConfig inside RRCReconfiguration. Two lists do all the work:

Table 6. The two SCell lists in CellGroupConfig TS 38.331 cl. 5.3.5.5.9.

6.1 SCellConfig

Each entry in the add-mod list is an SCellConfig:

Table 7. SCellConfig, abridged to the fields that decide behaviour. sCellConfigCommon and sCellConfigDedicated are both optional because a modification may change only one of them.

6.2 Delta semantics, and the one that bites

RRC reconfiguration in NR is a delta protocol and the rules compose in ways that are easy to get wrong. Within an RRCReconfiguration:

1. A field that is present replaces the stored value.
2. A field that is absent leaves the stored value untouched. It does not mean release, and it does not mean revert to default -- release requires an explicit release list or a SetupRelease set to release.
3. A list with add-mod semantics is merged entry by entry, keyed on its index field, not replaced wholesale.
4. Release lists are processed before add-mod lists in the same message.

Note also what an SCell configuration does not contain: no RACH configuration the UE would use spontaneously, no paging configuration, no SI scheduling. An SCell is not a cell a UE could camp on; it is a set of resources described to the UE over the PCell. The one exception is Random Access ordered on an SCell to align a secondary timing advance group, covered in §13.

7. SCell Activation and Deactivation

A configured SCell starts life deactivated. In that state the UE does not monitor its PDCCH, does not report CSI for it, does not transmit SRS on it and cannot be granted anything on it. Moving it to activated is a MAC-layer act, and it is the single most operationally important mechanism in carrier aggregation.

7.1 The SCell Activation/Deactivation MAC CE

One MAC control element, two sizes, distinguished by their DL-SCH LCID TS 38.321 cl. 6.1.3.10:

• One octet, DL-SCH LCID 58. Covers sCellIndex 1 to 7. Used when no configured SCell has an index above 7 -- the common case in FR1 deployments.
• Four octets, DL-SCH LCID 57. Covers sCellIndex 1 to 31. Used when any configured SCell has an index above 7. Note that this is about the index values in use, not the number of SCells: configure two SCells with indices 1 and 9 and you get the four-octet form.
• Both are fixed-size CEs, so both use the one-octet R/R/LCID subheader shape -- see the companion 07 MAC PDU and Control Elements.

Two properties of this CE cause more field problems than anything else in carrier aggregation:

• It is an absolute bitmap, not a delta. Every C_i corresponding to a configured SCell is obeyed. A CE with only C_2 set does not "activate SCell 2" -- it activates SCell 2 and deactivates every other configured SCell. Bits for SCells that are not configured are ignored.
• It is not acknowledged above HARQ. The only confirmation is the HARQ-ACK for the transport block that carried it. If that feedback is lost, or a NACK is falsely detected as an ACK, the network and the UE disagree about which carriers exist, and nothing in the protocol resolves the disagreement until the next CE.

Table 8. Decoding Octet 1. The R bit is the least significant bit, so valid values are always even. The second row is the classic mistake: a scheduler wanting to add SCell 1 alongside an already active SCell 2 sends 0x02 and turns SCell 2 off.

7.2 What the UE does on activation

In the slot in which an activating CE takes effect, the UE TS 38.321 cl. 5.9:

1. Applies firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id as the active BWPs of that SCell.
2. Starts or restarts the sCellDeactivationTimer for that SCell.
3. Begins monitoring the SCell's PDCCH -- or, under cross-carrier scheduling, begins expecting grants for it on the scheduling cell.
4. Triggers a power headroom report, because the set of cells sharing the UE's transmit power has changed (§12).
5. Begins CSI reporting for the SCell, and SRS transmission on it if configured.
6. Treats the SCell's HARQ entity as empty -- there is nothing buffered to recover.

Deactivation is the mirror image: stop the timer, stop monitoring PDCCH, stop CSI and SRS, flush every HARQ buffer for that cell, clear any configured downlink assignment and uplink grant on it, and abandon any ongoing Random Access on it. The HARQ flush is worth noticing -- a transport block in flight when the deactivation lands is lost, not retransmitted.

7.3 sCellDeactivationTimer

sCellDeactivationTimer sits in ServingCellConfig and applies only to serving cells without PUCCH; the PCell and any PUCCH SCell are never subject to it. It deactivates the SCell after a period with no activity, and it is restarted by activity -- a PDCCH indicating an uplink grant or a downlink assignment for that SCell, or a MAC PDU actually transmitted or received on a configured grant or assignment on it.

Table 9. Representative sCellDeactivationTimer values; the full enumeration is in §16. The right value follows from the traffic's inter-burst gap distribution, not from a power policy in the abstract -- a timer shorter than the typical gap makes the carrier useless rather than merely idle.

7.4 The activation delay, and why it dominates

This is the part that decides whether CA delivers anything. The requirement in TS 38.133 clause 8.3.2 is structured as three additive terms -- a HARQ delay for the MAC CE, an activation time, and a CSI reporting delay -- and the middle term holds the milliseconds, because it contains everything the UE physically has to do to turn a cold carrier into a usable one:

Table 10. The activation budget, step by step. §19.2 sums a concrete instance. Values are order-of-magnitude and move with SSB periodicity, with whether the SCell is a known cell, and with receiver design.

8. Dormancy, Hibernation and Fast Resume

Rel-15 gave the network two SCell states and a bad trade between them. Deactivated is cheap for the UE and expensive to leave. Activated is instantly usable and expensive to hold, because the UE monitors PDCCH every slot, reports CSI on schedule and transmits SRS on a carrier it may not be using. Rel-16 added a third state that sits between them.

8.1 What dormancy actually is

A dormant SCell is still activated. Nothing in its MAC state changes; what changes is its active downlink bandwidth part, which becomes the BWP named by dormantBWP-Id. That BWP has no PDCCH configured on it, so the UE stops blind-decoding on the carrier -- which is where most of the power goes -- while its CSI reporting and its time and frequency tracking loops keep running. The AGC does not have to be re-set, the tracking loops do not have to re-converge, and the CSI is current or nearly so.

Table 11. The three states compared. The row that justifies the whole feature is time to first usable grant: dormancy buys back the activation budget without paying the activated-state power bill.