LTE Buffer Status Report (BSR)

What is Buffer Status Report?

Buffer status report as the name indicates will carry the information on the amount of data available for each Logical Channel Group (LCG) from UE to eNB.

Why is BSR required?

When Scheduling Request Indication (link on SR) is send to eNB for UL grant, eNB has no idea on the amount of data available at UE due to this

1. eNB will not be knowing how much UL grant needs to allocate for the UE and 
2. also if the allocated grant was not sufficient, UE needs to keep sending SR's for UL grants till all the data is served. 

This will slow the UL transmissions as UE has to send SR and wait for UL grant for the next UL transmission.
To avoid this delay, BSR is send in the first UL grant allocation received after sending SR (based on trigger conditions explained in the next sections).
Now eNB with the BSR info has better understanding of the amount of data pending at UE and will send UL grant allocations based on the BSR without further waiting for SR's from UE.

Triggers for BSR?

Any of the below conditions will trigger BSR in UE:

1.  Data arrives for logical channel which belongs to a LCG and if
• no data is available on any of the logical channels belonging to any other LCG's or
• data is available only for the logical channels belonging to the lower priority LCG.
2. upon retxBSR-Timer expiry and UE has data available for transmission for any of the logical channels which belong to a LCG.
3. Number of padding bits after UL grant is allocated is equal to or larger than the size of the Buffer Status Report MAC CE and its subheader. 
4. periodicBSR-Timer expires

BSR triggered in the conditions (1) & (2) is referred as Regular BSR.
BSR triggered in the condition (3) is referred as Padding BSR.
BSR triggered in the condition (4) is referred as Periodic BSR.

Types of BSR's & LICD's of BSR's in MAC MAC CE?

1. Long BSR: When more than one LCG has data available for transmission long BSR MAC CE is used. Corresponding MAC CE LCID value is b'11110.
2. Short BSR: When only one LCG has data available for transmission short BSR MAC CE is used. Corresponding MAC CE LCID value is b'11101.
3. Truncated BSR: When more than one LCG has data available for transmission but remaining UL allocation is not sufficient to sent Long BSR then Truncated BSR MAC CE is used. Corresponding MAC CE LCID value is b'11100.

Regular & Periodic BSR  based on the data availability on LCG's can form either Long or Short BSR's MAC CE.

Padding BSR on the other hand can form either Long, Short or Truncated BSR's MAC CE based on the data availability on LCG's & the number of padding bits left after UL resources are allocated.

When to send BSR?

When at least one BSR has been triggered and not cancelled

1. If the UE has UL grant for new transmission for this TTI
• generate and include the BSR MAC CE in the MAC PDU.
• start or restart periodicBSR-Timer except when all the generated BSRs are Truncated BSRs
• start or restart retxBSR-Timer.
2. else if a Regular BSR has been triggered
• if a SemiPeristantScheduling UL grant is not configured or if the Regular BSR was not triggered for the data becoming available for a logical channel on which logical channel SR masking is setup
• a Scheduling Request is triggered for obtaining UL grant.
3. In all other cases, do nothing.

When are the BSR's cancelled?

If any of the below two conditions are satisfied, all the triggered BSR's are cancelled

1. if UL grant in this subframe can accommodate all pending data available for transmission but is not sufficient include BSR MAC CE and its subheader.
2. when a BSR is included in a MAC PDU for transmission.

BSR transmission for Multiple MAC PDU & other conditions

Below are the few important point to be considered while forming BSR's

1. Even when multiple events trigger BSR, at max only one MAC BSR CE can be transmitted with Regular & Periodic having more priority then Padding BSR's.
2. When forming multiple MAC PDU's, The UE shall transmit at most one Regular/Periodic BSR in a TTI. UE may include a padding BSR in any of the MAC PDUs which do not contain a Regular/Periodic BSR.
3. All BSRs transmitted in a TTI always reflect the buffer status after all MAC PDUs have been built for this TTI. 

Configuration parameters for BSR

RRC configures MAC with Periodic-BSR timer and retxBSR timer values (Mac-main-config IE).

Periodic-BSR timer: Periodic BSR timer is restarted every time either a long/short BSR is transmitted.

