• 逻辑信道 Bj 值更新流程
  • 1. Bj 的定义
  • 2. RRC 配置参数
  • 3. Bj 更新流程
    • 3.1 初始化（Bj = 0）
    • 3.2 LCP 过程前的递增（Bj 增加）
    • 3.3 LCP 资源分配
      • 第一轮：PBR 保证速率阶段
      • 第二轮：严格优先级阶段（所有信道参与，不限 Bj）
    • 3.4 PBR = infinity 的特殊处理
    • 3.5 NOTE 1 “Bj can be negative” 的含义
  • 4. 完整流程图
  • 5. 完整两轮 LCP 推演（三信道，初始 Bj = 0）
    • 5.1 初始参数
    • 5.2 逐步推演
    • 5.3 结果分析
  • 6. 后续 LCP 的延续推演
    • 6.1 第二次 LCP
    • 6.2 观察
  • 7. Bj 为负的场景（MAC 组包开销导致）
    • 7.1 场景设定
    • 7.2 推演
    • 7.3 观察
  • 8. 高优先级 PBR 过大对低优先级的影响
    • 8.1 问题
    • 8.2 协议防护：第一轮 Bj 上限约束
    • 8.3 推演
    • 8.4 结论
  • 9. 关键设计要点

博客地址

逻辑信道 Bj 值更新流程

基于 3GPP TS 38.321 V17.11.0 (2024-12)，第 5.4.3.1 节 Logical Channel Prioritization。

1. Bj 的定义

Bj 是 MAC 层为每个逻辑信道 j 维护的 UE 内部变量，用于 LCP（Logical Channel Prioritization）过程中的令牌桶（token bucket）机制。

2. RRC 配置参数

桶的最大容量 = PBR × BSD

3. Bj 更新流程

3.1 初始化（Bj = 0）

• 逻辑信道建立时：MAC 实体应将 Bj 初始化为 0。
• MAC 重置时（非 SCG 去激活导致）：将所有逻辑信道的 Bj 初始化为 0。

协议原文：

The MAC entity shall initialize Bj of the logical channel to zero when the logical channel is established.

1> if the MAC reset is not due to SCG deactivation: 2> initialize Bj for each logical channel to zero;

3.2 LCP 过程前的递增（Bj 增加）

在每个 LCP 过程实例之前，对每个逻辑信道 j 执行：

Bj = Bj + PBR × T

其中 T 是自上次 Bj 递增以来的时间间隔。

然后执行上限裁剪：

如果 Bj > PBR × BSD：
    Bj = PBR × BSD

协议原文：

1> increment Bj by the product PBR × T before every instance of the LCP procedure, where T is the time elapsed since Bj was last incremented;

1> if the value of Bj is greater than the bucket size (i.e. PBR × BSD): 2> set Bj to the bucket size.

NOTE: The exact moment(s) when the UE updates Bj between LCP procedures is up to UE implementation, as long as Bj is up to date at the time when a grant is processed by LCP.

3.3 LCP 资源分配

资源分配分两轮进行（5.4.3.1.3）：

第一轮：PBR 保证速率阶段

• 从 5.4.3.1.2 中选出的逻辑信道中，所有 Bj > 0 的信道按优先级从高到低依次分配资源
• 每个信道的分配量在逻辑上由 Bj 上限约束：发到 meet 自身 PBR（即 Bj 累积令牌量）后轮到下一个信道。这一约束并非协议明写，而是从 PBR=infinity 的例外条款反推得出（见下）
• 优先级高仅决定服务顺序（排在前面），不决定能拿多少——拿多少由 Bj 决定
• PBR = infinity 例外：该信道数据全部发完后，低优先级信道才能 meet 自身 PBR
• 分配完成后，对每个被服务的逻辑信道 j 递减 Bj：

Bj = Bj - 该逻辑信道 j 本次服务的 MAC SDU 总大小

正常流程下（PBR ≠ infinity），Bj 扣到 0 为止，不会为负。

第二轮：严格优先级阶段（所有信道参与，不限 Bj）

• 第一轮结束后如还有剩余 grant，所有选中信道按严格优先级从高到低继续服务（无论 Bj 值如何）
• 直到该信道数据耗尽或 UL grant 耗尽
• 第二轮不递减 Bj

协议原文：

2> logical channels selected in clause 5.4.3.1.2 for the UL grant with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel is set to infinity, the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel(s);

2> decrement Bj by the total size of MAC SDUs served to logical channel j above;

2> if any resources remain, all the logical channels selected in clause 5.4.3.1.2 are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.

NOTE 1: The value of Bj can be negative.

3.4 PBR = infinity 的特殊处理

协议规定，PBR 设为 infinity 的逻辑信道在第一轮中享有特权：

If the PBR of a logical channel is set to infinity, the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel(s);

这意味着该信道在第一轮中将所有待传数据发完后，低优先级信道才有机会 meet 自身 PBR。

关于 Bj：PBR=infinity 时，Bj 的递增（PBR×T=∞）和上限裁剪（PBR×BSD=∞）都导致 Bj 始终为 infinity。infinity 减去任何有限服务量仍为 infinity，不会变负。NOTE 1 的 “Bj can be negative” 不适用于此场景。

3.5 NOTE 1 “Bj can be negative” 的含义

