LTE: Connected Mode DRX

In LTE, without Discontinuous Reception (DRX), the UE has to be awake all the time in order to decode downlink data, as the data in the downlink may arrive at any time. This means that UE has to be monitoring PDCCH in every subframe in order to check if there is downlink data available. This consumes a lot of the user equipment’s power
DRX in LTE is introduced to improve UE battery lifetime. In DRX, UE discontinuously receives PDCCH. This post discusses LTE Connected mode DRX.
The eNodeB configures DRX with a set of DRX parameters. These DRX parameters are selected based on the application type such that power and resource savings are maximized.
When DRX is enabled, there may be an extended delay in receiving data as, the UE may be in DRX Sleep state at the time of data arrival at the eNodeB, and the eNodeB would have to wait until the UE becomes ON. So the DRX parameters have to be carefully selected such that the packet delay is minimized and power saving is maximized.
During DRX mode, the UE powers down most of its circuitry when there are no packets to be received. During this time UE listens to the downlink (DL) occasionally which is called DRX Active state whereas the time during which UE doesn’t listen PDCCH is called DRX Sleep state
DRX is also beneficial to the eNodeB. Without DRX, the UE would be transmitting periodic CSI or SRS very frequently (based on the configuration). With DRX, during OFF periods, the UE is not allowed to transmit Periodic CSI or SRS, so the eNodeB can assign these resources to the other UEs to maximize resource utilization.

DRX Configuration
The eNodeB configures the following RRC parameters for DRX. Entire DRX configuration is sent under drx-config structure under MAC-MainConfig. Each DRX parameter and its’ purpose is explained below
In RRC specification, almost all the DRX timer values are specified in terms of psfs. psf is a PDCCH subframe in which UE listens for PDCCH. In FDD every subframe is a DL/UL subframe so every subframe can be a psf whereas in TDD, only DL subframes are considered to be psfs.
  • drx-Inactivity-Timer specifies the number of consecutive PDCCH-subframe(s) for which the UE should be Active after successfully decoding a PDCCH indicating a new transmission (UL or DL) . This timer is restarted upon receiving PDCCH for a new transmission (UL or DL). Upon the expiry of this timer the UE should go to DRX mode.
  • shortDRX-Cycle is the first type of DRX cycle (if configured) that needs to be followed when UE enters DRX mode. This IE indicates the length of the short cycle in subframes which include ON time followed by a possible OFF (inactivity) time.
  • drxShortCycleTimer expressed as multiples of shortDRX-Cycle. The timer value can vary from 1 to 16 (short DRX cycles). This timer indicates the number of initial DRX cycles to follow the short DRX cycle before entering the long DRX cycle
  • longDRX-CycleStartOffset defines long DRX cycle length as well as the DRX offset. DRX offset is used to calculate the starting subframe number for DRX cycle.
  • onDurationTimer specifies the number of consecutive PDCCH-subframe(s) at the beginning of each DRX Cycle (DRX ON). i.e., is the number of subframes over which the UE shall read PDCCH during every DRX cycle before entering the power saving mode (DRX OFF)
  • HARQ RTT Timer specifies the minimum amount of subframe(s) duration from the time new transmission is received and before the UE can expect a retransmission of the same packet. This timer is fixed and not configured by RRC. For FDD the HARQ RTT Timer is set to 8 subframes. For TDD the HARQ RTT Timer is set to k + 4 subframes, where k is the interval between the downlink transmission and the transmission of associated HARQ feedback
  • drx-RetransmissionTimer indicates the maximum number of subframes for which UE should be monitoring PDCCH when a retransmission from the eNodeB is expected by the UE.

Same onDurationTimer value is applied for both long and short DRX cycles
If shortDRX-Cycle is configured, the value of longDRX-Cycle shall be a multiple of the shortDRX-Cycle value
UE indicates the support of Short DRX cycle in featureGroupIndicators bit- 4
UE indicates the support of Long DRX cycle and DRX command MAC control element (together) in featureGroupIndicators bit – 5

