看看协议中是如何描述Buffer Status Reporting的？

以一个实网中的异常场景开始，大概流程是有UL data要发送，UE触发BSR->no UL grant->SR->no UL grant->trigger RACH->RACH fail->RLF->RRC reestablishment：简单描述就是UE触发BSR，此时没有UL grant，之后触发SR，仍然没有 UL grant，之后触发RACH，RACH fail引起RLF，引起RRC reestablishment；这个异常场景在弱信号情况下比较常见，其中涉及的具体内容其实是比较多的，这篇就看下BSR的内容，BSR 的内容主要在38.321 5.4.5章节。

开始之前简单看下BSR和SR的区别：UE通过SR向gNB请求上行资源时，只指明了UE有上行数据需要发送，并没有指明需要发送的上行数据数量。而BSR的作用是将UE当前buffer中待发送的数据情况通知给gNB，gNB可根据BSR上报的UE buffer的数据量，给UE分配上行资源；换个角度看，UE发BSR时，是通过BSR MAC CE，既然能发BSR，肯定是有UL grant，足够发BSR，如果没有UL grant，UE要通过SR向gNB要UL grant，进而UE就要发送SR。接下来看看协议中是如何描述BSR的。

BSR相关的RRC层参数如下

logicalChannelSR-Mask：在配置configured uplink grant of type1 or type2 时用于控制SR 的触发。True代表对应logical channel有配置SR masking。

logicalChannelSR-DelayTimerApplied：用于指示是否对logical channel 应用SR 传输的delay timer;设置为false的话，BSR-Config中就不会包含logicalChannelSR-DelayTimer。

logicalChannelSR-DelayTimer：单位是subframe数，Value sf20 代表20 subframes, sf40 代表40 subframes,以此类推；该timer的作用顾名思义，就是在run期间不能触发SR。

periodicBSR-Timer：单位是subframe数， Value sf1 代表1 subframes, sf5 代表5 subframes,以此类推。

retxBSR-Timer：单位是subframe数， Value sf10 代表10 subframes, sf20 代表20 subframes,以此类推。

logicalChannelGroup：logical channel group的ID, 代表logical channel 对应的LCG ID。

说到参数LCG ID，那就顺带看下LC 和LCG的关系。实网下根据业务的不同，UE可能建立很多RB，如果为每一个逻辑信道(LC)上报一个BSR，会带来大量的信令开销。为了减少这种开销，和LTE相同，NR引入了逻辑信道组（LCG）的概念，不同的是，NR将LCG个数由LTE的4个扩展到了8个，以满足NR系统更多样的业务场景。所以UE是基于LCG上报BSR，而不是为每个逻辑信道上报一个BSR。而逻辑信道的分组是gNB的算法，逻辑信道分组也是为了提供更好的BSR上报机制，一般会将有相似调度需求的逻辑信道放入同一LCG中。例如将相同QCI/priority的逻辑信道放入同一LCG。如下图logical channel 4/2 分别对应的是LCG 7/0。

既然UE的LCG和逻辑信道的配置是由gNB控制的，那gNB就知道每个LCG包含哪些逻辑信道以及这些逻辑信道的优先级。虽然gNB无法知道一个单独的逻辑信道的缓存状态，但由于同一LCG中的逻辑信道有着类似的QoS/priority需求，所以基于LCG上报BSR也可以在一定程度上满足业务的QoS需求。

下面是38.321中BSR的内容。

BSR是用于向serving gNB 提供 MAC entity中的 UL data volume信息的过程，之后gNB根据BSR 中的UL data volume及自身loading，向UE下发对应的UL grant，用于UE UL 传输。

与BSR相关的几个RRC层参数分别是periodicBSR-Timer；retxBSR-Timer；logicalChannelSR-DelayTimerApplied；logicalChannelSR-DelayTimer；logicalChannelSR-Mask；logicalChannelGroup。

