The purpose and function of NR MAC CE is almost same as LTE MAC CE.

When we say 'communication between UE and Network', we normally think about only signaling message (RRC or NAS message). When I say 'communication' in this case, it means 'control command exchange' between UE and network, not the data traffic.

In UMTS case, it is true that only RRC and NAS message functions as communication between UE and Network, but in LTE and NR a special type of communication is introduced working at MAC Layer. It implies that there are special MAC structure that carries special control information. These special MAC structure carrying the control information is called 'MAC CE', which means 'MAC Control Element'. Motivation for this kind of communication would be obvious. It would be much faster comparing to RRC layer or NAS layer communication.

This special MAC structure is implemented as a special bit string in LCID field of MAC Header (Refer to LTE MAC page for the details of MAC header).

There are several MAC CE in downlink MAC and also several MAC CE in uplink MAC. Following table from 38.213 shows the LCID types of MAC header. The parts marked in red rectangle is LCID representing various MAC CE. These are relatively small set of MAC CE defined in 38.321 Rel 15 - 6.2.1. You may see this gets longer as new release comes out as you have seen in LTE.

• Evolution of MAC CE
• MAC CE List in 38.321 v15.1
• MAC CE List in 38.321 v15.3
• MAC CE List in 38.321 v16.4
• MAC CE List in 38.321 v17.1
• MAC CE List in 38.321 v19.0
• List of MAC CE
• How is a MAC CE actually framed inside a MAC PDU ?
• Where does a MAC CE sit inside a MAC PDU ?
• Why did the LCID space have to be extended ?
• When does a control action use a MAC CE rather than RRC or DCI ?
• What do the MAC CEs do, grouped by purpose ?
• Reference

Evolution of MAC CE

As in LTE, the structure and functionality of MAC CE would be an area that is evolving continuously as new 3GPP release comes out. In this section, I will consollidates MAC CE LCID structure from different releases so that we can keep track of the structure and functional evolution of MAC CE.

NOTE : The definition of LCID and eLCID is stated as follows in 38.321-6.2.1.

LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC CE or padding as described in 38.321-Tables 6.2.1-1, 6.2.1-1c and 6.2.1-2 for the DL-SCH and UL-SCH respectively. There is one LCID field per MAC subheader. The size of the LCID field is 6 bits. If the LCID field is set to 34, one additional octet is present in the MAC subheader containing the eLCID field and follow the octet containing LCID field. If the LCID field is set to 33, two additional octets are present in the MAC subheader containing the eLCID field and these two additional octets follow the octet containing LCID field.

eLCID: The extended Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC CE as described in 38.321-tables 6.2.1-1a, 6.2.1-1b, 6.2.1-2a and 6.2.1-2b for the DL-SCH and UL-SCH respectively. The size of the eLCID field is either 8 bits or 16 bits.

MAC CE List in 38.321 v15.1

MAC CE List in 38.321 v15.3

MAC CE List in 38.321 v16.4

MAC CE List in 38.321 v17.1

MAC CE List in 38.321 v19.0

< 38.321 -  Table 6.2.1-1: Values of LCID for DL-SCH >

< 38.321 -  Table 6.2.1-1a: Values of two-octet eLCID for DL-SCH >

< 38.321 -  Table 6.2.1-1b: Values of one-octet eLCID for DL-SCH >

< 38.321 -  Table 6.2.1-1c: Values of LCID for MBS multicast MCCH and MBS broadcast on DL-SCH >

< 38.321 -  Table 6.2.1-2: Values of LCID for UL-SCH when the LX field is not present or is set to 0 >

< 38.321 -  Table 6.2.1-2a: Values of two-octet eLCID for UL-SCH >

< 38.321 -  Table 6.2.1-2b: Values of one-octet eLCID for UL-SCH >

< 38.321 -  Table 6.2.1-2c: Values of LCID for UL-SCH when the LX field is set to 1 >

