Logical Channel Prioritization in LTE 4G

Introduction

Logical Channel Prioritization (TS 36.321) is the UE-side MAC procedure that runs every time a new uplink transmission is assembled for a grant. It is the last decision the UE makes before bytes hit the air: the scheduler has already decided how big the transport block is; LCP decides which logical channels fill it and in what order their SDUs are packed into the MAC PDU.

It sits at the heart of the uplink loop. A Scheduling Request (SR) asks for a grant, a Buffer Status Report (BSR) tells the eNB how much is queued, the eNB issues a grant on PDCCH (DCI format 0 / C-RNTI), and LCP is what turns that grant into a concrete set of bytes. Because the algorithm is fully standardised and deterministic, the eNB can predict exactly what the UE will do — which is what keeps buffer reporting and grant sizing in step.

LCP matters because a grant is scarce and shared. High-priority signalling and delay-sensitive flows must go first, yet low-priority bulk data must not starve. When something goes wrong — voice choppy under a big upload, signalling delayed, a channel that never seems to drain — the root cause is almost always one specific parameter or one of the two rounds, so a structured, step-by-step reading of the LCP configuration pays off immediately.

Why LCP is needed

LCP (TS 36.321) runs in the UE's MAC every time a new uplink transmission is assembled for a grant. The grant is scarce and shared: high-priority signalling and delay-sensitive flows must go first, but low-priority bulk data must not be starved forever. If MAC simply served channels in strict priority order, a greedy high-priority channel with a full buffer could swallow every grant and block everything below it indefinitely. LCP prevents that with a token-bucket scheme layered under strict-priority tie-breaking.