DRX Command MAC Control Element
We have seen that a number of timers which controls the UE’s DRX state (ON/OFF). In addition to these timers the eNodeB’s MAC can also control UE’s DRX behavior by transmitting a command called DRX Command as a MAC Control Element.
When the eNodeB doesn’t have any (more) data to be sent to the UE, it can transmit DRX Command MAC CE to the UE. Upon reception of DRX Command MAC CE, the UE enters short DRX cycle if configured, otherwise, the UE enters long DRX cycle.
In reality, DRX Command MAC CE shortens UE’s ON period. For example, if DRX Command MAC CE is received when either onDurationTimer or drx-Inactivity-Timer running, the UE stops the timer and enters into DRX cycle (Short/Long)
The DRX Command MAC control element is identified by a MAC PDU subheader with LCID as 11110. It has a fixed size of zero bits.

DRX Active Time
Active Time is the time during which the UE is considered to be monitoring PDCCH. The Active Time includes the time while:
onDurationTimer is running;
drx-InactivityTimer is running;
drx-RetransmissionTimer is running:
As an example, let us say that the UE has received new data in subframe #n on PDSCH. The UE starts HARQ RTT Timer in the same subframe #n. Upon the expiry of HARQ RTT timer, if the data for the corresponding HARQ process was not successfully decoded (CRC error) then the UE starts drx-RetransmissionTimer for the corresponding HARQ process. The UE needs to be monitoring PDCCH while this timer is running as the retransmission can be expected by the UE during this time.
mac-ContentionResolutionTimer is running:
The UE shall start mac-ContentionResolutionTimer from the next subframe after transmitting Msg3. Since the UE is waiting for the contention resolution which is via PDCCH reception on C-RNTI (in connected mode), the UE needs to be monitoring PDCCH. So the time duration in which mac-ContentionResolutionTimer is running is also considered as Active Time
Scheduling Request has been sent on PUCCH and is pending:
The UE has to be in active state from the next subframe after transmitting SR over the air on PUCCH. After transmitting SR, the UE should be DRX active in order to receive grant from the eNodeB
An uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer:
Let us say that the DCI0 for initial transmission is received at subframe #n, the UE shall become active at subframes n+8, n+16, n+24...n+(maxHARQTx-1)*8 for a possible retransmission
A PDCCH indicating a new transmission addressed to the C-RNTI of the UE has not been received after successful reception of a RAR for the preamble not selected by the UE
In the non-contention based RA, after receiving RAR, the UE should be in active state until PDCCH indicating new transmission addressed to C-RNTI of the UE is received

DRX Operation
When there is no data activity for drx-InactivityTimer amount of time (i.e., upon expiry of drx-InactivityTimer) or DRX Command MAC CE is received,
-  if the Short DRX cycle is configured, then the UE should  start or restart drxShortCycleTimer and start using Short DRX Cycle. Else if Short DRX cycle is not confired, the UE should use the Long DRX cycle
If drxShortCycleTimer expires, i.e., maximum number of short cycles are already used, then the UE should enter the Long DRX cycle
If a DRX Command MAC control element is received, the UE should stop onDurationTimer and drx-InactivityTimer
During the active time, the UE shall monitor the PDCCH; if the PDCCH indicates a new transmission (DL or UL) in subframe #n, then the UE should start/restart drx-InactivityTimer in subframe #n+1
The UE should start onDurationTimer in a subframe which satisfies the following equation (based on whether short DRX cycle is configured or not):
If the Short DRX Cycle is used,
[(SFN * 10) + subframe number] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle)
else if the Long DRX Cycle is used
[(SFN * 10) + subframe number] modulo (longDRX-Cycle ) =  drxStartOffset
When downlink assignment has been configured (DL SPS), and if the configured assignment recurs in subframe that does not fall in Active time, the UE need not decode PDSCH. It is the eNodeB’s responsibility to make sure that the configured assignment falls in onDurationTimer
During RAR-window, if a subframe falls in non-Active time, then the UE monitors PDCCH only for RA-RNTI
Regardless of whether the UE is monitoring PDCCH or not, the UE receives and transmits HARQ feedback when such is expected.
When more than one serving cell is configured (CA), the same active time applies to all activated serving cell(s). For FDD, The UE maintains a set of 8 HARQ-RTT/drx-RetransmissionTimers for each serving cell. The UE monitors PDCCH on all serving cells, even if the active time corresponds to only one serving cell

