NR LCP令牌桶与BSR博弈：MAC层资源分配的暗战

引言：为什么LCP是5G QoS的"守门人"

在5G NR系统中，当一个UE被调度获得PUSCH资源时，上行数据该发哪个逻辑信道？发多少？这不是简单的"先到先得"，而是一套精密的令牌桶优先级调度机制——Logical Channel Prioritization（LCP）。TS 38.321 Section 5.4.3定义的LCP过程，决定了eMBB、URLLC、VoNR等差异化业务如何在共享的PUSCH资源上公平而高效地竞争。与此同时，BSR（Buffer Status Report）作为UE向gNB报告缓存状态的唯一信令，其触发时机和报告格式直接决定了调度器的资源分配精度。LCP与BSR的联动，是理解5G QoS保障在MAC层落地实施的钥匙。

一、LCP过程的完整机制拆解

1.1 核心参数：每个逻辑信道的"身份证"

根据TS 38.321 Section 5.4.3.1，每个逻辑信道（除LCID 0和1）通过RRC信令配置以下LCP相关参数：

graph TD
    subgraph "逻辑信道配置参数体系"
        A[LCID 2: SRB2] --> A1[priority: 1]
        A --> A2[PBR: infinity]
        A --> A3[BSD: infinity]

        B[LCID 3: DRB-URLLC] --> B1[priority: 3]
        B --> B2[PBR: 256 kBps]
        B --> B3[BSD: 80 ms]

        C[LCID 4: DRB-eMBB] --> C1[priority: 8]
        C --> C2[PBR: 8 kBps]
        C --> C3[BSD: 320 ms]

        D[LCID 5: DRB-IMS] --> D1[priority: 5]
        D --> D2[PBR: 64 kBps]
        D --> D3[BSD: 100 ms]
    end

    subgraph "令牌桶模型"
        E[令牌注入速率 = PBR]
        F[桶容量 Bj = PBR × BSD]
        G[数据到达消耗令牌]
        E --> F
        F --> G
    end

1.2 令牌桶模型的数学本质

令牌桶的核心思想是：每个逻辑信道维护一个虚拟令牌桶Bj，以PBR速率持续注入令牌，桶容量上限为PBR×BSD。

令牌桶状态Bj在每个TTI更新：

Bj = min(Bj + PBR × TTI_duration, PBR × BSD)

当逻辑信道j被服务时，实际传输的数据量Rj从Bj中扣除：

如果 Rj ≤ Bj:  Bj = Bj - Rj  （令牌充足，正常服务）
如果 Rj > Bj:  Bj = 0         （令牌耗尽，超额部分不计入令牌桶）

设计意图：PBR保障每个逻辑信道的最低带宽——即使高优先级逻辑信道耗尽了资源，低优先级逻辑信道累积的令牌也能确保其PBR速率的数据被发送。BSD控制"容忍的突发时长"——URLLC的BSD通常很小（如20ms），因为URLLC需要持续低延迟；eMBB的BSD可以较大（如320ms），容忍较大的数据突发。

1.3 LCP两轮分配算法详解

TS 38.321 Section 5.4.3.2定义了LCP的两轮分配过程。这是理解MAC层资源分配的核心算法：

第一轮：令牌桶约束的优先级服务

按优先级从高到低遍历逻辑信道，对每个逻辑信道j： - 如果Bj > 0，分配资源给该逻辑信道，最多分配min(Bj, 剩余PUSCH容量, 逻辑信道待发数据量) - 从Bj中扣除已分配的数据量 - 当某个优先级下所有逻辑信道的Bj都耗尽时，进入下一优先级

第二轮：剩余资源的贪婪分配

按优先级从高到低再次遍历，不考虑令牌桶约束，将剩余PUSCH资源全部分配给有数据的逻辑信道。

