本文摘自: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节