<!-- title: NR LCP令牌桶与BSR博弈 -->
<!-- domain: ran -->

# 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相关参数：

| 参数 | 全称 | 取值范围 | 功能说明 |
|------|------|---------|---------|
| **priority** | Logical Channel Priority | 1~28（1最高） | 决定逻辑信道的服务顺序 |
| **PBR** | Prioritised Bit Rate | 0~∞ kBps | 令牌桶注入速率，保障最低带宽 |
| **BSD** | Bucket Size Duration | 20ms~1280ms | 令牌桶深度 = PBR × BSD |
| **allowedSCS-List** | Allowed Subcarrier Spacing | {15,30,60,120}kHz | 限制可用的SCS |
| **allowedServingCells** | Allowed Serving Cells | Cell ID列表 | 限制可用的小区 |
| **allowedCG-List** | Allowed Configured Grant | CG索引列表 | 限制可用的配置授权 |
| **LCG ID** | Logical Channel Group ID | 0~7 | BSR报告分组 |

```mermaid
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资源全部分配给有数据的逻辑信道。

```mermaid
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在以下三种情况下被触发：

| 触发类型 | 条件 | 精确描述 |
|---------|------|---------|
| **Regular BSR** | 新数据到达空缓存 | 当属于某个LCG的逻辑信道有新数据到达，且该逻辑信道的优先级**高于**同一LCG内任何已有数据的逻辑信道 |
| **Regular BSR** | 定时器超时 | **retxBSR-Timer**超时，且该LCG有数据待发 |
| **Periodic BSR** | 定时器超时 | **periodicBSR-Timer**超时 |
| **Padding BSR** | MAC PDU填充 | MAC PDU组装后仍有剩余空间，可容纳BSR MAC CE |

```mermaid
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格式：

| 格式 | 长度 | 结构 | 适用场景 |
|------|------|------|---------|
| **Short BSR** | 3字节 | LCG ID(3bit) + Buffer Size(5bit) | 单个LCG报告 |
| **Long BSR** | 4+字节 | LCG bitmap + 多个Buffer Size | 多个LCG同时报告 |
| **Short Truncated BSR** | 3字节 | 格式同Short BSR | 资源不足时截断报告 |
| **Long Truncated BSR** | 4+字节 | 格式同Long BSR | 资源不足时截断报告 |

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

| Buffer Size Index | 缓存字节范围 | 粒度 |
|-------------------|------------|------|
| 0 | BS = 0 | 精确 |
| 1 | 1~10 | 10字节 |
| 2 | 11~16 | 6字节 |
| 10 | 134~167 | ~33字节 |
| 20 | 2500~3163 | ~66字节 |
| 31 | >150000 | 极粗 |

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

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

### 3.1 URLLC与eMBB的资源争夺

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

| 配置项 | URLLC DRB (LCID 3) | eMBB DRB (LCID 4) |
|--------|-------------------|-------------------|
| priority | 3 | 8 |
| PBR | 256 kBps | 8 kBps |
| BSD | 20 ms | 320 ms |
| 令牌桶容量 | 256×20 = 5120 bit = 640 Byte | 8×320 = 2560 bit = 320 Byte |

**关键博弈**：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无法区分不同业务的缓存需求

```mermaid
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**

| 字段 | Short BSR (LCID 61) | Long BSR (LCID 62) |
|------|--------------------|--------------------|
| LCID | 61 | 62 |
| 第一字节 | LCG ID(3bit) + Buffer Size(5bit) | LCG Bitmap(8bit) |
| 后续字节 | 无 | 每个活跃LCG一个Buffer Size(1字节) |

**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](https://www.3gpp.org/DynaReport/38321.htm) — 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](https://www.3gpp.org/DynaReport/38331.htm) — LogicalChannelConfig, MAC-CellGroupConfig
3. [ShareTechnote — NR MAC LCP](https://www.sharetechnote.com/html/5G/5G_MAC_LCP.html) — LCP过程图解与参数说明
4. [Ericsson Technology Review — 5G NR MAC Layer Design](https://www.ericsson.com/en/reports-and-papers/ericsson-technology-review) — 运营商级MAC层配置实践
5. [3GPP TS 38.214 V19.x.x — NR Physical layer procedures for data](https://www.3gpp.org/DynaReport/38214.htm) — 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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)