LTE学习笔记HARQ、BSR

1、20140310 HARQ，BSRLTE：上行HARQ（二）      接下来，我们来看看上行是如何进行同步的。      首先需要说明的是，如果UE需要在PUSCH上发送数据，UE需要满足以下两个条件之一：      1）收到一个有效的UL Grant：该UL grant可以来自动态调度的PDCCH（DCI format 0/4，本文只介绍这种情况）、或来自RAR，或通过半静态配置。      2）收到一

2、个PHICH且指示为NACK：对应非自适应重传。      接下来，我们分FDD、TDD 16、TDD 0三种配置来介绍上行HARQ在时域上的同步关系！每种配置都包含2部分：1）UL grant/PHICH与对应的PUSCH传输之间的timing关系；2）PUSCH传输与对应的PHICH（ACK/NACK）之间的timing关系。1) FDD      对FDD而言，如果UE在子帧n收到了UL grant（DCI format 0/4，对应新传或自适应重传）或PHICH（只收到NACK，对应非自

3、适应重传），则UE会在n + 4子帧发送对应的PUSCH。（见36.213的8.0节）      对FDD而言，如果UE在子帧n收到了PHICH，则该PHICH对应UE在上行子帧n - 4发送的PUSCH。（见36.213的8.3节）      如图3所示。图3：FDD中的上行传输，UL grant、PUSCH、ACK/NACK之间的timing关系子帧n，n+4、n+8、n+12、n+16都对应同一HARQ process。只要确定了子帧n所使用的HARQ process number，根据t

4、iming关系，也就知道后续子帧n+4、n+8、n+12、n+16所使用的HARQ process。TDD的情况类似，但是timing关系略有不同。（注：每个子帧只对应一个HARQ process，空分复用的情况下是2个，每个对应一个TB。）2) TDD 16      对TDD UL/DL configuration 16而言，如果UE在子帧n收到了UL grant（DCI format 0/4，对应新传或自适应重传）或PHICH（只收到NACK，对应非自适应重传），则UE会在n + k子帧发送对应的PUSCH。其中k的值见36.213的Table 8

5、-2（见下图）。（见36.213的8.0节）Table 8-2 k for TDD configurations 0-6TDD UL/DLConfigurationsubframe number n0123456789046   46   1 6  4 6  42   4    4 34       444  

6、;      445        4 677   77  5图4给出了TDD Configuration 1和2下，UL grant/PHICH与对应的PUSCH传输之间的timing关系。以TDD Configuration 1为例，如果UE在子帧1收到了UL grant（或PHICH），则UE会在子帧7（n+k=1+6）发送PUSCH（或重传）；如果UE在子帧9收到了UL grant（或PH

7、ICH），则UE会在下一系统帧的子帧3（n+k=9+4）发送PUSCH（或重传）。图4：TDD 1/2中，UL grant/PHICH与对应的PUSCH传输之间的timing关系（对应36.213的Table 8-2）      对TDD UL/DL configuration 1-6而言，如果UE在子帧n收到了PHICH，则该PHICH对应UE在上行子帧n - k发送的PUSCH。其中k的值见36.213的Table 8.3-1（见下图）。（见36.213的8.3节）Table 8.3-1 k for TDD configurations 0

8、-6TDD UL/DLConfigurationsubframe number i0123456789074   74   1 4  6 4  62   6    6 36       664        665   

9、     6 664   74  6  图5给出了TDD Configuration 1和2下，PUSCH传输与对应的PHICH（ACK/NACK）之间的timing关系。以TDD Configuration 1为例，如果UE在子帧2发送了PUSCH，则UE会在子帧6（N-K=6-4）接收对应的PHICH；如果UE在子帧7发送了PUSCH，则UE会在下一系统帧的子帧1（N-K=1-4=7）接收对应的PHICH。 图5：TDD 1/2中，PUSCH传输与对应的PHIC

10、H（ACK/NACK）之间的timing关系（对应36.213的Table 8.3-1）      图6举了一个例子： TDD 1下，假如UE在下行子帧1收到UL grant，对照图4可知，UE会在上行子帧7发送PUSCH，进一步对照查图5可知，UE会在下行子帧1接收PHICH（和UL grant）。如果需要重传，对照图4可知，UE会在上行子帧7进行重传，如此反复！这就是一个完整的HARQ处理流程。 图6：举例3) TDD 0      对TDD UL/DL configur

