BWP Switching & Adaptation in 5G NR

Introduction

A Bandwidth Part is the mechanism that decouples the carrier the cell operates from the bandwidth a given UE is actually working over at this instant. The cell can be 100 MHz wide in FR1 or 400 MHz in FR2, but the UE tunes to, and only processes, one active DL BWP and one active UL BWP per serving cell at a time. Everything the UE does on the air — monitoring PDCCH, receiving PDSCH, transmitting PUSCH/PUCCH/SRS — happens inside that active BWP.

BWP switching lives in the connected-mode lifecycle, right where the scheduler meets power management. Once the UE is in RRC_CONNECTED with dedicated config, the network is constantly deciding how much bandwidth the UE should be listening across: wide when a burst is flowing, narrow when the link is idle. That decision is executed as a BWP switch — by DCI, by an inactivity timer, by RRC reconfiguration, or implicitly during access.

Because a switch is a distinct, observable event with a small number of triggers, most "BWP" tickets — the UE went deaf after a burst, throughput never ramped, an SCell never woke — localise to which trigger fired (or failed to) and whether the switch delay was respected. That is exactly why walking the triggers one by one pays off.

Why BWP switching is needed

Concretely, two problems force the mechanism to exist. First, power: forcing a UE to receive across an entire 100/400 MHz carrier every slot would drain its battery for no reason during the long quiet stretches that dominate real traffic. Second, capability and flexibility: not every UE supports the full carrier bandwidth, and different services want different numerologies. A BWP solves both — it is a contiguous block of PRBs on one carrier with its own subcarrier spacing, cyclic prefix and control resources, and the UE only lives on the active one.

What a BWP Is

5G carriers can be enormous — up to 100 MHz in FR1 and 400 MHz in FR2. Forcing a UE to receive across that entire span every slot would drain its battery for no reason, and would also assume every UE supports the full carrier bandwidth, which many do not. A BWP fixes both problems at once: it is a contiguous block of PRBs, defined on a single carrier, carrying its own subcarrier spacing, cyclic prefix and control resources. The UE only tunes to, and only processes, the currently active BWP — the rest of the carrier is, for that UE at that moment, invisible.

Crucially, each configured BWP is a self-contained radio world. Every entry carries its own locationAndBandwidth (where it sits and how wide it is), its own subcarrierSpacing and cyclicPrefix, and its own dedicated channel configuration: PDCCH-Config (the CORESETs and search spaces the UE monitors), PDSCH-Config for downlink data, and on the uplink PUSCH-Config, PUCCH-Config and SRS-Config. Because control, data and feedback are all bound per BWP, switching the active BWP does not merely retune the frequency window — it swaps the entire set of resources the UE lives on. A CORESET valid on one BWP simply does not exist on another.

How BWPs Are Configured

BWPs are configured per serving cell inside the RRC serving-cell config. The downlink BWPs live in a BWP-Downlink list and the uplink BWPs in a BWP-Uplink list, each entry carrying a bwp-Id, a generic part (BWP: locationAndBandwidth, subcarrierSpacing, cyclicPrefix) and a dedicated part (BWP-DownlinkDedicated / BWP-UplinkDedicated) holding the channels that live on it. A small set of identity fields then decides which BWP is active and when the UE moves between them.

Two subtleties are worth internalising. First, the numbering: the initial BWP is always bwp-Id 0, and dedicated BWPs take IDs 1 to 4, so a cell can present the initial BWP plus up to four dedicated ones. Second, the dormant BWP, added in Release 16, is a downlink BWP on which the UE performs CSI measurements and reporting but does not monitor PDCCH. Moving an SCell into its dormant BWP lets the network keep the cell's channel state fresh — so it can be re-activated instantly — while paying almost none of the power cost of active PDCCH monitoring. It is a middle gear between fully active and fully deactivated.

Some precision on the fields you will actually see in RRC. locationAndBandwidth is a single INTEGER encoded as an RIV (resource-indication value) over a 275-PRB reference, jointly coding the start PRB and the number of contiguous PRBs. subcarrierSpacing is one of the numerology enumerations (kHz15, kHz30, kHz60, kHz120…), and cyclicPrefix is normal by default (extended only at 60 kHz). bwp-Id is an INTEGER 0–4. The bwp-InactivityTimer is an enumeration of millisecond values (for example ms2, ms3, ms4… up to the low-second range) — treat these as an enumerated ladder from TS 38.331 rather than a free integer.

