LTE资源调度（4）-上行资源申请方式和BSR缓存状态报告

1.UE申请上行资源的途径

当UE需要向网侧发送数据的时候，必须要有上行RB资源，如果没有RB资源则需要先向网侧申请RB资源。UE有三种方式向网侧申请RB资源：

（1）向网侧发送BSR。BSR的全称是Buffer Status Report，即缓存状态报告。UE可以在MAC层的PDU（即分组数据单元）中插入一个BSR控制单元来告诉网侧：我的某个或某几个逻辑信道组当前有多少数据需要发送，希望你能分配一些RB资源给我。

这种通过发送BSR控制单元的方式，可以让网侧知道UE需要发送的数据量，网侧可以针对性的分配RB资源。但是这里有个问题，UE发送BSR控制单元这个动作本身也是需要上行RB资源的，如果UE没有任何上行RB资源，也是没有办法发送BSR的，那么这个时候UE就需要下面这种方式向网侧发送资源申请。

（2）向网侧发送SR。当UE无法发送BSR申请RB资源的时候，可以通过发送SR（Scheduling Request）请求的方式申请资源。因为BSR是被封装在MAC PDU里的，通过PUSCH信道发送到网侧，因此需要上行RB资源，而SR信号是可以在PUCCH控制信道中传输的，并不需要上行RB资源就可以向网侧发出资源的申请。但这种申请方式有个不好的地方是，网侧收到的只是一个SR信号，并不知道UE接下来需要上传多少字节的数据，从而并不清楚该分配多少的资源是合适的，因此后续UE可能仍然需要发送BSR来申请更多的上行资源。网侧收到UE的SR请求后，分配多少的RB资源是由设备厂家的算法决定的，一般来说，网侧收到SR信号后，分配的RB资源至少能够满足BSR的发送。

并不是所有的UE都能发出SR信号。SR是在PUCCH控制信道中传输的，资源也是有限的，网侧的RRC层也会根据实际需要，只给某些UE配置SR资源。只有配置了SR资源的UE，才能向网侧发送SR请求，而没有被配置SR资源的UE，是无法向网侧发送发送SR请求的。如果某个UE既无法发送BSR，又不能发送SR信号，那么这个UE怎么申请上行资源呢？这个时候UE就需要发起竞争随机接入过程了。

（3）发起竞争随机接入。关于竞争随机接入过程的目的，我已经在博文《LTE-TDD随机接入过程（1）-目的和分类》里详细介绍过，里面提到竞争接入的目的之一就是获取上行RB资源。在这种方式中，UE将在MSG3中插入一个BSR控制单元来告诉网侧需要的资源信息。当然，这种方式也是UE迫不得已才会采用的，毕竟这种方式的时延相对BSR和SR来说是最大的。

UE申请资源的过程，将优先采用BSR的方式，如果不能发送BSR，则采用SR的方式，最后才会考虑竞争随机接入的方式。如下面的图1所示，无论是上面的哪种方式，是SR申请还是竞争随机接入申请，还是BSR申请，网侧实际分配的资源可能都不足以让UE传完数据，此时UE会继续发送BSR来申请更多的资源。本文将详细描述BSR的相关内容，以后的博文再详细描写SR的申请过程。

（图1）

2.BSR携带的信息

上文已经提到，BSR可以向网侧申请资源，用于UE的数据上传。网侧收到BSR后，根据BSR携带的内容，为UE分配合适的资源。那么这里就有个问题：UE的待传数据量是动态随机变动的，比如某个时刻UE需要发送999个字节的数据，而下一秒可能需要发送1000001个字节的数据，这种变化是不确定的，UE怎么向网侧表达这种需求信息呢？最简单的方法，当然是UE将具体的数字（比如1000001这个数）编码到BSR的信息里，但这样的话，在空口中传输的bit位个数就比较多。协议在这里采用了另一种方式来编码BSR信息：使用0～63这64个index索引，来代表不同的字节范围。这样无论UE有多少数据要发，BSR只需要6个bits的空间就足够了，减少了空口传输的比特位数。而且，UE发送具体的字节数也是没有意义的，毕竟当eNB为UE调度资源的时候，UE侧BSR的信息有很大的概率已经更新为其它值了。