11、ation 0而言，一个系统帧内的下行子帧数少于上行子帧数。因此，一个下行子帧可能需要同时给2个上行子帧发送UL grant，为了实现该功能，DCI format 0/4新增了一个2 bit的字段：UL index（见36.212的5.3.3.1.1节和5.3.3.1.8节）。与此同时，一个下行子帧可能需要同时反馈2个上行子帧的ACK/NACK信息，为了将不同上行子帧对应的PHICH区分开，又新增了的概念（见36.213的9.1.2节）。 注意：只有TDD UL/DL configuration 0下的上行子帧4和9对应；其它情况下（包括其它TDD配置和FDD），。  对T

12、DD UL/DL configuration 0而言，如果UE在子帧n收到的UL grant的MSB置为1，或在子帧0或5接收到的PHICH对应（反馈的不是子帧4或9的ACK/NACK信息），则UE会在子帧n + k发送对应的PUSCH，其中k的值见36.213的Table 8-2。 对TDD UL/DL configuration 0而言，如果UE在子帧n收到的UL grant的LSB置为1，或在子帧0或5接收到的PHICH对应，或在子帧1或6接收到PHICH，则UE会在子帧n + 7发送对应的PUSCH。 对TDD UL/DL configuration 0而言，如果U

13、E在子帧n收到的UL grant的MSB和LSB均置为1，则UE会在子帧n + k和n + 7都发送对应的PUSCH。（见36.213的8.0节） 从图7中可以看出：在TDD 0中，（1）任意一个下行子帧发送的UL grant都可能对应2个上行子帧发送的PUSCH；2）某个上行子帧可能得到来自2个下行子帧的UL grant。例如：如果在下行子帧0收到的UL grant的LSB置为1，同时在下行子帧1收到的UL grant的MSB置为1，则对应上行子帧7，会收到2个UL grant！关于1个上行子帧有2个UL grant的情形该如何处理，我没有找到相关的介绍。但我这里也有些疑惑：2个U

14、L grant如果调度到同一块PRB资源怎么办？或是2选一？或是eNodeB在做上行调度时，保证对应一个上行子帧只会收到一个UL grant？图7：TDD 0中，UL grant（PHICH）与对应的UL-SCH之间的timing关系 如图8所示，下行子帧0需要同时反馈上行子帧3（）和4（）的ACK/NACK信息；下行子帧5需要同时反馈上行子帧8（）和9（对应）的ACK/NACK信息。如果UE在对应的子帧n收到了PHICH，则该PHICH对应UE上行子帧n - k发送的PUSCH数据，其中k的值见36.213的Table 8.3-1；如果UE在对应的子帧n收到了PHICH，则该PHI

15、CH对应UE上行子帧n - 6发送的PUSCH数据。其中k的值见36.213的Table 8.3-1。（见36.213的8.3节）图8：TDD 0中，PUSCH传输与对应的ACK/NACK之间的timing关系【举例】      图9是一个FDD下，上行HARQ的例子。TDD除了timing关系不同外，其它处理是一样的。图不是很清晰，大家注意一下每个子帧对应的虚线。图9：非自适应和自适应HARQ操作（FDD）      注：R-10中新增了DCI format 4以支持上行空

16、分复用，此时2个codeword对应的是不同的HARQ process，处理方式与之前介绍的相同。但在非自适应重传时，如果接收到的NACK数与最近接收到的PDCCH指示的TB数，有特殊处理，大家可以关注下36.213的8.0节。因为对DCI format 4没有太深的了解，这里我就不做介绍了。本文总结：1） 如何确定是重传还是新传？给定某个HARQ process，无论收到的PHICH指示的是ACK还是NACK，只要同时还收到UL grant，则UE会忽略PHICH而使用UL grant来决定如何进行下一次传输（新传还是重传）。当前子帧或后续子帧中接收到的UL grant中的NDI来决定是进行

17、重传（NDI没有反转），还是进行新传（NDI反转，此时会清空HARQ缓存区）。2） 什么时候会清空缓冲区？是否清空HARQ缓存区是由UL grant的NDI来决定的。3） 如何确定HARQ process？对于FDD而言，如果上行传输模式为TM1，则有8个上行HARQ process；如果上行传输模式为TM2，则有上行HARQ process数将翻倍，为16个，此时每个子帧有2个HARQ process。对于TDD而言，如果上行传输模式为TM1，则不同的TDD上下行配置对应的上行HARQ process数见36.213的Table 8-1所示（如下图）；如果上行传输模式为TM2，则有上行HAR