sequenceDiagram
    participant UE as UE MAC层
    participant LCH as 逻辑信道队列
    participant TB as 令牌桶
    participant PUSCH as PUSCH资源

    Note over UE,PUSCH: 调度授权到达，PUSCH容量 = C bytes

    UE->>TB: 更新所有Bj = min(Bj + PBR×TTI, PBR×BSD)

    rect rgb(200, 230, 255)
        Note over UE,PUSCH: 第一轮：令牌桶约束分配
        loop 按priority从1到28
            UE->>LCH: 查询逻辑信道j待发数据量 RRC_data_j
            UE->>TB: 检查Bj > 0?
            alt Bj > 0 且 有数据
                TB-->>UE: 允许分配 grant_j = min(Bj, RRC_data_j, 剩余C)
                UE->>PUSCH: 分配grant_j字节
                UE->>TB: Bj = Bj - grant_j
            else Bj ≤ 0
                TB-->>UE: 跳过此逻辑信道
            end
        end
    end

    rect rgb(255, 230, 200)
        Note over UE,PUSCH: 第二轮：贪婪分配（忽略令牌桶）
        loop 按priority从1到28
            UE->>LCH: 查询逻辑信道j剩余数据量
            alt 有剩余数据
                UE->>PUSCH: 分配min(剩余数据, 剩余C)
            end
        end
    end

    UE->>UE: 构建MAC PDU，填充MAC CE（BSR/PHR）

二、BSR触发机制与报告格式全解析

2.1 BSR的三种触发条件

根据TS 38.321 Section 5.4.5，BSR在以下三种情况下被触发：

stateDiagram-v2
    [*] --> NoBSR: 无数据待发

    NoBSR --> RegularBSR_Triggered: 高优先级新数据到达<br/>(空缓存 → 有数据)
    NoBSR --> RegularBSR_Triggered: retxBSR-Timer超时<br/>且有数据待发

    state "RegularBSR_Triggered" as RBT {
        [*] --> WaitingSR
        WaitingSR --> SR_Sent: 发送SR请求PUSCH
        SR_Sent --> BSR_Sent: 获得PUSCH授权<br/>发送BSR MAC CE
        BSR_Sent --> [*]: 重启periodicBSR-Timer<br/>重启retxBSR-Timer
    }

    NoBSR --> PeriodicBSR_Triggered: periodicBSR-Timer超时

    state "PeriodicBSR_Triggered" as PBT {
        [*] --> Send_PBSR
        Send_PBSR --> [*]: 在下一个PUSCH中发送
    }

    RBT --> NoBSR: BSR发送完成
    PBT --> NoBSR: BSR发送完成

2.2 BSR报告格式与LCG映射

TS 38.321 Section 6.1.3.1定义了四种BSR MAC CE格式：

Buffer Size字段的量化表（5bit，32级）是关键——它使用非线性映射，小缓存区间粒度更细，大缓存区间粒度更粗：

设计意图：非线性量化降低了信令开销（5bit代替32bit精确值），同时保证小缓存场景的精度——这对URLLC等小包业务至关重要。量化误差在小缓存时小于10%，在大缓存时可能超过50%，但大缓存通常对应eMBB业务，调度精度要求相对宽松。

三、LCP与BSR的联动博弈：运营商视角

3.1 URLLC与eMBB的资源争夺

考虑一个典型的URLLC+eMBB共传场景：

关键博弈：URLLC的PBR高（256kBps）但BSD小（20ms），意味着令牌桶每20ms清空一次，不容忍长时间等待。eMBB的PBR低（8kBps）但BSD大（320ms），令牌可以累积320ms的量（320 Byte），形成较大的突发容忍度。

运营商配置策略： - 保守策略（移动）：URLLC的PBR设高（如512kBps），确保第一轮分配就能满足URLLC需求；eMBB的PBR设低（如4kBps），大量资源留给第二轮贪婪分配 - 激进策略（电信）：URLLC和eMBB都给较高的PBR，通过priority差来保证顺序，减少第二轮分配的不确定性 - 成本影响：保守策略的URLLC保障更可靠，但PUSCH利用率可能较低；激进策略利用率高，但URLLC峰值时可能挤占eMBB

3.2 LCG分组策略对BSR精度的影响

TS 38.321将逻辑信道映射到最多8个LCG（Logical Channel Group）。LCG的分组策略直接影响BSR报告的精度和调度效率：

策略A：按QoS特征分组（推荐） - LCG 0: SRB（信令承载） - LCG 1: URLLC DRB - LCG 2: eMBB DRB - LCG 3: IMS/VoNR DRB - 优势：gNB调度器能精确识别每类业务的缓存状态 - 开销：Long BSR可能需要4字节以上

策略B：按PDU Session分组 - 每个PDU Session一个LCG - 优势：与核心网QoS Flow一一映射 - 劣势：LCG数量可能不够（最多8个）

策略C：极简分组 - 所有DRB归入LCG 1 - 优势：Short BSR只需3字节，信令开销最小 - 劣势：gNB无法区分不同业务的缓存需求

