本文摘自：http://blog.sina.com.cn/s/blog_927cff010101ab3t.html
Buffer Status Report（BSR）
在前一篇博客（见《LTE：上行调度请求（Scheduling Request，SR）》）中已经介绍到，UE通过SR向eNodeB请求上行资源时，只指明了其是否有上行数据需要发送，而没有指明自己需要发送多少上行数据。UE需要通过BSR（Buffer Status Report）告诉eNodeB，其上行buffer里有多少数据需要发送，以便eNodeB决定给该UE分配多少上行资源。
根据业务的不同，UE可能建立大量的无线承载（radio bearer，每个bearer对应一个逻辑信道），如果为每一个逻辑信道上报一个BSR，会带来大量的信令开销。为了避免这种开销，LTE引入了LCG（Logical Channel Group）的概念，并将每个逻辑信道放入一个LCG（共4个）中。UE基于LCG来上报BSR，而不是为每个逻辑信道上报一个BSR。
某个逻辑信道所属的LCG是在逻辑信道建立时通过IE: LogicalChannelConfig的logicalChannelGroup字段来设置的 。
LogicalChannelConfig ::= SEQUENCE {
ul-SpecificParameters SEQUENCE {
priority INTEGER (1..16),
prioritisedBitRate ENUMERATED {
kBps0, kBps8, kBps16, kBps32, kBps64, kBps128,
kBps256, infinity, kBps512-v1020, kBps1024-v1020,
kBps2048-v1020, spare5, spare4, spare3, spare2,
spare1},
bucketSizeDuration ENUMERATED {
ms50, ms100, ms150, ms300, ms500, ms1000, spare2,
spare1},
logicalChannelGroup INTEGER (0..3) OPTIONAL -- Need OR
} OPTIONAL, -- Cond UL
...,
[[ logicalChannelSR-Mask-r9 ENUMERATED {setup} OPTIONAL -- Cond SRmask
]]
}
将逻辑信道分组是为了提供更好的BSR上报机制。将那些有相似调度需求的逻辑信道放入同一LCG中，并通过short BSR上报其buffer状态。
如何分组取决于eNodeB的算法实现（例如：将相同QCI/priority的逻辑信道放入同一LCG中）。即上行的QoS管理是由eNodeB负责管理的。
由于UE的LCG和逻辑信道的配置是由eNodeB控制的，所以eNodeB知道每个LCG包含哪些逻辑信道以及这些逻辑信道的优先级。虽然eNodeB无法知道一个单独的逻辑信道的buffer状态，但由于同一LCG中的逻辑信道有着类似的QoS/priority需求，所以基于LCG来上报buffer状态也可以使得上行调度提供合适的调度结果。
一、BSR MAC Control Element
BSR通过MAC层的BSR MAC Control Element上报，包含2种格式：
· Short BSR或Truncated BSR格式：只上报一个LCG的BSR。其格式由一个LCG ID域和一个对应的Buffer Size域组成。如图1所示
图1：Short BSR和Truncated BSR MAC control element
· Long BSR格式：包含了4个Buffer Size域，对应LCG ID 0~3。该格式会将所有LCG的Buffer Size一起上报给eNodeB。如图2所示
图2：Long BSR MAC control element
LCG ID域长为2 bit，指定了上报的buffer状态对应的LCG，其值与IE:LogicalChannelConfig 的logicalChannelGroup字段对应。
Buffer Size域长为6 bit，指定了UE在发送这个BSR的TTI内的所有MAC PDU都生成以后，对应LCG的所有逻辑信道的RLC层和PDCP层中剩余的可用于传输的有效数据的总和（见36.322的4.5节和36.323的4.5节）。该数据量以byte为单位，但不将RLC头部和MAC头部信息计算在内。
从36.321的6.1.3.1节可以看出，eNodeB收到BSR后，通过Buffer Size域得到一个index，再用这个index查Table 6.1.3.1-1或Table 6.1.3.1-2，可以得到UE真正需要发送的“近似”上行数据量。因为UE在发送BSR时，无法确定后续发送的上行数据中会有哪些RLC头部和MAC头部，所以计算时不将RLC头部和MAC头部信息计算在内。而从Table 6.1.3.1-1和Table 6.1.3.1-2可以看出，通过Buffer Size域得到的index对应的是一个Buffer Size的范围，而不是一个精确的Buffer Size，因此是一个“近似”上行数据量。
在载波聚合中，可能存在多个上行载波单元同时发送数据，BSR指示的数据量也可能远大于Rel-8中指示的数据量，因此在Rel-10中，LTE额外提供了一个BSR值的表（见36.321的Table 6.1.3.1-2）。具体使用Table 6.1.3.1-1还是Table 6.1.3.1-2是通过IE：MAC-MainConfig的extendedBSR-Sizes-r10字段来配置的。
一个BSR MAC control element与一个MAC subheader对应。BSR对应的MAC subheader中的LCID域如图3所示：（见36.321的Table 6.2.1-2）
图3：UL-SCH的所有LCID值
注意：LCID与LCG ID是不同的。LCID是用来唯一地指定MAC PDU中的一个MAC SDU或MAC control element或padding的。而LCG ID是用来指定逻辑信道所属的逻辑信道组ID的，只用于BSR上报。
二、BSR的触发方式
当如下事件发生时，将会触发BSR上报：
1、UE的上行数据buffer为空且有新数据到达：当所有LCG的所有逻辑信道都没有可发送的上行数据时，如果此时属于任意一个LCG的任意一个逻辑信道有数据变得可以发送，则UE会触发BSR上报。例如：UE第一次发送上行数据。该BSR被称为“Regular BSR”;
2、高优先级的数据到达：如果UE已经发送了一个BSR，并且正在等待UL grant，此时有更高优先级的数据（即该数据所属的逻辑信道【而不是LCG】比任意一个LCG的逻辑信道的优先级都要高）需要传输，则UE会触发BSR上报。该BSR被称为“Regular BSR”；
3、UE周期性地向eNodeB更新自己的buffer状态：eNodeB通过IE：MAC-MainConfig的periodicBSR-Timer字段为UE配置了一个timer（配置成”infinity”则去使能该timer），如果该timer超时，UE会触发BSR上报。例如：当UE需要上传一个大文件时，数据到达UE传输buffer的时间与UE收到UL grant的时间是不同步的，也就是说UE在发送BSR和接收UL grant的同时，还在不停地往上行传输buffer里填数据，因此UE需要不停地更新需要传输的上行数据量。该BSR被称为“Periodic BSR”；
4、为提高BSR的健壮性，LTE提供了一个重传BSR的机制：这是为了避免UE发送了BSR却一直没有收到UL grant的情况。eNodeB通过IE：MAC-MainConfig的retxBSR-Timer字段为UE配置了一个timer，当该timer超时且UE的任意一个LCG的任意一个逻辑信道里有数据可以发送时，将会触发BSR。该BSR被称为“Regular BSR”。
5、废物再利用：当UE有上行资源且发现需要发送的数据不足以填满该资源时，多余出来的bit会作为Padding bit而被填充一些无关紧要的值。与其用作padding bit，还不如用来传BSR这些有用的数据。所以当padding bit的数量等于或大于“BSR MAC control element + 对应的subheader”的大小时，UE会使用这些bit来发送BSR。该BSR被称为“Padding BSR”。
从上面的介绍可以看出，只有当某个逻辑信道属于某个LCG时，它的数据才会被统计到对应的BSR中并上报给eNodeB；对于不属于任一LCG的逻辑信道（logicalChannelGroup字段是OPTIONAL的），其数据不会被统计，不会影响任何BSR行为。
如果至少触发了一个BSR且该BSR没有被取消且UE已经在该TTI内收到了用于新传数据的UL grant，则UE会
· 生成BSR MAC control element；
· 除非所有生成的BSR均为Truncated BSR，否则UE会启动或重启periodicBSR-Timer；
· 启动或重启retxBSR-Timer；
当触发了Regular BSR，但UE没有足够的UL-SCH资源用于发送BSR时，UE会发送SR请求；而当触发了Periodic BSR或Padding BSR，但UE没有足够的UL-SCH资源用于发送BSR时，UE不会发送SR请求。
对于Regular和Periodic BSR而言，如果在该TTI内有多于1个LCG中有数据需要发送，则上报Long BSR；否则上报Short BSR。
对于Padding BSR而言，当padding bit的数量等于或大于“Short BSR +对应的subheader”的大小但小于“Long BSR + 对应的subheader”的大小时，如果在该TTI内有多于1个LCG中有数据需要发送，则将有数据要发送且优先级最高的逻辑信道所在的LCG的BSR上报给eNodeB，该BSR格式为Truncated BSR；如果该TTI内只有1个LCG有数据需要发送，则发送Short BSR。
对于Padding BSR而言，当padding bit的数量等于或大于“Long BSR + 对应的subheader”的大小时，发送Long BSR。
即使有多个事件触发了BSR，一个MAC PDU至多也只能包含一个MAC BSR control element（如果一个TTI内有多个MAC PDU，如在空分复用或载波聚合的情况下，则每个MAC PDU都能携带一个MAC control element）。其中Regular BSR和Periodic BRS的优先级要高于Padding BSR，即优先传输Regular/Periodic BSR。
当UE收到一个新传数据的UL grant时，都会重启retxBSR-Timer。
如果在某个子帧内收到的UL grant能够容纳UL buffer里的所有pending data，却不足以容纳额外的BSR MAC control element和其对应的subheader时，所有已经触发的BSR都会被取消。
当一个BSR包含在一个待传输的MAC PDU里时，所有已经触发的BSR都会被取消。
UE在每个TTI至多只能发送一个Regular/Periodic BSR。如果UE在一个TTI内需要发送多个MAC PDU，则它可以在任意一个不包含Regular/Periodic BSR的MAC PDU里携带一个padding BSR。
UE在一个TTI里传输的所有BSR反映的是这个TTI内的所有MAC PDU都生成以后的buffer状态。每个LCG在每个TTI内至多只能上报一个buffer状态值（注意：不是BSR）。假如UE在一个TTI内上报了多个BSR，且其中几个BSR都上报了同一个LCG的buffer状态，那么对应同一LCG的这些buffer状态值必须是相同的。
需要注意的是，一个Padding BSR是不允许取消那些已经触发的Regular/Periodic BSR的。Padding BSR只能为某个特定的MAC PDU而触发，且当这个MAC PDU生成后，该trigger就被取消了。
有意思的是，UE上报的BSR与UE如何处理UL grant没有直接的关系。UE是基于逻辑信道优先级给无线承载分配资源的，与逻辑信道属于哪个LCG没有任何关系。例如：某个 UE为了发送HTTP请求（假定该业务对应的逻辑信道属于LCG 2），已经发送了BSR。在UE收到对应UL grant之前，新出现了一个RRC消息。由于RRC消息对应的逻辑信道的优先级比HTTP请求对应的逻辑信道的优先级要高，所以当UE收到UL grant（该UL grant是因为HTTP请求才予以分配的）后，UE会将上行资源优先分配给RRC消息，而不是分配给HTTP请求。（具体流程可参考我以前发布的博文《LTE：MAC复用和逻辑信道优先级》）
注：1）CCCH、SRB1、SRB2默认属于LCG 0（在36.331中搜索logicalChannelGroup，能看出协议中是有明确说明的）；2）RRC消息在SRB上传输且SRB默认属于LCG 0，比LCG 2的优先级要高。
【参考资料】
[1] TS 36.300的11.3节
[2] TS 36.321的5.4.5和6.1.3.1节
[3] TS 36.331的periodicBSR-Timer、retxBSR-Timer、logicalChannelGroup
[4] 《Buffer Status Reports and Uplink Scheduling》 by John
[5] 《4G LTE/LTE-Advanced for Mobile Broadband》的13.2.2.2节
[6] 《LTE - The UMTS Long Term Evolution, 2nd Edition》的4.4.2.2节
0 0