Periodic CSI on PUCCH and SRS in DRX mode
When not in Active time, the UE shall not transmit periodic SRS (type-0 triggered SRS)
A release-8 UE shall not transmit periodic CSI on PUCCH when not in Active time.
In release-9, CQI-mask IE is introduced which limits CQI/PMI/PTI/RI reports to the on duration period of the DRX cycle. If the IE CQI-mask is not setup by RRC, CQI/PMI/RI/PTI on PUCCH shall not be reported when not in Active time; else UE should send CQI/PMI/RI/PTI on PUCCH only if onDurationTimer is running

When more than one serving cell is configured (CA), one value of cqi-Mask applies for all serving cells (the associated functionality is common i.e. not performed independently for each cell)


Reference: 3GPP TS 36.321, 36.213, 36.331
DRX calculations

Long DRX-cycle           Offset          onDurationTimer           Short DRX-cycle
                                                    

                                                                                              UL-DL Config
        Is Short DRX?         Is TDD?         

Long DRX Occasions
Long DRX Occasions will be displayed here


Short DRX Occasions
Short DRX Occasions will be displayed here


LTE: Buffer Status Reporting Procedure

The Buffer Status reporting procedure is used to provide the serving eNB with the information about the amount of data available for transmission in the UL buffers of the UE
Trigger for BSR and the types of BSRs
There are three types of BSRs; Regular BSR, Periodic BSR, and Padding BSR
Before we learn about how BSR is triggered, it is important to know about RRC parameters which control BSR reporting. RRC configures two timers periodicBSR-Timer and retxBSR-Timer and optionally allocates a Logical Channel Group (LCG) to each logical channel.
Logical Channel Group is signalled under LogicalChannelConfig of each RB. The mapping of a RB (or logical channel) to a LCG is done at the time when RB is setup by the eNB which may be based on the corresponding QoS attributes of the radio bearers such as QCI. There are 4 LCGs numbered from 0 to 3. For SRB1 and SRB2, LCG is 0 by default
A Buffer Status Report (BSR) shall be triggered if any of the following events occur:
  • When UL data, for a logical channel which belongs to a LCG, becomes available for transmission in the RLC entity or in the PDCP entity and there is no data available for transmission for any of the logical channels which belong to any LCG (This is called as Regular BSR)
  • When UL data, for a logical channel which belongs to a LCG, becomes available for transmission in the RLC entity or in the PDCP entity and the data belongs to a logical channel with higher priority than the priorities of the logical channels whose buffers are not empty (This is also called as Regular BSR)
  • retxBSR-Timer expires and the UE has data available for transmission for any of the logical channels which belong to a LCG (Even this is also called as Regular BSR)
  • UE has UL resources allocated and number of padding bits is equal to or larger than the size of the BSR MAC CE + its subheader (This is referred to as Padding BSR)
  • When periodicBSR-Timer expires, the triggered BSR is called as Periodic BSR

