Logical Channel Prioritization in 5G NR

1. The Problem LCP Solves

An uplink grant is one number: a transport block size, for one HARQ process, in one slot. It says nothing about which of the UE's bearers it is meant for, because the gNB does not know -- all it has is a Buffer Status Report that lumped the UE's queues into at most eight groups, several milliseconds ago. The UE, on the other hand, knows exactly what it has queued and exactly what each bearer was promised. So the division of the grant is left entirely to the UE, and the algorithm that does it is Logical Channel Prioritisation TS 38.321 cl. 5.4.3.1.

That division has to satisfy three things at once, and they conflict:

• Priority must be respected. A voice bearer must not wait behind a file upload.
• Guaranteed rates must be honoured. A bearer configured with a prioritised bit rate must actually get that rate on average, even when a higher-priority bearer always has data.
• Nothing may be wasted. The transport block is going out regardless. Every octet not filled with data is filled with padding, which costs the same power and the same spectrum.

Strict priority alone satisfies the first and third and fails the second: a busy high-priority channel starves everything below it forever. A fixed per-bearer reservation satisfies the second and fails the third: a bearer with nothing to send wastes its reservation. LCP resolves this with a token bucket per logical channel and a two-stage allocation -- serve everybody's tokens first in priority order, then hand out whatever is left by strict priority.

2. Where a Logical Channel Comes From: QoS Flow to DRB to LCH

LCP's inputs are logical channels, and a logical channel is the bottom of a chain that starts at the 5GC. Each link in that chain is one-to-one, which is what makes the bottom of it interesting: five one-to-one pipelines meet one shared transport block.

Table 1. Representative 5QI values, TS 23.501 Table 5.7.4-1. These are the intent; the LCH priority value is the implementation, and nothing in the specs forces them to agree.

3. The Per-Logical-Channel Parameters

Everything LCP needs about a logical channel is in ul-SpecificParameters inside LogicalChannelConfig, signalled per bearer inside RLC-BearerConfig TS 38.331.

priority

prioritisedBitRate

bucketSizeDuration

logicalChannelGroup

schedulingRequestID

logicalChannelSR-Mask

logicalChannelSR-DelayTimerApplied

allowedServingCells

allowedSCS-List

maxPUSCH-Duration

configuredGrantType1Allowed

allowedCG-List

allowedPHY-PriorityIndex

bitRateQueryProhibitTimer

Table 2. LogicalChannelConfig -> ul-SpecificParameters, the complete LCP-relevant set. The last five rows are eligibility gates rather than rate parameters, and they are checked before any arithmetic happens (§5).

4. The Token Bucket: PBR, BSD and Bj

Each logical channel j has a variable Bj, in octets, initialised to zero when the channel is established. Before every invocation of LCP, MAC does two things to it TS 38.321 cl. 5.4.3.1:

Bj  =  Bj + PBR x T                  -- T = time since Bj was last incremented
if Bj > PBR x BSD:  Bj = PBR x BSD   -- the bucket cannot overflow

then, after round 1 of the allocation:

Bj  =  Bj - (octets of MAC SDU served to channel j in round 1)
                                     -- Bj MAY go negative, and does

Three properties fall straight out of those three lines and between them explain almost every LCP surprise:

• The bucket fills to its cap after exactly BSD of idleness. Cap divided by rate is PBR x BSD / PBR = BSD. So bucketSizeDuration is literally how many milliseconds of unused allowance you may bank, independent of the rate.
• Bj can go negative. Round 3 does not touch Bj, but round 1 can serve up to Bj and the subheader is not counted against it -- and more importantly, an implementation that has served a channel generously in round 3 will still credit it the full PBR next slot. Negative Bj is the mechanism that pays back over-service; it is not an error state.
• PBR = kBps0 means Bj is permanently zero, so the channel is never served in round 1 at all and lives entirely off round 3. That is the correct configuration for best-effort traffic and a serious misconfiguration for a GBR bearer.

kBps0

kBps8

kBps16

kBps32

kBps64

kBps128

kBps256

kBps512

kBps1024

kBps4096

kBps65536

infinity

Table 3. Token fill rate per slot. Slot durations are 1 ms, 0.5 ms and 0.125 ms. The per-slot figure is what matters, because LCP runs per grant and grants arrive per slot at most.