18、Q process数将翻倍，此时每个子帧有2个HARQ process。 这里我们不考虑子帧绑定（subframe bundling）的场景4） 如何确定冗余版本RV？如果是非自适应重传，UE只会收到PHICH中指示的ACK/NACK信息，而不会显式地收到RV信息。上行HARQ是同步的，RV遵循一个固定的顺序：0, 2, 3, 1（注意：这个顺序只对“非自适应重传”有意义）。新传使用的RV由UL grant指定，值为0；若之后UE收到NACK，则会使用前一次传输对应的下一个RV版本（对应0，下一个RV值为 2；对应2，下一个RV值为 3）来发起重传，依此类推。如果是自适应重

19、传，则UE不仅会收到PHICH，还会收到PDCCH（UL grant）。如果需要重传，UE会根据UL grant的指示来选择RV（见36.213的Table 8.6.1-1），但不一定是0, 2, 3, 1的顺序。如果UL grant中指示的MCS index为028，则RV = 0并使用Table 8.6.1-1中指示的真正的MCS。如果UL grant中指示的MCS index为2931，RV版本见Table 8.6.1-1，并且从表中可以看出，这3个MCS index是预留的，不携带真正的MCS信息，因此如果MCS index为2931，其MCS遵循前一次传输使用的MCS（TB size

20、和调制方式都与前一次传输，或者说，最近一次接收到的MCS index为028的UL grant相同）。（见36.213的Table 8.6.1-1）5） 如何确定同步关系？本章分FDD、TDD 16、TDD 0三种配置来介绍上行HARQ在时域上的同步关系。每种配置都包含2部分：1）UL grant/PHICH与对应的PUSCH传输之间的timing关系；2）PUSCH传输与对应的PHICH（ACK/NACK）之间的timing关系。FDDTDD16TDD0UL grantn+4n+kn+k/n+7PHICH（ACK/NACK）n-4n-kn-k/n-66） 上行HARQ中的自适应和非自适应处理

21、有何不同？1、 如果是非自适应重传，UE只会收到PHICH中指示的ACK/NACK信息。如果是自适应重传，则UE不仅会收到PHICH，还会收到PDCCH（UL grant）。2、 在非自适应重传时，重传与与前一次传输使用相同的PRB资源和MCS。因此下行只需要PHICH这一种控制信令，而不需要PDCCH（UL grant），从而降低了开销。在自适应重传时是为了避免分割上行频域资源或避免与随机接入的资源发生碰撞。此时eNodeB不仅会发送PHICH，还会发送PDCCH（UL grant）以指示重传所使用的新的PRB资源和MCS。3、 自适应重传/非自适应重传的同步timing时间不一样。二、HA

22、RQ bundling和HARQ multiplexing 对于TDD，如果UE不支持聚合超过1个serving cell，即非载波聚合的条件下，RRC层可以给UE配置2种ACK/NACK反馈模式。（见36.213的10.1.3节）1、HARQ-ACK bundling（或称为HARQ bundling、ACK/NACK bundling）2、HARQ-ACK multiplexing（或称为HARQ multiplexing、ACK/NACK multiplexing）      可以看出，只有TDD且非载波聚合的情况下，才有HARQ bun

23、dling和HARQ multiplexing的概念。      UE使用HARQ bundling还是HARQ multiplexing是通过PUCCH-ConfigDedicated的tdd-AckNackFeedbackMode字段来配置的。该字段对PUCCH和PUSCH上回复的ACK/NACK均有效。一、HARQ bundling      HARQ bundling：将同一serving cell的多个下行子帧的对应同一codeword的ACK/NACK做逻辑与（logical AND

24、）操作，最终得到1 bit（非空分复用，使用PUCCH format 1a）或2 bit（空分复用，使用PUCCH format 1b）的ACK/NACK信息。做HARQ bundling操作的是属于同一HARQ绑定窗口内的个PDSCH传输和指示下行SPS释放PDCCH的子帧，那些没有发送PDCCH/PDSCH的子帧是不考虑在内的。（根据每个子帧发送多少个codeword，即是否使用空分复用，决定发送多少个bit的信息）      注意：HARQ bundling只用于单个cell的场景。也就是说，载波聚合并不使用HARQ bundling。图

25、1：HARQ bundling的一个例子      上图是HARQ bundling的一个例子，空分复用的UE在4个下行子帧接收到的PDSCH对应在同一个上行子帧回ACK/NACK。eNodeB在第1、2、4个子帧发送了PDSCH，对应codeword 0，HARQ 反馈分别为NACK/ACK/ACK，则有0 & 1 & 1 = 0；对应codeword 1， HARQ 反馈分别为ACK/ACK/ACK，则有1 & 1 & 1 = 1。则在对应的PUCCH/PUSCH上做反馈时，会携带2 bit的信息01，即对应