graph LR
    subgraph "LCG分组策略对比"
        A["策略A: 按QoS分组<br/>BSR精度: ★★★★★<br/>信令开销: ★★★<br/>调度效率: ★★★★★"]
        B["策略B: 按会话分组<br/>BSR精度: ★★★★<br/>信令开销: ★★★★<br/>调度效率: ★★★★"]
        C["策略C: 极简分组<br/>BSR精度: ★★<br/>信令开销: ★<br/>调度效率: ★★"]
    end

    A -->|"推荐"| D[5G商用网络]
    B -->|"MEC场景"| E[边缘计算部署]
    C -->|"IoT海量连接"| F[mMTC场景]

四、实战抓包识别与故障排查

4.1 抓包识别要点

在MAC层抓包中识别LCP和BSR行为：

1. 识别BSR MAC CE

2. 识别Regular BSR触发

Regular BSR触发后，UE会先发送SR（Schedule Request）——在PUCCH Format 1上发送单bit SR。如果在sr-ProhibitTimer运行期间，SR不能重复发送。当sr-TransMax次SR都未获响应时，UE触发随机接入（RA）。

3. 通过BSR推测LCP行为

通过连续多个TTI的BSR值变化，可以反推LCP分配： - 如果某LCG的BSR持续下降，说明该LCG的逻辑信道正在被正常服务 - 如果某LCG的BSR不降反升，可能是PUSCH授权不足或LCP分配偏向了更高优先级的LCG

4.2 常见故障场景

场景1：URLLC上行延迟突增 - 现象：URLLC数据包上行延迟从5ms突增到50ms+ - 排查： 1. 检查BSR是否正常发送（retxBSR-Timer配置是否过长） 2. 检查SR是否被gNB正确接收（PUCCH SR资源是否冲突） 3. 检查LCP配置——URLLC的PBR是否过低，导致第一轮分配不足 4. 检查是否有更高优先级的SRB数据占用了PUSCH资源 - 根因：运营商常见配置错误是将retxBSR-Timer设为320ms甚至更长，URLLC在等待BSR重传期间无法获得调度

场景2：eMBB吞吐量异常低 - 现象：eMBB业务上行吞吐量远低于预期 - 排查： 1. 检查eMBB逻辑信道的PBR和BSD配置 2. 检查是否有高优先级逻辑信道（如IMS）持续占用PUSCH 3. 检查BSR是否将eMBB和IMS归入同一LCG，导致gNB调度器无法区分 - 根因：LCG配置不当，eMBB和URLLC共用LCG，gNB按总量调度但LCP内部优先保证URLLC

场景3：VoNR上行MOS分偏低 - 现象：VoNR通话质量差，上行MOS低于3.0 - 排查： 1. 检查IMS DRB的PBR是否覆盖EVS编码速率（如12.65kbps → PBR至少16kBps） 2. 检查BSD是否过短——语音包20ms一帧，BSD至少需要40ms以容忍调度延迟 3. 检查BSR的5bit量化误差——语音包较小（~32字节），如果量化粒度太粗，gNB可能低估了缓存需求

五、RRC配置参数全景

LCP和BSR的核心RRC参数定义在TS 38.331的LogicalChannelConfig和MAC-CellGroupConfig中：

关键定时器配置（MAC-CellGroupConfig）：

MAC-CellGroupConfig ::= SEQUENCE {
    schedulingRequestConfig        SchedulingRequestConfig,
    BSR-Config                     BSR-Config,
    PHR-Config                     PHR-Config OPTIONAL,
    ...
}

BSR-Config ::= SEQUENCE {
    periodicBSR-Timer    ENUMERATED {sf1, sf5, sf10, sf16, sf20, sf40,
                                      sf80, sf128, sf256, sf320, sf640,
                                      sf1280, sf2560, infinity},
    retxBSR-Timer        ENUMERATED {sf10, sf20, sf40, sf80, sf160, sf320,
                                      sf640, sf1280, sf2560, infinity},
    logicalChannelSR-DelayTimer  BOOLEAN OPTIONAL,
    logicalChannelSR-Mask        BOOLEAN OPTIONAL,
    ...
}

逻辑信道配置（LogicalChannelConfig）：

