Friday, July 4, 2014

Power Head Room

What is Power Headroom ?

Power headroom indicates how much transmission power left for a UE to use in addition to the power being used by current transmission. Simply put, it can be described by a simple formula as below.
    Power Headroom = UE Max Transmission Power - PUSCH Power = Pmax - P_pusch
If the Power Headroom value is (+), it indicates "I still have some space under the maximum power" implying "I can transmit more data if you allow".
If the power Headroom value is (-), it indicate "I am already transmitting the power greater than what I am allowed to transmit".

How does UE report Power Headroom Value ?

PHR is a type of MAC CE(MAC Control Element) that report the headroom between the current UE Tx power (estimated power) and the nominal power. eNodeB (Network) use this report value to estimate how much uplink bandwidth a UE can use for a specific subframe. Since the more resource block the UE is using, the higher UE Tx power gets, but the UE Tx power should not exceed the max power defined in the specification. So UE cannot use much resource block (bandwidth) if it does not have enough power headroom.

You will find the following fig and table from 36.321.


How can I figure out real power value from this report value ? You can find the mapping table from 36.133 as shown below.



When does UE transmit the Power Headroom Report ?

There are two triggers for PHR (Power Headroom Report).
    i) Path Loss Change greater than a certain threshold : UE can calculate the path loss based on RS(Reference Signal) power notified by network and the measured RS power at UE antenna port. If this value changes over a certain threshold UE transmit PHR.
    ii) By some peridic Timer.
These triggers are specified in RRC messages (e.g, RRC Connection Setup, RRC Connection Reconfiguration) as shown below.


BSR and Logical Channel Group

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.

Thursday, July 3, 2014

Timing Advance in LTE

In LTE, when a UE wants to communicate with an eNodeB (cell), one of the first things it has to do is get its timing adjusted using PRACH (Physical Random Access Channel) procedure. Why do we have to adjust the timing for the UE in LTE? To answer this question let us look at the following scenario:
UE1 is located near the cell edge and UE2 is located closer to the eNodeB as shown in the diagram. Both the UEs need to access the network for services and to do that they will first use the PRACH to initiate communications with the eNodeB. The PRACH is a collision based common Uplink (UL) channel used by all UEs in a cell to first communicate with the eNodeB. During this critical first communication the eNodeB will give the UE three important pieces of information:
1.       a temporary identifier (C-RNTI)
2.       permission to transmit on the UL (Grant)
3.       ADJUST the UEs UL transmission time
Lets focus only on the "adjustment of the UEs UL transmission time". Each time a UE enters a cell or powers on in a cell the UE needs to read the Downlink (DL) transmissions of the cell. To be able to read the DL transmissions it needs to understand where radio frames/subframes/slots start and end, in other words it synchronizes with the cell transmissions on the DL. The propagation delay experienced on the DL for UE1 is δ1 and propagation delay experienced on the DL for UE2 is δ2. In other words δ1 > δ2, because UE1 is further away from the eNodeB than UE2. It is important to note that UEs will use the DL arrival of sub frames as a reference to determine the time of transmission of its UL subframe.
Given this scenario (if we do not make any adjustments) the following will happen. Let us look at the timeline starting at subframe t and ending at subframe t+1 at the eNodeB. Lets assume that the eNodeB allocates Resource Block 3 on the UL for the subframe starting at time t to UE1.
  • Since UE1 receives the signal from eNodeB with a propagation delay of δ1, UE1's UL transmission time for subframe t will start at time (t+ δ1) with respect to eNodeB
  • UE1 receives UL allocation for subframe starting at time t, its transmission will be received by eNodeB starting at time (t+δ1+δ1) since UL transmission will also experience propagation delay (assumed to be equal for DL and UL)
  • Effectively the UE1's UL transmission for the subframe t will be received at the eNodeB starting at {t+(2*δ1)} and ending at {(t+1) + (2*δ1)}
Now let us see what happens if UE2 is allocated Resource Block 3 on the UL for the subframe starting at (t+1)! Note that this should be OK if there was no propagation delay!!
  • Since UE2 receives the signal from eNodeB with a propagation delay of δ2, UE2's UL transmission time for subframe starting at (t+1) will start at time {(t+1) + δ2} with respect to eNodeB
  • UE2 receives UL allocation for subframe (t+1), its transmission will be received by eNodeB starting at time {(t+1)+δ2+δ2} since UL transmission will also experience propagation delay (assumed to be equal for DL and UL)
  • Effectively the UE2's UL transmission for the subframe (t+1) will be received at the eNodeB starting at {(t+1) + (2*δ2)} and ending at {(t+2) + (2*δ2)}
As can be seen from the timeline diagram, the start of UE2's UL reception at {(t+1) + (2*δ2)} overlaps UE1's transmission which ends at {(t+1) + (2*δ1)}. Keep in mind δ1>δ2. If we do not make adjustments to UE timings, these overlaps will exist creating interference and resulting in reception failures at the eNodeB. One way to avoid this is to adjust the timing for every UE in the cell by measuring the propagation delays at the eNodeB for each UE in the cell. This is what is achieved by the PRACH preamble procedures.

When the PRACH preambles are sent, the eNodeB will measure the arrival delay for each UE and convey to each UE (via MAC signaling) the amount of timing adjustment it must do prior to its next transmission. For example, if UE1 and UE2 advance their timing and start their UL transmissions earlier by 2δ1 and 2δ2 respectively, their transmissions will be received at the appropriate subframe start and end times. This will prevent any collisions and interference with their transmissions.