LTE:Buffer Status Report(BSR)

本文摘自:http://blog.sina.com.cn/s/blog_927cff010101ab3t.html

Buffer Status ReportBSR

      在前一篇博客(见《LTE:上行调度请求(Scheduling RequestSR》)中已经介绍到,UE通过SReNodeB请求上行资源时,只指明了其是否有上行数据需要发送,而没有指明自己需要发送多少上行数据。UE需要通过BSRBuffer Status Report)告诉eNodeB,其上行buffer里有多少数据需要发送,以便eNodeB决定给该UE分配多少上行资源。

      根据业务的不同,UE可能建立大量的无线承载(radio bearer,每个bearer对应一个逻辑信道),如果为每一个逻辑信道上报一个BSR,会带来大量的信令开销。为了避免这种开销,LTE引入了LCGLogical Channel Group)的概念,并将每个逻辑信道放入一个LCG(共4个)中。UE基于LCG来上报BSR,而不是为每个逻辑信道上报一个BSR

      某个逻辑信道所属的LCG是在逻辑信道建立时通过IE: LogicalChannelConfiglogicalChannelGroup字段来设置的 

 

 

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负责管理的。

      由于UELCG和逻辑信道的配置是由eNodeB控制的,所以eNodeB知道每个LCG包含哪些逻辑信道以及这些逻辑信道的优先级。虽然eNodeB无法知道一个单独的逻辑信道的buffer状态,但由于同一LCG中的逻辑信道有着类似的QoS/priority需求,所以基于LCG来上报buffer状态也可以使得上行调度提供合适的调度结果。

 

一、BSR MAC Control Element

      BSR通过MAC层的BSR MAC Control  Element上报,包含2种格式:

·        Short BSRTruncated BSR格式:只上报一个LCGBSR。其格式由一个LCG ID域和一个对应的Buffer Size域组成。如图1所示

 

LTE:Buffer Status Report(BSR)_第1张图片

1Short BSRTruncated BSR MAC control element

 

·        Long BSR格式:包含了4Buffer Size域,对应LCG ID 0~3。该格式会将所有LCGBuffer Size一起上报给eNodeB。如图2所示

 

LTE:Buffer Status Report(BSR)_第2张图片

