LTE学习笔记 HARQ、BSR

20140310 HARQ，BSR
LTE：上行HARQ（二）
接下来，我们来看看上行是如何进行同步的。

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

2）收到一个PHICH且指示为NACK：对应非自适应重传。

接下来，我们分FDD、TDD 1~6、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，对应非自适应重传），则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，根据timing关系，也就知道后续子帧n+4、n+8、n+12、n+16所使用的HARQ process。

TDD的情况类似，但是timing关系略有不同。

（注：每个子帧只对应一个HARQ process，空分复用的情况下是2个，每个对应一个TB。

）
2) TDD 1~6
对TDD UL/DL configuration 1~6而言，如果UE在子帧n收到了UL grant（DCI format 0/4，对应新传或自适应重传）或PHICH（只收到NACK，对应非自适应重传），则UE会在n + k子帧发送对应的PUSCH。

其中k的值见36.213的Table 8-2（见下图）。

（见36.213的8.0节）
Table 8-2 k for TDD configurations 0-6
图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（或PHICH），则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-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传输与对应的PHICH（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 configuration 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），。

对TDD 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而言，如果UE在子帧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个UL 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，则该PHICH对应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以支持上行空分复用，此时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来决定是进行重传（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，则有上行HARQ 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）来发起重传，依此类推。

如果是自适应重传，则UE不仅会收到PHICH，还会收到PDCCH（UL grant）。

如果需要重传，UE会根据UL grant的指示来选择RV（见36.213的Table 8.6.1-1），但不一定是0, 2, 3, 1的顺序。

如果UL grant中指示的MCS index为0~28，则RV = 0并使用Table 8.6.1-1中指示的真正的MCS。

如果UL grant中指示的MCS index为29~31，RV版本见Table 8.6.1-1，并且从表中可以看出，这3个MCS index 是预留的，不携带真正的MCS信息，因此如果MCS index为29~31，其MCS遵循前一次传输使用的MCS（TB size和调制方式都与前一次传输，或者说，最近一次接收到的MCS index为0~28的UL grant相同）。

（见36.213的Table 8.6.1-1）
5）如何确定同步关系？
本章分FDD、TDD 1~6、TDD 0三种配置来介绍上行HARQ在时域上的同步关系。

每种配置都包含2部分：1）UL grant/PHICH与对应的PUSCH传输之间的timing
关系；2）PUSCH传输与对应的PHICH（ACK/NACK）之间的timing关系。

6）上行HARQ中的自适应和非自适应处理有何不同？
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时间不一样。

二、HARQ 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 bundling和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）操作，最终得到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。

图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，即对应的所有下行子帧的第一个codeword都需要重传，而第二个codeword 不需要重传。

假定上图中其他条件不变，eNodeB在第3个子帧（对应阴影部分）也发送了PDCCH 和PDSCH，但UE没有检测到，此时UE应该反馈00。

但由于UE不知道eNodeB是否在第三个
子帧发送了数据，根据HARQ bundling的原理，还是会反馈01，这就不对了。

为了解决这类问题，LTE提出了DAI的概念，这在之前的博文已经介绍。

注意：协议中的提到“spatial HARQ-ACK bundling（或spatially-bundled）”与“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绑定窗口的处理）
使用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 multiplexing，至多只能携带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总是假定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的数据。

由于只需要传输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）操作（注意：在协议中，这称为“spatially bundled”或“spatial HARQ-ACK bundling”处理，与HARQ bundling不是同一个概念），得到1 bit 的ACK/NACK信息。

做HARQ multiplexing操作的是属于同一HARQ绑定窗口内的下行子帧，根据有多少个子帧发送了下行数据，或M值的大小，决定发送多少bit的信息。

这两种情况的区别，见后续介绍。

图5：HARQ multiplexing的一个例子
上图是HARQ multiplexing的一个例子，空分复用的UE在4个下行子帧接收到的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上做反馈时，会携带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（即非载波聚合条件下），则该UE只支持HARQ bundling，而不支持HARQ multiplexing。

（见36.213的10.1.3节）
总结：参考/s/articlelist_2457665281_0_1.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的优先级要高。