retxBSR timer: For every UL grant received, retxBSR Timer is restarted.

References

1. 3GPP 36.321

LTE Timing Advance Command

What is Timing advance in LTE and why is it required?

As UE is not always stationary with respect to eNB, the variation in distance between UE and eNB will reflect in UL transmission time (msg received at eNB). Due to the change, eNB encounters interference as UL transmission of different UE's can be overlapping.

How is it achieved?

To avoid this kind of interference, eNB will either periodically or need basis correct the UE to either advance or delay the UL transmission with a granularity of 16 Ts(basic time unit).
UE receives the Timing Advance (TA) in either the MAC CE Timing Advance command or in RAR during RACH procedure.

1. if UE receives the TA in MAC CE or
   if UE receives the TA in RAR and if preamble index is not selected by UE or
   if UE receives the TA in RAR and if time alignment timer is not running
• apply the Timing Advance command
• start or restart time alignment timer
2. else ignore the Timing Advance command

The new correction is valid till the expiry of time alignment timer. As cyclix prefix (CP) is added to start of each OFDM symbol, the overlapping interference at eNB can be ignored till the time it's not exceeding the Tcp (Duration of Cyclix Prefix).

What happens if Time alignment timer is expired?

When Time alignment timer is expired, UE is assumes to have lost UL sync with eNB and

1. releases PUCCH/SRS configuration
2. flush all HARQ buffers
3. clear any configured UL & DL grants

How does UE obtain the time alignment timer configuration?

