The LTE habit you have to unlearn

In LTE a UE operated across the whole channel bandwidth, full stop. Tell it the carrier is 20 MHz and it lit its receiver across all 100 resource blocks, all the time — connected, idle-ish, pulling a file, or sitting on a keep-alive. There was no notion of a sub-band the network told the UE to live in. The channel was the channel, numerology was fixed at 15 kHz across the whole thing, and you never configured a slice of the carrier because the concept didn't exist.

Now make the carrier 100 MHz wide, which 5G NR routinely does, and that habit becomes a liability. Force a UE to keep its RF front end and baseband running across all 100 MHz continuously, for bandwidth it isn't using, and you torch the battery for nothing. A wide carrier buys peak throughput when there's traffic; the cost is that listening to it is expensive. LTE never faced this because its carriers were narrow enough that "use the whole thing" was a fine default.

NR's answer is the Bandwidth Part (BWP). It's the single most important NR concept with no LTE equivalent, and once you internalize it, a lot of NR scheduling and power-saving behavior stops looking mysterious. If the wider frame structure — subcarrier spacing, slots, mu — isn't fresh, the 5G NR numerology guide is the right prerequisite, because a BWP carries exactly one numerology.

A single 100 MHz carrier mapped onto the carrier-wide CRB grid anchored at Point A, with four configured Bandwidth Parts, one active, and the three switch mechanisms: DCI, the inactivity timer, and RRC reconfiguration.
A single 100 MHz carrier mapped onto the carrier-wide CRB grid anchored at Point A, with four configured Bandwidth Parts, one active, and the three switch mechanisms: DCI, the inactivity timer, and RRC reconfiguration.

What a BWP actually is

A Bandwidth Part is a contiguous set of common resource blocks on a carrier, with a single numerology — one subcarrier spacing and one cyclic prefix (TS 38.211 §4.4.5). Two parameters define it: a location (where its lower edge sits on the carrier) and a bandwidth (how many RBs wide it is). That's the whole object. Contiguous, one numerology, located, sized.

Three properties matter, because each is a delta from LTE:

  • One numerology per BWP. Subcarrier spacing and cyclic prefix are properties of the BWP, not the cell. One UE can have a BWP at 15 kHz and another at 30 kHz on the same FR1 carrier. In LTE, spacing was a carrier-wide constant you never touched.
  • Up to four DL BWPs and four UL BWPs per UE, per serving cell, with exactly one active at a time in each direction (TS 38.213 §12). Configure four, activate one — that's the line to memorize. The other three sit dormant in the UE's config until something switches to them.
  • The UE only ever tunes to the active BWP. It isn't sampling the whole 100 MHz and ignoring the rest; its receiver bandwidth tracks the active BWP. Park it on a narrow BWP and it genuinely keeps only a sliver of spectrum alive.

Keep numerology inside one frequency range when you reason about this. FR1 data lives at 15/30/60 kHz, FR2 at 60/120 kHz (TS 38.101-1 / 38.101-2). The "15 kHz for coverage, 30 kHz for capacity on one carrier" trick is an FR1 example — don't mentally drop a 120 kHz FR2 BWP onto a sub-6 carrier. The 5G frequency bands reference lays out which channel bandwidths and spacings are legal in each range.

CRB versus PRB: the renumbering that trips everyone

Here's the part that catches LTE engineers, and it follows straight from BWPs existing. NR carries two resource-block numbering systems, and you have to keep them straight. LTE had effectively one: RBs were numbered across the carrier and that was that. NR splits the idea in two because the UE no longer sees the whole carrier.