2Long BSR MAC control element

 


      LCG ID域长为2 bit,指定了上报的buffer状态对应的LCG,其值与IE:LogicalChannelConfig logicalChannelGroup字段对应。

      Buffer Size域长为6 bit,指定了UE在发送这个BSRTTI内的所有MAC PDU都生成以后,对应LCG的所有逻辑信道的RLC层和PDCP层中剩余的可用于传输的有效数据的总和(见36.3224.5节和36.3234.5节)。该数据量以byte为单位,但不将RLC头部和MAC头部信息计算在内。

      36.3216.1.3.1节可以看出,eNodeB收到BSR后,通过Buffer Size域得到一个index,再用这个indexTable 6.1.3.1-1Table 6.1.3.1-2,可以得到UE真正需要发送的“近似”上行数据量。因为UE在发送BSR时,无法确定后续发送的上行数据中会有哪些RLC头部和MAC头部,所以计算时不将RLC头部和MAC头部信息计算在内。而从Table 6.1.3.1-1Table 6.1.3.1-2可以看出,通过Buffer Size域得到的index对应的是一个Buffer Size的范围,而不是一个精确的Buffer Size,因此是一个“近似”上行数据量。

        在载波聚合中,可能存在多个上行载波单元同时发送数据,BSR指示的数据量也可能远大于Rel-8中指示的数据量,因此在Rel-10中,LTE额外提供了一个BSR值的表(见36.321Table 6.1.3.1-2。具体使用Table 6.1.3.1-1还是Table 6.1.3.1-2是通过IEMAC-MainConfigextendedBSR-Sizes-r10字段来配置的。

 

      一个BSR MAC control element与一个MAC subheader对应。BSR对应的MAC subheader中的LCID域如图3所示:(见36.321Table 6.2.1-2

 

LTE:Buffer Status Report(BSR)_第3张图片

3UL-SCH的所有LCID

 

      注意LCIDLCG ID是不同的。LCID是用来唯一地指定MAC PDU中的一个MAC SDUMAC control elementpadding的。而LCG ID是用来指定逻辑信道所属的逻辑信道组ID的,只用于BSR上报。

 

二、BSR的触发方式

      当如下事件发生时,将会触发BSR上报:

      1UE的上行数据buffer为空且有新数据到达:当所有LCG的所有逻辑信道都没有可发送的上行数据时,如果此时属于任意一个LCG的任意一个逻辑信道有数据变得可以发送,则UE会触发BSR上报。例如:UE第一次发送上行数据。该BSR被称为“Regular BSR;

      2、高优先级的数据到达:如果UE已经发送了一个BSR,并且正在等待UL grant,此时有更高优先级的数据(即该数据所属的逻辑信道【而不是LCG】比任意一个LCG的逻辑信道的优先级都要高)需要传输,则UE会触发BSR上报。该BSR被称为“Regular BSR”;

      3UE周期性地向eNodeB更新自己的buffer状态:eNodeB通过IEMAC-MainConfigperiodicBSR-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通过IEMAC-MainConfigretxBSR-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来发送BSRBSR被称为“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 BSRPadding BSR,但UE没有足够的UL-SCH资源用于发送BSR时,UE不会发送SR请求。

      对于RegularPeriodic BSR而言,如果在该TTI内有多于1LCG中有数据需要发送,则上报Long BSR;否则上报Short BSR

      对于Padding BSR而言,当padding bit的数量等于或大于“Short BSR +对应的subheader”的大小但小于“Long BSR + 对应的subheader”的大小时,如果在该TTI内有多于1LCG中有数据需要发送,则将有数据要发送且优先级最高的逻辑信道所在的LCGBSR上报给eNodeB,该BSR格式为Truncated BSR;如果该TTI内只有1LCG有数据需要发送,则发送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 BSRPeriodic 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 BSRMAC PDU里携带一个padding BSR

      UE在一个TTI里传输的所有BSR反映的是这个TTI内的所有MAC PDU都生成以后的buffer状态。每个LCG在每个TTI内至多只能上报一个buffer状态值(注意:不是BSR)。假如UE在一个TTI内上报了多个BSR,且其中几个BSR都上报了同一个LCGbuffer状态,那么对应同一LCG的这些buffer状态值必须是相同的。

      需要注意的是,一个Padding BSR是不允许取消那些已经触发的Regular/Periodic BSR的。Padding BSR只能为某个特定的MAC PDU而触发,且当这个MAC PDU生成后,该trigger就被取消了。

     

      有意思的是,UE上报的BSRUE如何处理UL grant没有直接的关系。UE是基于逻辑信道优先级给无线承载分配资源的,与逻辑信道属于哪个LCG没有任何关系。例如:某个 UE为了发送HTTP请求(假定该业务对应的逻辑信道属于LCG 2),已经发送了BSR。在UE收到对应UL grant之前,新出现了一个RRC消息。由于RRC消息对应的逻辑信道的优先级比HTTP请求对应的逻辑信道的优先级要高,所以当UE收到UL grant(该UL grant是因为HTTP请求才予以分配的)后,UE会将上行资源优先分配给RRC消息,而不是分配给HTTP请求。(具体流程可参考我以前发布的博文《LTEMAC复用和逻辑信道优先级》)

 

      注:1CCCHSRB1SRB2默认属于LCG 0(在36.331中搜索logicalChannelGroup,能看出协议中是有明确说明的)2RRC消息在SRB上传输且SRB默认属于LCG 0,比LCG 2的优先级要高。

 

【参考资料】

[1]      TS 36.30011.3

[2]      TS 36.3215.4.56.1.3.1

[3]      TS 36.331periodicBSR-TimerretxBSR-TimerlogicalChannelGroup

[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


你可能感兴趣的:(LTE)