The eNodeB is responsible for UL QoS management. In order to fulfill this responsibility eNB needs ongoing information from the UE.
The UE needs a way to report to the eNB which radio bearers (RBs) need UL resources and how much resource they need. The eNB can then
schedule the UE based on the QoS characteristic of the corresponding radio bearers and the reported buffer status.
If a UE is connected to a number of PDNs, say IMS, Internet and a VPN, it may have quite a few radio bearers configured in addition to
the RRC signaling RBs. Keeping the eNB informed of the status of a large number of radio bearers will require considerable signaling
overhead. Consequently the LTE standards include the concept of a Logical Channel Group (LCG). This signaling reduction mechanism allocates
radio bearers to one of four groups. The mapping of a radio bearer (or logical channel) to a Logical Channel Group is done at radio bearer
setup time by the eNB based on the corresponding QoS attributes of the radio bearers such as QoS Class Identifier (QCI).
The introduction of the LCG has an impact on the UE buffer status reports which still need to keep the eNB informed as much as possible.
The UE reports an aggregate buffer status for the combination of radio bearers in a logical channel group. The eNB knows the radio bearers
contained in the group and their priorities. Although the eNB may not have status on an individual radio bearer, provided that the QoS
requirements of the bearers in an LCG are similar it can schedule the UE in a fair and appropriate fashion.
To help the eNB, the UE sends Buffer Status Reports (BSRs) for the LCGs. BSRs are triggered under the following conditions:
1 New data arrives in previously empty buffers: Assuming we are at the “beginning” of UL data transmission when all data buffers are empty,
if data becomes available for transmission in the UE for any radio bearer a BSR is triggered.
2 Higher Priority data arrives: If the UE has already sent a BSR and is waiting for a grant but then higher priority data becomes available
for transmission, the eNB needs to know this and therefore a new BSR is triggered. Note that this happens even when the triggering RB is in the
same LCG for which there is an outstanding BSR.
3 To update the eNB about the current status of buffers: If, for example, a UE is uploading a file, the data is arriving in the UE transmission
buffer asynchronously with respect to the grants it receives from eNB. Consequently there is an ongoing need to keep the eNB updated as to the
amount of data still to be transmitted. For this purpose the UE keeps a timer. When the periodicBSR-Timer expires, a BSR is triggered. The timer,
configured by RRC, ranges from 5ms up to 2.56 seconds. It can be disabled by setting it to infinity, which is also the default.
4 To provide BSR robustness: The LTE standard provides a mechanism to improve the robustness of buffer status reporting. We want to avoid deadlock
situations which may occur when the UE sends a BSR but never receives a grant. A BSR retransmission mechanism is built into the UE implementation.
The UE keeps a retxBSR-Timer which is started when a BSR is sent and stopped when a grant is received. If the timer expires, and the UE has still
has data available for transmission, a new BSR is triggered. The retransmission timer, configured by RRC, ranges from 320ms up to 10.24 seconds.
Unlike the periodic timer it cannot be disabled. The default is 2.56 seconds.
Relationship between BSR and Grant processing:
Interestingly, there is no direct relationship between the BSRs sent by the UE and how it processes a grant from eNB. Resource grants are allocated
by the UE to radio bearers on a logical channel priority basis. Membership in a particular LCG is not relevant. For example, let’s say a UE requests
resources for LCG 2 in order to send a HTTP request. Before the grant was received an RRC message becomes ready to send. Then when the grant is
received the RRC message gets priority and uses up as much of the resource as it needs. The HTTP request will get the leftovers, if any. Note that
RRC messages are sent on SRBs which are assigned to LCG 0 by default.