ms5

ms20

ms50

ms100

ms300

ms1000

Table 4. Bucket cap = PBR x BSD. Read the last column as the answer to "how long may this channel be idle and still claim its full allowance the moment it wakes up?"

5. Step 0: Which Logical Channels May Use This Grant At All

Before any arithmetic, MAC decides which logical channels are even candidates for this particular grant TS 38.321 cl. 5.4.3.1.2. This is not a priority question and it is not a rate question -- it is a compatibility question, and a channel that fails it is not starved, it is absent.

allowedSCS-List

maxPUSCH-Duration

configuredGrantType1Allowed

allowedServingCells

Table 5. LCP restrictions. Every one of them exists because a grant is not just a quantity of bytes -- it has a numerology, a duration, a cell and a priority class, and those matter to some bearers and not to others.

6. The Three-Round Algorithm

Table 6. The three rounds, TS 38.321 cl. 5.4.3.1. Channels configured with equal priority should be served equally -- note that this is a should, and implementations differ.

Two implementation facts that the spec text does not spell out but that every trace shows:

• Rounds 1 and 3 are combined into one RLC request per logical channel. A channel allocated 30 octets in round 1 and 70 in round 3 produces one subPDU of 100 octets, not two of 30 and 70. That matters for the subheader arithmetic -- one subheader, not two -- and it is why a trace shows one SDU per logical channel per PDU.
• The space accounting includes subheaders. A channel allocated n octets of MAC SDU consumes n + 2 octets of the grant (or n + 3 if n > 255). The Bj decrement in round 2 uses the SDU size only. Every textbook worked example that omits this gets the last channel's allocation wrong.

7. Worked Allocation 1: a 200-Octet Grant Across Three Channels

30 kHz SCS, so a slot is 0.5 ms. Three logical channels are eligible for this grant; no MAC control element is pending.

LCID 5

ms5

LCID 6

ms5

LCID 7

ms5

Table 7. Starting state. Total queued is 220 octets against a 200-octet grant, so something will be left behind -- the question is what.

LCID 7 keeps 26 octets queued. Note what did not happen: LCID 7 was not starved. It received 54 of the 80 octets it had, more than LCID 6 got in round 1, purely because rounds 1 and 3 together fill the block. A naive reading of "priority 9 behind priority 4 and 6" would predict zero.

8. Worked Allocation 2: the Same Grant, One Parameter Changed

Same grant, same buffers, same priorities. One change: LCID 7 is reconfigured from prioritisedBitRate = kBps0 to kBps32 with bucketSizeDuration = ms5, and by the time the grant arrives its bucket holds 100 octets.

This is the whole point of PBR, and it is worth stating plainly: prioritisedBitRate moves capacity up the priority order into round 1, where the low-priority channel is protected from the ones above it. priority alone cannot do that. Conversely, a prioritisedBitRate set generously on a bulk channel converts LCP from a priority scheduler into a weighted-fair one, which is sometimes exactly what an operator wants and is almost never what the template shipped with.

8.1 The PBR = infinity case

Take the same three channels and set LCID 5 to prioritisedBitRate = infinity with 150 octets queued instead of 40. Round 1 now serves all 150 octets of LCID 5 before meeting the PBR of anything below it:

9. Worked Bj Accumulation Across Idle Slots

The rate guarantee only works because Bj accumulates while the channel is not being served. Here is that accumulation with real numbers, for a channel that has been quiet.

Now change only bucketSizeDuration to ms100. The fill rate is unchanged at 32 octets per slot, but the cap becomes 64 000 x 0.1 = 6 400 octets, reached after 200 slots of idleness. A channel that has been quiet for 100 ms can now claim 6 400 octets in a single round 1 -- more than four full 1500-octet transport blocks' worth of protected allocation, ahead of every lower-priority channel. The long-run rate is identical; the instantaneous impact on everything else is twenty times larger.

10. Where MAC Control Elements Fit: the Fixed Priority Order

LCP allocates to logical channels, but a MAC PDU also has to carry control elements, and those are not logical channels and have no Bj. TS 38.321 clause 5.4.3.1.3 settles it with a fixed list -- not a configurable priority, a hard-coded order:

