One of the other numbers which you would very frequently come accross is RNTI. RNTI stands for Radio Network Temporary Identifier. It appears in almost every LTE log, usually as a four digit hexadecimal number next to a PDCCH or a MAC PDU. So you should be able to tell which kind of RNTI you are looking at.

As the name implies, it is a kind of Identification number. Normally we use indentification number to differntiate one thing from all other similar things. For example, your driver's license number let you identify yourself from all other drivers. Social Security number do the same thing as well.

Getting more specifically into LTE, this RNTI is used to indentify one specific radio channel from other radio channel and one user from another user. As you may recall, in WCDMA is a RNTI concept which is carried as part of MAC header to deferentiate one user to another while in communication state. and in WCDMA case it used special channelization code to deferentiate one radio channel from the other.

Putting it very simply, you can think of RNTI as a kind of UE ID for the traffic between UE and eNB lower layer. But it would be more accurate to think of it as '[UE ID] + DCI Type ID' since each of DCI message (more precisely the CRC bits of each DCI) is scrambled by a specific RNTI Value. [UE ID] (UE ID in bracket) means that some RNTI is dedicated for a specific UE and some RNTI is not.

Then you may notice that there are not so many different DCI types but there are a huge set of RNTI types and ask how a few DCI types can be mapped to such a big number of RNTI types. Actually this is one of the thing you have to (or will) figure out as you read along this page.

The page first lists the RNTI types and the 36.321 and 36.213 tables behind them, including what the current release has added. Then it explains who assigns each RNTI, how the value reaches the other side without a message field, and where the specifications use each one.

Followings are the list of topics that will be described in this page.

• Types of RNTIs
• How/Who determines each types of RNTI ?
• How RNTI value is informed ?
• How each of RNTI is used ?
• Reference

Types of RNTIs

Each RNTI type answers one question for the UE: who is this PDCCH for, and what kind of transmission does it schedule? Let's list the types first. Then we read the 36.321 and 36.213 tables that fix their values and their DCI formats, and finally we check what the current release has added to them.

What kind of RNTIs are there in LTE ?

The answer is A LOT -:). Followings are the brief summary of RNTIs being used in LTE. More detailed explanation will be updated continuously later.

• P-RNTI : It stands for Paging RNTI. Used for Paging Message.
• SI-RNTI : It stands for System Information RNTI. Used for transmission of SIB messages
• RA-RNTI : It stands for Random Access RNTI. Used for PRACH Response.
• C-RNTI : It stands for Cell RNTI. Used for the transmission to a specific UE after RACH.
• T-CRNTI : It stands for Temporary C-RNTI. Mainly used during RACH
• SPS-C-RNTI : It stands for Semi persistance Scheduling C-RNTI
• TPC-PUCCH-RNTI : It stands for Transmit Power Control-Physical Uplink Control Channel-RNTI
• TPC-PUSCH-RNTI : It stands for Transmit Power Control-Physical Uplink Shared Channel-RNTI
• M-RNTI : It stands for MBMS RNTI
• CC-RNTI : It stands for Common Control RNTI
• G-RNTI : It stands for Group RNTI
• SC-RNTI : It stands for Single Cell RNTI
• SL-RNTI : It stands for Sidelink RNTI
• SC-N-RNTI : It stands for Single Cell Notification RNTI
• eIMTA-RNTI : It stands for Enhanced Interference Management and Traffic Adaptation - RNTI

Who issues these RNTI ?

Network issues RNTI.

Exactly what does RNTI do for each of those radio channel ? The detailed process differs with the types of RNTIs, but generally speaking all of these RNTI is used to scramble the CRC part of the radio channel messages. It implies that if UE does not know the exact RNTI values for each of the cases, it cannot decode the radio channel messages even though the message reaches the UE intact.

One of the most common questions that I got about RNTI is "There are a lot of different types of RNTI and I don't see any RNTI information on DCI or Higher layer signaling message. Then how can PHY layer know which RNTI it has to use to decode a data ?". The answer is "MAC or Layer 1 controller would instruct PHY on which RNTI it has to be used". Then a next questions comes out. "How MAC or Layer 1 controller would know which RNTI to be used ?". There is no explicit algorithm for this, MAC/L1 controller needs to figure it out "based on context". For example, if it is at the subframe where SIB is transmitted, it would instruct PHY to use SI-RNTI. if UE is in connected mode, it may instruct to use C-RNTI, TPC RNTI etc.

