Carrier Aggregation Tutorial: Configure, Measure, and Troubleshoot CA
A complete practical walkthrough of carrier aggregation: decoding UE band combinations, configuring PCell and SCells, timing advance groups, measuring real gain, and diagnosing every common activation failure.
This is the hands-on companion to carrier aggregation explained. That article covers what CA is and why aggregate throughput rarely matches the sum of the carriers. This one covers what you actually do in front of a network: read the UE's capability, configure the carriers, verify it worked, and work out why it didn't.
Prerequisites. You should be comfortable with component carriers, the PCell/SCell relationship, and the difference between a configured and an activated SCell. You'll also want access to gNB counters and, ideally, a UE-side diagnostic tool. If the concepts are shaky, read the explainer first — this tutorial assumes them.
Step 0 — A working recap
Three facts drive everything in this tutorial.
CA aggregates carriers under one scheduler. One MAC entity, one RRC connection, one timing relationship. This is what separates it from dual connectivity, where two nodes schedule independently and the split happens at PDCP.
The PCell is not just "the first carrier." It anchors the RRC connection, carries the security context, handles random access, and by default carries all HARQ feedback for every carrier. Radio link failure on the PCell drops the connection; failure on an SCell does not.
SCells have two independent states. RRC configures them. MAC activates them. A configured-but-deactivated SCell contributes nothing, and this distinction causes a large share of CA confusion during testing.
Hold those three and the rest is procedure.
Step 1 — Decode what the UE can actually do
Almost every CA investigation ends here, and it's the step most often skipped.
CA is constrained by band combinations the UE explicitly declares. Supporting two bands individually says nothing about supporting them together — the combination has to be in the list.
Where the capability comes from
The network sends UECapabilityEnquiry; the UE replies with UECapabilityInformation, containing the UE-NR-Capability structure. The fields that matter for CA:
supportedBandCombinationList is the core. Each entry describes one combination: which bands, how many carriers in each, and per-carrier capability.
bandParametersList within each combination gives per-band detail — bandwidth class, supported subcarrier spacings, MIMO layers, modulation order.
featureSetCombinations qualifies each combination. A combination can be present but with a feature set that reduces layers, modulation, or supported bandwidth on one carrier. Reading only the band list and skipping feature sets is a common route to a wrong conclusion.
Uplink entries are separate. Downlink and uplink combinations are declared independently, and uplink support is dramatically narrower. Downlink 4CC with uplink 1CC is normal.
Reading the notation
Band combinations use a compact notation worth parsing at a glance:
CA_n78C → two contiguous carriers in n78 (class C)
CA_n78A-n1A → one carrier in n78 + one carrier in n1
CA_n78A-n1A-n3A → three carriers across three bands
DC_n78A_n1A → dual connectivity, not CA
The trailing letter is the bandwidth class, telling you how many contiguous carriers and what aggregate bandwidth is supported within that band:
| Class | Carriers in band | Typical aggregate |
|---|---|---|
| A | 1 | One carrier only |
| B | 2 | Limited aggregate BW |
| C | 2 | Contiguous, wider aggregate |
| D, E, F… | 3+ | Progressively larger |
CA_n78C and CA_n78A-n78A are not the same thing, and a network configured for one won't work with a UE supporting only the other.
Fallback combinations
A UE supporting CA_n78A-n1A-n3A implicitly supports the fallback combinations beneath it — CA_n78A-n1A, CA_n78A-n3A, and each single carrier. 3GPP defines this so devices don't have to enumerate every subset.
This matters when reading logs: a combination you don't see listed may still be usable as a fallback. It also lets the network degrade gracefully when a carrier becomes unavailable, rather than tearing down CA entirely.
The truncation problem
The capability message can exceed signalling size limits. When it does the UE truncates — and which combinations survive depends on the band filter in the network's enquiry.
The consequence: what you see depends on what you asked for. If an expected combination is missing, check the UECapabilityEnquiry filter before concluding the device doesn't support it. Some UEs also reorder priorities based on the filter, so two enquiries can produce genuinely different lists from the same device.
Where to look
From the network side, the gNB logs the decoded capability — vendor-specific location, but always available.
From the device side, use a diagnostic tool: QXDM or QCAT for Qualcomm chipsets, Nemo, TEMS, or Accuver for drive-test platforms. What you want is raw ASN.1 decoded against TS 38.331. Tedious the first time, routine afterwards.
For lab work, several open-source ASN.1 decoders handle NR RRC messages, which is often faster than waiting for a vendor tool licence.
Step 2 — Configure the carriers
With a valid combination confirmed, configuration proceeds in a specific order.
Choose the PCell deliberately
The PCell should be the carrier with the best coverage, not the widest bandwidth.
This trips people up constantly. The instinct is to anchor on the 100 MHz mid-band carrier because it's fastest. But the PCell must stay reliable across the whole cell, and a mid-band footprint is smaller than a low-band one. Anchoring on mid-band produces cell-edge connection drops that look mysterious until you realise CA caused them.
The usual answer: low band as PCell, mid band as SCell. Low-band reliability with mid-band capacity layered on where conditions allow — exactly the inter-band CA value proposition.
Configure measurements first
The network can't sensibly add an SCell it has no measurements for. Before SCell configuration you need:
Measurement objects (measObjectNR) for each candidate SCell frequency — SSB frequency, subcarrier spacing, cells to measure.
Report configurations (reportConfigNR) defining when the UE reports. For SCell addition, event A4 (neighbour becomes better than a threshold) is the usual trigger. Some deployments use periodic reporting for simplicity.
Measurement identities linking each object to a report configuration.
Skip this and SCells either never get added, or get added blind with no knowledge of whether the carrier is usable at the UE's location.
Watch measurement gaps. If the SCell frequency falls outside the UE's active receive bandwidth, the UE needs scheduling gaps to retune and measure — costing throughput on the serving carrier. Per-FR gaps (Release 16 onward) reduce this where supported.
Add the SCells
SCell addition is an RRCReconfiguration carrying sCellToAddModList. Each entry needs:
sCellIndex — the identifier used in MAC activation commands.
sCellConfigCommon — cell-level parameters: SSB configuration, frequency information, TDD pattern.
sCellConfigDedicated — UE-specific parameters: BWP configuration, PDSCH/PUSCH configuration, CSI reporting.
Also set here: whether the SCell carries uplink, and which PUCCH group it belongs to.
Timing advance groups
Often overlooked, and it causes real failures.
Carriers with different propagation characteristics may need different timing advance values. NR groups carriers into Timing Advance Groups (TAGs), each with its own TA.
The PCell always sits in the pTAG. SCells can share it or be placed in an sTAG. Rule of thumb: carriers from the same site with similar propagation share a TAG; carriers with materially different propagation — widely separated bands, or different physical locations in a distributed deployment — need a separate sTAG.
Getting this wrong produces uplink failures on the SCell that look like RF problems. An SCell in the wrong TAG transmits outside the expected reception window.
An sTAG requires its own random access on the SCell to establish timing, which is why SCell uplink activation is slower than downlink.
Cross-carrier scheduling
By default each carrier carries its own PDCCH scheduling its own PDSCH. Cross-carrier scheduling lets one carrier's PDCCH schedule another's data, via crossCarrierSchedulingConfig.
Useful when one carrier suffers control-channel interference, or for scheduling a carrier without its own control region. The cost is concentrated PDCCH load on the scheduling carrier, which can become the limit.
PUCCH groups
By default all HARQ feedback for all carriers returns on the PCell uplink. With four or more carriers this saturates PCell PUCCH capacity, and the symptom is throughput plateauing regardless of how many SCells you add.
A secondary PUCCH group designates an SCell to carry feedback for a subset of carriers. Worth doing past three or four aggregated carriers.
Activation policy and dormancy
RRC addition leaves the SCell configured but deactivated. Activation is a MAC control element — a few milliseconds, versus an RRC round trip.
The two-stage model is deliberate: SCells kept configured-but-dormant let the scheduler ramp capacity quickly without RRC signalling per burst.
Vendors expose activation thresholds — buffer occupancy, sustained throughput, data volume. Defaults are frequently conservative, and this is one of the most common reasons a correctly configured network shows no CA gain in testing.
The sCellDeactivationTimer deactivates an SCell after a period without scheduling. Too short causes activation thrashing; too long wastes UE power on an idle carrier.
Release 16 added SCell dormancy — a dormant BWP where the UE continues CSI reporting without monitoring PDCCH. Faster resumption than full reactivation, lower power than full activity, genuinely useful for bursty traffic.
Step 3 — Measure the gain properly
Most CA validation fails here, because the test is easy to design badly.
Establish a baseline
Disable SCell addition entirely. Run the test. Record it. Without a single-carrier number under identical conditions you have nothing to compare against, and no way to distinguish "CA isn't working" from "this location is bad."
Design the test correctly
Run long enough. SCell activation takes milliseconds and TCP takes time to ramp. A 5-second test can finish before CA meaningfully contributes. Use at least 30 seconds and record sustained throughput, not peak.
UDP first, then TCP. UDP at a fixed high rate tells you what the radio delivers. TCP tells you what an application gets. If UDP shows the gain and TCP doesn't, the problem is above the radio — congestion control, receive window, buffer sizing, or the server.
Verify SCells were actually scheduled. The step people skip. Pull per-carrier PRB counters. If the SCell shows zero scheduled PRBs, no amount of throughput analysis tells you anything.
Test at multiple locations. Cell centre gives the ceiling; mid-cell gives what users get; cell edge often shows the SCell contributing nothing, which is expected rather than broken.
Control the variables. Same location, orientation, time of day, test server, and an empty cell if possible. CA measurements are noisy enough already.
A test matrix worth running
| Test | Config | Location | Duration | What it tells you |
|---|---|---|---|---|
| 1 | PCell only | Cell centre | 60 s | Single-carrier ceiling |
| 2 | PCell + SCell | Cell centre | 60 s | Best-case CA gain |
| 3 | PCell only | Mid-cell | 60 s | Realistic baseline |
| 4 | PCell + SCell | Mid-cell | 60 s | Realistic CA gain |
| 5 | PCell + SCell | Cell edge | 60 s | Where the SCell stops helping |
| 6 | PCell + SCell | Centre, UDP | 60 s | Radio capability vs TCP effects |
| 7 | PCell + SCell | Centre, short burst | 5 s | Activation policy responsiveness |
Test 7 exposes conservative activation thresholds — if a short burst shows no gain but a long transfer does, the threshold is your problem, not the radio.
What to record
| Metric | Source | Why it matters |
|---|---|---|
| Per-carrier PRB utilisation | gNB counters | Confirms SCells were scheduled |
| Per-carrier MCS distribution | gNB counters | Shows whether SCell conditions were usable |
| Per-carrier BLER | gNB counters | Rules out link adaptation problems |
| Per-carrier MIMO rank | gNB counters | Explains halved contribution |
| SCell activation duration | MAC CE traces | Reveals conservative policy |
| RSRP / SINR per carrier | UE logs | Explains unequal contribution |
| Aggregate vs baseline throughput | Test tool | The actual result |
| PUCCH utilisation on PCell | gNB counters | Detects feedback bottleneck |
A worked expectation
Suppose you aggregate 100 MHz on n78 and 20 MHz on n1.
Naive expectation: 120 MHz worth of throughput. Realistic expectation is lower, and explaining why before testing is the mark of understanding the system.
At cell centre, n78 might run 4 layers at 256QAM — near its ceiling. n1 at 20 MHz with 2 layers contributes perhaps a sixth of what n78 does, not a fifth, because it has fewer layers. Move to mid-cell and n78 drops to 2 layers at 64QAM while n1 holds up better on propagation, so the ratio shifts even as the total falls.
At cell edge, n78 may be marginal while n1 carries the connection — precisely the inter-band CA argument, and precisely why low band should have been your PCell.
Step 4 — Troubleshoot activation
Work through these in order. They're roughly ordered by how often each turns out to be the cause.
SCell never added
Check the band combination is genuinely present in supportedBandCombinationList — including fallbacks. Not that both bands are supported individually.
Check the capability enquiry filter. A filtered enquiry may have truncated the combination out of the response.
Check measurement configuration exists for the SCell frequency, with a measurement identity linking object to report config.
Check reporting thresholds are being met. An A4 threshold set too high means the UE never reports the neighbour. Pull the measurement reports and compare against the configured threshold.
Check measurement gaps if the SCell frequency is outside the active BWP. Without gaps the UE can't measure it.
Check network-side admission control. Some vendors limit SCell configuration by cell load or licensed capacity.
SCell added but never activated
Almost always the activation policy.
Compare the activation threshold to your test traffic. A threshold tuned for sustained heavy load won't fire for a 10 MB transfer.
Check the deactivation timer. A short timer with bursty traffic produces thrashing — activated and deactivated repeatedly, contributing little either way.
Check SCell quality against the deactivation threshold. An SCell in marginal conditions may be added, activated, then immediately deactivated.
Check MAC CE traces directly. If the activation command is being sent and the UE isn't responding, that's a different problem from it never being sent.
SCell activated but contributing little
Check per-carrier SINR and MCS. Low MCS means the SCell contributes a fraction of its bandwidth. If the UE is at the edge of that carrier's coverage, this is correct behaviour.
Check MIMO rank on the SCell. Rank 1 instead of rank 4 quarters the contribution. Line-of-sight or a poorly conditioned channel does this.
Check the UE's per-carrier layer capability. Many devices support 4 layers on the PCell and 2 on SCells — a capability limit, not a configuration error.
Check whether the feature set for this combination reduces capability. This is why reading feature sets matters.
Check PUCCH capacity on the PCell. If feedback is the bottleneck, adding carriers stops helping.
Throughput lower with CA than without
Rare but real, and worth recognising.
Check whether the PCell changed. A reconfiguration that moved the PCell to a worse carrier costs more than the SCell gains.
Check PCell PUCCH load. Aggregated feedback from several carriers can degrade the PCell.
Check measurement gap overhead. Gaps needed to measure the SCell frequency cost serving-carrier throughput. On a marginal SCell you pay the gaps and get nothing back.
Check test duration. A short test pays activation overhead without receiving the benefit.
Uplink CA not working
Check uplink band combinations specifically. Declared separately, support much narrower. Frequently the answer is simply that the device doesn't support it.
Check power headroom. A power-limited UE gains little from uplink aggregation — fixed transmit power across more carriers reduces per-carrier SNR. At cell edge, uplink CA can genuinely reduce throughput.
Check the TAG configuration. SCell uplink needs valid timing advance, which needs the right TAG and completed random access on the SCell if it's in an sTAG.
Check whether uplink is configured on the SCell at all. Downlink-only SCells are common and correct.
Step 5 — A pre-escalation checklist
Before raising a CA problem with a vendor, confirm:
- Band combination present in
supportedBandCombinationList, including fallbacks - Feature set for that combination checked for reduced capability
- Uplink combinations checked separately from downlink
- Capability enquiry filter verified as not truncating the response
- Measurement objects, report configs, and measurement identities all configured
- Measurement gaps configured if the SCell frequency is outside the active BWP
- PCell selected on the coverage carrier, not the widest one
- TAG assignment appropriate for the band separation
- PUCCH group configured if aggregating four or more carriers
- Activation thresholds compared against actual test traffic
- Deactivation timer checked for thrashing
- Single-carrier baseline measured under identical conditions
- Test duration at least 30 seconds, sustained throughput recorded
- Per-carrier PRB counters confirm the SCell was scheduled
- Per-carrier SINR, MCS, rank and BLER recorded
Most escalations that survive this list are genuine. Most that don't, aren't.
Common questions
Does CA increase peak throughput or cell capacity? Peak throughput for the individual UE. Cell capacity is largely unchanged — the same total spectrum, just letting one UE reach across more of it.
Can carriers use different numerologies? Yes in NR, unlike LTE-A. A low-band carrier can run 15 kHz subcarrier spacing while a mid-band carrier runs 30 kHz in the same aggregation — useful because their propagation environments genuinely differ.
Can I aggregate FR1 and FR2? Yes, with combinations defined in TS 38.101-3. In practice FR1+FR2 is often deployed as NR-DC rather than CA, because the two are frequently on separate nodes.
How many carriers is realistic? NR permits 16. Commercial devices typically support 2–4 downlink carriers in FR1. Check the device, not the specification.
Why is my UE reporting fewer combinations than the datasheet claims? Almost always the capability enquiry filter, or a truncated response. Try a narrower filter targeting the specific bands you care about.
Reference
3GPP TS 38.331 — RRC specification. sCellToAddModList, measurement configuration, UECapabilityInformation structure, TAG configuration.
3GPP TS 38.321 — MAC specification. SCell activation and deactivation control elements, deactivation timer, dormancy behaviour.
3GPP TS 38.306 — UE radio access capabilities. The definitive reference for interpreting reported capability.
3GPP TS 38.101-1 — UE radio transmission and reception, FR1. Band combinations and bandwidth classes.
3GPP TS 38.101-3 — FR1 and FR2 interworking, including inter-band combinations and NR-DC.
3GPP TS 38.213 — Physical layer procedures for control, including PUCCH groups and cross-carrier scheduling.
3GPP TS 38.214 — Physical layer procedures for data, MCS tables and per-carrier resource allocation.
The single highest-value habit: check the band combination before anything else. A large share of CA investigations end at that first step, and the ones that don't at least start from solid ground.
For the conceptual side — why aggregate throughput doesn't equal the sum of carriers, and how CA differs from dual connectivity — see carrier aggregation explained and dual connectivity explained.