The Cell Radio Network Temporary Identifier (C-RNTI) is a unique identifier used in cellular networks, including 5G. It is a temporary identifier assigned to a UE by the base station (in the case of 5G, this is the gNodeB) when the UE first successfully establishes a connection to the cellular network. Usually it is assigned during the RACH process (msg 4) .

The C-RNTI is specific to the cell the UE is currently connected to. If the UE moves to a different cell, a new C-RNTI will be assigned by the new cell's gNodeB. This identifier is critical for efficient and accurate communication between the UE and the network infrastructure.

The structure of MAC-CE for C-RNTI is as follows. The C-RNTI MAC CE is identified by MAC subheader with LCID

< 38.321 - Figure 6.1.3.2-1: C-RNTI MAC CE >

C-RNTI Overview

C-RNTI (Cell Radio Network Temporary Identifier) is a unique temporary identifier assigned to a UE by a base station (gNodeB in 5G). It is typically assigned during the Random Access Channel (RACH) procedure (message 4).

The C-RNTI is specific to the cell the UE is currently connected to. If the UE moves to a different cell, a new C-RNTI will be assigned by the new cell's gNodeB. This identifier is crucial for maintaining seamless and efficient communication between the UE and the network infrastructure.

Purposes of C-RNTI

The C-RNTI serves the following purposes:

• Identification: It uniquely identifies the UE within a particular cell, which is essential for the management and delivery of data.
• Communication: It is used in the uplink and downlink to multiplex and demultiplex the data and control information. This means that when a signal is received, the gNodeB can identify which UE sent it, and when the gNodeB sends a signal, the UE knows it is the intended recipient.
• Resource Allocation: It is used for scheduling decisions on the uplink and downlink. When the gNodeB allocates resources for the UE to transmit data, it references the C-RNTI (Each DCI is masked with C-RNTI).

Use in the RACH Process

During the RACH procedure, the C-RNTI is assigned in msg 4 as part of the contention resolution process. Once assigned, the C-RNTI allows the UE to establish a unique communication link with the gNodeB.

Key Features of C-RNTI

• Temporary but Essential: Valid as long as the UE remains connected to a specific cell. Upon handover, a new C-RNTI is issued by the new cell.
• Critical for Uplink and Downlink Scheduling: The gNodeB uses the C-RNTI to determine and allocate resources for data transmission, ensuring efficient network operations.
• Foundation of Addressing: Masking of DCI with C-RNTI ensures that communication is directed only to the intended recipient.

• What is the C-RNTI MAC CE, and when does the UE send it ?
• How does contention resolution differ when a C-RNTI MAC CE is used ?
• When does a UE get a new C-RNTI ?
• How does the C-RNTI relate to the other RNTIs ?
• Reference

What is the C-RNTI MAC CE, and when does the UE send it ?

Most of this page is about the C-RNTI itself, which is the right thing to explain first. The MAC CE is a narrower subject. I found it easier once I stopped thinking of it as a way to assign a C-RNTI, because it never assigns one.

The C-RNTI MAC CE carries a C-RNTI the UE already holds. It has a fixed size, and it consists of one field of 16 bits which is the C-RNTI itself. TS 38.321 identifies it with LCID 58 on UL-SCH.

Being fixed in size has a consequence for the framing. A fixed-size MAC CE needs no length field, so its MAC subheader is a single octet holding two reserved bits and the six-bit LCID. The whole subPDU is therefore three octets, one of subheader and two of C-RNTI.

The UE sends it in Msg3, and only when it already holds a valid C-RNTI. Three situations produce that. The first is a handover, where random access runs on the target cell. The second is a re-establishment or a resume, where the UE returns to a cell that has a context for it. The third is uplink data arriving while the UE is out of uplink synchronisation, so random access is the only way to get a grant.

A UE performing initial access has no C-RNTI to send. It puts a CCCH SDU in Msg3 instead, carrying RRCSetupRequest. Whether this MAC CE is present therefore tells the gNB which kind of UE it has, before decoding anything else.

• It reports a C-RNTI, it does not assign one : The UE sends a value it already holds. This MAC CE is never how a UE first obtains one.
• Two octets of payload, LCID 58 : A single 16-bit field, fixed in size, on UL-SCH.
• The subPDU is three octets : Fixed size means a one-octet subheader with no length field.
• It appears in Msg3 only : Handover, re-establishment or resume, and uplink data arriving while out of synchronisation.
• Its absence is informative too : A Msg3 carrying a CCCH SDU instead marks a UE doing initial access.

How does contention resolution differ when a C-RNTI MAC CE is used ?

What the UE puts in Msg3 decides how contention resolution works. The two paths differ enough that recognising which one a log is following saves a lot of time.

Take the initial access path first. Msg3 carries a CCCH SDU. The gNB echoes the first 48 bits of that SDU back in a UE Contention Resolution Identity MAC CE, inside Msg4. Every UE that sent the same preamble compares the echo against what it sent. The one that matches has won the contention, and its TC-RNTI becomes its C-RNTI.