There are a lot of tables related to RNTI Type and Specific Physical/MAC layer operation. It would not be easy to make any sense out of these tables, but just look into these tables as often as possible. As your understanding / knoledge of LTE PHY procedure, you would make more sense out of these tables.

Following table from 36.321 shows the range of values which is allocated for each RNTI types.

< 36.321 - Table 7.1-1: RNTI values. >

Following table from 36.321 shows the types of RNTIs and it's usage.

< 36.321 - Table 7.1-2: RNTI usage. >

Following table from 36.213 shows the relationships between types of RNTIs and DCI Format. You would notice that some DCI format can be scrambled by many other types of RNTI type. Then you may ask how PHY layer figure out which RNTI types it has to use to decode a certain DCI type.  It depends on communication status. For example, DCI Format 1A can be scrambled by SI-RNTI, P-RNTI, C-RNTI. In this case, UE will try something like followings

• UE will use SI-RNTI if it is in idle mode and within SI-transmission window
• UE will use P-RNTI if it is in idle mode and it is at the PO (Paging Occasion) subframe
• UE will use C-RNTI while it is in commuincation status

< 36.213 - Table 7.1-1: PDCCH and PDSCH configured by SI-RNTI >

< 36.213 - Table 7.1-1A: PDSCH configured by SI-RNTI >

< 36.213 - Table 7.1-2: PDCCH and PDSCH configured by P-RNTI >

< 36.213 - Table 7.1-3: PDCCH and PDSCH configured by RA-RNTI >

< 36.213 - Table 7.1-5: PDCCH and PDSCH configured by C-RNTI >

< 36.213 - Table 7.1-7: PDCCH and PDSCH configured by Temporary C-RNTI >

The two 36.321 tables above come from v14.2.1. The current 36.321 v19.3.0 keeps the same structure, but it moves one SI-RNTI value and adds three RNTI types. The table below lists every difference. The 36.213 tables above still match 36.213 v19.4.0, apart from the word Subclause, which is now Clause.

< 36.321 v19.3.0 Table 7.1-1 and Table 7.1-2 against the v14.2.1 tables above >

Most of these changes serve features outside the everyday LTE call flow. AUL C-RNTI belongs to autonomous uplink on unlicensed spectrum, and PUR-RNTI and CB-RNTI belong to the IoT features for small data. So a log from an ordinary LTE UE rarely shows them. The SI-RNTI change is different, because a decoder that still treats FFF4 as SI-RNTI misreads that value on a current network.

• The value alone does not tell the RNTI type : the range 0001 to FFF3 is shared by many types, so the UE and the log decoder need the context as well.
• Only a few values are fixed : P-RNTI is FFFE, M-RNTI is FFFD, CC-RNTI is FFFC, SC-RNTI is FFFB, SC-N-RNTI is FFFA, and SI-RNTI is FFFF or FFF9.
• Check the release of any RNTI table you use : the v14.2.1 table still lists FFF4 as SI-RNTI, while v19.3.0 reserves FFF4.

How/Who determines each types of RNTI ?

RNTIs come from three kinds of source. The UE computes some of them from the PRACH resource it used, the eNB assigns others in a MAC or RRC message, and the specification fixes a few as constants. The three lines below cover the random access chain, and the paragraphs after them add the rest.

RA-RNTI : UE determines RA-RNTI as explained in here in the RACH page.

T-CRNTI : Network allocate T-CRNTI via RAR as shown in here in the RACH page.

C-RNTI : T-CRNTI becomes C-RNTI once Contention Resolution gets passed.

RA-RNTI follows directly from the PRACH resource. For a normal UE, 36.321 computes RA-RNTI = 1 + t_id + 10 x f_id. Here t_id is the index of the first subframe of the PRACH, from 0 to 9, and f_id is the index of the PRACH within that subframe, from 0 to 5. So the UE and the eNB both know the RA-RNTI without any signalling. BL UEs, UEs in enhanced coverage and NB-IoT UEs use extended formulas that also include the SFN.