List of MAC CE

Followings are the list of the MAC CEs specified in 38.321 as of now. Since each of these items is a pretty big top, I will create a separate page for each of these items.

How is a MAC CE actually framed inside a MAC PDU ?

I spent a while assuming a MAC CE carried a header of its own. It does not. A MAC CE is a payload, and what identifies it is the MAC subheader in front of it.

A MAC PDU is a sequence of MAC subPDUs. Each subPDU is one MAC subheader followed by one of three things: a MAC SDU, a MAC CE, or padding. The LCID value in that subheader says which of the three it is. For a MAC CE it also says which one.

The subheader comes in two shapes, and the deciding question is whether the thing behind it has a fixed length. A fixed-size MAC CE always occupies the same number of octets, so there is nothing to signal. Its subheader is one octet, holding two reserved bits and the six-bit LCID. Padding and the UL-CCCH MAC SDU use the same one-octet form.

A variable-size MAC CE, or any ordinary MAC SDU, needs a length. Its subheader replaces the second reserved bit with the F field and adds an L field behind the LCID. F set to 0 means L is 8 bits and the subheader is two octets. F set to 1 means L is 16 bits and the subheader is three octets.

The eLCID escapes add octets on top of that, in the way the quoted text in Evolution of MAC CE describes. An LCID of 34 is followed by one further octet carrying an 8-bit eLCID. An LCID of 33 is followed by two further octets carrying a 16-bit eLCID. In both cases the LCID itself has stopped being a name and become a pointer to one.

Figure 1 draws all five layouts against a common octet ruler.

Figure 1. The LCID value both names the MAC CE and decides how many octets the subheader occupies.

• A MAC CE is a payload, not a header : The MAC subheader in front of it is what names it.
• Fixed-size means a one-octet subheader : Two reserved bits and the six-bit LCID, with no length field at all.
• Variable-size adds F and L : F set to 0 gives an 8-bit length. F set to 1 gives a 16-bit length.
• eLCID makes the LCID a pointer : An LCID of 34 or 33 says the real identifier follows, in one octet or two.
• The LCID decides the subheader size : Resolve the LCID first, or you do not know where the payload starts.

Where does a MAC CE sit inside a MAC PDU ?

The order of subPDUs inside a MAC PDU is not free. TS 38.321 fixes it, and it fixes it differently for the two directions.

In a downlink MAC PDU the MAC CE subPDUs come before every MAC SDU subPDU, and before the padding. In an uplink MAC PDU they are placed after all the subPDUs carrying MAC SDUs, and still before the padding. The two directions are mirror images of each other.

The reason is about when each end can do its work. A gNB sending a MAC CE wants the UE to act on it. Putting the CEs at the front lets the UE apply a timing advance or a DRX command without parsing the data first. A UE building an uplink PDU has the opposite problem. It wants its buffer status report to describe what is left after packing. So it fills the data in first, and appends the control elements afterwards.

This is one of the places where NR differs from LTE, where MAC CEs sat at the front in both directions. Anyone reading an NR uplink trace with LTE habits will look for the MAC CEs in the wrong place.

Figure 2 draws both layouts.

Figure 2. The asymmetry is deliberate. Each direction puts the MAC CEs where the sender can fill them in latest and the receiver can act on them earliest.

• Downlink puts MAC CEs first : They come before every MAC SDU, so the UE can act on them before parsing data.
• Uplink puts MAC CEs last : They come after every MAC SDU. The UE can then report the state that is true after packing.
• Padding is last in both directions : It is a subPDU like any other, with its own one-octet subheader.
• This changed from LTE : LTE placed MAC CEs at the front in both directions. An LTE habit finds them in the wrong place in an NR uplink PDU.

Why did the LCID space have to be extended ?

The version tables in this page show the MAC CE list growing release by release. The eLCID escape appears part way through that growth, and the arithmetic behind it is short enough to work through.