The Four Switching Triggers

There are four ways the active BWP changes, running from most dynamic to most static. Knowing which trigger fired tells you how fast the change is and what state carries over. Each is broken out below with its own debugging and failure notes, because in the field a "BWP problem" is almost always one specific trigger misbehaving.

1. DCI-based (dynamic)

The scheduling DCI carries a 2-bit Bandwidth part indicator field, present in UL format DCI 0_1 and DL format DCI 1_1. Those two bits map to a bwp-Id through a small standardised association (with up to four configured BWPs the mapping is direct). If the field names a BWP different from the current active one, the UE switches to it as part of executing that same DCI — the very assignment or grant the DCI carries is then applied on the new BWP. This is the fast path: one DCI both switches and schedules, so a data burst can arrive on a wide BWP with no separate signalling round-trip. Note it is the scheduling formats that carry the field: the fallback formats DCI 0_0 / DCI 1_0 have no BWP indicator and cannot switch.

Precision to keep straight: the switching DCI 1_1 (DL) / DCI 0_1 (UL) is scrambled with the C-RNTI and is decoded in a UE-specific search space (USS) inside a CORESET of the currently active BWP — because you can only be told to switch by a message you can already read. The scheduled PDSCH/PUSCH that rides the same DCI lands on the new BWP, timed by k0 (DL) / k2 (UL) chosen large enough to clear the switch delay.

2. Timer-based (autonomous fallback)

When the UE is on a non-default DL BWP, the bwp-InactivityTimer runs. It is started — and restarted — by scheduling activity: any DL assignment or UL grant on the active BWP resets it. If it expires, meaning nothing has been scheduled for the configured span, the UE autonomously falls back to the BWP named by defaultDownlinkBWP-Id, which is typically the narrow, low-power BWP. No DCI is needed; the UE moves itself. This is the main power-saving lever, and it is why the default BWP is usually the smallest one.

3. RRC reconfiguration (semi-static)

An RRCReconfiguration can change the BWP set entirely, or point firstActiveDownlinkBWP-Id / firstActiveUplinkBWP-Id at a different BWP; the change takes effect when the reconfiguration is applied. This path is slow — it involves signalling and processing — but it is how the network reshapes the whole configuration, not just picks among existing BWPs.

4. Initial access / random access (implicit)

Before dedicated config the UE simply uses the initial BWP, where it performed cell search and RACH. During random access the UL BWP used for the preamble and Msg3 is tied to the active BWP, and if the active BWP lacks the RACH resources the UE switches to the initial BWP to run the procedure. There is no explicit "switch" command here; the BWP the UE lands on is dictated by the procedure and the config.

Switching Over Time — A Picture

Picture one wide carrier with two configured DL BWPs: a narrow default (BWP₁) and a wide one (BWP₂). The UE rests on the narrow default to save power. Traffic arrives, a DCI with the Bandwidth part indicator pointing at BWP₂ switches the UE wide and schedules its data in the same breath. Each subsequent grant restarts the bwp-InactivityTimer. When traffic stops, the timer counts down and, on expiry, the UE returns itself to BWP₁.

Reading a BWP switch in the logs

A switch is a discrete event in the UE MAC/PHY trace: the DCI that carried the indicator, the old and new bwp-Id, and the slot at which the active BWP flips. Timer-driven fallbacks show up as an inactivity-timer expiry followed by the same flip toward the default BWP, with no DCI attached.

Representative UE MAC/PHY log — illustrative, values vary by vendor/build:

Switching Delay and Scheduling Restriction

Switching is not free. The UE needs time to retune its RF front-end, reload the new BWP's numerology and reconfigure baseband, and during that interval it can neither reliably receive nor transmit. TS 38.133 captures this as a BWP switch delay requirement, and it distinguishes two capability categories — broadly a Type 1 and a Type 2 — reflecting how quickly a given UE implementation can complete the switch. The actual delay in each category also depends on the numerology (the slot length of the target BWP) and on the trigger. Treat these as capability- and numerology-dependent values drawn from that spec rather than a single fixed microsecond figure.

The practical consequence is a scheduling restriction around the switch. During the switch-delay window the UE is not expected to transmit or receive on either the old or the new BWP, so the scheduler must leave that gap clear. A DCI that triggers a DL switch is received on the old BWP, and its scheduled PDSCH must be placed far enough after the DCI that the switch has completed — the network respects the UE's reported delay when choosing the scheduling offset (for example the k0 / k2 timing). Get this wrong and the UE would be told to receive data it is physically mid-retune to reach.

