05:52 - 
FAQ
No comments
FAQ
No comments
How Buffer Status Reports and Uplink Scheduling works in LTE?
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:
- o 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.
- o 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.
- o 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.
- o 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.
Padding BSR
o When a UE does not have enough data to completely fill a resource allocation from the eNB the unused space is referred to as “padding”. If this padding space is large enough to accommodate a BSR then the UE is expected to send a BSR, even when there is no pressing reason for doing so. Hence this type of BSR is called a “Padding BSR”. Depending on the amount of padding space available it could be a short or long BSR, and if short, the UE sends info related to the LCG containing the highest priority logical channel that has data available for transmission. The idea is that the eNB scheduler benefits from getting more up to date info.
o Note that if either a Regular or Periodic BSR is triggered it will be sent at the next opportunity along with data if there is data and there is room for both the data and the BSR. These BSRs have higher priority than the data. In contrast, a Padding BSR has lower priority than data so is only sent when there is available space and no more data.
o It is also possible that a Padding BSR and a Regular/Periodic BSR are triggered for the same TTI. In this case the longer of the two choices is sent.
0 comments:
Post a Comment