Table 8. MAC CE and data priority, TS 38.321 cl. 5.4.3.1.3. Ranks 8-11 and 14 are Rel-16/17 additions; the shape of the list -- identity first, reports above data, padding reports last -- is Rel-15.

One more rule that has real operational effect: MAC does not build a PDU whose only contents are a padding BSR and padding. If nothing else wants to go out, the grant is skipped -- and with skipUplinkTxDynamic configured, skipped without any transmission at all. So the absence of an uplink transmission on a granted occasion is not necessarily a failure; it can be the correct behaviour.

11. RLC Segmentation, and How a Partly-Served Channel Resumes

LCP produces a size per logical channel, not data. MAC then asks the RLC entity for a PDU of that size, and RLC decides how to satisfy it TS 38.322. Two rules bound what RLC may do:

• MAC shall not ask RLC to segment an RLC SDU if the whole SDU fits in the space allocated to that channel. Gratuitous segmentation costs header octets and reassembly state for nothing.
• If segmentation is necessary, MAC shall maximise the segment size to fill the allocation as fully as possible. A half-used allocation is worse than a segment.

Table 9. What happens inside one logical channel's allocation. The last three rows are why an allocation can produce less data than LCP allocated -- and none of them is visible in the LCP arithmetic itself.

Two consequences worth remembering. First, "data available for transmission" for LCP purposes is defined by RLC and PDCP, not by MAC TS 38.322 cl. 5.5 TS 38.323 cl. 5.10: it includes RLC SDUs not yet built into PDUs, PDUs pending initial transmission, PDUs pending retransmission, and PDCP SDUs and control PDUs. Second, a partially served channel needs no special handling at the MAC layer at all -- MAC keeps no per-channel position. The resumption point lives in RLC, which is why LCP looks stateless in a trace apart from Bj.

12. Intra-UE Prioritisation and Cancellation (Rel-16)

Rel-15 LCP assumes one grant at a time. Rel-16 URLLC broke that assumption: a UE can hold a periodic configured grant dimensioned for sensor traffic and receive a dynamic grant for a latency-critical message that overlaps it in time, and it can only transmit one of them. lch-BasedPrioritization in MAC-CellGroupConfig turns on the machinery that resolves this.

Table 10. Rel-16 prioritisation mechanisms. The last row is the one that gets mixed up with the others in analysis -- it is inter-UE and has nothing to do with LCP.

13. Configuration Reference (ASN.1 and Ranges)

LogicalChannelConfig ::= SEQUENCE {
    ul-SpecificParameters      SEQUENCE {
        priority                     INTEGER (1..16),
        prioritisedBitRate           ENUMERATED {kBps0, kBps8, kBps16,
                                        kBps32, kBps64, kBps128, kBps256,
                                        kBps512, kBps1024, kBps2048,
                                        kBps4096, kBps8192, kBps16384,
                                        kBps32768, kBps65536, infinity},
        bucketSizeDuration           ENUMERATED {ms5, ms10, ms20, ms50,
                                        ms100, ms150, ms300, ms500, ms1000,
                                        spare7, ..., spare1},
        allowedServingCells          SEQUENCE (SIZE (1..maxNrofServingCells-1))
                                        OF ServCellIndex        OPTIONAL,
        allowedSCS-List              SEQUENCE (SIZE (1..maxSCSs))
                                        OF SubcarrierSpacing    OPTIONAL,
        maxPUSCH-Duration            ENUMERATED {ms0p02, ms0p04, ms0p0625,
                                        ms0p125, ms0p25, ms0p5,
                                        spare2, spare1}         OPTIONAL,
        configuredGrantType1Allowed  ENUMERATED {true}          OPTIONAL,
        logicalChannelGroup          INTEGER (0..maxLCG-ID)     OPTIONAL,
        schedulingRequestID          SchedulingRequestId        OPTIONAL,
        logicalChannelSR-Mask        BOOLEAN,
        logicalChannelSR-DelayTimerApplied  BOOLEAN,
        ...,
        bitRateQueryProhibitTimer    ENUMERATED {s0, s0dot4, s0dot8,
                                        s1dot6, s3, s6, s12, s30} OPTIONAL,
        [[ allowedCG-List-r16        SEQUENCE (SIZE (0..maxNrofConfiguredGrantConfigMAC-1-r16))
                                        OF ConfiguredGrantConfigIndexMAC-r16 OPTIONAL,
           allowedPHY-PriorityIndex-r16  ENUMERATED {p0, p1}     OPTIONAL ]]
    }                                                            OPTIONAL,
    ...
}