Two further per-BWP behaviours follow the active BWP across a switch. CSI reporting is configured per BWP (through the BWP's CSI-MeasConfig resources), so after a switch the UE reports channel state on the new BWP's resources; measurements tied to the old BWP simply do not carry over. Likewise SRS is per-BWP via SRS-Config, so uplink sounding resumes on the new UL BWP's sounding resources. And because PDCCH-Config — the CORESETs and search spaces — is per BWP, the UE's control monitoring moves wholesale to the new BWP: the DCI that commanded the switch had to be received on the BWP the UE was already monitoring, because you cannot be told to switch by a message you could only read after switching.

TDD Pairing, and BWPs Across Carriers

On a TDD carrier the downlink and uplink share the same frequency, so their BWPs are not independent. The DL and UL BWPs that share a bwp-Id are treated as a pair, and they switch together: a DCI that moves the DL BWP moves the paired UL BWP with it. This keeps the UE's single RF chain coherent — it would make no sense to receive on one part of the band and transmit on another when the two directions time-share the same spectrum. On an FDD carrier, by contrast, DL and UL sit on separate frequencies with separate RF, so their BWPs can be switched more independently, each with its own indicator and its own inactivity behaviour on the DL side.

BWP switching also composes with carrier aggregation. Each serving cell — the PCell and every SCell — has its own BWP configuration and its own active BWP, switched on that cell. This is where the Release-16 dormant BWP earns its keep. Rather than fully deactivating an SCell (which loses its channel state and makes re-activation slow) or leaving it fully active (which burns power on PDCCH monitoring), the network can move the SCell into its dormantBWP-Id: the UE keeps measuring and reporting CSI on that cell but stops monitoring its PDCCH. Entering and leaving the dormant BWP is driven by a dedicated DCI (a special use of DCI 1_1's bitmap on the scheduling cell), so a burst of SCell traffic can be served almost immediately — the channel estimate is already warm. It is the fast-standby gear for aggregated cells.

The Power-Saving Story and DRX

Put the pieces together and BWP adaptation becomes a battery strategy. Configure a narrow default BWP, set a sensible bwp-InactivityTimer, and the UE naturally spends its quiet time on a small bandwidth that is cheap to monitor and cheap to keep warm. The instant real traffic appears, a DCI switches it to a wide BWP for high throughput; when the burst ends and the timer lapses, it drifts back to narrow without any signalling. The default BWP being narrow is not an accident — it is the whole point of the fallback.

This dovetails with DRX (Discontinuous Reception). DRX decides when the UE must wake to monitor PDCCH at all; BWP adaptation decides how much bandwidth it monitors while awake. Together they attack the two big drains — how often you listen and how wide you listen — so a UE can be both asleep more of the time and cheaper to run while awake. The two mechanisms even interlock in detail: the DRX active-time and the bwp-InactivityTimer both react to scheduling, and the network tunes them together so the UE narrows its bandwidth and then sleeps, rather than fighting between the two. On the SCell side, the dormant BWP plays the same tune at the cell level — keeping the channel warm without the monitoring cost.

Summary

The fastest way to reason about — or root-cause — bandwidth adaptation is to identify which of the four triggers moved (or should have moved) the active BWP. DCI (DCI 1_1/0_1 with the 2-bit Bandwidth part indicator, C-RNTI, UE-specific search space) switches the UE up to a wide BWP and schedules in the same DCI; the bwp-InactivityTimer autonomously switches it down to defaultDownlinkBWP-Id when scheduling stops; RRCReconfiguration reshapes the set or the first-active BWP; and initial access / RACH just dictate where the UE begins.

Every switch costs a switch delay (TS 38.133, Type 1/Type 2, numerology-dependent) during which the UE can neither transmit nor receive, so the scheduler always places the post-switch PDSCH/PUSCH after that gap and CSI/SRS/PDCCH resources move wholesale to the new BWP. On TDD the paired DL/UL BWPs switch together; across carriers each cell switches its own BWP, and the Rel-16 dormant BWP keeps SCells warm at almost no monitoring cost. Read log-in-hand: check the switch cause, the DCI format and indicator, the old/new bwp-Id, and that k0/k2 clears the switch delay — the first field that does not line up is your root cause.