The step from Temporary C-RNTI to C-RNTI has one condition. If Msg3 carried a CCCH SDU, as in initial access, the UE sets its C-RNTI to the Temporary C-RNTI when contention resolution succeeds. If Msg3 carried a C-RNTI MAC control element, the UE already has a C-RNTI. It then discards the Temporary C-RNTI and keeps its own.

The eNB assigns the remaining UE-specific RNTIs in RRC. After a handover, the UE uses newUE-Identity from mobilityControlInfo as its C-RNTI in the target cell. SPS-Config carries semiPersistSchedC-RNTI, and TPC-PDCCH-Config carries a 16 bit tpc-RNTI for the TPC-PUCCH-RNTI or the TPC-PUSCH-RNTI. The common RNTIs need no signalling at all, because 36.321 Table 7.1-1 fixes their values.

• The UE computes RA-RNTI : it comes from the time and frequency index of the PRACH, so no message carries it.
• The eNB assigns the UE-specific RNTIs : Temporary C-RNTI in the RAR, and newUE-Identity, SPS C-RNTI and the TPC RNTIs in RRC.
• The common RNTIs are constants : P-RNTI, SI-RNTI and M-RNTI have fixed values in 36.321.

How RNTI value is informed ?

How a RNTI value is informed to the other party of the communication ? If you are mainly working on higher layer or in WCDMA, you may expect there is a specific signaling message or MAC field that carries this ID. But in LTE, this ID is embedded and carried to the other party in much lower layer. Also, there is no specific field to carry RNTI value itself. It is combined with CRC field of each Physical layer data as shown below (This is only one example for PDCCH case).

• The left half is the PDCCH payload a₀ to a_A-1. It passes to the output c₀ to c_A-1 unchanged.
• The right half is the 16 CRC parity bits. Each CRC bit b_A+k is added modulo 2 to one RNTI bit x_rnti,k, and the bracket marks this step as the place where the RNTI is used.
• The top row labels the last CRC bit a₁₅. It is the parity bit p₁₅, as the sequence p₀, p₁, p₂ before it shows.

36.212 clause 5.3.3.2 defines this step. After the 16 CRC parity bits are attached, they are scrambled with the RNTI, and x_rnti,0 is the MSB of the RNTI. When closed-loop UE transmit antenna selection is configured, the CRC of DCI format 0 is also scrambled with an antenna selection mask.

The receiver undoes the same step. The UE computes the CRC over the decoded payload and adds one of its RNTIs. If the result matches the received CRC bits, the PDCCH is for this UE and for that RNTI type. A PDCCH scrambled with another RNTI fails the check, so the UE treats it as a decoding failure. This is why the RNTI never appears as a field in the DCI.

• The RNTI costs no bits in the DCI : it is added modulo 2 onto the 16 CRC bits instead of being carried as a field.
• A CRC check is also an address check : the UE finds its PDCCHs by testing each decoded candidate against the RNTIs it monitors.
• A wrong RNTI looks like a bad radio link : a UE with the wrong RNTI sees only CRC failures, so check the RNTI before you blame the channel.

How each of RNTI is used ?

Following is the quotes from 3GPP specification showing how RNTI is used for various cases.. for the exact details, you should see the specification but this partial quote would give you a rough idea of the usage of RNTI.

From 36.212 -----------------------------------------------------------------------------------------------

5.3.3 Downlink control information

• A DCI transports downlink or uplink scheduling information, or uplink power control commands for one RNTI. The RNTI is implicitly encoded in the CRC.

5.3.3.1.3 Format 1A

• Format 1A is used for random access procedure initiated by a PDCCH order only if format 1A CRC is scrambledwith C-RNTI
• For distributed VRB: .. if the format 1A CRC is scrambled by RA-RNTI, P-RNTI, or SI-RNTI

5.3.3.2 CRC attachment

• This section explain in detail on how CRC is scrambled by RNTI. Following is the summary of this process. As you see, RNTI is used to scramble CRC bits of PDCCH.

From 36.213 ------------------------------------------------------------------------------------------------