BSR携带的索引值与字节大小的对应关系具体如图2所示，index=0表示某个逻辑信道组没有数据需要发送，index=63表示某个逻辑信道组有超过150K字节的数据需要发送。当UE有30个字节的数据需要发送时，只需要将BSR控制单元的值填为8。网侧在解码BSR信息后，发现BSR的值等于8，就知道UE侧需要发送的数据量在26～31字节之间，为eNB给UE分配合适大小的资源提供了参考依据。需要注意的是，这里并不意味着网侧就会给UE分配26个字节或31个字节对应的资源，UE也不能做类似的假定。因为网侧在收到BSR后，有可能只会分配极少数量的资源，比如这个例子中，网侧可能只会分配10个字节的资源给UE，而不是26个字节也不是31个字节，甚至很多时候，网侧在收到BSR后，并不会给该UE分配任何的上行资源。网侧如何给某个UE分配资源，是由设备厂家的算法决定的，UE不会也不应该对资源申请的结果做特定大小的假设。

（图2）

3.逻辑信道组

为了减少在空口中传输的信息比特个数，协议并不是为每个逻辑信道都绑定一个BSR值，而是为每个逻辑信道组绑定一个BSR值。上文已经提到，BSR携带的是0～63这64种索引值，每个索引值对应不同范围的字节数目，这个字节数并不是该UE所有待传的数据量，也不是某个逻辑信道待传的数据字节数，而是某个逻辑信道组待传的数据量。每个逻辑信道组都有一个BSR值与其绑定，当UE的某个逻辑信道组有数据需要发送时，就可以上报该逻辑信道组的BSR值。

逻辑信道组（Logic Channel Group，简称LCG），顾名思义，就是将一个或多个逻辑信道归为一组。RRC在配置每个逻辑信道属性参数logicalChannelConfig的时候，可以为该逻辑信道分配相应的LCG ID号logicalChannelGroup，这个ID号的范围是0～3，也就是说只有4个逻辑信道组，如图3所示。

（图3）

虽然逻辑信道的组号LCGID由RRC配置，但协议对其中的某些特定的逻辑信道规定了具体的LCGID值，比如：SRB0、SRB1、SRB2这三个逻辑信道，要固定配置LCGID=0。从这个细节我们也可以看到，虽然逻辑信道组是没有优先级概念的，但协议还是偏向LCGID0的优先级高于其他LCGID，eNB的RRC在给其他逻辑信道配置LCGID的时候，不应该将DRB的LCGID配置成0。另外，逻辑信道与逻辑信道组的匹配还需要参考该逻辑信道承载业务的QCI，对于优先级比较高的业务，可以将该逻辑信道的LCGID配置为1。

4.BSR控制单元的格式

UE上报的BSR控制单元（control element）有两种格式：

（1）当BSR属于Short BSR（短BSR）或者Truncated BSR（截短BSR）类型时，BSR控制单元固定占1个字节，只能携带1个逻辑信道组的BSR信息。该BSR信息所对应的逻辑信道组ID固定占用2比特，取值0～3，BSR域固定占6比特，取值0～63。

（2）当BSR属于Long BSR（长BSR）类型时，BSR控制单元固定占3个字节，可以携带所有逻辑信道组的BSR信息。因为协议只规定了4种逻辑信道组，因此不需要再携带LCG ID值，从LCG ID0到LCG ID3依次编码6个比特的BSR域：Buffer Size #0对应LCGID0的BSR值，Buffer Size #1对应LCGID1的BSR值，Buffer Size #2对应LCGID2的BSR值，Buffer Size #3对应LCGID3的BSR值。

两种格式如下面的图4所示。

（图4）

需要注意的是，图4中的Buffer Size #1和#2是跨字节的，关于跨字节的高低位合并问题，与DCI码流的高低位合并规则是相同的，详见博文《LTE下行物理层传输机制（5）-DCI格式的选择和DCI1A》。

每个MAC控制单元都对应着一个MAC子头，这个子头里的LCID域用来表示控制单元的类型。上面提到的BSR的三种类型Short BSR、Truncated BSR、Long BSR，就是通过子头中的LCID值确定的（关于MAC PDU更详细的组成结构，后面博文再单独介绍），如下图5所示。协议为这三种BSR类型分别定义了不同的LCID值：如果与控制单元相对应的子头的LCID值是28（即二进制11100），那么表示UE上传的是Truncated BSR，这个时候网侧MAC层只需要提取1个字节的控制单元码流，从中就可以解析出逻辑信道组ID号和BSR值；类似的，如果与控制单元相对应的子头的LCID值是30，则表示UE上传的是Long BSR，网侧需要提取3个字节的控制单元码流，从中解析出所有逻辑信道组的BSR值。