retxBSR-Timer and periodicBSR-Timer
retxBSR-Timer is introduced to improve the robustness of UE’s buffer status reporting behavior. This avoids deadlock situation such as the case where the UE has transmitted BSR but never received an uplink grant. This could be for example; eNodeB has erroneously decoded data on PUSCH and transmitted NACK but UE detected NACK as ACK.
The UE starts/restarts retxBSR-Timer upon indication of a grant for transmission of new data on UL-SCH. Upon the expiry of this timer, regular BSR is triggered. This timer is configured by RRC and can vary from 320ms till 10.24 seconds     
periodicBSR-Timer triggers Periodic BSR. Periodic BSR is used to provide the eNodeB with the updated buffer status report. Unlike retxBSR-Timer, periodicBSR-Timer is optional and can be set to Infinity to disable this timer. Its’ values vary from 5ms to 2.56 seconds.
BSR Formats
BSR is UE’s MAC procedure and the BSR is sent as ‘Buffer Status Report MAC Control Element’
BSR MAC CE consists of either Short BSR/Truncated BSR or Long BSR.
Short BSR/Truncated BSR is 1-byte MAC CE, so it requires two bytes (including 1-byte subheader) for reporting using this format.
Long BSR requires 4-bytes (3-bytes of Long BSR MAC CE + 1-byte subheader)
LCID value of 11100 indicates Truncated BSR, 11101 indicates Short BSR and 11110 indicates Long BSR

Short/Truncated BSR and Long BSR formats are presented below. 
 


In Short/Truncated BSR, buffer status is reported for only one LCG. LCG ID identifies the LCG (0 to 3) for which buffer status is being reported. Since there are 4 LCGs, 2-bits are required to identity LCG.
Using Long BSR, the UE can report buffer status of all LCGs (0 to 3). So the Long BSR consists of four Buffer Size fields, corresponding to LCG IDs #0 through #3
In either Short/Truncated BSR or Long BSR, the buffer size field is of 6-bits size which indicates the total amount of data available across all logical channels of a LCG after the MAC PDU has been built. The amount of data is indicated in number of bytes. It shall include all data that is available for transmission in the RLC layer and in the PDCP layer. The size of the RLC and MAC headers are not considered in the buffer size computation.
The Buffer status is reported as one of the ‘Index’ shown in the below table which is based on the buffer size. The ‘Index’ value varies from 0 to 63 which requires exactly 6 bits

Relationship between BSR types and BSR formats
For Regular and Periodic BSR:
       -  if more than one LCG has data available for transmission in the TTI where the BSR 
                 is transmitted: report Long BSR;
       -  else report Short BSR.
For Padding BSR:
       -  if the number of padding bits is equal to or larger than the size of the Short BSR 
              plus its subheader but smaller than the size of the Long BSR plus its subheader:
         -  if more than one LCG has data available for transmission in the TTI where 
              the BSR is transmitted: report Truncated BSR of the LCG with the highest 
              priority logical channel with data available for transmission;
         -  else report Short BSR.
        -  else if the number of padding bits is equal to or larger than the size of the Long 
               BSR plus its subheader, report Long BSR.

If a Regular BSR is triggered, MAC triggers Scheduling Request procedure. If the UE has a valid PUCCH resource for transmission of SR, then SR is transmitted, otherwise, Random Access procedure is triggered
When a BSR other than Regular BSR is triggered, Scheduling Request shall not be triggered

In Release-9, a new IE logicalChannelSR-Mask-r9 under LogicalChannelConfig is introduced. This controls SR triggering on a logical channel basis when an uplink grant has been configured (UL SPS). For example, logical channel ID - 2 has IE logicalChannelSR-Mask setup, and if uplink has been configured (UL SPS), then the UE doesn’t trigger SR procedure. The UE may anyway use the configured grant to transmit data available on this logical channel so triggering SR would be unnecessary.

A MAC PDU shall contain at most one MAC BSR control element, even when multiple events trigger a BSR by the time a BSR can be transmitted in which case the Regular BSR and the Periodic BSR shall have precedence over the padding BSR

All triggered BSRs shall be cancelled in case the UL grant can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the BSR MAC control element plus its subheader

All triggered BSRs shall be cancelled when a BSR is included in a MAC PDU for transmission