Common Resource Blocks (CRB)Physical Resource Blocks (PRB)
Reference frameCarrier-wideInside one BWP
AnchorPoint A (subcarrier 0 of CRB 0)Lower edge of the BWP
Index 0 sits atThe carrier's absolute zeroThe start of the active BWP
Who uses itThe network's absolute spectrum mapEvery grant the UE receives
SpecTS 38.211 §4.4.4.2 / §4.4.4.3TS 38.211 §4.4.4.4
Common Resource Blocks are the carrier-wide reference grid, numbered from a single anchor called Point A and counting upward across the entire carrier for a given subcarrier spacing. Point A is the zero of that map, and it's a property of the carrier, not the cell. Physical Resource Blocks are numbered within a BWP: PRB 0 sits at the lower edge of the BWP and counts up to its width. They're local, relative, and restart at zero at every BWP boundary.

So the relationship is just an offset. If a BWP starts at CRB N<sub>start</sub>, then PRB k inside that BWP equals CRB (N<sub>start</sub> + k). PRB 0 is not CRB 0 unless the BWP happens to start at Point A, which it usually doesn't.

Why does this bite? Because every frequency-domain allocation a UE receives is expressed in PRBs of its active BWP, not in carrier coordinates. When a grant says "PRBs 0 through 9," that's the first ten RBs of the active BWP, wherever it sits. The same PRB index means a different absolute frequency depending on which BWP is active. Map it back to CRBs through the BWP start offset, or you'll be looking at the wrong subcarriers entirely — a real source of confusion the first time you trace NR scheduling with an LTE reflex that says "RB 5 is RB 5."

The initial BWP, and where it comes from

A UE has to talk to the cell before any dedicated BWPs are configured — during initial access it has no RRC-configured BWP set at all. So NR defines an initial BWP for exactly this window (TS 38.213 §12).

The initial DL BWP isn't configured by dedicated signaling; it's derived. Its location and bandwidth come from the CORESET#0 configuration the MIB points to (the Type0-PDCCH control resource set the UE uses to find the scheduling for SIB1), and SIB1 then carries the explicit initialDownlinkBWP / initialUplinkBWP (TS 38.213 §13; TS 38.331). This is why the initial BWP is constrained to be narrow: it has to be small enough that the UE — which knows nothing yet — can find CORESET#0 and read SIB1 inside it. You can't make the initial BWP wide and clever; it's the bootstrap, and the bootstrap has to fit the control resource set the UE uses to read it.

Once RRC-connected, the network configures dedicated BWPs — up to four per direction — with their own locations, bandwidths, and numerologies (TS 38.331: BWP-Downlink / BWP-Uplink). One is flagged as the first to activate (firstActiveDownlinkBWP-Id) and one as the default to fall back to (defaultDownlinkBWP-Id). The initial BWP got the UE in the door; the dedicated BWPs are where it does its work.

Three ways the active BWP changes

The active BWP isn't static — it moves underneath a running UE, through three distinct mechanisms with very different speeds.

1. DCI — the fast, scheduler-driven path

The scheduling grant itself carries a Bandwidth part indicator field (DCI formats 0_1 for uplink, 1_1 for downlink), and that field flips the active BWP at Layer 1 — no RRC round trip, no reconfiguration message (TS 38.212 §7.3.1; TS 38.213 §12). The scheduler decides, in the same grant that allocates resources, that the UE should now live on a different BWP. This is the workhorse: the gNB sees traffic arrive and switches the UE from a narrow BWP to a wide one as part of scheduling the very data that justified the switch.

2. Timer — the automatic fallback

Each UE can run a bwp-InactivityTimer (TS 38.213 §12; TS 38.331). While the UE is on a non-default BWP and nothing is scheduled, the timer counts down; when it expires, the UE falls back to the default BWP on its own. This is the power-saving safety net: if the scheduler forgets to move a UE back, or traffic simply stops, the UE doesn't sit indefinitely on a wide BWP burning power — it quietly returns to the narrow default.

3. RRC — the slow, structural path

RRC reconfiguration can redraw the whole BWP set, change which BWP is active, or change any BWP's configuration (TS 38.331). This is the heavyweight option, used when the set of BWPs changes, not for moment-to-moment switching. It's the same RRCReconfiguration machinery covered in the NAS vs RRC walkthrough.