Following is some examples of 3GPP description related to RNTI. Just to focus which type of DCI is scrambled by which RNTI Type.

5.1.1.1 UE behaviour

• δ_PUSCH is a UE specific correction value, also referred to as a TPC command and is included in PDCCH with DCI format 0 or jointly coded with other TPC commands in PDCCH with DCI format 3/3A whose CRC parity bits are scrambled with TPC-PUSCH-RNTI
• if the TPC command PUSCH δ_PUSCH is included in a PDCCH with DCI format 0 where the CRC is scrambled by the Temporary C-RNTI
• The UE attempts to decode a PDCCH of DCI format 0 with the UE’s C-RNTI or SPS CRNTI and a PDCCH of DCI format 3/3A with this UE’s TPC-PUSCH-RNTI in every subframe

5.1.2.1 UE behaviour

• δ_PUCCH is a UE specific correction value, also referred to as a TPC command, included in a PDCCH with DCI format 1A/1B/1D/1/2A/2 or sent jointly coded with other UE specific PUCCH correction values on a PDCCH with DCI format 3/3A whose CRC parity bits are scrambled with TPC-PUCCH-RNTI.
• The UE attempts to decode a PDCCH of DCI format 3/3A with the UE’s TPC-PUCCH-RNTI and oneor several PDCCHs of DCI format 1A/1B/1D/1/2A/2 with the UE’s C-RNTI or SPS C-RNTI on every subframe except when in DRX.
• If the UE decodes a PDCCH with DCI format 1A/1B/1D/1/2A/2 and the corresponding detected RNTI equals the C-RNTI or SPS C-RNTI of the UE, the UE shall use the δ PUCCH provided in that PDCCH.

6.1 Physical non-synchronized random access procedure

• A preamble index, a target preamble received power (PREAMBLE_RECEIVED_TARGET_POWER), a corresponding RA-RNTI and a PRACH resource are indicated by higher layers as part of the request.
• Detection of a PDCCH with the indicated RA-RNTI is attempted during a window controlled by higher layers

7.1 UE procedure for receiving the physical downlink shared channel

• If a UE is configured by higher layers to decode PDCCH with CRC scrambled by the SI-RNTI, the UE shall decode the PDCCH and the corresponding PDSCH according to any of the combinations defined in table 7.1-1. The scrambling initialization of PDSCH corresponding to these PDCCHs is by SI-RNTI. // SI-RNTI scrambles the DCI for SIB messages.
• If a UE is configured by higher layers to decode PDCCH with CRC scrambled by the P-RNTI, the UE shall decode the PDCCH and the corresponding PDSCH according to any of the combinations defined in table 7.1-2. The scrambling initialization of PDSCH corresponding to these PDCCHs is by P-RNTI. // P-RNTI scrambles the DCI for Paging message.
• If a UE is configured by higher layers to decode PDCCH with CRC scrambled by the C-RNTI, the UE shall decode the PDCCH and any corresponding PDSCH according to the respective combinations defined in table 7.1-5. The scrambling initialization of PDSCH corresponding to these PDCCHs is by C-RNTI.
• If a UE is configured by higher layers to decode PDCCH with CRC scrambled by the Temporary C-RNTI and is not configured to decode PDCCH with CRC scrambled by the C-RNTI, the UE shall decode the PDCCH and the corresponding PDSCH according to the combination defined in table 7.1-7. The scrambling initialization of PDSCHcorresponding to these PDCCHs is by Temporary C-RNTI.

Reference

• 36.321 : 3GPP - E-UTRA Medium Access Control (MAC) protocol specification, v19.3.0. Clause 5.1.4, clause 5.1.5, Table 7.1-1 and Table 7.1-2.
• 36.212 : 3GPP - E-UTRA Multiplexing and channel coding, v19.3.0. Clause 5.3.3.2.
• 36.213 : 3GPP - E-UTRA Physical layer procedures, v19.4.0. Table 7.1-1 to Table 7.1-7.
• 36.331 : 3GPP - E-UTRA Radio Resource Control (RRC); Protocol specification, v19.3.0. SPS-Config, TPC-PDCCH-Config and MobilityControlInfo.