每个logical channel 可以使用 logicalChannelGroup 分配到一个 LCG。LCG 的最大数量为八个。更具体的，MAC entity是根据 RLC和 PDCP中的data volume计算过程确定logical channel可用的 UL 数据量，用于BSR的上报。

BSR 触发场景（BSR的分类）

(1)属于某个LCG的逻辑信道的有UL data要发送 ，并且该 UL data对应逻辑信道的优先级高于任何其他LCG有UL data要发送的逻辑信道的优先级或

当所有LCG 逻辑信道都没有UL data要发送时，某个LCG的逻辑信道有UL data要发送，在这种情况下触发的BSR叫做 regular BSR；

(2)为了避免UE发送了BSR却一直没有收到UL grant的情况，gNodeB为UE配置了一个retxBSR-Timer定时器，当retxBSR-Timer 超时并且某个LCG的至少一个逻辑信道有UL data要发送，在这种情况下触发的BSR也称为Regular BSR，目的是使得UE周期性地向gNB更新Buffer Status；

(3)考虑到当regular BSR、padding BSR的触发条件都不满足时，网络侧也能知道UE的buffer status，以便后续为UE分配适当UL grant，定义了在periodicBSR-Timer 超时，在这种情况下触发的BSR称为Periodic BSR。

(4)UL grant给多了，UL数据组包接收后，还有剩余bits没用完，就要在对应的资源上加padding(MAC需要用 0 来填充)，那padding bits数大于等于BSR MAC CE 加上其subheader的大小时,触发的BSR叫做 padding BSR；

当多个逻辑信道同时触发Regular BSR时，每个逻辑通道各自触发一个独立的Regular BSR，最后UE根据LCG 确定具体的buffer上报BSR。接下来看下BSR MAC CE的结构。

BSR MAC CE

如开头所述，为提高空口效率，BSR并不是为每个LC绑定一个BSR，而是为每个LCG绑定一个BSR，上报时以LCG为单位上报，如上图的LCG ID用于区分BSR。

BSR MAC CE包含的类型分别是Short BSR/Long BSR/Short Truncated BSR/Long Truncated BSR，分别通过LCID 59～62进行区分。Pre-emptive BSR MAC CE用于IAB场景，不在本篇内容之内。

四种BSR MAC CE的发送与BSR的类型优先序，padding BSR 根据场景的不同可以上报上述四种BSR MAC CE；而Regular BSR和Periodic BSR 只能上报Short BSR/Long BSR MAC CE,具体内容后面再说。

short BSR/short Truncated BSR MAC CE

short BSR和short Truncated BSR MAC CE的结构如上，分别由3 bits的LCG ID及5 bits的Buffer size组成，其中LCG ID对应的是BSR 上报的LCG id；

Buffer size代表PDCP和RLC的data volume 单位是bytes，其中RLC header和MAC subheader不在buffer size的计算范围内。

short BSR和short Truncated BSR MAC CE的Buffer size为5bits，对应0～31个value，分别代表不同的buffer size value，对应如下。

例如上报的Buffer size index 为18 ，就代表buffer size 实际value在(2014,2806]bytes之间，之后网络侧根据实际loading，下发对应的UL grant即可。

long BSR/long Truncated BSR MAC CE

从MAC CE的结构看LCGi 对应LCG0～LCG7；对于long BSR,当LCGi=1时，代表LCG i的Buffer size field 会上报，也就是BSR MAC CE中会包含其Buffer size field， 当LCGi=0时，代表LCG i 不会有Buffer size field上报，即BSR MAC CE中不会有其Buffer size field。对于Long Truncated BSR，当LCGi=1时，代表LCG i 有pending size要发送， 当LCGi=0时，代表LCG i 没有pending size要发送，其实功能和long BSR类似。

long BSR/long Truncated BSR的Buffer size对应8bits，其Buffer size index范围是0254(255 reserved)，代表不同的bytes值。Buffer size field 以LCG i升序排列(LCG 07) 。对于long Truncated BSR，Buffer size的大小有限制，不能超过padding bits数。