Long BSR example: Let us consider an example in which only Long BSR is being transmitted (the grant size is such that there is no padding also)

MAC PDU: 1E 2C 31 3F
Subheader: 1E 00011110 LC ID is the 5 least significant bits 11110 Long BSR MAC CE
Remaining 3 octets (24 bits) will carry Long BSR MAC CE which contains BSR for LCG ID#0 through LCG ID#3, where each LCG occupies 6 bits. Binary format of hex 2C 31 3F = 001011000011000100111111
BSR index for LCG ID#0 = 001011= 11 Buffer Size of LCG ID#0 is more than 42 bytes and less than or equal to 49 bytes.
         BSR index for LCG ID#1 = 000011= 3 (12 < Buffer Size (in bytes) <= 14)
         BSR index for LCG ID#2 = 000100= 4 (14 < Buffer Size (in bytes) <= 17)
         BSR index for LCG ID#3 = 001100 = 63 (Buffer Size (in bytes) > 150000)

Short BSR example: Let us consider an example in which only Short BSR is being transmitted (the grant size is such that there is no padding also)

MAC PDU: 1D 2C
Subheader: 1D 00011101 LCD ID is the 5 least significant bits 11101 Short BSR MAC CE
Second octet (2C) will carry Short BSR MAC CE. Binary format of 2C = 00101100. Two MSBs carry LCG ID, in this case, LCG ID = 0. Remaining 6-bits (101100) carry Buffer Size Index for LCG ID #0.
BSR index for LCG ID#0 = 101100= 44 Buffer Size of LCG ID#0 is more than 7505 bytes and less than or equal to 8787 bytes. 

LTE: Scheduling Request Procedure


The Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission.
UE’s MAC triggers scheduling request when a regular BSR is triggered and UE doesn’t have uplink resources for transmission of at least the regular BSR. Regular BSR is triggered when data becomes available for transmission in the uplink.
eNodeB needs to configure the UE with SR configuration via RRC signalling in order for the UE to transmit SR on PUCCH. The SR configuration structure is as given below


sr-PUCCH-ResourceIndex indicates the UE with the frequency domain resources whereas sr-ConfigIndex determines the time domain resources of PUCCH which carriers SR. eNodeB controls the maximum number SR transmissions from each UE on PUCCH using the parameter dsr-TransMax
If the UE has no valid PUCCH resources (SR is either not configured or released), then the UE initiates Random Access procedure
Once SR is triggered, the UE calculates the SR periodicity and offset (explained at the end of this post) which is based on sr-ConfigIndex IE. After transmitting the first SR on PUCCH, if the UE doesn’t receive uplink resources from the eNodeB, then based on the periodicity, the UE re-sends SR on PUCCH. This process continues till UE transmits SR for dsr-TransMax number of times on PUCCH if the UE doesn’t receive uplink resources from the eNodeB. After transmitting SR for maximum (dsr-TransMax) number of times, the UE releases SR resources (frequency as well as time), initiates random access procedure and cancels all pending (triggered) SRs
SR periodicities of 5, 10, 20, 40, and 80 ms are initially proposed in release-8. In release-9, short SR periodicities of 1 and 2 ms are introduced which reduces the latency.
When a short SR period is configured or when running VoIP traffic, the SR can be retransmitted unnecessarily. To avoid unnecessary SR transmissions, in release-9, an SR prohibit timer (sr-ProhibitTimer-r9) is introduced to reduce the load on PUCCH.
sr-ProhibitTimer-r9 IE is under mac-MainConfig and it can take values from 0 to 7. SR prohibit timer value is in number of SR period(s). Value 0 means no timer for SR transmission on PUCCH is configured. Value 1 corresponds to one SR period, Value 2 corresponds to 2*SR periods and so on. The UE starts this timer after transmitting an SR. When this timer is running, the UE is not supposed to be transmitting SR on PUCCH.
UE uses PUCCH Format 1 for transmitting SR alone. When SR and HARQ feedback in uplink happens to coincide in the same subframe, the UE shall transmit HARQ feedback on SR's frequency resource using PUCCH Format 1a/1b. Since PUCCH received is on SR resource, the eNodeB can easily understand that HARQ feedback and SR are present in the same subframe
If the UE is not configured for simultaneous PUSCH and PUCCH transmission or, if the UE is configured for simultaneous PUSCH and PUCCH transmission and not transmitting PUSCH, in case of collision between CSI and SR in a same subframe, CSI is dropped
UE release SR resources in the following cases
  • When UE has transmitted SR for maximum amount times (dsr-TransMax)
  • After timeAlignmentTimer expiry
  • During MAC reset procedure
  • During Handover (during Handover, MAC reset is performed)