The LCID field is six bits, so it has 64 codepoints in total. Most of them were spoken for before any MAC CE was defined.

That leaves fewer than thirty codepoints in each direction for every MAC CE type the specification would ever define. Release 15 fitted comfortably. By Release 16 the space was gone. Carrier aggregation, beam management, semi-persistent CSI and SRS, PDCP duplication and sidelink all wanted control elements.

Widening the LCID field would have changed every subheader in the protocol. Release 16 spent two of the remaining codepoints on escapes instead. An LCID of 34 says the identifier continues in one more octet, and an LCID of 33 says it continues in two. That buys 256 further values through the one-octet form, and 65536 through the two-octet form. Only the subPDUs that need them pay the extra octet or two.

This is why the tables in this page come in pairs. Every release from 16 onward has an LCID table and an eLCID table for each direction. A MAC CE introduced after the exhaustion point lives in the second of the two.

• Six bits give 64 codepoints : Logical channel identities alone take 32 of them, and CCCH and padding take more.
• Fewer than thirty were ever available for MAC CEs : Release 16 exhausted them.
• The escape was cheaper than a wider field : Widening LCID would have changed every subheader, including those that did not need it.
• The cost falls only where it is used : A subPDU pays the extra octets only when its identifier is in the extended space.
• That is why each release has two tables per direction : One for LCID and one for eLCID.

When does a control action use a MAC CE rather than RRC or DCI ?

The question I find most useful when meeting an unfamiliar MAC CE is why it is a MAC CE at all. NR has three ways to send a control instruction. The choice trades speed against reliability and size.

A pattern runs through the table, and it explains most of the MAC CE list. RRC configures, and MAC CE activates. The heavy description of a CSI report, an SRS resource set or an SCell arrives once by RRC. After that a MAC CE turns it on and off. Sending the whole description again for every change would be far too slow. A DCI is far too small to carry it.

The reporting MAC CEs work by the same logic in the other direction. A buffer status report is too large for a DCI and far too frequent for RRC. MAC is the only layer left.

One consequence is worth remembering when reading a trace. A MAC CE does not take effect the instant it is received. The specification defines an application delay for several of them, measured from the HARQ acknowledgement of the transport block that carried it. An SCell that appears inactive shortly after an activation MAC CE is usually inside that window rather than failing.

• RRC configures and MAC CE activates : The structure arrives once by RRC. A small MAC CE switches it on and off afterwards.
• MAC CE sits between DCI and RRC : Slower than a DCI and faster than RRC. Larger than a DCI and smaller than RRC.
• HARQ is what makes a MAC CE reliable : The transport block carrying it is retransmitted, which a DCI never is.
• Reports go by MAC CE for the same reason : Too big for a DCI, and too frequent for RRC.
• Application delay is defined, not immediate : Several MAC CEs take effect a specified time after the HARQ acknowledgement.

What do the MAC CEs do, grouped by purpose ?

The list in List of MAC CE is ordered by specification section. That is the right order for looking something up, and the wrong order for learning what exists. Grouped by purpose the same list is much shorter to hold.

Two observations come out of the grouping. The first is how many of these elements only activate and deactivate. That is the RRC configures, MAC CE activates pattern from the section above. It accounts for the carrier aggregation, beam management and measurement groups almost entirely.

The second is where the growth happened. The first four groups were largely complete in Release 15, because they cover things every connection needs. Everything added since is a feature that only some deployments use, which is exactly the traffic that exhausted the LCID space.

• Most MAC CEs only switch things on and off : The configuration itself came earlier, by RRC.
• The Release 15 groups are the universal ones : Random access, timing, reporting and power saving are needed by every connection.
• Later groups are feature specific : Sidelink, duplication, positioning and multicast are used only where those features are deployed.
• The spec-ordered list stays the reference : Use the grouping to find the area. Use List of MAC CE to find the section number.

Reference

[1]