Contention Resolution is a mechanism by which gNB can resolve the contention by the same PRACH preambles transmitted by multiple UEs. This is performed by msg2 and  msg4 of the RACH process.

As multiple UEs may select the same preamble for initial access, contention resolution ensures the cell validates which UE should keep the initially assigned C-RNTI after the Random Access Response.

The UE Contention Resolution Identity MAC CE is identified by MAC subheader with LCID as specified in Table 6.2.1-1. It has a fixed 48-bit size and consists of a single field defined as follows. UE Contention Resolution Identity contains the UL CCCH SDU. If the UL CCCH SDU is longer than 48 bits, this field contains the first 48 bits of the UL CCCH SDU.

• Structure of the MAC CE
• Why is the identity 48 bits, and what is in it ?
• How does the UE decide whether it won ?
• Why does echoing the message back work at all ?
• What happens in two-step random access ?
• Reference

Structure of the MAC CE

The specification figure shows the MAC CE on its own. On the wire it never travels on its own, and seeing what sits in front of it makes the size easier to reason about.

< 38.321-Figure 6.1.3.3-1 > draws the MAC CE as six octets stacked one above another. Every octet carries the same label, because there is only one field. The ruler across the top marks the eight bit positions within each octet.

<  38.321-Figure 6.1.3.3-1: UE Contention Resolution Identity MAC CE >

Two things about that figure are worth stating, because both are unusual.

The first is that there is only one field. Most MAC CEs divide their octets into named subfields, such as a group identity and a buffer size, or a bitmap followed by a list. This one has no internal structure at all. The MAC entity never interprets the 48 bits, and it has no need to. It only compares them.

The second is what the figure leaves out. Like every MAC CE this one travels inside a MAC subPDU, behind a MAC subheader. The MAC CE has a fixed size, so that subheader is a single octet holding two reserved bits and the six-bit LCID. The complete subPDU is therefore seven octets.

Figure 1 shows the same MAC CE with the subheader that carries it.

Figure 1. The specification figure stops at the payload. What reaches the air is the payload plus the subheader that names it.

• One field, and no internal structure : All six octets are a single value, unlike most MAC CEs which divide into named subfields.
• MAC never interprets the value : It compares the 48 bits. Nothing at this layer needs to know what they mean.
• The subheader is one octet : A fixed-size MAC CE carries no length field, so two reserved bits and the LCID are all it needs.
• The complete subPDU is seven octets : One of subheader, and six of identity.
• Nothing is reserved or spare : All 48 bits carry the identity, which is why the field is exactly the size of UL-CCCH.

Why is the identity 48 bits, and what is in it ?

The quoted definition above says the field contains the UL CCCH SDU, and the first 48 bits of it if the SDU is longer. I read that for a while as though truncation were the normal case. It is not. For ordinary initial access the 48 bits are the whole message.

The number comes from the size of the logical channel. UL-CCCH is 48 bits, which is six octets, and that is the container for RRCSetupRequest and its siblings. A MAC CE of 48 bits therefore reflects one of those messages exactly.

There is one channel where the SDU does not fit, and it is why the specification words the field the way it does. UL-CCCH1 is 64 bits, and it exists to carry RRCResumeRequest1. That message needs the extra room. It carries a full I-RNTI rather than a short one. Echoing it would cost two octets more than the MAC CE has. The last two are dropped.

Truncating is safe here for the same reason the mechanism works at all. The identity does not have to be complete. It only has to differ from what any other contending UE sent. The first 48 bits of a resume request already carry the I-RNTI bits that make it unique.

Figure 2 sets the two channel sizes against the fixed 48 bits of the MAC CE.

Figure 2. The specification says the first 48 bits because one case needs truncating. For ordinary initial access nothing is left out.

• 48 bits is the size of UL-CCCH : Six octets, which is exactly what RRCSetupRequest occupies.
• Nothing is truncated in ordinary initial access : The MAC CE reflects the whole message the UE sent.
• UL-CCCH1 is the exception : RRCResumeRequest1 is 64 bits, so its last two octets never reach the MAC CE.
• Truncation does not break it : The echo needs to be distinguishing, not complete, and the leading bits already are.
• It is a downlink MAC CE : LCID 62 on DL-SCH, sent by the gNB in Msg4.

How does the UE decide whether it won ?

The decision is made by the UE, not by the network, and it is made by a comparison rather than by an instruction.

When the UE transmits Msg3 it starts ra-ContentionResolutionTimer, configured in RACH-ConfigCommon with values from sf8 to sf64. While that timer runs the UE monitors PDCCH. A Msg4 that arrives carries the UE Contention Resolution Identity MAC CE, and the UE compares its 48 bits against the CCCH SDU it transmitted.

A match means the UE has won. It stops the timer, considers contention resolution successful, and promotes the TC-RNTI it was given in the Random Access Response into its C-RNTI.