Time alignment timer value is received in SIB-2 (common to all UE's) and mac-MainConfig (UE specific value). 

UE applies the value received in SIB-2 when moving from idle to connected mode or during rrc connection reestablishment radio link recovery phase.

When UE receives dedicated time alignment timer in either the rrc connection setup or rrc connection reconfiguration, UE will apply the new value during the next timer restart.

TimeAlignmentTimer ::= ENUMERATED {
sf500, sf750, sf1280, sf1920, sf2560, sf5120,
sf10240, infinity}

References

1. 3GPP 36.213
2. 3GPP 36.321

LTE Random Access Procedure (RACH)

When is RACH Procedure triggered?

RACH procedure is triggered when UE is camped on to a cell and any of the below conditions happens

1. UE requires UL synchronization with eNB for sending UL data 
• UE is moving from idle to connected  or
• Handover to other cell (Target eNB may/may not provide dedicated preamble through rrc reconfiguration message of source eNB).
2. eNB receives DL data but finds UL synchronization with UE is lost (PDCCH order).
• eNB notifies UE to do PRACH by sending DCI 1A with/without a dedicated preamble info.
3. UE doesn't have any grant to transmit UL Data and finds PUCCH resources are not configured/released for transmission of SR
• eNB doesn't configure UE with any PUCCH resources for SR transmission or
• When max-SR transmission have reached, UE releases PUCCH resources or
• Time alignment timer expiry, UE releases PUCCH resources.

Different types of RACH Procedures and their differences

RACH procedures are of two types

1. Non-Contention Based:
• UE uses the dedicated preamble allocated by  eNB.
• Scenario: Handover and PDCCH order.
2. Contention Based
• Preamble is selected by MAC itself. While doing RACH procedure several UE's may selected the same preamble, so additional contention resolution is required. Contention resolution procedure is assumed to be completed when UE receives contention resolution MAC CE or DCI 0 with C-RNTI for the transmitted msg3.

RACH procedure

RACH procedure sequence is as follows

1. Preamble selection: If Preamble index is not provided to UE, based on the msg3 size, power level and other parameters in RACH-CommonConfig, UE will select a preamble index.
2. RACH Transmission: Based on the prach-config parameter, UE computes the prach transmission opportunity and transmits preamble index on PRACH channel. At the same time RA-RNTI is computed based on the RACH transmission parameters.
                                            RA-RNTI = t_id +10* f_id
3. PDCCH RA-RNTI Montioring: 3ms/sub-frames after RACH transmission sub-frame, UE will start monitoring the PDCCH channel for RA-RNTI for a duration of RA-Response window irrespective of the measurement gap.
4. RAR Reception: If UE successfully receives Random Access Resonse (RAR) on RA-RNTI  and contains the same preamble index in the received RAPID.
   If Preamble index was provide by eNB, RACH procedure ended and is considered as successful
   else UE proceeds to contention resolution procedure.
• apply Timing Advancement Command (TAC)
• update the Temp C-RNTI to the value received (only in case of contention resolution process)
• use the received UL grant for transmitting msg3 (only in case of contention resolution process)
5. RAR Reception: Else if UE successfully receives Random Access Resonse (RAR) on RA-RNTI  but contains back off indicator.
• set the back off parameter in UE to the BI value received in RAR.
6. RAR Failure Case:If UE fails to receive RAR within RA-Response window or if received RAR doesn't contain the transmitted preamble index in any of the RAPID's, RACH procedure is considered as unsuccessful
• increment PREAMBLE_TRANSMISSION_COUNT by 1  
• if PREAMBLE_TRANSMISSION_COUNT is PreambleTransMax +1, indicate RACH problem to upper layers.
• if the preamble was selected by UE, UE will select a random back off time from 0 to back off parameter before going to retry RACH procedure.
• retry the RACH procedure step (1).

What does UE send in UL for the received RAR-GRANT?

Based on the below conditions which triggered RACH procedure MAC will be forming the TB (msg3)

1. If RACH is triggered due to CCCH data, msg3 will be either RRC connection request or RRC connection re-establishment request.
2. Else if Grant is received in the 1st RAR and RACH is not triggered due to CCCH data and UE contains a valid C-RNTI; MAC will include the C-RNTI MAC CE along with the UL data/BSR.

Contention Resolution Procedure

Contention resolution procedure is applicable only if preamble index is selected by UE. UE starts/restarts contention resolution timer for transmission of msg3 or non-adaptive HARQ re-transmisssion of msg3. After transmission of msg3, UE will monitor the PDCCH channel for C-RNTI/Temp C-RNTI till contention resolution timer is expired irrespective of the measurement gap.

If UE receives data notification on PDCCH channel and 

1.  If C-RNTI MAC CE was included in the msg3 and if RACH was due to PDCCH order and PDCCH transmission was addressed to C-RNTI or  if RACH was triggered by MAC itself and PDCCH transmission was addressed to C-RNTI and contains UL grant for new transmission
• consider Contention resolution as successful.
• stop contention resolution timer
• discard Temp C-RNTI
• RACH procedure is considered successful.
2. Else if msg3 was CCCH data and UE receives PDCCH transmission addressed to Temp C-RNTI and MAC PDU decodes successfully and contains the contention resolution id in msg3.
• consider Contention resolution as successful.
• stop contention resolution timer
• set C-RNTI to Temp C-RNTI.
• discard Temp C-RNTI
• RACH procedure is considered successful.
3. Else consider contention resolution is not successful.

If contention resolution timer expires, contention resolution is not successful.

If contention resolution is not successful then

1. if time alignment timer is running, stop the time alignment timer
2. flush HARQ buffer used for msg3
3. increment PREAMBLE_TRANSMISSION_COUNT by 1  
4. if PREAMBLE_TRANSMISSION_COUNT is PreambleTransMax +1, indicate RACH problem to upper layers.
5. UE will select a random back off time from 0 to back off parameter before going to retry RACH procedure.

What happens when lower layers sends RACH problem indication?

When upper layers receives RACH problem indication, UE will re-try to camp on to the same cell, while parallel doing PLMN search to find any other alternative cells.

RACH parameters obtained from SIB-2 and Mobility message

RadioResourceConfigCommon in SIB-2/RRC mobility message contains all the parameters required for RACH (prach-config & RACH-ConfigCommon).

PRACH-ConfigSIB ::= SEQUENCE {
     rootSequenceIndex INTEGER (0..837),
     prach-ConfigInfo PRACH-ConfigInfo
}

PRACH-ConfigInfo ::= SEQUENCE {
     prach-ConfigIndex INTEGER (0..63),
     highSpeedFlag BOOLEAN,
     zeroCorrelationZoneConfig INTEGER (0..15),
     prach-FreqOffset INTEGER (0..94)
}

RACH-ConfigCommon ::= SEQUENCE {
      preambleInfo SEQUENCE {
              numberOfRA-Preambles ,
              preamblesGroupAConfig SEQUENCE {
                       sizeOfRA-PreamblesGroupA,
                       messageSizeGroupA ENUMERATED {b56, b144, b208, b256},
                       messagePowerOffsetGroupB
       },
      powerRampingParameters SEQUENCE {
               powerRampingStep ENUMERATED {dB0, dB2,dB4, dB6},
               preambleInitialReceivedTargetPower,
      },
      ra-SupervisionInfo SEQUENCE {
               preambleTransMax,
              ra-ResponseWindowSize,
              mac-ContentionResolutionTimer
     },
    maxHARQ-Msg3Tx INTEGER (1..8), 
}

In case of handover additional RACH-ConfigDedicated is included in mobility message which contains dedicated preamble index for non-contention based RACH procedure.

RACH-ConfigDedicated ::= SEQUENCE {
     ra-PreambleIndex INTEGER (0..63),
     ra-PRACH-MaskIndex INTEGER (0..15)
}

References

1. 3GPP 36.321

LTE Scheduling Request

Scheduling Request is triggered when UE is in uplink sync with eNodeB and doesn’t have any PUSCH/PUCCH resource allocated for transmission of the new control plane or user plane data. 

UE uses the SR-Configuration received in RRC connection setup or RRC reconfiguration request to determine the next Scheduling Request (SR) available opportunity (computes the frame and sub-frame).

SchedulingRequestConfig ::= CHOICE {

release NULL,

setup SEQUENCE {

    sr-PUCCH-ResourceIndex INTEGER (0..2047),

    sr-ConfigIndex INTEGER (0..157),

    dsr-TransMax ENUMERATED {

    n4, n8, n16, n32, n64, spare3, spare2, spare1}

}

}

Based on the ConfigIndex, UE-specific periodicity and subframe offset is determined as below.

SR configIndex (I)	SRperiodicity (ms)	SR subframe offset
0 – 4	5	I
5 – 14	10	I-5
15 – 34	20	I-15
35 – 74	40	I-35
75 – 154	80	I-75
155 – 156	2	I-155
157	1	I-157

SR indication is transmitted based on the configured sr-PUCCHResourceIndex in the SFN and sub-frame number which satisfies the below condition.

((SFN*10+subframe)-SRoffset) mod SRperiodicity = 0

Nevertheless SR will NOT be transmitted if:

1. SR opportunity falls in measurement gap or
2. SR-Prohibit status timer is running or
3. DL PDCCH with UL resources is received

If eNB doesn't allocate any DCI's till when UE needs to retry SR?

UE is configured with SR-Prohibit timer & max SR retries. Whenever a SR is transmitted, SR Prohibit timer is started and UE is not supposed to re-transmit (when no valid PUSCH resource is received) SR  till SR-Prohibit timer is expired. When UE has retried max SR times, UE is considers to have lost uplink synchronization with eNB and will release PUCCH/SRS resources and initiate RACH procedure. 

References:

1. 3GPP 36.321
2. 3GPP 36.213

Cell Reselection, Redirection and Handover (2G/3G/4G)

Idle Mode Procedure (Reselection)

Reselection and its trigger conditions

Reselection procedure is triggered by UE when UE is in idle mode and finds the neighbor and serving cell received signal power/quality levels are satisfying the below conditions.

1. Neighbor cell is of high priority and received signal power/quality level is better than thresholdHigh limit or
2. Neighbor cell is of lower priority and serving received signal power/quality level is below the thresholdLow limit and the neighbor received signal power/quality is above the thresholdLow and
3. More than 1 second has elapsed since the UE camped on the current serving cell.

Cell properties like ThresholdLow, ThresholdHigh and Cell Priority values are obtained from the below System Information Blocks 

•         LTE SIB-3
•        LTE SIB-4                         (for Intra LTE) 
•         LTE SIB-5                         (for Inter LTE)
•         LTE SIB-6                         (for UMTS)
•         LTE SIB-7                         (for GSM)
•         LTE SIB-8                         (for CDMA)
•         WCDMA SIB19                 (for LTE)
•         GSM SI2quater                  (for 3G/LTE)

Lower the value of priority in SIB, lower is cell priority.

Cell Selection/Reselection Criteria

For cell camp

Srxlev> 0 AND Squal> 0

In case of reselection from a lower priority cell to higher priority cell the below condition should hold good for atleast the t-reselection timer

If threshServingLowQ is provided in SIB3, then

Squal > ThresxHighQ (FDD) or SrxlevTarget > ThresxHigh (TDD/GERAN/CDMA)

else 

            SrxlevTarget > ThresxHigh  

In case of reselection from a high priority cell to lower priority cell the below condition should hold good for atleast the t-reselection timer

If threshServingLowQ is provided in SIB3, then

SqualServing < ThresxServingLowQ &

SqualTarget > ThresxLowQ (FDD) or SrxlevTarget > ThresxLow (TDD/GERAN/CDMA)

else

SrxlevServing < ThresServingLow

SrxlevTarget  > ThresxLow

So when will UE start measuring the neighbor cells?

1. UE will always measure all the high priority cells (Inter & Intra RAT).
2. UE will start measuring Intra Freq low priority cells if serving cell satisfies the below condition 
   SrxlevServing < sIntraSearch(SIB3)
3. UE will start measuring Inter Freq and Inter RAT low priority cells if serving cell satisfies the below condition
   SrxlevServing < sNonIntraSearch(SIB3)

Where

Srxlev= Qrxlevmeas–(Qrxlevmin+ Qrxlevminoffset) –Pcompensation

Squal= Qqualmeas–(Qqualmin+ Qqualminoffset)

Srxlev	Cell selection RX level value (dB)
Squal	Cell selection quality value (dB)
Qrxlevmeas	Measured cell RX level value (RSRP)
Qqualmeas	Measured cell quality value (RSRQ)
Qrxlevmin	Minimum required RX level in the cell (dBm), obtained in SIB1
Qqualmin	Minimum required quality level in the cell (dB), obtained in SIB1
Qrxlevminoffset	Offset to the signalled Qrxlevmintaken into account in the Srxlevevaluation as a result of a periodic search for a higher priority PLMN while camped normally in a VPLMN,obtained in SIB1
Qqualminoffset	Offset to the signalled Qqualmintaken into account in the Squalevaluation as a result of a periodic search for a higher priority PLMN while camped normally in a VPLMN,obtained in SIB1
Pcompensation	max(PEMAX_H–PPowerClass, 0) (dB)
PEMAX_H	Maximum TX power level an UE may use when transmitting on the uplink in the cell (dBm) defined as PEMAX_H in [TS 36.101],obtained in SIB1
PPowerClass	Maximum RF output power of the UE (dBm) according to the UE power class as defined in [TS 36.101]

Connected Mode Procedure (Redirection & Handover)

Connected mode procedures are driven by eNB. eNB uses the measurement reports sent from UE to decide if redirection/handover is required.

When does UE get chance to measure neighbor cells?

eNB configures UE with specific measurement gap. During this time, UE can stop monitoring PDCCH channel and start measuring neighbor cells.  Measurement Gap duration is fixed to 6msec. Measurement gap config has a periodicity of either 40ms (gp0) or 80ms (gp1) and gapoffset value. Measurement gap will start from the SFN and sub-frame which satisfies the below condition  

           SFN mod T = FLOOR(gapOffset/10);

           subframe = gapOffset mod 10;

           with T = MGRP/10; MGRP = 40 for gp0 and 80 for gp1

Measurement gap configuration is received through RRC reconfiguration message. UE can also use the DRX cycles if configured for measurements.

Which Neighbor cells to measure?

Through RRC reconfiguration messages, UE will receive a measurement object, which contains the neighbor cells information and event condition to report.
Below are the lists of events reported by UE to eNB

A1	Serving becomes better than threshold
A2	Serving becomes worse than threshold
A3	Neighbor becomes offset better than serving cell + extra margin
A4	Neighbor becomes better than threshold
A5	Serving becomes worse than threshold1 AND neighbor becomes better than threshold2
A6	Neighbour becomes offset better than SCell
B1	Inter RAT neighbor becomes better than threshold
B2	Serving becomes worse than threshold1 AND inter RAT neighbor becomes better than threshold2

Why different procedures - Redirection & Handover?

In Handover procedure, target cell allocates all the required radio resources (Radio bearers and dedicated PRACH resource) upfront for the UE to move seamlessly. Target Cell radio resource information is provided to UE by serving cell in RRC reconfiguration message. UE stays in connected mode during this procedure.

In Redirection procedure, target cell will not be allocating any radio resources upfront. So UE has to release the radio connection (in serving cell) and use the target cell info provided in the RRC Reconfiguration (if any, else UE needs to do full scan) to camp and further request for the radio resources in target cells. UE goes to idle mode in serving cell and once it moves to target cell, UE moves to connected mode through RRC connection request.

Conversion between RSRP<->RSCP<->RSSI/ ECNO<->RSRQ

4G->2G/3G

• RSRP

The reporting range of RSRP is defined from -140 dBm to -44 dBm with 1 dB resolution.

Reported value	Measured quantity value	Unit
RSRP_00	RSRP < -140	dBm
RSRP_01	-140 < RSRP < -139	dBm
RSRP_02	-139 < RSRP < -138	dBm
…	…	…
RSRP_95	-46 < RSRP < -45	dBm
RSRP_96	-45 < RSRP < -44	dBm
RSRP_97	-44 < RSRP	dBm

• RSRP

The reporting range of RSRQ is defined from -19.5 dB to -3 with 0.5 dB resolution.

Reported value	Measured quantity value	Unit
RSRQ_00	RSRQ < -19.5	dB
RSRQ_01	-19.5 < RSRQ < -19	dB
RSRQ_02	-19 < RSRQ < -18.5	dB
…	…	…
RSRQ_32	-4 < RSRQ < -3.5	dB
RSRQ_33	-3.5 < RSRQ < -3	dB
RSRQ_34	-3 < RSRQ	dB

3G->4G 

• ECNO

The reporting range is for CPICH Ec/Io is from -24dB ...0 dB.

Reported value	Measured quantity value	Unit
CPICH_Ec/No _00	CPICH Ec / Io < ‑24	dB
CPICH_Ec/No _01	-24 < CPICH Ec / Io < ‑23.5	dB
CPICH_Ec/No _02	-23.5 < CPICH Ec / Io < ‑23	dB
…	…	…
CPICH_Ec/No _47	-1 < CPICH Ec / Io < -0.5	dB
CPICH_Ec/No _48	-0.5 < CPICH Ec / Io < 0	dB
CPICH_Ec/No _49	0 < CPICH Ec / Io	dB

• UTRA RSSI

The reporting range for UTRA carrier RSSI is from -100dBm ...-25 dBm.

Reported value	Measured quantity value	Unit
UTRA_carrier_RSSI_LEV _00	UTRA carrier RSSI < ‑100	dBm
UTRA_carrier_RSSI_LEV _01	-100 < UTRA carrier RSSI < ‑99	dBm
UTRA_carrier_RSSI_LEV _02	-99 < UTRA carrier RSSI < ‑98	dBm
…	…	…
UTRA_carrier_RSSI_LEV _74	-27 < UTRA carrier RSSI < -26	dBm
UTRA_carrier_RSSI_LEV _75	-26 < UTRA carrier RSSI < -25	dBm
UTRA_carrier_RSSI_LEV _76	-25 < UTRA carrier RSSI	dBm

• RSCP

The reporting range for CPICH RSCP is from -120 dBm ...-25 dBm.

Reported value	Measured quantity value	Unit
CPICH_RSCP_LEV _-05	CPICH RSCP < ‑120	dBm
CPICH_RSCP_LEV _-04	-120 < CPICH RSCP < ‑119	dBm
CPICH_RSCP_LEV _-03	-119 < CPICH RSCP < ‑118	dBm
…	…	…
CPICH_RSCP_LEV _89	-27 < CPICH RSCP < -26	dBm
CPICH_RSCP_LEV _90	-26 < CPICH RSCP < -25	dBm
CPICH_RSCP_LEV _91	-25 < CPICH RSCP	dBm

References:

1. 3GPP 36.133
2. 3GPP 36.304
3. 3GPP 36.331
4. 3GPP 25.133
5. 3GPP 44.018
6. 3GPP 45.008