26、的所有下行子帧的第一个codeword都需要重传，而第二个codeword不需要重传。      假定上图中其他条件不变，eNodeB在第3个子帧（对应阴影部分）也发送了PDCCH和PDSCH，但UE没有检测到，此时UE应该反馈00。但由于UE不知道eNodeB是否在第三个子帧发送了数据，根据HARQ bundling的原理，还是会反馈01，这就不对了。为了解决这类问题，LTE提出了DAI的概念，这在之前的博文已经介绍。 注意：协议中的提到 “spatial HARQ-ACK bundling（或spatially-bundled）”

27、与“HARQ-ACK bundling”不是同一个概念。“spatial HARQ-ACK  bundling（或spatially-bundled）”是指将同一小区，同一下行子帧发送的2个codeword对应的2个ACK/NACK做逻辑与（logical AND）处理，得到1 bit 的ACK/NACK信息。它主要应用于HARQ multiplexing、PUCCH format 1b with channel selection和PUCCH format 3。（这只是对单个下行子帧的处理，而HARQ bundling/multiplexing是对整个HARQ绑定窗口的处

28、理）使用HARQ bundling的场景有3种（见36.213的7.3节）：      （1）tdd-AckNackFeedbackMode设置为bundling；      （2）tdd-AckNackFeedbackMode设置为multiplexing，但回应ACK/NACK的上行子帧对应的M值为1（M的取值见36.213的Table 10.1.3.1-1），即一个上行子帧对应一个下行子帧的场景。这种场景至多需要回应2 bit（空分复用）的ACK/NACK，如果使用HARQ multipl

29、exing，至多只能携带1 bit的信息，反而不如使用HARQ bundling将2 bit的信息都回复给eNodeB（使用PUCCH format 1b）。      （3）对于TDD UL-DL configuration 5且UE不支持聚合超过1个serving cell（即非载波聚合条件下），则该UE只支持HARQ bundling。（见36.213的10.1.3节）对于HARQ bundling，当UE配置了TM 3/4/8/9并且ACK/NACK在PUSCH上传输（注意：不包含PUCCH上回应ACK/NACK的情况），则UE总是假定

30、codeword 0和1都使能，并最终生成2 bit的ACK/NACK信息。如果UE在HARQ绑定窗口内只在codeword 0检测到PDSCH传输，则UE为codeword 1生成NACK。（关于codeword使能/去使能，会在后面介绍）      通过之前的介绍，我们可以看出，对于HARQ bundling，只要UE在绑定窗口内有一个TB没有正确接收（NACK/DTX），对应该TB所在的codeword，eNodeB就应该收到NACK或根本没收到HARQ反馈，并重传所有下行子帧对应该codeword的数据。  

31、0;   由于只需要传输1或2 bit的ACK/NACK信息，HARQ bundling能够提高上行控制信令的UL coverage和capacity（尤其对小区边缘的UE）。而不足之处在于eNodeB无法确认哪一个或几个下行子帧解码失败，只好把所有下行子帧的数据都重传一遍，这会导致throughput的下降。二、HARQ multiplexing      HARQ multiplexing：将同一serving cell的同一下行子帧发送的2个codeword对应的ACK/NACK做逻辑与（logical AND）操作（

32、注意：在协议中，这称为“spatially bundled”或“spatial HARQ-ACK  bundling”处理，与HARQ bundling不是同一个概念），得到1 bit 的ACK/NACK信息。做HARQ multiplexing操作的是属于同一HARQ绑定窗口内的下行子帧，根据有多少个子帧发送了下行数据，或M值的大小，决定发送多少bit的信息。这两种情况的区别，见后续介绍。 图5：HARQ multiplexing的一个例子      上图是HARQ multiplexing的一个例子，空分复用的UE在4个

33、下行子帧接收到的PDSCH对应在同一个上行子帧回ACK/NACK。eNodeB在第1、2、4个下行子帧发送了PDSCH，对应第1个子帧，2个codeword的HARQ 反馈分别为NACK/ACK，则有0 & 1 = 0；对应第2个子帧，2个codeword的HARQ 反馈分别为ACK/ACK，则有1 & 1 = 1；对应第3个子帧，没有下行传输，则有0 & 0 = 0（注意：这个0可能发送，也可能不发送，这会在后续介绍）；对应第4个子帧，2个codeword的HARQ 反馈分别为ACK/ACK，则有1 & 1 = 1。则在对应的PUCCH/PUSCH上做反馈时，

34、会携带3 bit（或4 bit）的信息011（或0101），即第1个下行子帧的2个codeword都需要重传。 使用HARQ multiplexing的场景：tdd-AckNackFeedbackMode设置为multplexing，且反馈ACK/NACK的上行子帧对应的M值为大于1（M的取值见36.213的Table 10.1.3.1-1），即一个上行子帧对应多个下行子帧的场景。（见36.213的7.3节）      对于TDD UL-DL configuration 5且UE不支持聚合超过1个serving cell（即非载波聚合条件下），