A mismatch means another UE won the same preamble. The UE discards the TC-RNTI and treats the attempt as failed. Expiry of the timer with no Msg4 at all produces the same outcome. In both cases the UE backs off, increments its preamble transmission counter and tries again. Reaching preambleTransMax raises a random access problem to RRC.

Figure 3 follows the comparison and both of its outcomes.

Figure 3. Every contending UE receives the same Msg4. The MAC CE is what lets each one determine, on its own, whether the message was meant for it.

• The UE decides, by comparing : Nothing in Msg4 names the winner, so each UE checks the echo against what it sent.
• ra-ContentionResolutionTimer bounds the wait : It starts at Msg3 and runs from sf8 to sf64, and the UE monitors PDCCH throughout.
• A match promotes the TC-RNTI : The temporary identity from the Random Access Response becomes the C-RNTI.
• A mismatch and a timeout end the same way : The TC-RNTI is discarded and the UE backs off before trying another preamble.
• Failure is counted : Reaching preambleTransMax raises a random access problem to RRC rather than retrying forever.

Why does echoing the message back work at all ?

Reflecting a message the UE just sent looks like a strange way to identify someone. It is worth working through why the network cannot simply address the winner instead.

At this point in the procedure the gNB does not know who any of the contending UEs are. It received a preamble, and a preamble carries no identity. It answered with a Random Access Response addressed to an RA-RNTI computed from the PRACH occasion, and that response allocated a TC-RNTI. Every UE that chose the same preamble in the same occasion received that same response. All of them now hold the same TC-RNTI.

That shared TC-RNTI is the whole problem. A Msg4 addressed to it reaches every contending UE, and each of them will decode it. Addressing cannot separate them, because they are all wearing the same address.

What does separate them is what they sent. Their Msg3 transmissions collided. In practice the gNB decodes at most one of them. It has no idea which UE that was, but it does have the bits. Reflecting those bits back is the one statement the gNB can make that exactly one UE will recognise.

Seen that way the MAC CE is not an identifier the network assigns. It is a receipt. It says which Msg3 was decoded. Each UE then determines whether that Msg3 was its own.

The alternative path avoids all of this. A UE that already holds a C-RNTI puts a C-RNTI MAC CE in Msg3 instead of a CCCH SDU. It has stated an identity that is already unique in the cell, so the gNB can address it directly and no receipt is needed.

• The gNB does not know who is contending : A preamble carries no identity, so there is nobody to address.
• Every contending UE holds the same TC-RNTI : They all received the same Random Access Response, so addressing cannot separate them.
• Only one Msg3 is usually decoded : The transmissions collide, and the gNB reflects whichever set of bits it recovered.
• The MAC CE is a receipt, not an identity : It reports which Msg3 was decoded, and each UE checks it for itself.
• A known UE needs no receipt : A C-RNTI MAC CE in Msg3 states a unique identity. The gNB can then address the winner directly.

What happens in two-step random access ?

Release 16 added a two-step random access procedure, and the same identity does the same job inside it.

Two-step random access folds the four messages into two. MsgA combines the preamble with the payload that Msg3 would have carried, so a UE performing initial access puts its CCCH SDU there. MsgB combines what Msg2 and Msg4 would have carried.

Contention still has to be resolved, because two UEs can still choose the same preamble and the same PUSCH occasion. MsgB therefore carries a success RAR, and inside it is the same contention resolution identity, still 48 bits, still holding what the UE sent. The UE compares it exactly as it does in the four-step case.

What changes is the packaging rather than the mechanism. In four-step random access the identity travels as a MAC CE in Msg4. In two-step it travels as a field of the success RAR in MsgB. The comparison the UE performs, and what it concludes from a match, are the same in both.

• Two-step random access still contends : Two UEs can pick the same preamble and PUSCH occasion, so resolution is still needed.
• The CCCH SDU moves to MsgA : It travels with the preamble instead of waiting for a grant.
• The identity travels in the success RAR : MsgB carries the same 48 bits, as a field rather than as a MAC CE.
• The UE does the same comparison : Only the packaging differs between the two procedures.

Reference

[1] 3GPP TS 38.321 - NR; Medium Access Control (MAC) protocol specification. Section 6.1.3.3 defines the UE Contention Resolution Identity MAC CE, and section 5.1.5 covers contention resolution.

[2] 3GPP TS 38.321 - Table 6.2.1-1 gives the DL-SCH LCID values, where this MAC CE is 62.

[3] 3GPP TS 38.331 - NR; Radio Resource Control (RRC) protocol specification. RACH-ConfigCommon holds ra-ContentionResolutionTimer, and UL-CCCH and UL-CCCH1 define the message sizes.

[4] C-RNTI MAC CE - the other way a UE resolves contention, on this site.

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