LogicalChannelConfig ::= SEQUENCE {
    allowedSCS-List          SEQUENCE OF SubcarrierSpacing OPTIONAL,
    allowedServingCells      SEQUENCE OF ServCellIndex OPTIONAL,
    allowedCG-List           SEQUENCE OF ConfiguredGrantConfigIndex OPTIONAL,
    logicalChannelGroup      INTEGER (0..7),
    logicalChannelSR-Mask    BOOLEAN,
    logicalChannelSR-DelayTimerApplied BOOLEAN,
    prioritisedBitRate       ENUMERATED {kBps0, kBps1, ..., kBpsInfinity},
    bucketSizeDuration       ENUMERATED {ms5, ms10, ms20, ms50, ms80, 
                                          ms100, ms150, ms200, ms300, 
                                          ms500, ms750, ms1000, ms1280},
    ...
}

六、LCP扩展：MAC CE优先级与资源分配顺序

TS 38.321 Section 5.4.3.2还规定了MAC CE在MAC PDU中的优先级——这是一个容易被忽视但实战中极为重要的细节：

MAC PDU组装优先级（从高到低）：

1. C-RNTI MAC CE 或 UE Contention Resolution Identity MAC CE
2. BSR MAC CE（除Padding BSR）
3. PHR MAC CE、Configured Grant Confirmation等
4. 来自逻辑信道的数据（按LCP过程分配）
5. Padding BSR MAC CE

设计意图：MAC CE优先于数据——因为C-RNTI CE用于竞争解决（RA场景），BSR用于告知gNB缓存状态（影响后续调度），这些控制信息比数据更重要。这也意味着如果一个小的PUSCH授权到达，可能全部被MAC CE占用，数据一个字节都发不出去。

实战影响：在RRC重配置场景中，UE可能需要发送RRC重配完成消息（SRB1），如果同时还有BSR要发，PUSCH资源分配顺序为：C-RNTI CE → BSR → SRB1数据 → 其他DRB数据。对于极小的PUSCH授权（如窄带调度），可能出现SRB1消息都无法完整发送的情况。

常见问题

Q1: Regular BSR和Periodic BSR的区别是什么？ A: Regular BSR是事件触发的——当更高优先级的新数据到达时立即触发，确保gNB能及时调度；Periodic BSR是定时触发的——periodicBSR-Timer超时时触发，作为保底机制确保gNB定期获知缓存状态。Regular BSR触发后会发送SR请求PUSCH资源，Periodic BSR在已有PUSCH资源时直接携带。

Q2: Truncated BSR什么时候使用？ A: 当MAC PDU的剩余空间不足以容纳完整的Long BSR MAC CE时（需要报告多个LCG但空间只够报告部分），UE使用Truncated BSR。此时UE优先报告最高优先级逻辑信道所在的LCG的缓存状态。

Q3: 为什么SRB（LCID 0/1）不参与LCP过程？ A: TS 38.321规定SRB的优先级始终最高，PBR和BSD为infinity，且不参与令牌桶计算。SRB数据在任何逻辑信道数据之前被服务——这是设计选择，确保RRC信令（如切换命令、重配置消息）始终能及时传输。

Q4: allowedSCS-List和allowedServingCells参数如何影响LCP？ A: 这两个参数限制了逻辑信道可以在哪些时频资源上传输。例如，URLLC DRB可以配置allowedSCS-List = {120kHz}，只允许在120kHz SCS的BWP上传输，确保低延迟；eMBB DRB可以配置allowedServingCells限制只在主小区传输，避免CA场景下的额外调度复杂性。

Q5: BSR的5bit量化误差如何影响URLLC调度？ A: URLLC典型包大小为32~200字节，对应BSR表Index 2~6，量化粒度为6~20字节。对于32字节的URLLC包，BSR报告可能显示为28~40字节的范围（Index 2~3），gNB按40字节调度是安全的。但如果多个URLLC包同时到达，量化误差可能累积——100字节可能被量化为84~109字节，gNB按84字节调度就不足了。这就是为什么URLLC场景建议使用更频繁的BSR报告（短periodicBSR-Timer）。

参考来源

1. 3GPP TS 38.321 V19.x.x — NR MAC protocol specification — Section 5.4.3 (LCP), Section 5.4.5 (BSR), Section 6.1.3.1 (BSR MAC CE)
2. 3GPP TS 38.331 V19.x.x — NR RRC protocol specification — LogicalChannelConfig, MAC-CellGroupConfig
3. ShareTechnote — NR MAC LCP — LCP过程图解与参数说明
4. Ericsson Technology Review — 5G NR MAC Layer Design — 运营商级MAC层配置实践
5. 3GPP TS 38.214 V19.x.x — NR Physical layer procedures for data — PUSCH资源分配与调度约束

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。