由于NR可配置8个LCG，如果将8个LCG缓存数据的大小全部上报给gNB，即使一些LCG中没有缓存数据，也会造成资源浪费，因此在NR中设计了可变大小的BSR格式。结合上面的描述可以看出，short 和long BSR 的区别就是short BSR的大小是固定的，long BSR 大小可变；其中，Truncated BSR是在上行资源不足以上报 normal BSR时，向网络侧上报部分LCG的信息。

BSR 上报流程

Regulat BSR 和Periodic BSR

对于Regular BSR，如果有logical channel 触发了BSR且有配置logicalChannelSR-DelayTimerApplied=true，那MAC entity要start/restart logicalChannelSR-DelayTimer；其他情况，不需要开启logicalChannelSR-DelayTimer，logicalChannelSR-DelayTimer有在running就要停止。

对于Regular BSR和Periodic BSR，当多于一个LCG有UL data 要传输时，对于有UL data传输的所有LCGs要上报Long BSR;否则，只有一个LCG有UL data要传输， 就上报Short BSR。

Padding BSR

对于Padding BSR，对应padding bits大于等于short BSR+subheader的size但是小于long BSR+subheader的size时，

1 恰巧当前不止一个LCG有UL data传输时

1.1如果当前padding bits等于Short BSR+subheader，就report 有UL data要传输的最高优先级LC 的short Truncated BSR；

1.2 当padding bits大于short BSR+subheader的size但是小于long BSR+subheader的size，就根据LCG 中LC的优先级降序的顺序上报Long Truncated BSR(如果出现优先级相同的情况，就根据LCGID升序的顺序上报)。

2 如果只有一个LCG有UL data传输时，就上报Short BSR。

padding bits大于等于long BSR+subheader的size时，就上报包含所有有UL data传输的LCG long BSR。

BSR cancel

当UL grant 足以用于传输所有pending的data但不够额外容纳 BSR MAC CE 及其subheader时，可以取消所有触发的 BSR。当传输的MAC PDU包括long或short BSR MAC CE 时，应取消在 MAC PDU 组装之前触发的所有 BSR，因为此时的long或short BSR MAC CE对应的buffer status包含MAC PDU assembly之间触发的BSR内容。

其他规定

当前至少一个BSR被触发且还没有取消时，如果当前的UL grant足够发送BSR MAC CE+subheader，就发送当前的生成功的BSR MAC CE，启动或重启 periodicBSR-Timer(所有生成的 BSR 都是long或 short Truncated BSR时 不需要开启periodicBSR-Timer)，也要开启retxBSR-Timer。

当前至少一个BSR被触发且还没有取消时，logicalChannelSR-DelayTimer没有run且触发了Regualer BSR：

1 当前没有UL grant进行传输;

2 对于configured ul grant的场景，在logicalChannelSR-Mask=false时触发了regular BSR（比如configured ul grant场景配置的UL grant 不够了，也要通过SR去要UL grant）;

3 可用于新传输的 UL-SCH 资源不满足发送 经过LCP映射限制过程后的触发的BSR，意思就是触发BSR后得到的UL grant还是不够新传(LCP 过程其他篇再说);

上述情况就要触发SR，向网络侧要UL grant。

这里就是开篇 UE发送BSR后，没有收到UL grant 之后触发SR的理论依据。

即使多个事件已触发 BSR，一个MAC PDU最多应只能包含一个 BSR MAC CE。

Regular BSR 和Periodic BSR 的优先级高于padding BSR，对于由retxBSR-Timer超时触发的BSR，MAC entity 认为触发BSR的LC 的优先级是最高的。即retxBSR-Timer超时引起的BSR的LC要优先处理。

MAC entity应在收到在任何 UL-SCH上传输新数据的UL grant后重新启动retxBSR-Timer。

上面这段描述并没有特别强制的问题，就描述了下对应情况允许的做法，就列在这里做记录。

最后各个timer的汇总如下