Now the path where Msg3 carries a C-RNTI MAC CE. No echo is needed here. The UE has already stated an identity that is unique within the cell, so there is nothing to disambiguate. Contention resolution succeeds when the UE receives a PDCCH addressed to that C-RNTI. A UE Contention Resolution Identity MAC CE never appears in this path.

The outcomes differ as well, and this is the part worth remembering. The first path ends with a C-RNTI the UE did not have before, promoted from the TC-RNTI. The second ends with the UE keeping the C-RNTI it arrived holding, and discarding the TC-RNTI that the Random Access Response gave it.

Figure 1 sets the two paths side by side.

Figure 1. The C-RNTI MAC CE removes a step. A UE that can name itself does not need the gNB to echo anything back to prove which UE won.

• The CCCH path needs an echo : The gNB returns the first 48 bits of the CCCH SDU. Each UE checks it against what it sent.
• The C-RNTI path needs none : The identity was already unique in the cell, so a PDCCH addressed to it is proof enough.
• Only one path produces a new C-RNTI : The TC-RNTI is promoted in the CCCH path, and discarded in the C-RNTI path.
• The two MAC CEs never appear together : A UE Contention Resolution Identity MAC CE in Msg4 means Msg3 held no C-RNTI MAC CE.
• Msg3 content is the fork : Everything after it follows from whether the UE could name itself.

When does a UE get a new C-RNTI ?

The opening of this page says a new C-RNTI is assigned when the UE moves to a different cell. That is the common case. Setting out every event that changes one makes the boundaries clearer, and shows where the identity survives.

One row deserves more than a line. A C-RNTI belongs to a cell group rather than to a single serving cell. Under carrier aggregation one C-RNTI covers the primary cell and every secondary cell in that group. Cross-carrier scheduling uses it on all of them. A UE configured with dual connectivity has two, one per cell group, because it has two MAC entities.

The other pattern in the table is that a C-RNTI never travels. Every event that moves the UE to a new cell produces a new value rather than carrying the old one across. That is what makes it a cell-scoped identity. The identity that survives mobility is the 5G-GUTI, not anything at this layer.

• A C-RNTI is never carried between cells : Handover, re-establishment and resume each produce a new value.
• It is per cell group, not per serving cell : One C-RNTI covers the PCell and every SCell in the group.
• Dual connectivity means two : One per cell group, because each cell group has its own MAC entity.
• RRC_IDLE and RRC_INACTIVE hold none : In RRC_INACTIVE the I-RNTI names the stored context instead.
• Only initial access promotes a TC-RNTI : Every other assignment is an explicit one from the network.

How does the C-RNTI relate to the other RNTIs ?

An RNTI is a 16-bit number, and the C-RNTI is one of several kinds. They share one value space, which is worth seeing laid out before looking at what each one does.

Figure 2. Nothing in a C-RNTI value marks it as a C-RNTI. Its meaning comes from which node assigned it and what the UE was told to do with it.

The table below gives the ones a UE meets most often.

The mechanism they all share is CRC scrambling. A DCI on PDCCH has its CRC scrambled with the RNTI it is meant for. A UE recovers that DCI only if it descrambles with the same value. That is how one PDCCH search space serves every UE in a cell without any per-UE addressing field.

It is worth being precise about what that mechanism does and does not give. It provides addressing, and nothing more. A DCI is neither ciphered nor integrity protected. A C-RNTI travels in the clear, in Msg3 and in the RRC reconfiguration that assigns it. Anyone receiving the cell can recover it. Confidentiality and integrity come from the PDCP layer, not from RNTI scrambling.

• Every RNTI is 16 bits : Most are drawn from the same 0001 to FFEF range. The value alone does not say which kind it is.
• P-RNTI and SI-RNTI are constants : FFFE and FFFF are the same in every cell. A UE needs them before it has been told anything.
• RA-RNTI is computed, not assigned : It comes from the time and frequency of the PRACH occasion. That is all the network knows at that point.
• CRC scrambling is the shared mechanism : It is how a single search space serves every UE without an explicit address field.
• Scrambling is addressing, not security : A C-RNTI travels in the clear, and protection comes from PDCP.

Reference

[1] 3GPP TS 38.321 - NR; Medium Access Control (MAC) protocol specification. Section 6.1.3.2 defines the C-RNTI MAC CE, and section 5.1.5 covers contention resolution.

[2] 3GPP TS 38.321 - Table 7.1-1 gives the RNTI values, and Table 6.2.1-2 gives the UL-SCH LCID values.

[3] 3GPP TS 38.331 - NR; Radio Resource Control (RRC) protocol specification. newUE-Identity carries the C-RNTI assigned at handover.

[4] 3GPP TS 38.213 - NR; Physical layer procedures for control. Section 10.1 covers the search spaces a UE monitors for each RNTI.

[5] MAC CE - the LCID tables and the MAC subheader formats, on this site.