35、则该UE只支持HARQ bundling，而不支持HARQ multiplexing。（见36.213的10.1.3节）总结：参考二、Buffer Status Report（BSR）      在前一篇博客（见LTE：上行调度请求（Scheduling Request，SR）中已经介绍到，UE通过SR向eNodeB请求上行资源时，只指明了其是否有上行数据需要发送，而没有指明自己需要发送多少上行数据。UE需要通过BSR（Buffer Status Report）告诉eNodeB，其上行buffer里有多少数据需要发送，以便eNodeB

36、决定给该UE分配多少上行资源。      根据业务的不同，UE可能建立大量的无线承载（radio bearer，每个bearer对应一个逻辑信道），如果为每一个逻辑信道上报一个BSR，会带来大量的信令开销。为了避免这种开销，LTE引入了LCG（Logical Channel Group）的概念，并将每个逻辑信道放入一个LCG（共4个）中。UE基于LCG来上报BSR，而不是为每个逻辑信道上报一个BSR。      某个逻辑信道所属的LCG是在逻辑信道建立时通过IE: LogicalChannelC

37、onfig 的logicalChannelGroup字段来设置的 。  LogicalChannelConfig :=         SEQUENCE     ul-SpecificParameters            SEQUENCE        priority  

38、                       INTEGER (1.16),       prioritisedBitRate               ENUMERATED &

39、#160;                                           kBps0, kBps8, kBps16, kBps32, kBps64, kBps

40、128,                                            kBps256, infinity, kBps512-v1020, kBp

41、s1024-v1020,                                            kBps2048-v1020, spare5, spare

42、4, spare3, spare2,                                            spare1,  

43、0;    bucketSizeDuration               ENUMERATED                            

44、60;                ms50, ms100, ms150, ms300, ms500, ms1000, spare2,                          &

45、#160;                 spare1,       logicalChannelGroup                  INTEGER (0.3)    

46、    OPTIONAL          - Need OR          OPTIONAL,                         

47、                                   - Cond UL    .,      logicalChannelSR-Mask-r9  

48、60;      ENUMERATED setup    OPTIONAL       - Cond SRmask            将逻辑信道分组是为了提供更好的BSR上报机制。将那些有相似调度需求的逻辑信道放入同一LCG中，并通过short BSR上报其buffer状态。      如何分组取决于eNodeB的算法实现（

49、例如：将相同QCI/priority的逻辑信道放入同一LCG中）。即上行的QoS管理是由eNodeB负责管理的。      由于UE的LCG和逻辑信道的配置是由eNodeB控制的，所以eNodeB知道每个LCG包含哪些逻辑信道以及这些逻辑信道的优先级。虽然eNodeB无法知道一个单独的逻辑信道的buffer状态，但由于同一LCG中的逻辑信道有着类似的QoS/priority需求，所以基于LCG来上报buffer状态也可以使得上行调度提供合适的调度结果。 一、BSR MAC Control Element  

50、0;   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 ·        Lo

51、ng BSR格式：包含了4个Buffer Size域，对应LCG ID 03。该格式会将所有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

52、的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时，无法确定后续发送的上行数

53、据中会有哪些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.

54、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是

55、不同的。LCID是用来唯一地指定MAC PDU中的一个MAC SDU或MAC control element或padding的。而LCG ID是用来指定逻辑信道所属的逻辑信道组ID的，只用于BSR上报。 二、BSR的触发方式      当如下事件发生时，将会触发BSR上报：      1、UE的上行数据buffer为空且有新数据到达：当所有LCG的所有逻辑信道都没有可发送的上行数据时，如果此时属于任意一个LCG的任意一个逻辑信道有数据变得可以发送，则UE会触发BSR上报。例如：UE第一

56、次发送上行数据。该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

57、（配置成”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-MainC

58、onfig的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”

59、的大小时，UE会使用这些bit来发送BSR。该BSR被称为“Padding BSR”。      从上面的介绍可以看出，只有当某个逻辑信道属于某个LCG时，它的数据才会被统计到对应的BSR中并上报给eNodeB；对于不属于任一LCG的逻辑信道（logicalChannelGroup字段是OPTIONAL的），其数据不会被统计，不会影响任何BSR行为。      如果至少触发了一个BSR且该BSR没有被取消且UE已经在该TTI内收到了用于新传数据的UL grant，则UE会· 

60、       生成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资源