-- maxLCG-ID = 7, so eight logical channel groups exist.
-- ul-SpecificParameters is absent for a downlink-only logical channel,
-- which is the only legitimate way for a channel to have no LCP config.

Listing 1. Abridged from TS 38.331. ... marks omitted enumeration members and extension markers. Note that logicalChannelSR-Mask and logicalChannelSR-DelayTimerApplied are mandatory BOOLEANs, not OPTIONAL -- they are always present and always decidable.

bucketSizeDuration

LogicalChannelConfig

bitRateQueryProhibitTimer

LogicalChannelConfig

logicalChannelSR-DelayTimer

BSR-Config

periodicBSR-Timer

BSR-Config

retxBSR-Timer

BSR-Config

timeAlignmentTimer

TAG-Config

Table 11. Timers that touch LCP. Only the first is an LCP parameter proper; the rest govern whether LCP gets a grant to work on at all. The BSR timers are covered in the companion 10 BSR, PHR, SR document.

14. Failure Modes and What Each One Means

Table 12. LCP failure modes. Almost every row is "detected by nobody": LCP has no failure condition of its own, so every fault presents as a performance symptom on some other bearer.

15. Illustrative Message Traces

15.1 The configuration LCP is working from

RRCReconfiguration
 cellGroupConfig
  rlc-BearerToAddModList
   [0] logicalChannelIdentity ............ 1        -- SRB1, DCCH
       servedRadioBearer: srb-Identity ... 1
       mac-LogicalChannelConfig
        ul-SpecificParameters
         priority ......................... 1
         prioritisedBitRate ............... infinity
         bucketSizeDuration ............... ms5
         logicalChannelGroup .............. 0
         schedulingRequestID .............. 0
         logicalChannelSR-Mask ............ FALSE
         logicalChannelSR-DelayTimerApplied FALSE
   [1] logicalChannelIdentity ............ 5        -- DRB2, conv. voice
       servedRadioBearer: drb-Identity ... 2
       mac-LogicalChannelConfig
        ul-SpecificParameters
         priority ......................... 4
         prioritisedBitRate ............... kBps32   -- 16 oct/slot at 30 kHz
         bucketSizeDuration ............... ms5      -- cap 160 octets
         logicalChannelGroup .............. 1
         schedulingRequestID .............. 0
         allowedSCS-List .................. { kHz30 }
         maxPUSCH-Duration ................ ms0p125
   [2] logicalChannelIdentity ............ 6        -- DRB3, conv. video
        ul-SpecificParameters
         priority ......................... 6
         prioritisedBitRate ............... kBps32
         bucketSizeDuration ............... ms5
         logicalChannelGroup .............. 2
   [3] logicalChannelIdentity ............ 7        -- DRB4, background
        ul-SpecificParameters
         priority ......................... 9
         prioritisedBitRate ............... kBps0    -- round 3 only
         bucketSizeDuration ............... ms5
         logicalChannelGroup .............. 2
         configuredGrantType1Allowed ...... (absent) -- may NOT use CG type 1

Listing 2. The four logical channels used throughout §7 and §8. Note prioritisedBitRate = infinity on SRB1 and kBps0 on the background bearer -- the two extremes of the enumeration, both correctly used.

15.2 The allocation of Worked Allocation 1

14:22:07.4185  [MAC-UL] grant: DCI 0_1, C-RNTI 0x5A31, TBS 200 octets
                        HARQ pid 2, k2 = 4, PUSCH slot 4193.7, SCS 30 kHz,
                        PUSCH duration 2 symbols (0.07 ms), phy priority p0