During Handover, the source eNodeB has to provide the UE with a new SR configuration to be used in target eNodeB as the UE releases the existing SR resources in source eNodeB
SR configuration table is given below (Table 10.1.5-1 from 3GPP TS 36.213). SR transmission instances are the uplink subframes satisfying (10*SFN + subframe Noffset,SR) mod SRperiodicity = 0


SR configuration Index ISR
SR Periodicity (ms)
SRperiodicity
SR subframe offset Noffset,SR
0 ‒ 4
5
ISR
5 ‒ 14
10
ISR ‒ 5
15 ‒ 34
20
ISR ‒ 15
35 ‒ 74
40
ISR ‒ 35
75 ‒ 154
80
ISR ‒ 75
155 ‒ 156
2
ISR ‒ 155
157
1
ISR ‒ 157

One can also calculate SR instances from the below 'SR Calculator'

sr-ConfigIndex (0-157):          TDD UL-DL Config:

                     Is TDD?

SR timing will be displayed here

Full details of Scheduling Request subframes within one full SFN cycle

RNTIs in LTE


What is RNTI?

RNTI stands for Radio Network Temporary Identifier. RNTIs are used to differentiate/identify a connected mode UE in the cell, a specific radio channel, a group of UEs in case of paging, a group of UEs for which power control is issued by the eNB, system information transmitted for all the UEs by the eNB etc…

There are a several RNTI types in LTE such as SI-RNTI, P-RNTI, C-RNTI, Temporary C-RNTI, SPS-CRNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, RA-RNTI, and M-RNTI. Each RNTI’s usage, its value range etc…are discussed in detail below


SI-RNTI (System Information RNTI)
  • SI-RNTI is used for broadcast of system information.
  • It is a common RNTI meaning that, it is not allocated to any UE explicitly.
  • SI-RNTI is of 16-bit in length and its value is fixed to 65535 (0xFFFF). A single SI-RNTI is used to address SystemInformationBlockType1 as well as all SI messages
  • Broadcast of System Information uses BCCH logical channel which is then mapped to DL-SCH transport channel which intern mapped to PDSCH physical channel. The UEs should know the scheduling information for PDSCH which is carrying System Information. The required scheduling information is contained in DCI (Downlink Control Information) whose CRC is scrambled by SI-RNTI
  • DCI Formats which carries scheduling information for System Information are DCI Format 1A and DCI Format 1C in common search space
  • The UE starts decoding PDCCH scrambled with SI-RNTI at the start of SI-Window (for the concerned SI message) until the end of the SI-window, or until the SI message was received excluding the following subframes. 
          - subframe #5 in radio frames for which SFN mod 2 = 0
          - any MBSFN subframes
          - any uplink subframes in TDD

  • If the SI message was not received by the end of the SI-window, the UE repeats reception at the next SI-window occasion for the concerned SI message