（图5）

5.UE触发BSR的时机

当以下事件之一发生时，UE将会触发一个BSR（注意：这里只是触发BSR，而不是向网侧实际发送一个BSR）：

（1）当属于某个逻辑信道组的某个逻辑信道有上行数据可供传输，并且这条逻辑信道的优先级高于目前任何逻辑信道组中任何逻辑信道的优先级，或者目前同个逻辑信道组中所有其它的逻辑信道均无可传数据，此时将触发一个BSR，且该BSR叫做常规BSR（Regular BSR）。如下文的图6所示，后面还会继续用到这个图。

前一个触发场景的意思是，无论UE之前是不是已经发出了BSR，抑或这个时候还在等待上行授权，只要具有更高优先级的逻辑信道有新数据要传，那么这个时候UE就要重新触发一次BSR。后一个触发场景的意思是，有一个逻辑信道组之前是没有数据可传的，此时其中某个逻辑信道有数据可传了，那么不管其他逻辑信道组的状态是什么，都要重新触发一次BSR。

（图6）

当UE触发了一个BSR且当前TTI时刻有上行RB可用时，UE将组建BSR控制单元；当UE触发了一个常规BSR且当前TTI时刻没有上行RB可用时，是没有办法发送BSR的，但是否就需要发送SR申请资源呢？不然，此时还要看下面两种情况，只有满足其中之一，才会通过SR发送资源申请（注：只有当常规BSR不能发送的时候才会继续考虑是否通过发送SR来申请资源，而周期BSR和填充BSR不能发送的时候，是不会考虑发送SR的）：

（A）没有已经配置的上行授权。如果网侧激活了UL SPS，那么认为该UE的上行授权已经被配置。

（B）常规BSR是由某个逻辑信道有上行数据可传触发的，但RRC并没有配置该逻辑信道的logicalChannelSR-Mask参数。换句话说，如果UE已经触发了一个常规BSR，且已经配置了上行授权，此时若网侧将参数logicalChannelSR-Mask设置为true，就不会触发SR。logicalChannelSR-Mask参数属于逻辑信道的参数，在logicalChannelConfig信元中配置（见上文图3）。

综合（A）和（B），当UE触发了一个常规BSR，且已经配置了上行授权，同时该逻辑信道的logicalChannelSR-Mask为true，那么就不需要发送SR。

这里具体说说条件（A）和（B）的由来：    在最初的R9协议版本中，只要触发了常规BSR且该TTI时刻没有上行RB可用，就需要通过触发SR来申请资源，当时并没有增加（A）和（B）的限制，但后来随着协议的完善，发现UE在进行UL SPS时这里是有缺陷的。如果没有这两个条件，当UE处于UL SPS状态时，原本为了减少信令交互的SPS机制，可能会出现频繁发送SR申请资源的情况，这个与UL SPS的设计初衷是违背的。举个例子：UE在DRB1中进行UL SPS数据的周期传输，在某个非SPS周期的TTI时刻，DRB1中有新数据可传，满足常规BSR的触发条件，由于还没有到ULSPS周期的TTI时刻，所以没有可用的上行RB，此时UE将为DRB1触发一个SR过程。但实际上这个时候是不需要触发SR的，因为在UL SPS周期时刻到的时候，自然就有了上行RB资源，不需要进行申请。 为了避免UE在UL SPS状态时不必要的SR发送，浪费SR资源，以及减少UE监测PDCCH的时间，2009年11月，高通、诺西等多家公司联合提出了这样的一个限制方案，从而当UE处于UL SPS状态的时候，可以控制特定逻辑信道的SR发送。 比如，UE在UL SPS过程中，使用DRB1进行数据的周期上传，这个时候网侧可以将DRB1的logicalChannelSR-Mask设置为true，那么UE在配置了UL SPS之后，就不会因DRB1有了新数据而触发SR过程了。

（2）分配有上行资源，并且填充比特数大于或等于BSR控制单元与其MAC子头的比特数之和，此时将触发一个BSR，且该BSR叫做填充BSR（Padding BSR）。之所以增加这种机制，主要是基于有效利用资源的考虑。示意图参考下文的图7。

（图7）

