UE向 eNB发送SR时，只携带了是否有上行数据的信息，而并没有将所要传输上行数据的大小告知eNB。eNB只会分配一个固定大小的上行资源，UE在此资源上要么发送上行数据（上行资源太小足够），要么发送Buffer status Report(BSR)（上行资源不够）。？是否正确？
在高层UE根据业务的不同可以建立多个无限承载（Radio Bearer）,没个Radio Bearer都是一个逻辑信道。BSR的触发如果以逻辑信道是否有数据发送的话，那么一个UE在同一时刻可能会存在很多的BSR，这显然不合理。LTE将多个逻辑信道放到一个所谓的LCG（Lofical Channel Group，总共四个）里面，以LCG为单位上报BSR。需要注意的是某逻辑信道可能不属于任何一个LCG，此时这个逻辑信道不会有BSR的相关行为。LTE也存在基于逻辑信道的SR。
某个逻辑信道属于哪一个LCG是在逻辑信道建立时被设置的，配置字段为LogicalChannelConfig.logicalChannelGroup，如下：

同一LCG内部的逻辑信道一般具有相似的调度需求。具体的LCG划分是由算法实现的。从这里可以看出eNB无法知道某个逻辑信道的buffer状态，但由于同属一个LCG的Qos/Prority类似，该逻辑信道的Buffer状态触发LCG上报BSR，分配的上行资源一般是可以满足要求的。
BSR通过MAC层的BSR MAC Control Element上报。在MAC层，BSR有两种格式：
1， Short BSR/ Truncated BSR
Short BSR顾名思义就是一种较短的BSR，只包含了LCG ID和BufferSize两个域，如下图所示。LCG ID占2Bit，BufferSize占6bit,指明了UE在该BSR对应TTI内所有MAC PDU都生成以后，改LCG下所有逻辑信道的RLC层和PDCP层中剩余待传数据的总和，以Byte为单位不包括头部信息。

2，Long BSR
Long BSR比Short BSR 长，依次包含了所有LCG (0-3)的BufferSize信息，如下图所示。注意这里的LCG ID已经隐含在顺序里面了。

事实上BufferSize并不直接指明buffer的大小， 准确来讲应该是BufferSizeIndex，查表（ Table 6.1.3.1-1 或 Table 6.1.3.1-2）之后才能得到 UE 真正需要发送的“近似”上行数据量。

一个 BSR MAC control element 与一个 MAC subheader 对应。BSR对应的MAC subheader 中的LCID 域如下表所示。

UE触发BSR的发送有如下几种情况：
1，4个LCG的所有逻辑信道为空时，有一逻辑信道有信赖数据需要发送。
2， UE 已经发送了一个 BSR，并且正在等待 UL grant，此时有高与4个LCG内所有逻辑信道优先级的数据出现，将触发BSR。
3， UE 周期性更新bufferstatus。这个周期是由Mac-MainConfig.periodicBSR-Timer控制的，如果超时则发送BSR。这种情况一般出现在大文件的传输时，BSR计算的数据大小仅仅包含了MAC和PDCP并不是所有待传数据的大小，此时，周期性更新bufferStatus是一个好的解决办法。
4， BSR重传
5， Padding BSR
值得注意的是BSR的发送是需要上行资源的，通常情况都是SR->BSR,某些情况下UE没有足够的上行资源发送BSR，此时如果BSR必须发送，则BSR->SR。