P-RNTI (Paging RNTI)
  • P-RNTI is used by the UEs for the reception of paging.
  • It is a common RNTI meaning that it is not allocated to any UE explicitly.
  • P-RNTI is of 16-bit in length and its value is fixed to 65534 (0xFFFE).
  • Paging message is carried by PCCH logical channel which is mapped to PCH transport channel. The PCH transport channel is mapped to PDSCH physical channel. The eNB scrambles PDCCH’s CRC with P-RNTI for transmission of PDSCH that carries paging information
  • DCI Formats which carries scheduling information for paging are DCI Format 1A and DCI Format 1C in common search space


RA-RNTI (Random Access RNTI)
  • As part of Random Access procedure, the eNB’s MAC generates Random Access Response (RAR) as a response to the Random Access Preamble transmitted by the UE. RAR is transmitted on DL-SCH transport channel which intern is mapped to PDSCH. The eNB scrambles PDCCH’s CRC with RA-RNTI for transmission of PDSCH that carries RAR(s).
  • RA-RNTI can be addressed to multiple UEs, i.e., multiple UEs might decode PDCCH scrambled by the same RA-RNTI.
  • RA-RNTI unambiguously identifies which time-frequency resource was utilized by the UE to transmit the Random Access preamble (explained below)
  • RA-RNTI is of 16-bit in length and its value is derived from the below equation where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0 ≤ f_id< 6).
                                              RA-RNTI= 1 + t_id+10*f_id
  • For FDD there is at most one PRACH resource per subframe f_id = 0 RA-RNTI range is 1 to 10 whereas for TDD, the RA-RNTI ranges from 1 to 60
  • The values corresponding to the RA-RNTI values of a cell’s PRACH configuration are not used in the cell for any other RNTI (C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI, TPC-PUCCH-RNTI or TPC-PUSCH-RNTI)
  • DCI Formats which carries scheduling information for RAR are DCI Format 1A and DCI Format 1C in common search space


Temporary C-RNTI
  • As part of Random Access procedure, the eNB’s MAC generates Random Access Response (RAR) as a response to the Random Access Preamble transmitted by the UE. The MAC RAR contains Temporary C-RNTI
  • Temporary C-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).
  • During contention based random access procedure, the UE stores received Temporary C-RNTI (received in RAR) and uses it during random access procedure. The UE shall discard the Temporary C-RNTI value received in RAR during non-contention based random access procedure
  • The UE shall use Temporary C-RNTI for scrambling of msg3 (PUSCH corresponding to RAR grant) and it’s retransmissions
  • During contention based RA procedure, the UE monitors PDCCH scrambled with Temporary C-RNTI for DCI0 in common search space (This DCI0 monitoring is for possible retransmission of msg3)
  • In downlink, UE Contention Resolution (UE Contention Resolution Identity MAC Control Element) is on PDSCH for which PDCCH will be scrambled by Temporary C-RNTI. This is applicable only if UE has included CCCH SDU (RRC Connection Request or RRC Connection Re-establishment) in Msg3
  • DCI Format which carriers scheduling information for Contention Resolution in the downlink can be either DCI Format 1A in Common and UE specific search space or DCI Format 1 in UE specific search space
  • The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA success and does not already have a C-RNTI. It is dropped by others (for which contention is not successful)
  • A UE which detects RA success and already has a C-RNTI, resumes using its C-RNTI and discards Temporary C-RNTI