（3）重传定时器retxBSR-Timer超时，并且UE在某个逻辑信道组中的任意一个逻辑信道有可传数据，此时UE将会触发一个BSR，且该BSR也叫做常规BSR。

（4）周期定时器periodicBSR-Timer超时，此时UE将会触发一个BSR，且该BSR叫做周期BSR（Periodic BSR）。之所以增加这种机制，是防止以上条件都不满足时，eNB侧也可以知道UE的资源需求，为UE分配适当的上行资源。

retxBSR定时器和periodicBSR定时器由RRC配置，可在RRCConnectionSetup、RRCConnectionReestablishment或RRCConnectionReconfiguration消息中的radioResourceConfigDedicated信元的mac-MainConfig字段中带给UE，如图8所示。

 

  （图8）

参数的取值类似于下面的表格所示，单位是子帧或ms，sf320表示320ms。

mac-MainConfig explicitValue :  {           ul-SCH-Config            {                 maxHARQ-Tx                     n4,                 periodicBSR-Timer          sf10,                                 retxBSR-Timer                  sf320,                 ttiBundling                          FALSE           }          ... ...  }

尽管有多个事件可以触发BSR，但一个MAC PDU中最多只能包含一个BSR MAC控制单元，且常规BSR和周期BSR优先于填充BSR的发送。

关于retxBSR定时器和periodicBSR定时器启动或重启的时机：

（1）如果UE已经触发了一个BSR，且在该TTI有新数据传输的上行RB资源，那么除截短BSR外，启动或重启periodicBSR定时器。

（2）如果UE已经触发了一个BSR，且在该TTI有新数据传输的上行RB资源，启动或重启retxBSR定时器。

（3）一旦UE收到了在UL-SCH上传输新数据的授权，则重启retxBSR定时器。

当上行授权可以满足所有待传数据的传输，但不足以额外传输BSR控制单元及其MAC子头的比特总和时，UE将取消全部触发的BSR。当传输的MAC PDU中已经包含了BSR，则取消全部触发的BSR。

前文已经提到，网侧收到的BSR控制单元中只有三种类型：长BSR、短BSR和截短BSR，这些是从BSR长度的角度分类的，而常规BSR、填充BSR和周期BSR，则是从BSR触发原因的角度分类的。这两种分类之间存在着一定的关系，比如对于常规BSR来说，既可能是长BSR也可能是短BSR，下面具体说说这两种分类方式之间的关系。

6.常规BSR、填充BSR、周期BSR与短BSR、截短BSR、长BSR的关系

（1）常规BSR

如果UE发送的是常规BSR，且该TTI有超过1个逻辑信道组有可传数据，那么上报长BSR，否则上报短BSR。上面图6的场景1，有3个逻辑信道组有数据可传，此时上报长BSR；在场景2中，只有1个逻辑信道组有数据可传，此时上报短BSR；场景3与场景2的触发原因相同，也是由于LCG-ID1中只有1个逻辑信道5有可传数据，但因为LCG-ID0中的逻辑信道0也有可传数据，所以上报长BSR。

（2）填充BSR

（A）如果填充比特数大于或等于短BSR与其MAC子头的比特数之和（即2个字节），但小于长BSR与其MAC子头的比特数之和（即4个字节），那么：

--------（a）如果上报BSR的TTI时刻有超过1个逻辑信道组的数据可传，则上报具有最高优先级逻辑信道的逻辑信道组的截短BSR。之所以称为截短BSR，是因为此时有多个逻辑信道组的数据可传，按理说应该上报长BSR的，但限于可用的填充资源有限，只能发送1个逻辑信道组的BSR，所以定义了这个“截短BSR”，以便于区分一个字节的短BSR。

--------（b）否则，上报短BSR。

（B）否则，如果填充比特数大于或等于长BSR与其MAC子头的比特数之和，则上报长BSR。此时不需要关心有多少个逻辑信道组有数据可传，统一向网侧报长BSR。

（3）周期BSR

如果UE发送的是周期BSR，且该TTI有超过1个逻辑信道组有可传数据，那么上报长BSR，否则上报短BSR，不会上报截短BSR。

我们在讨论常规BSR、周期BSR、填充BSR的时候，它的修饰词常常是“触发”(trigger)，而在描述长BSR、短BSR、截短BSR的时候，它的修饰词往往是“发送”（report），注意这里的区别。上面几种类型的关系总结如下：

（图9）

参考文献：

（1）3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification

（2）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)