LTE 终端如何申请 RB 资源以及现实面临的问题
作者简介： 曹改建，网名阿米尔C，多年LTE／GSM协议开发经验，熟悉UE侧和eNB侧协议开发流程。曾先后就职于多家知名的通信/半导体类公司，带领过团队从阅读3GPP协议开始，完成整个eNB MAC层的代码设计和编写工作。2008年硕士毕业于东南大学导航制导与控制专业。
责编： 贾维娣（[email protected]）微信联系jiaweidi1214加入“CSDN物联网技术交流群”，与更多专家、技术同行进行热点、难点技术交流。
1. LTE 终端为什么要申请 RB 资源
LTE系统由终端和网络设备组成，终端一般使用UE（ User Equipment）表示， 最常见的UE就是手机， 网络设备包括eNB（ Evolved Node B）、核心网等节点单元。 UE和eNB之间通过无线传输， 这种传输通常被称作空口传输， eNB与核心网之间则通过有线连接。
只有正常驻留在一个服务小区中的UE，才能执行文件收发或拨打电话等业务。每个服务小区都会对应着一个eNB节点，该eNB节点负责为小区内所有的UE分配RB（ Resource Block，资源块）资源。 在协议分层实现中，应用层的文件收发或拨打电话等业务数据，最终都需要映射到相应的物理共享信道，并通过物理共享信道中的RB来承载和进行空口无线传输。
如果UE有文件需要上传，则需要eNB为该UE在物理上行共享信道PUSCH中分配RB资源，而如果UE有文件需要下载，则需要eNB为其在物理下行共享信道PDSCH中分配RB资源。如果eNB没有为本小区中的某个UE在共享信道中分配RB资源，那么UE就不能执行相应的业务。
2. LTE 终端申请资源的三种方式
当UE完成随机接入， 需要向网侧上传用户数据时，必须要有PUSCH信道中的上行RB资源，如果没有RB资源则需要预先向网侧申请RB资源。 LTE协议规范为UE提供了三种向网侧申请PUSCH信道中RB资源的方式：
向网侧发送BSR申请上行RB资源
BSR的全称是Buffer Status Report，即缓存状态报告。 UE可以在MAC层的PDU中插入一个BSR控制单元来告诉网侧：我的某个或某几个逻辑信道组当前有多少字节的数据需要发送，希望你 （网络）能分配一些上行RB资源给我 （ UE）。
这种通过发送BSR控制单元的方式，可以让网侧知道UE大概需要发送的数据量的范围，网侧可以针对性的为该UE分配上行RB资源的数目。但是， UE发送的BSR控制单元这个动作本身就是在PUSCH信道中传输的，需要使用PUSCH信道中的RB。 如果UE当前没有分配到PUSCH信道中的RB资源， 是没有办法向网侧发送BSR信息的， 此时UE需要通过下面的方式向网侧发送资源申请。
向网侧发送SR申请上行RB资源
SR的全称是Scheduling Request，即调度请求。 如果UE触发了一个常规BSR（ BSR的一种类型），同时发现UE当前并没有获得PUSCH信道中的上行RB授权，且不受上行SPS限制的时候， UE可以在PUCCH信道中通过发送SR信号的方式来申请上行RB资源。
跟BSR的方式相比，这种通过SR申请的方式有个缺点， 就是网侧收到的只是一个SR信号，并不知道UE大概需要上传多少字节的数据， 无法判断分配多少的资源是合适的。
网侧收到UE的SR请求后，分配多少RB资源是由设备生产厂家的算法决定的。 一般来说， 网侧收到SR信号后，分配的RB资源至少能够允许UE通过BSR申请一次上行RB资源。
并不是所有的UE都能发出SR信号。 SR在PUCCH控制信道中传输， 而PUCCH信道的资源本身也是有限的。 网侧的RRC层会根据实际需要，只给某些UE配置SR资源。只有配置了SR资源的UE，才能向网侧发送SR请求，而没有配置SR资源的UE，是无法向网侧发送发送SR请求的。
如果某个UE触发了常规BSR，但无法发出BSR控制单元， 且又不能发出SR，那么这个时候UE就需要通过发起竞争随机接入过程来申请上行RB资源。
发起竞争随机接入过程申请上行RB资源
发起竞争随机接入过程主要有两个目的， 获取上行RB资源和获取上行TA同步。
在这种资源申请方式中，UE将在MSG3中插入一个BSR控制单元来告诉网侧大概有多少字节的数据需要上传。由于通过这种方式申请资源的时延是最大的，所以只是UE的最后选择。
当然，如果UE是第一次接入网络，那么第一次申请资源只能通过竞争随机接入过程完成，后续再通过SR和BSR的方式申请上行RB资源。
总结一下上文的描述： UE 完成随机接入过程之后， 申请上行资源的时候将优先采用 BSR 的方式，如果不能发送 BSR，则可能采用 SR 的方式，最后才会考虑竞争随机接入的方式， 如下面的图 2-1 所示。
需要注意的是，无论是通过 BSR 申请，还是 SR 申请，抑或是通过竞争随机接入申请，网侧实际分配的 RB 资源可能都不足以让 UE 一次性传完所有的待传数据， UE 需要继续向网侧申请资源。
3. 通过 BSR 申请资源
网侧收到 BSR 后，根据 BSR 携带的内容，为 UE 分配合适的资源。 这里就有个问题： UE 的待传数据量是动态随机变动的，比如某个时刻 UE 需要发送 999个字节的数据，而下一秒可能需要发送 10001 个字节的数据，这种变化是不确定的， UE 怎么向网侧表达这种需求信息呢？最简单的方法，当然是 UE 将具体的数字（比如 10001 这个数）编码到 BSR 的信息里，但这样的话，在空口中传输的 bit 位个数就比较多。协议在这里采用了另一种方式来编码 BSR 信息：使用0～63 这 64 个索引， 每个索引值代表不同的字节范围。这样无论 UE 有多少数据要发， BSR 只需要 6 个 bits 的空间就足够了，减少了空口传输的比特位数。而且， UE 在空口中发送具体的字节数也是没有意义的，毕竟当 eNB 为 UE 调度资源的时候， UE 侧 BSR 的信息有很大的概率已经更新为其它值了。
UE 上报的 BSR 控制单元（control element）有两种格式：
当 BSR 属于 Short BSR（短 BSR）或者 Truncated BSR（截短 BSR）类型时， BSR 控制单元固定占 1 个字节，只能携带 1 个逻辑信道组的 BSR 信息。该 BSR 信息所对应的逻辑信道组 ID 固定占用 2 比特，取值 0～3， BSR 域固定占 6 比特，取值 0～63。
当 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 值。
两种格式如下面的图 3-1 所示。
每个 MAC 控制单元都对应着一个 MAC 子头，这个子头里的 LCID 域用来表示控制单元的类型。上面ᨀ到的 BSR 的三种类型 Short BSR、 Truncated BSR、Long BSR，就是通过子头中的 LCID 值确定的，如下表 3-1 所示。
协议为这三种 BSR 类型分别定义了不同的 LCID 值：如果与控制单元相对应的子头的LCID 值是28 （即二进制11100），那么表示UE 上传的是Truncated BSR，这个时候网侧 MAC 层只需要提取 1 个字节的控制单元码流，从中就可以解析出逻辑信道组 ID 号和 BSR 值；类似的，如果与控制单元相对应的子头的 LCID 值是 30，则表示 UE 上传的是 Long BSR，网侧需要ᨀ取 3 个字节的控制单元码流，
从中解析出所有逻辑信道组的 BSR 值。
4. 触发 BSR 的几种方式
当以下事件之一发生时， UE 将会触发一个 BSR，此时若该 UE 也存在着足够的、可以承载 BSR 控制单元的 PUSCH 上行 RB 资源，那么 UE 就会组装一个携带 BSR 控制单元的 MAC PDU，发向 eNB。
（1）当属于某个逻辑信道组的某个逻辑信道有上行数据待传输，并且这条逻辑信道的优先级高于目前任何逻辑信道组中任何逻辑信道的优先级，或者目前同个逻辑信道组中所有其它的逻辑信道均无待传数据，此时将触发一个 BSR，且该 BSR 叫做常规 BSR（ Regular BSR）。如下面三种触发常规 BSR 的场景：
当 UE 触发了一个常规 BSR 且当前 TTI 时刻 PUSCH 没有上行 RB 可用时，是没有办法向 eNB 发送 BSR 的。如果此时网侧已经为该 UE 配置了 SR 资源，那么能否继续通过发送 SR 申请资源还要看下面两种情况，只有满足其中之一，才会通过 SR 发送资源申请：
（A）没有已经配置的上行授权。如果网侧激活了 UL SPS，那么认为该 UE的上行授权已经被配置。
（B）当前的常规 BSR 是由某个逻辑信道有上行可传数据触发的，但 RRC并没有配置该逻辑信道的 logicalChannelSR-Mask 参数。换句话说，如果 UE已经触发了一个常规BSR，且已经配置了上行授权 ，此时若网侧将参数logicalChannelSR-Mask 设置为 true，就不会触发 SR。logicalChannelSR-Mask 参数属于逻辑信道的参数，在logicalChannelConfig 信元中配置。
综合（A）和（B），当 UE 触发了一个常规 BSR，且已经配置了上行授权，同时该逻辑信道的 logicalChannelSR-Mask 为 true，那么就不能（也没有必要）通过发送 SR 申请资源。
（2） UE 分配有上行资源，并且填充比特数大于或等于 BSR 控制单元与其MAC 子头的比特数之和，此时将触发一个 BSR，且该 BSR 叫做填充 BSR （ Padding BSR）。之所以增加这种机制，主要是基于有效利用资源的考虑。示意图参考下文的图 4-2。
（3）周期定时器 periodicBSR-Timer 超时，此时 UE 将会触发一个 BSR，且该 BSR 叫做周期 BSR（ Periodic BSR）。
（4）重传定时器 retxBSR-Timer 超时，并且 UE 在某个逻辑信道组中的任意一个逻辑信道有可传数据，此时 UE 将会触发一个 BSR，且该 BSR 也叫做常规BSR。
retxBSR、periodicBSR 定时器由 RRC 配置，在 radioResourceConfigDedicated信元的 mac-MainConfig 字段中带给 UE，如下方所示周期定时器和重传定时器的参数列表。单位是子帧或 ms， sf320表示 320ms。
MAC-MainConfig ::= SEQUENCE {
ul-SCH-Config SEQUENCE {
...
periodicBSR-Timer ENUMERATED {
sf5, sf10, sf16, sf20, sf32, sf40, sf64, sf80,
sf128, sf160, sf320, sf640, sf1280, sf2560,
infinity, spare1} OPTIONAL, -- Need ON
retxBSR-Timer ENUMERATED {
sf320, sf640, sf1280, sf2560, sf5120,
sf10240, spare2, spare1},
...网侧收到的 BSR 控制单元中只有三种类型：长 BSR、短 BSR 和截短 BSR，这些是从 BSR 长度的角度分类的，而常规 BSR、填充 BSR 和周期 BSR，则是从BSR 触发原因的角度分类的。这两种分类之间存在着一定的关系，比如对于常规BSR 来说，既可能是长 BSR 也可能是短 BSR，下面具体说说这两种分类方式之间的关系。
常规 BSR
如果 UE 发送的是常规 BSR，且该 TTI 有超过 1 个逻辑信道组有可传数据，那么上报长 BSR，否则上报短 BSR。上面图 4-1 中的场景 1，有 4 个逻辑信道组有数据可传，此时上报长 BSR；在场景 2 中，只有 1 个逻辑信道组有数据可传，此时上报短BSR；场景 3 与场景 2 的触发原因相同，也是由于 LCG-ID1 中只有 1个逻辑信道 5 有可传数据，但因为 LCG-ID0 中的逻辑信道 1 也有可传数据，所以上报长 BSR。
填充 BSR
（A）如果填充比特数大于或等于短 BSR 与其 MAC 子头的比特数之和，但小于长 BSR 与其 MAC 子头的比特数之和，那么：
如果上报 BSR 的 TTI 时刻有超过 1 个逻辑信道组的数据可传，则上报具有最高优先级逻辑信道的逻辑信道组的截短 BSR。之所以称为截短 BSR，是因为此时有多个逻辑信道组的数据可传，按理说应该上报长 BSR 的，但限于可用的填充资源有限，只能发送1 个逻辑信道组的BSR，所以定义了这个“截短BSR”，以便于区分一个字节的短 BSR。
否则，上报短 BSR。
（B）否则，如果填充比特数大于或等于长 BSR 与其 MAC 子头的比特数之和，则上报长 BSR。
周期 BSR
如果 UE 发送的是周期 BSR，且该 TTI 有超过 1 个逻辑信道组有可传数据，那么上报长 BSR，否则上报短 BSR，不会上报截短 BSR。我们在讨论常规 BSR、周期 BSR、填充 BSR 的时候，它的修饰词常常是“触发” (trigger)，而在᧿述长 BSR、短BSR、截短 BSR 的时候，它的修饰词往往是“发送”（ report），注意这里的区别。
5. 目前面临的流量掉坑问题和解决方案
在实际测试过程中，有时候我们会发现， UE 在执行上行数据传输的过程中，在某段时间流量会突然降低，比如由稳定的 10Mbps 突然降低到 8Mbps，如图5-1 所示，那这是为什么呢？
这个问题往往是由于 UE 在空口中没有检测到 DCI0 导致。 UE 通过 BSR 或SR 向 eNB ᨀ交上行 RB 资源申请后， eNB 会通过 DCI0 告诉 UE，为该 UE 分配的 RB 的位置和大小数目，但如果 UE 漏检了 DCI0， UE 就没有办法使用这些 RB资源。
虽然协议引入了重传定时器，但仍然还有一些问题。如图 4-3 所示，因为重传定时器的最小时间周期是 320ms，那么就意味着 UE 在图 5-1 所示的场景下，可能需要等待 320ms，才能向 eNB 申请 PUSCH 资源， 流程如图 5-2 所示。
对于正在执行上行灌包业务的 UE 来说， 320ms 时间内无法上传数据，可能就会导致几 M 的流量损失， 就如同 5-1 所示的曲线。
图 5-1 的红色柱形图中，因 320ms 无法上传数据，导致这 1 秒内的流量出现“掉坑” 现象。依据目前的协议是无法从根本上来解决这个问题。但我们可以进行某些处理来避免出现这种“掉坑”现象的概率。
比如， 如果是 DCI0 漏检导致的掉坑， eNB 可以继续执行自适应重传，并使用新传时的 MCS 值，如图 5-3 所示。 从实际测试效果上看，这种处理方式可以有效的降低上行流量“掉坑”的概率，提升系统的上行吞吐量。