C-RNTI (Cell RNTI)
  • C-RNTI is a unique identification used for identifying RRC Connection and scheduling which is dedicated to a particular UE.
  • The eNB assigns different C-RNTI values to different UEs. When Carrier Aggregation is configured, same C-RNTI applies to all serving cells.
  • The eNB uses C-RNTI to allocate a UE with uplink grants, downlink assignments, PDCCH orders etc.
  • The eNB also uses C-RNTI to differentiate uplink transmissions (e.g. PUSCH, PUCCH) of a UE from others.
  • C-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).
  • After connection establishment or re-establishment the Temporary C-RNTI (as explained above) is promoted to C-RNTI.
  •  During Handovers within E-UTRA or from other RAT to E-UTRA, C-RNTI is explicitly provided by the eNB in MobilityControlInfo container with IE newUE-Identity
  • DCI Formats 0 and 1A in Common and UE specific search space and DCI Formats 1, 1B, 1D, 2, 2A, 2B, 2C, and 4 in UE specific search space will be transmitted on PDCCH with CRC scrambled by the C-RNTI
  • The scrambling initialization of PDSCH corresponding to the PDCCHs with DCI Formats 1, 1A, 1B, 1D, 2, 2A, 2B, and 2C is by C-RNTI
  • The scrambling initialization of the PUSCH corresponding to the PDCCHs with DCI Format 0/4 and the PUSCH retransmission for the same transport block is by C-RNTI


SPS C-RNTI (Semi-Persistent Scheduling C-RNTI)
  • SPS C-RNTI identifies semi-persistent grants/assignments. 
  • SPS C-RNTI is a dedicated RNTI and is configured by RRC. eNB configures the UE with a SPS C-RNTI as part of sps-Config as discussed in detail here
  • The CRC parity bits obtained for the PDCCH payload are scrambled with the SPS C-RNTI for SPS activation, release, re-activation and retransmission
  • SPS C-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).
  • For SPS activation/re-activation/retransmission in downlink, DCI Format 1A (common and UE specific search space) and DCI Formats 1/2/2A/2B/2C (UE specific search space) with PDCCH’s CRC is scrambled by SPS C-RNTI are used. The scrambling initialization of PDSCH corresponding to these PDCCHs and PDSCH without a corresponding PDCCH is by SPS C-RNTI
  • For SPS release in downlink, DCI Format 1A (common and UE specific search space) with PDCCH’s CRC is scrambled with SPS C-RNTI is used
  • For SPS activation/re-activation/retransmission/release in uplink, DCI Format 0 (common and UE specific search space) with PDCCH’s CRC is scrambled by SPS C-RNTI is used. The scrambling initialization of PUSCH corresponding to these PDCCHs and PUSCH retransmission for the same transport block is by SPS C-RNTI. The scrambling initialization of initial transmission of PUSCH without a corresponding PDCCH and the PUSCH retransmission for the same transport block is by SPS C-RNTI.
  • UE monitors SPS C-RNTI only on PCell


TPC RNTI (Transmit Power Control RNTI)
  • TPC RNTI is used for uplink power control purpose. There are two types, TPC-PUSCH-RNTI and TPC-PUCCH-RNTI
  • Normally TPC RNTI is assigned to a group of UEs. eNB may configure the UE with TPC-PUSCH-RNTI and TPC-PUCCH-RNTI via RRC signalling
  • TPC-PUSCH-RNTI/TPC-PUCCH-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).
  • DCI format 3/3A (common search space) whose CRC is scrambled with TPC-PUCCH-RNTI is used for the transmission of TPC commands for PUCCH
  • DCI format 3/3A (common search space) whose CRC is scrambled with TPC-PUSCH-RNTI is used for the transmission of TPC commands for PUSCH
  • DCI format 3 is used for the transmission of TPC commands for PUCCH and PUSCH with 2-bit power adjustments. DCI format 3A is used for the transmission of TPC commands for PUCCH and PUSCH with single bit power adjustments.
  • The notation 3/3A implies that the UE shall receive either DCI format 3 or DCI format 3A depending on the configuration


M-RNTI (MBMS RNTI)
  • Indication of an MBMS specific RNTI, the M-RNTI, on PDCCH is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about an MCCH information change
  • The DCI format 1C (common search space) with M-RNTI is used for notification and includes an 8-bit bitmap to indicate the one or more MBSFN Area(s) in which the MCCH change(s)
  • M-RNTI is of 16-bit in length and its value is fixed to 65533 (0xFFFD)

Reference 3GPP TS 36.300, 36.331, 36.211, 36.212, 36.213, 36.321