14:22:07.4185  [MAC] LCP step 0 -- candidate selection
   LCID 1  DCCH  : allowedSCS-List absent, maxPUSCH-Duration absent
                   -> eligible, 0 octets available
   LCID 5  voice : allowedSCS-List {kHz30} matches the grant
                   maxPUSCH-Duration ms0p125 >= 0.07 ms  -> eligible
                   40 octets available,  Bj = 50
   LCID 6  video : eligible, 100 octets available, Bj = 30
   LCID 7  bulk  : eligible, 80 octets available,  Bj = 0   (PBR kBps0)
   pending MAC CEs: none

14:22:07.4185  [MAC] LCP round 1  (decreasing priority, bounded by Bj)
   LCID 1  prio 1  PBR=inf : 0 octets available            -> 0
   LCID 5  prio 4  Bj=50   : min(50, 40) = 40  + 2 subhdr  -> space 200 -> 158
   LCID 6  prio 6  Bj=30   : min(30, 100) = 30 + 2 subhdr  -> space 158 -> 126
   LCID 7  prio 9  Bj=0    : min(0, 80) = 0                -> space 126

14:22:07.4185  [MAC] LCP round 2  (decrement Bj by SDU octets served)
   LCID 5  Bj 50 -> 10
   LCID 6  Bj 30 -> 0
   LCID 7  Bj 0  -> 0

14:22:07.4185  [MAC] LCP round 3  (strict priority, Bj ignored, 126 octets)
   LCID 5 : buffer empty                                   -> +0
   LCID 6 : min(70, 126) = 70, subheader already counted    -> space -> 56
   LCID 7 : new subheader 2 octets, min(80, 54) = 54        -> space -> 0

14:22:07.4185  [MAC] build: 3 subPDUs, 0 padding
   LCID 5  L=40    RLC PDU complete
   LCID 6  L=100   RLC PDU complete
   LCID 7  L=54    RLC segment, SI=first, SO=0, 26 octets retained
   total 42 + 102 + 56 = 200 octets = TBS                   [consistent]

Listing 3. Round by round, with the space accounting explicit. Note that step 0 records why each channel was admitted, not just that it was -- which is what makes the failure in §15.3 diagnosable.

15.3 A failure: a bearer excluded from every ordinary grant

14:31:02.010  [MAC-UL] grant: DCI 0_1, TBS 848 octets, SCS 30 kHz,
                        PUSCH 14 symbols = 0.5 ms, phy priority p0
14:31:02.010  [MAC] LCP step 0
   LCID 5  voice : maxPUSCH-Duration = ms0p125
                   grant PUSCH duration = 0.5 ms
                   *** 0.5 ms > 0.125 ms -> NOT eligible ***
   LCID 6  video : eligible
   LCID 7  bulk  : eligible
14:31:02.010  [MAC] LCP: LCID 5 contributed 0 octets

-- the same thing on the next 21 grants, all 14-symbol PUSCH --

14:31:12.510  [MAC] LCID 5: 0 octets sent in 10.5 s across 22 grants
                    total granted in that window: 17 264 octets
                    LCID 5 buffer occupancy: monotonically rising, 4 210 octets
14:31:12.510  [MAC] BSR: LCG 1 buffer size index 20  -> > 3909 and <= 5446
14:31:12.512  [MAC-UL] grant: TBS 1544 octets  -- scheduler responding to the BSR
14:31:12.512  [MAC] LCP step 0: LCID 5 still NOT eligible (0.5 ms PUSCH)
14:31:12.512  [MAC] LCID 5 contributed 0 octets; 1544-octet grant filled by
                    LCID 6 and LCID 7

-- Diagnosis: the cell never schedules sub-slot PUSCH, so a bearer restricted
-- to maxPUSCH-Duration ms0p125 can never be served. The BSR keeps reporting
-- growing data, the scheduler keeps granting more, and the grants keep being
-- consumed by the OTHER bearers. Larger grants make the symptom worse, not
-- better, because they attract more lower-priority data.

Listing 4. Exclusion, not starvation. The bearer's buffer grows, the scheduler responds correctly, and none of the extra capacity reaches the bearer that asked for it.

15.4 Control elements winning against data

14:35:44.821  [MAC-UL] grant: TBS 56 octets, C-RNTI 0x5A31, HARQ pid 0
14:35:44.821  [MAC] pending: Regular BSR (LCG 1, LCG 2 have data)
                             Single Entry PHR (phr-PeriodicTimer expired)
                    buffers: LCID 5 = 620 oct, LCID 6 = 1400 oct