LCP is a purely UE-side procedure. The eNB never tells the UE how to split a grant; it only sizes the grant (via DCI format 0 on PDCCH, CRC scrambled by the UE's C-RNTI, in the UE-specific search space) and trusts the UE to fill it by the standardised algorithm. Because the algorithm is deterministic, the eNB can nonetheless predict what the UE will do — which is why the BSR the UE reports and the grants the eNB issues stay in step. The whole scheme rests on three per-channel RRC parameters and one state variable, so those come first.

The per-logical-channel parameters

RRC configures each logical channel through the LogicalChannelConfig IE (TS 36.331), carried inside the bearer setup. Three fields drive LCP directly, and a fourth (logicalChannelGroup) ties the channel to buffer reporting, covered later.

The token bucket Bj

The state that ties these parameters together is a per-channel variable the spec calls Bj — the current token balance of logical channel j, measured in bytes. Think of it as a bucket that is continuously topped up by a tap running at PBR and drained whenever the channel is served in round 1. Formally, before every LCP run MAC increments Bj by PBR × T, where T is the elapsed time since Bj was last incremented — but never above the ceiling PBR × BSD. Any overflow above the ceiling is simply discarded, which is the whole point of BSD: it stops a channel that has been silent for minutes from accumulating a gigantic entitlement.

When the channel is served in round 1, Bj is decremented by exactly the number of bytes taken, and it may legitimately go negative. A negative balance means the channel has recently drawn more than its long-run PBR entitlement, so it must wait for the tap to refill before it wins round 1 space again. Crucially, Bj is not touched in round 2 — bytes handed out in the second pass are "bonus" capacity that does not count against the channel's guaranteed rate. This asymmetry is what makes the two rounds mean two different things.

The two-round LCP algorithm

When a new UL grant arrives, MAC first refreshes every bucket (the Bj += PBR × T step), then allocates bytes in a defined order. TS 36.321 breaks this into two passes over the channels that have data to send.

Round 1 — serve the guaranteed share. Consider all logical channels with data available, in decreasing priority order (lowest priority value first). Each channel is allocated resources up to the minimum of (its buffered data) and (its current bucket balance Bj). Only channels with Bj > 0 are eligible; a channel sitting at a negative balance is skipped this round. As bytes are taken, Bj is decremented by that amount. When round 1 finishes, every channel has received roughly its PBR worth of the grant, doled out strictly in priority order so that if the bucket shares alone exceed the grant, the important channels are the ones that got served.

Round 2 — spend what is left. If the grant still has room after every bucket share is served, MAC does a second pass, again in strict decreasing priority order, but this time ignoring Bj entirely. The highest-priority channel with remaining data takes as much as it can, then the next, and so on, until the transport block is full or all buffers are empty. Because Bj is not decremented here, a channel can be served well above its PBR in a single grant whenever there is spare capacity — the algorithm never wastes grant bytes just to enforce a rate cap.

The packing rules that keep both sides in sync

On top of the two rounds, TS 36.321 fixes a few rules so the UE and eNB always build the same PDU and never waste bytes:

Reading LCP in the UE MAC logs

LCP itself is a UE-internal decision, but modern modem traces expose it: the grant size, each channel's Bj before the pass, and the bytes each channel won across the two rounds. Reading these three together tells you immediately whether a starved channel is starved by design (negative Bj, small grant) or by misconfiguration (wrong priority/PBR).

Representative UE MAC log (QXDM/QCAT-style) — illustrative, values vary by vendor/build:

Logical Channel Groups and the BSR

LCP decides how to fill a grant the UE already has. But the eNB can only issue a right-sized grant if it knows how much the UE is holding — and that is reported by the Buffer Status Report (BSR). Reporting per individual logical channel would be far too much overhead, so LTE groups channels into Logical Channel Groups (LCG) and reports buffer occupancy per group.

There are exactly four groups, LCG 0 through LCG 3, and each logical channel is assigned to one via the logicalChannelGroup field at bearer setup. The assignment follows priority: high-priority channels (signalling, voice) are grouped together and lower-priority bulk channels in another, so the eNB can tell "urgent bytes waiting" apart from "background bytes waiting" from the report alone.

The 6-bit index does not carry a raw byte count; it points into a standardised buffer-size table, so a value covers a range of bytes. A BSR is triggered by events such as new higher-priority data arriving (Regular BSR), a periodic timer expiring (Periodic BSR), or spare room in a grant that a BSR can usefully fill (Padding BSR). The relationship with LCP is a tight feedback loop: LCP consumes the buffer, the buffer level drives the next BSR, the BSR drives the next grant, and LCP runs again on that grant.

How LCP maps onto radio bearers

Every logical channel LCP arbitrates over is the MAC face of a radio bearer. Two families exist: Signalling Radio Bearers (SRBs) carrying RRC and NAS control, and Data Radio Bearers (DRBs) carrying user-plane traffic. LCP does not know or care about that distinction directly — it only sees priority, PBR and Bj — but the network configures those parameters so that the bearer hierarchy falls out naturally.

• SRB over DRB. Signalling bearers are configured with the lowest priority values (highest priority). SRB0 (on CCCH) and SRB1 carry the RRC messages that keep the connection alive — measurement reports, reconfiguration, handover signalling — and must never be delayed behind a file upload. They are typically given a small guaranteed rate but sit at the top of the priority order, so in both rounds their bytes go in first.
• Among DRBs, by QCI. Each DRB maps to a QoS Class Identifier that characterises its traffic (delay budget, loss tolerance, GBR vs non-GBR). The network translates QCI into concrete LCP settings: a QCI 1 voice bearer (GBR, tight delay) gets a higher priority and a matching PBR; a QCI 9 best-effort bearer gets a low priority and often a small PBR with a large BSD so it lives mostly off round 2 leftovers.

The result is a clean ordering: control signalling first, then real-time GBR data, then interactive traffic, then background best-effort — all expressed to MAC purely as priority/PBR/BSD triples. This is why you can reason about a UE's uplink behaviour just from the LogicalChannelConfig table without ever mentioning bearers: the bearer policy has already been baked into those numbers.

Worked example: splitting one grant across SRB1 and two DRBs

Put it together with a concrete grant. The UE holds three channels and receives a UL grant of 1200 bytes (ignoring MAC subheader and short BSR CE overhead for clarity — assume a small BSR is placed first per the packing rules). Their configuration and buffered data at grant time:

Round 1 walks the channels in priority order, each taking min(data, Bj), decrementing Bj:

• SRB1 (prio 1): Bj unbounded, only 100 B buffered → takes 100 B. Grant left: 1100 B.
• DRB1 (prio 5): min(400, 200) → takes 200 B, Bj → 0. Grant left: 900 B. Still 200 B buffered.
• DRB2 (prio 12): min(5000, 100) → takes 100 B, Bj → 0. Grant left: 800 B. Still 4900 B buffered.

Round 2 walks the same order ignoring Bj, filling the remaining 800 B by strict priority:

• SRB1: buffer already empty → skip.
• DRB1: 200 B left → takes all 200 B. Grant left: 600 B.
• DRB2: 4900 B left → takes 600 B, filling the grant. Grant left: 0.

Notice the outcome. Signalling and voice are fully cleared; the best-effort bearer got its guaranteed 100 B in round 1 plus whatever room was left over (600 B) in round 2, and still has 4300 B waiting — which will trigger the next BSR and, in turn, the next grant. DRB1's Bj is now 0 and DRB2's is 0, so if a second grant arrived in the very next TTI before the tap refilled, round 1 would allocate them almost nothing and round 2 would again favour the higher-priority channel. That is the token bucket doing its job across grants, not just within one.

Summary

LCP is the deterministic MAC procedure that turns one UL grant into a concrete, ordered set of bytes. Read it in the order the algorithm runs: refresh every bucket (Bj += PBR × T, capped at PBR × BSD), place MAC CEs (BSR/PHR) first, run round 1 for fairness (each channel up to min(data, Bj) in priority order), then round 2 for efficiency (leftover to the highest-priority channel with data, ignoring Bj).

When a channel misbehaves, the first field to check is almost always one of three: the channel's priority (wrong order), its PBR/BSD (too small a guaranteed share, or a negative Bj excluding it from round 1), or the grant size itself (a BSR/scheduler sizing problem upstream, not LCP). Isolating which of the two rounds the byte was lost in turns a vague "voice choppy under upload" into a specific, testable hypothesis.

Best used config-in-hand: line up the LogicalChannelConfig triples against the LCP allocation trace and the reported BSR, and the first number that does not match the intended bearer policy is your root cause.

Quick Q&A