正常流程下（PBR ≠ infinity），第一轮每信道受 Bj 上限约束，Bj 扣到 0 为止，不会为负。NOTE 1 覆盖的是以下边缘场景：

NOTE 1 是给实现兜底的——”Bj 变几个字节的负数不算 bug”——而非描述主流程。

4. 完整流程图

逻辑信道建立 / MAC重置
        │
        ▼
    Bj = 0  ←── 初始化
        │
        ▼
┌───────────────────────────────┐
│  每次 LCP 过程前（递增）        │
│  Bj += PBR × T                │
│  Bj = min(Bj, PBR × BSD)      │
└───────────────┬───────────────┘
                │
                ▼
┌─────────────────────────────────────┐
│  第一轮：PBR 保证速率（Bj 上限约束）   │
│  按优先级依次服务 Bj>0 的信道         │
│  每信道最多发 Bj，Bj 扣到 0          │
└───────────────┬─────────────────────┘
                │ grant 有剩余
                ▼
┌─────────────────────────────────────┐
│  第二轮：严格优先级（不限制，不减 Bj）  │
│  剩余 grant 按优先级分配             │
│  直到数据耗尽或 grant 用完           │
└─────────────────────────────────────┘
                │
                ▼
          等待下次 LCP
          (Bj 继续累积 PBR×T)

5. 完整两轮 LCP 推演（三信道，初始 Bj = 0）

5.1 初始参数

UL Grant = 15000 bits，所有信道初始 Bj = 0。

5.2 逐步推演

5.3 结果分析

五点观察：

1. 第一轮人人有份：每个 Bj>0 的信道都能拿到自己的 Bj 份额（200/100/80 bits），优先级决定服务顺序而非独占权。
2. 第一轮 Bj 扣到 0 为止：不会透支、不会为负。
3. 第二轮 grant 充裕（14620 bits），非常活跃：剩余 grant 远超第一轮消耗（380 bits），第二轮是主战场。
4. 第二轮才体现优先级差距：LC1 优先拿走 9800 清空数据，LC2 捡漏 4820，LC3 颗粒无收。
5. 低优先级在第一轮不会被饿死：LC3 即使优先级最低，第一轮也有 80 bits 保证份额。

6. 后续 LCP 的延续推演

承接上例，第二次 LCP 前 LC1 数据已清空、LC2 剩 2080 bits、LC3 剩 5920 bits。新数据到达：LC1 新增 3000 bits 待传。

6.1 第二次 LCP

三信道数据全部清空，grant 还剩 4000 bits，可用于 padding BSR 或填充。

6.2 观察

两次 LCP 全部以 Bj=0 结束，所有信道的第一轮 Bj 都被授予且被消费干净。第二轮在两次 LCP 中都承担了大部分数据发送——第二轮才是实际数据搬运的主战场，第一轮只负责保障每个信道不低于 PBR 对应的速率底线。

7. Bj 为负的场景（MAC 组包开销导致）

7.1 场景设定

上次 LCP 中，LC1 的 Bj=200，但因 RLC 分段 + MAC subheader 的实际组包粒度，最终发出了 215 bits，导致 Bj = 200 - 215 = -15。本次 LCP 时，LC1 新增了大量数据到达。

UL Grant = 12000 bits

7.2 推演

7.3 观察

1. Bj 轻微负数不构成实质惩罚：-15 经过一次递增（+200）立即回正为 185，LC1 顺利进入第一轮。只有深度负值（几百以上）才会导致真正”禁赛”。
2. 第一轮 Bj 恢复到正常上限约束：LC1 进入第一轮后严格按 Bj=185 服务，扣到 0。
3. 第二轮仍旧活跃：8715 bits grant 留给第二轮按优先级分配。
4. MAC overhead 导致的负数被递增快速覆盖，这正是协议设计的意图——”Bj can be negative” 只是一个过渡态，不影响整体公平性。

8. 高优先级 PBR 过大对低优先级的影响

8.1 问题

如果 PBR 给高优先级配置得很大，同时该 LC 有大量待发数据，低优先级 LC 是否一直无法发送？

8.2 协议防护：第一轮 Bj 上限约束

因为第一轮每信道最多发 Bj（PBR 累积令牌），高优先级 LC 无法”一口吃光” grant。推演如下：

UL Grant = 15000 bits（每次 LCP 均相同）

两信道 Bj 均已累积至各自桶容量上限，模拟高优先级长期”满桶”的场景。

8.3 推演

8.4 结论

即使 LC1 的 Bj 高达 200000（PBR=2000kbps, BSD=100ms），第一轮一次 LCP 最多拿 min(Bj, grant) = 15000 bits，扣完后 Bj = 185000。Bj 会在每轮消耗中逐步下降：每次 LCP 净减少 15000-2000=13000，约 15~16 次 LCP 后 Bj 扣到 ≤0，届时 LC1 退出第一轮，LC2 自动获得第一轮排他资格。

第一轮 Bj 上限约束本身就是防饥饿的核心设计。 低优先级在第一轮的保障不靠”透支-禁赛”的跨轮次轮换（那是 Bj 负值边缘场景的补救），而是靠 Bj 上限在本轮内为每个信道强制预留份额。

9. 关键设计要点