14:35:44.821  [MAC] multiplexing by cl. 5.4.3.1.3 priority order:
   rank  6  Long BSR (triggered, not padding)
            subheader 2 + bitmap 1 + 2 buffer sizes = 5 octets   -> 51 left
   rank  7  Single Entry PHR
            subheader 1 + 2 octets                  = 3 octets   -> 48 left
   rank 12  logical channel data -- LCP runs on the remaining 48 octets
            LCID 5  prio 4  Bj=160 (capped) : min(160, 620) = 46 + 2 subhdr
                                              -> space 48 -> 0
            LCID 6  prio 6                  : 0 octets available in this grant

14:35:44.821  [MAC] build: 3 subPDUs, 0 padding
   subPDU 1  LCID 5   L=46    (SDU first in the uplink)
   subPDU 2  LCID 62  Long BSR, LCG 1 idx 22, LCG 2 idx 24
   subPDU 3  LCID 57  Single Entry PHR
   total 48 + 5 + 3 = 56 octets = TBS                        [consistent]

-- 8 of 56 octets (14%) went to reports. The video bearer got nothing at all
-- from a grant that was nominally shared. On a grant this size the priority
-- order in cl. 5.4.3.1.3 dominates the LCP arithmetic completely.

Listing 5. Reports outrank data. Note that the reports were built first and placed last: uplink wire order is SDUs then CEs, but the allocation order is the priority list.

15.5 Rel-16 intra-UE prioritisation

14:41:19.2500  [MAC] configured grant CG#1 occasion: PUSCH slot 8238.4,
                     TBS 120 octets, phy priority p0
14:41:19.2500  [MAC] LCP for CG#1: LCID 7 (prio 9) selected, 118 octets
14:41:19.2500  [MAC] MAC PDU built for HARQ pid 4, 120 octets, NOT YET SENT

14:41:19.2502  [MAC-UL] DCI 0_1: dynamic grant, PUSCH slot 8238.4 (OVERLAP),
                        TBS 88 octets, priority indicator = p1
14:41:19.2502  [MAC] LCP step 0 for the dynamic grant:
   LCID 5  allowedPHY-PriorityIndex = {p1}  -> eligible
   LCID 7  allowedPHY-PriorityIndex = {p0}  -> NOT eligible
14:41:19.2502  [MAC] LCP for dynamic grant: LCID 5 (prio 4), 86 octets

14:41:19.2502  [MAC] lch-BasedPrioritization: two grants overlap in slot 8238.4
   CG#1          highest-priority selected LCH = LCID 7, priority 9
   dynamic grant highest-priority selected LCH = LCID 5, priority 4
   -> transmit the dynamic grant; DE-PRIORITISE CG#1

14:41:19.2503  [MAC-UL] PUSCH sent: 88 octets, HARQ pid 6, LCID 5 L=86
14:41:19.2503  [MAC] HARQ pid 4: MAC PDU retained in buffer, deprioritised,
                     no transmission occurred
14:41:19.2610  [MAC-DL] DCI 0_1: retransmission grant, HARQ pid 4, NDI unchanged
14:41:19.2612  [MAC-UL] PUSCH sent: HARQ pid 4, the retained 120-octet PDU

-- HARQ pid 4 shows a 'retransmission' with no initial transmission. That is
-- correct Rel-16 behaviour, not a protocol error.

Listing 6. A configured grant losing to a higher-priority dynamic grant, and the de-prioritised PDU going out later on the same HARQ process.

16. Release Deltas: Rel-15 to Rel-18

Table 13. LCP-relevant changes by release. Notably, the algorithm is unchanged since Rel-15 -- everything new is either an extra eligibility gate or an extra rank in the CE priority list.

17. Reading LCP in Logs: a Checklist

1. Get the grant's properties, not just its size. Numerology, PUSCH duration, serving cell, configured-grant index and physical-layer priority all gate eligibility before any arithmetic happens. A grant is not a quantity of bytes (§5).

2. Check eligibility before priority. If a bearer contributed zero octets, find out whether it was a candidate at all. Exclusion and starvation need opposite fixes and look identical in a throughput graph.