So it's a layered system: RRC defines and redraws the set, DCI does fast per-grant switching, and the timer provides an automatic retreat to safety — a semi-static structure from RRC with a fast dynamic layer on top and a fallback for when the dynamic layer goes quiet.

Why BWPs exist: three payoffs

Power saving. This is the headline. Park the UE on a narrow default BWP when it isn't moving much data and its receiver keeps only a small slice alive instead of sampling a 100 MHz carrier continuously. The bwp-InactivityTimer automates the retreat so the saving happens without the scheduler micromanaging it. LTE simply couldn't do this — its UEs used the whole channel by definition. BWPs are one of the core levers in the broader 5G network energy saving toolkit. Mixed numerology. Because numerology is per-BWP, one UE can carry different services on different BWPs at different spacings — a 15 kHz BWP for coverage-limited or latency-tolerant traffic and a 30 kHz BWP for higher-capacity traffic, coexisting on the same FR1 carrier. The BWP is the container that makes per-service numerology possible without forcing the whole cell onto one spacing. Adapting bandwidth to traffic. Throughput and battery pull in opposite directions, and a fixed carrier bandwidth forces one compromise. BWPs let the active bandwidth track load: narrow to sip power when there's nothing to send, wide to sprint when there is. The UE doesn't pay for bandwidth it isn't using, but the bandwidth is one DCI away when it's needed. For getting peak rate beyond a single carrier, that's where carrier aggregation stacks on top of the active BWP per component carrier.

The gotchas that bite

PRB indices are BWP-relative, not carrier-relative. Already covered, but it causes the most head-scratching, so here it is in the form it bites: the same PRB number points at different absolute frequencies depending on which BWP is active. Always resolve a grant's PRBs through the active BWP's start offset before reasoning about where on the carrier it sits. A UE can only be scheduled within its active BWP. This follows directly from "one active BWP at a time," and the consequence is sharp: if the active BWP is narrow, the grant is bounded by it. A UE parked on a 5 MHz BWP cannot be handed a 50 MHz allocation no matter how empty the rest of the carrier is — the scheduler has to switch it to a wider BWP first (the DCI mechanism above). A UE's instantaneous peak rate is capped by its active BWP, not by the carrier. If you're debugging why a UE isn't getting the throughput the carrier should allow, check which BWP it's on before you look anywhere else. Switching isn't free. Changing BWP — especially when it moves the center frequency or bandwidth the RF has to tune to — costs a short retuning gap during which the UE can't send or receive, and the standard defines BWP switch delay budgets for exactly this reason. A scheduler that thrashes a UE between BWPs spends real airtime on retuning and gives up throughput. The design intent is deliberate, infrequent switches — narrow when idle-ish, wide for a sustained burst — not per-slot ping-ponging.

If you want to see all of this on real captures — CORESET#0 deriving the initial BWP, a BWP-Downlink in an RRC message, and the BWP indicator flipping inside a DCI grant — you can start a free 7-day trial (no credit card) and work through it hands-on.

The takeaway

Bandwidth Parts are NR's cleanest example of a feature with no LTE ancestor. LTE handed the UE the whole carrier and that was the end of it. NR carves the carrier into up to four BWPs per direction, keeps exactly one active, gives each its own numerology, and renumbers resource blocks inside each BWP as PRBs over the carrier-wide CRB grid anchored at Point A. The initial BWP bootstraps access from CORESET#0 and SIB1; dedicated BWPs do the real work; the active one moves by fast DCI, automatic timer fallback, or structural RRC reconfiguration. Why it's worth it comes down to one sentence: the carrier got too wide to listen to continuously, so NR lets the UE live in just the slice it needs — narrow to sip power, wide to sprint — and bounds every grant to that slice. Configure four, activate one, and always ask which one is active before you trust a PRB index.