Carrier Aggregation (LTE-Advanced)
Aggregating component carriers in LTE-A — PCell/SCell, SCell activation MAC CE, and DL vs UL CA.
A single LTE carrier tops out at 20 MHz, and a UE on one carrier can only go so fast. Carrier Aggregation (CA), introduced in LTE-Advanced (Release 10), is how you break past that ceiling: the network bonds several carriers together so the UE receives (and sometimes transmits) across all of them at once, and their throughputs simply add up. Each aggregated carrier is a Component Carrier (CC) and appears to the UE as its own serving cell. This page is grounded in TS 36.300 (architecture), TS 36.331 (RRC) and TS 36.321 (MAC).
Introduction
Carrier Aggregation is the LTE-Advanced feature that lets one UE use several carriers at the same time as if they were a single, wider carrier. It exists because peak data rate scales with bandwidth, and a lone LTE carrier is capped at 20 MHz — so the only way to go faster without new physics is to bond carriers together. Each bonded carrier is a Component Carrier (CC), and to the UE each CC looks like its own serving cell, all driven by a single MAC scheduler.
CA lives entirely in RRC_CONNECTED. A UE always does initial access and mobility on one anchor carrier — the PCell — and the network then adds extra carriers (SCells) by RRC and switches them on and off by MAC control element as traffic demands. That two-stage "configure slowly, activate quickly" design is what makes CA cheap to run: capacity can be turned on within milliseconds and put back to sleep to save UE battery.
It matters because CA is the single biggest lever behind LTE-Advanced peak-rate headlines, and it is also how operators make use of fragmented spectrum — stitching together bits of bandwidth scattered across different bands into one fast pipe. Understanding PCell/SCell roles, activation, scheduling and HARQ across carriers is essential to reading any CA-capable UE's behaviour.
On this page
Why Carrier Aggregation is needed
In plain words: imagine a motorway toll plaza with one open lane — traffic can only clear so fast no matter how good the cars are. CA opens several lanes at once and funnels them to a single controller, so total throughput is the sum of the lanes. And because the operator's "lanes" (spectrum) are often scattered around the site — some here, some in another field entirely — CA also lets you bond lanes that are not even next to each other into one flow.
Concretely, CA solves two problems at once. First, the bandwidth ceiling: peak rate scales with bandwidth and a single LTE carrier is limited to 20 MHz, so bonding five carriers yields roughly 100 MHz of effective bandwidth and roughly five times the peak throughput — with no change to the underlying waveform. Second, fragmented spectrum: real operators rarely own one clean 100 MHz block; they own pieces in different bands. CA lets them aggregate an 1800 MHz carrier with an 800 MHz carrier (and more) so scattered holdings behave like one big pipe, all under one scheduler with tight timing.
Operating one UE on two or more Component Carriers simultaneously, each a full LTE carrier of up to 20 MHz presented as a serving cell, under a single MAC entity.
To widen effective bandwidth past a single carrier for higher peak throughput, and to make usable, contiguous-feeling capacity out of spectrum an operator owns across different bands.
RRC configures a PCell and adds SCells; one MAC scheduler serves all CCs with an independent HARQ entity per CC; the UE recombines the carriers into one data flow.
What Carrier Aggregation Is
Peak data rate scales with bandwidth. One LTE carrier gives you at most 20 MHz; aggregate five of them and you get roughly 100 MHz of effective bandwidth — and therefore roughly five times the peak throughput — without inventing any new physics. Release 10 allowed up to 5 CCs (100 MHz); later releases raised the ceiling (Rel-13 to 32 CCs). CA is simply operating one UE on multiple carriers simultaneously, under a single MAC scheduler.
Operating a UE on 2 or more Component Carriers at the same time. Each CC is a full LTE carrier of up to 20 MHz with its own resource grid, presented to the UE as a serving cell (a PCell or an SCell).
To widen the effective bandwidth beyond a single 20 MHz carrier and boost peak throughput — and to opportunistically stitch together fragmented spectrum an operator owns across different bands.
RRC (TS 36.331) configures one primary cell and adds secondary cells. One MAC entity (TS 36.321) schedules across all of them, with an independent HARQ entity per CC. The UE reassembles the layers into a single data flow.
Mental model: CA takes several separate "pipes" (carriers) and bonds them into one fat pipe to the UE. The width of the fat pipe is the sum of the carrier bandwidths, so the peak rate is (roughly) the sum of the per-carrier peak rates.
How many carriers, by release: a UE's CA support is described by its band combinations and a CA bandwidth class (A–F), which bounds the aggregated bandwidth and number of CCs. Rel-10/11 allowed up to 5 CCs (100 MHz); Rel-13 extended DL CA to 32 CCs (up to 640 MHz in principle). Real handsets aggregate far fewer — typically 2–5 DL CCs — and each CC still uses one of the standard LTE bandwidths (1.4/3/5/10/15/20 MHz).
Serving Cell Roles — PCell and SCell
Under CA every CC is a serving cell, but they are not equal. Exactly one is special and always present; the rest are helpers that can come and go.
| Aspect | PCell (Primary Cell) | SCell (Secondary Cell) |
|---|---|---|
| How many | Exactly one per UE | Zero or more (up to 4 in Rel-10) |
| Origin | The cell the UE did initial access / handover on | Added by RRC after connection is up |
| Uplink control | Carries PUCCH (HARQ-ACK, CQI, SR) | No PUCCH (feedback funnels to PCell) |
| RRC / NAS / security | Yes — anchors signalling and mobility | No — pure extra bandwidth |
| Mobility | Changed only by handover | Added/removed by RRCConnectionReconfiguration |
| Activation state | Always active; never deactivated | Added deactivated; toggled by MAC CE |
Everything anchors on the PCell. All the "control-plane weight" — RRC connection, NAS, security keys, radio-link monitoring, the PUCCH feedback channel and system-information acquisition — lives on the PCell. An SCell is deliberately dumb: it adds a data pipe and nothing else, which is exactly why it can be switched on and off so cheaply.
Remember: there is exactly one PCell and it is indispensable; SCells are layered on for capacity and can appear or vanish based on demand.
CA Types by Frequency Layout
How the aggregated carriers sit in spectrum determines how hard the RF is to build. TS 36.101 defines the allowed band combinations; conceptually there are three layouts:
| CA type | Layout | RF difficulty / notes |
|---|---|---|
| Intra-band contiguous | Multiple CCs in the same band, adjacent to each other (no gap). | Easiest: the CCs form one continuous block, so a single wideband RF chain can often cover them all. |
| Intra-band non-contiguous | Multiple CCs in the same band but with a gap between them. | Harder: same band, but the gap means the RF must handle two separated chunks. |
| Inter-band | CCs in different bands (e.g. an 1800 MHz carrier plus an 800 MHz carrier). | Most flexible for spectrum use, but needs separate RF chains/antennas per band. Very common in real deployments. |
How SCells Are Configured and Activated
Adding capacity is a two-stage story on purpose: RRC configures the SCell (slow, signalling-heavy), and then a MAC control element activates it (fast, cheap). Splitting the two lets the network turn bandwidth on and off in milliseconds for power saving.
The eNB adds an SCell via RRCConnectionReconfiguration (TS 36.331): each SCell is a SCellToAddMod entry with an sCellIndex (1–7 in Rel-10/11, extended to 1–31 in Rel-13), its cellIdentification (physical cell ID and DL carrier frequency) and radioResourceConfigCommonSCell, carried in the sCellToAddModList. This tells the UE the SCell's frequency, bandwidth and physical-layer setup.
An SCell always starts deactivated. Keeping a configured-but-idle carrier fully powered would waste UE battery and generate needless CQI reporting, so the carrier stays dark until it is actually needed.
The eNB turns the SCell on/off with the Activation/Deactivation MAC CE (TS 36.321) — a 1-octet (or 4-octet, for >7 SCells) bitmap where each bit maps to an sCellIndex. This is far faster than an RRC reconfiguration, so the network can react to traffic bursts instantly.
sCellDeactivationTimer: each configured SCell also runs an inactivity timer, sCellDeactivationTimer. If no PDCCH grant is received on the SCell before it expires, the SCell auto-deactivates — so an SCell that stops carrying traffic falls asleep on its own, saving power without any extra signalling. (The PCell has no such timer; it is always active.)
Why two mechanisms: RRC (add/remove) is the "install/uninstall"; the Activation/Deactivation MAC CE plus sCellDeactivationTimer is the "power switch". You install a carrier once and then flick it on and off cheaply as demand rises and falls.
SCell Addition & Activation Call Flow
Configuring and switching on a secondary carrier is not a single step — it is a short sequence that starts with the network measuring whether a candidate carrier is worth adding, then configuring it over RRC, and only then activating it with a MAC CE. The flow below is the standard CA build-up in RRC_CONNECTED, from measurement configuration all the way to aggregated data.
Reading the flow: (1–2) the eNB sends an RRCConnectionReconfiguration with a measConfig — a measObject on the candidate carrier plus a reportConfig, typically event A4 ("neighbour becomes better than a threshold"), the natural trigger for adding capacity. (3) When A4 fires, the UE sends a MeasurementReport with the candidate's RSRP/RSRQ. (4–5) The eNB adds the carrier as a secondary cell with a second RRCConnectionReconfiguration carrying sCellToAddModList — one SCellToAddMod with an sCellIndex (and optionally crossCarrierSchedulingConfig) — added deactivated. (6) When there is data to move, the eNB sends the Activation/Deactivation MAC CE whose bit for that sCellIndex is set, and the SCell wakes up. (7–8) The UE begins CQI/SRS reporting and PDCCH monitoring for the SCell, and the scheduler places PDSCH across PCell and SCell together.
Why measure before adding? An SCell only helps if the UE can actually receive it well. Configuring a measurement (event A4 on the candidate carrier) lets the eNB confirm the carrier is strong enough at the UE before spending RRC signalling to add it — otherwise it would add a carrier the UE cannot use and waste both signalling and the sCellDeactivationTimer cycle.
Scheduling Across Carriers, and HARQ
Once several CCs are live, a question appears: which carrier's PDCCH carries the grant for a given carrier's data? There are two answers.
The default. Each CC's own PDCCH schedules its own PDSCH/PUSCH. The grant and the data it points to live on the same carrier — no cross-references needed.
One CC's PDCCH schedules the data on another CC. Useful when one carrier has a clean control channel (e.g. a low band) and another (e.g. a heavily interfered carrier) is better left for data only.
The DCI gains a Carrier Indicator Field (CIF) — 3 bits naming which serving cell the grant applies to. It is enabled per cell by RRC via crossCarrierSchedulingConfig. Without it, the UE assumes self-scheduling.
HARQ is per-CC. Each serving cell has its own independent HARQ entity — up to 8 processes per CC in FDD (and up to 15 in some TDD configurations). There is one transport block per CC per TTI per codeword (with two codewords when spatial multiplexing is active), so aggregating N carriers gives you N parallel HARQ pipelines, each with its own NDI/RV/soft buffer. All the HARQ-ACK feedback, however, still rides the PCell's PUCCH. CA multiplies capacity partly because it multiplies the number of independent HARQ streams.
Downlink vs Uplink CA, Throughput, and CA vs Dual Connectivity
CA is not symmetric. Downloading is where users feel speed, so DL CA is everywhere — a UE routinely aggregates 2, 3 or more DL CCs. UL CA is rarer: transmitting on several carriers at once drains the UE's battery and strains its power amplifier, so a common configuration is several DL CCs but only one UL carrier (on the PCell). The PCell always provides the uplink control (PUCCH); UL SCells add uplink data capacity only when the UE can afford it.
The headline benefit is simple arithmetic: peak throughput scales roughly with the sum of the per-CC capacities. Compute each CC's peak the usual way and add them up.
So two 20 MHz carriers roughly double a single carrier's rate; five roughly quintuple it — minus a little for the extra control overhead. The per-CC calculation is exactly the throughput math from the throughput page; CA just sums it across carriers.
CA is often confused with Dual Connectivity (DC), introduced in Rel-12, because both let a UE use spectrum from more than one place. The difference is architectural: CA lives under a single MAC and one scheduler in one eNB; DC uses two MAC entities and two schedulers — a Master eNB and a Secondary eNB — coordinating loosely over the X2 interface, which tolerates non-ideal backhaul between separate sites.
| Carrier Aggregation (CA) | Dual Connectivity (DC) | |
|---|---|---|
| MAC entities | One | Two (one per cell group) |
| Schedulers | One eNB scheduler | Two (MeNB and SeNB) |
| Timing coordination | Tight (same eNB) | Looser (separate eNBs) |
| Cell roles | PCell + SCells | PCell (MCG) + PSCell (SCG) + SCells |
| Backhaul between legs | Not needed (single node) | X2, tolerates non-ideal backhaul |
One-liner: CA = one brain aggregating many carriers with tight timing; DC = two brains (MeNB + SeNB) cooperating over X2. CA is simpler and tighter; DC scales across separated sites.
LTE ↔ NR: the CA concept carries straight into NR — a PCell plus SCells under one MAC, RRC add + MAC-CE activate, per-CC HARQ — but NR generalises it. Each NR CC can be far wider (up to 100 MHz in FR1, 400 MHz in FR2), so a handful of CCs reach much higher aggregate bandwidth, and NR adds bandwidth parts (BWPs) within a carrier for finer, faster adaptation. NR also folds CA and DC into one framework of cell groups: the LTE PSCell/SCG idea becomes central to Multi-RAT Dual Connectivity (MR-DC), most famously EN-DC, where an LTE PCell (master) and an NR PSCell (secondary) serve the UE together — the mechanism behind non-standalone 5G. So the LTE distinction you learned here (CA = one MAC; DC = two) is exactly the seam along which 5G NSA is built.
Summary
Carrier Aggregation bonds several Component Carriers into one wide pipe under a single MAC scheduler, so peak throughput adds up roughly to the sum of the per-CC rates. Every CC is a serving cell, but roles are asymmetric: exactly one PCell anchors all control-plane weight (RRC, NAS, security, PUCCH, mobility) and is never deactivated, while SCells are pure bandwidth that come and go.
The build-up is deliberately two-staged: RRC configures an SCell (SCellToAddMod/sCellIndex in RRCConnectionReconfiguration) in a deactivated state after an event-A4 measurement confirms the carrier is usable, then the fast Activation/Deactivation MAC CE switches it on — and sCellDeactivationTimer lets it fall asleep again on its own. Data can be self-scheduled (each CC's own PDCCH) or cross-carrier scheduled (tagged by the CIF, enabled by crossCarrierSchedulingConfig), and HARQ runs independently per CC while all feedback funnels to the PCell's PUCCH.
Finally, keep CA and Dual Connectivity distinct: CA is one MAC/one scheduler in one node with tight timing; DC is two MACs/two schedulers cooperating over X2 across sites. That very distinction is the foundation NR reuses for EN-DC and 5G non-standalone.
Q. What is the difference between a PCell and an SCell, and how is an SCell switched on?
A. The PCell is always present — it carries PUCCH, handles RRC/NAS and initial access, and is never deactivated. An SCell is added by RRC (SCellToAddMod / sCellIndex in sCellToAddModList inside RRCConnectionReconfiguration) purely for extra throughput, starts deactivated, and is switched on/off by the Activation/Deactivation MAC CE for fast, low-overhead control, with sCellDeactivationTimer auto-deactivating it after inactivity.
Q. Self-scheduling vs cross-carrier scheduling?
A. In self-scheduling each CC's PDCCH schedules its own data. In cross-carrier scheduling one CC's PDCCH schedules another CC's PDSCH/PUSCH, identified by the Carrier Indicator Field (CIF) in the DCI and enabled by crossCarrierSchedulingConfig.
Q. How is Carrier Aggregation different from Dual Connectivity?
A. CA uses a single MAC entity and one scheduler in one eNB with tight timing (PCell + SCells). DC uses two MAC entities and two schedulers — a Master eNB and a Secondary eNB — coordinating over X2 with non-ideal backhaul, with a PCell in the MCG and a PSCell in the SCG.
Where Carrier Aggregation connects
CA sits on top of the scheduler and the HARQ machinery, and it is the main lever behind LTE-Advanced peak-rate numbers.