3. Read `prioritisedBitRate` and `bucketSizeDuration` together. Neither means anything alone: the fill rate is PBR and the burst allowance is PBR x BSD. A channel with a high PBR and ms5 behaves nothing like the same PBR with ms300.

4. Account for the subheaders. Two octets per active logical channel, three if its SDU exceeds 255. Sum the subPDUs against the TBS; if they do not match, your reconstruction of the allocation is wrong (§6).

5. Separate round 1 from round 3. A channel served in round 1 is being protected by its PBR; a channel served only in round 3 is living on leftovers. The totals can look the same and the robustness under load is completely different.

6. Check whether a MAC CE took the space. On grants below about 100 octets, a triggered BSR plus a PHR can be a fifth of the block, and they outrank all data (§10). Look for the reports before blaming the LCP arithmetic.

7. Correlate with the DRX cycle. Buckets fill during off-duration, so the first grant after each on-duration is the one most dominated by round 1. Latency spikes locked to the DRX period are usually a bucketSizeDuration story (§9).

8. Look for padding-only configured grants. A configured grant going out full of padding every period almost always means configuredGrantType1Allowed or allowedCG-List is missing on the bearer it was dimensioned for.

9. Check `logicalChannelGroup` against `priority`. LCP does not use LCG, but the BSR does, and a scheduler that cannot see the difference between two channels will grant the wrong shape of resource for both.

10. On Rel-16 and later, check for de-prioritised PDUs. A HARQ process with a retransmission and no initial transmission is lch-BasedPrioritization working, not a fault (§12).

18. Glossary

priority

lch-BasedPrioritization

19. References

• 3GPP TS 38.321 -- NR MAC protocol specification. Clause 5.4.3.1 (Logical channel prioritisation, the Bj update and the three rounds), 5.4.3.1.2 (selection of logical channels -- the restrictions), 5.4.3.1.3 (multiplexing of MAC CEs and MAC SDUs -- the priority list), 5.4.3.2 (multiplexing and assembly), 5.4.2 (uplink grant reception and prioritisation between overlapping grants), 5.4.4 (Scheduling Request), 5.4.5 (Buffer Status Reporting), 6.1.2 (the MAC PDU LCP produces).
• 3GPP TS 38.331 -- RRC protocol specification. LogicalChannelConfig and ul-SpecificParameters, RLC-BearerConfig, MAC-CellGroupConfig (lch-BasedPrioritization, bsr-Config), ConfiguredGrantConfig (phy-PriorityIndex).
• 3GPP TS 38.322 -- NR RLC protocol specification. Clause 5.2 (segmentation and reassembly), 5.5 (data volume calculation -- the "data available for transmission" that LCP consumes).
• 3GPP TS 38.323 -- NR PDCP protocol specification. Clause 5.10 (data volume calculation), and PDCP duplication, which is what allowedServingCells exists for.
• 3GPP TS 38.214 -- Physical layer procedures for data. Clause 5.1.3.2 and 6.1.4.2 (transport block size determination), clause 6.1 (PUSCH duration, which maxPUSCH-Duration gates on).
• 3GPP TS 23.501 -- System architecture for the 5G System. Clause 5.7 and Table 5.7.4-1 (5QI characteristics: resource type, priority level, packet delay budget, packet error rate).
• 3GPP TS 38.300 -- NR overall description. Clause 12 (QoS architecture: QoS flow to DRB mapping), clause 6.2 (MAC services).

Companion documents in this set

• 05 HARQ -- the buffer semantics behind a de-prioritised MAC PDU, and the retransmissions that consume a channel's allocation.
• 06 Channel Mapping -- where a logical channel identity comes from and what DCCH, DTCH and CCCH mean.
• 07 MAC PDU and Control Elements -- the subPDU and subheader formats whose overhead the arithmetic in §7 accounts for, and every control element in the priority list of §10.
• 08 Scheduling -- the other half of the story: who decides the transport block size that LCP then divides.
• 10 BSR, PHR, SR -- how the network learns what to grant, the logical channel group mapping, and the reports that outrank data in §10.
• 11 DRX -- the wake/sleep cycle that determines how full the buckets are when a grant arrives (§9).
• 15 RRC Procedures -- where LogicalChannelConfig is signalled and reconfigured.