LCID is one of the most important component of a MAC header. Basically it tells the characteristics or the destination of the MAC data. For example, it tells whether the MAC data is for control signal or user data or signaling message etc. For the details, refer to MAC PDU Structure for SCH.

• One Subheader for Every Element
• The Five Bits That Carry the LCID
• What the Values Mean
• The Extended LCID
• Reference

One Subheader for Every Element

A MAC PDU is not one object with a header on the front. It is a run of elements, and every one of them arrives with a subheader of its own. The LCID is the field in that subheader which says what the element is.

36.321 clause 6.1.2 builds the PDU in two halves. The MAC header is one or more subheaders, and the payload holds the things those subheaders describe. Each subheader corresponds to either a MAC SDU, a MAC control element or padding. The subheaders keep the same order as the elements, so the third subheader belongs to the third element. Figure 1 draws that shape.

Figure 1. The LCID is what makes this readable. The payload carries no label of its own, so the only way to tell a control element from a service data unit is to read the subheader that stands for it.

The clause adds two ordering rules. MAC control elements are always placed before any MAC SDU, so a decoder meets the control traffic first whatever the scheduler had to send. Padding occurs at the end of the MAC PDU. The exception is single-byte or two-byte padding, and its subheaders are placed at the beginning of the MAC PDU before any other subheader.

One limit bounds the PDU. 36.321 clause 6.1.2 allows a maximum of one MAC PDU per transport block per MAC entity. Everything a MAC entity sends in that block therefore shares one header and one run of LCID values.

• One subheader per element : 36.321 clause 6.1.2 gives every MAC SDU, every control element and padding one of its own.
• Order is preserved across the two halves : the subheaders run in the same order as the elements they describe.
• Control elements come before data : the clause places every MAC control element ahead of any MAC SDU.
• Padding closes the PDU : except for one or two byte padding, whose subheaders open it instead.
• One PDU per transport block : per MAC entity, so one header covers everything sent in that block.

The Five Bits That Carry the LCID

The subheader is octet aligned, and the first octet is where the field lives. Four fields share that octet, and the LCID takes five of its eight bits.

36.321 clause 6.2.1 gives the subheader the field order R, F2, E and LCID. R is a reserved bit set to 0. F2 and F together say how large the Length field is. E says whether another subheader follows. The LCID field size is 5 bits, which leaves 32 codepoints to cover every logical channel and every control element a direction defines. Figure 2 sets out the octets in order, drawn for the 15 bit Length field.

Figure 2. Only the first octet is always there, and the LCID owns five of its eight bits. Everything after it is conditional, which is why a subheader can be one octet long or four.

The E field is what chains the header together. 36.321 sets E to 1 to indicate another set of at least R/F2/E/LCID fields. It sets E to 0 to indicate that a MAC SDU, a MAC control element or padding starts at the next byte. A decoder therefore reads one octet, tests one bit, and either loops or stops.

The Length field is the part that is not always there. The clause drops the L field for the last subheader in the MAC PDU and for fixed sized MAC control elements, because neither of those needs a length. Where L is present, 36.321 Table 6.2.1-3 sizes it. With F2 and F both 0 the field is 7 bits, with F2 at 0 and F at 1 it is 15 bits, and with F2 at 1 it is 16 bits.

• The LCID field is 5 bits : 36.321 clause 6.2.1 fixes it there, so each direction has 32 codepoints in all.
• Three other fields share the first octet : one reserved bit, one format bit and one extension bit.
• E chains the subheaders : 1 means another R/F2/E/LCID set follows, 0 means the payload starts at the next byte.
• The Length field is conditional : absent for the last subheader and for every fixed size control element.
• F and F2 size that length : 7 bits, 15 bits or 16 bits, by 36.321 Table 6.2.1-3.

What the Values Mean

Thirty two codepoints is not a generous budget, and the specification spends it differently in each direction. The same five bits therefore mean one thing on the downlink and something else on the uplink.

36.321 Table 6.2.1-1 and Table 6.2.1-2 divide the range the same way. The bottom of the range names logical channels. The top of the range names MAC control elements. 11111 is padding in both directions. The table below sets the two side by side, so a codepoint that carries different meanings is easy to find.

Three uplink codepoints all mean CCCH. 36.321 clause 6.2.1 gives 00000 as the ordinary value. It gives 01011 to a Category 0 UE outside enhanced coverage that supports frequency hopping for unicast, and 01100 to a BL UE or a UE in enhanced coverage with the same support. A fourth codepoint, 01101, carries CCCH and an Extended Power Headroom Report together.

The MCH has a table of its own. 36.321 Table 6.2.1-4 gives 00000 to MCCH, 00001 to 11100 to MTCH, and 11110 to MCH Scheduling Information. A note there lets an MTCH take the MCCH value when there is no MCCH on the MCH.

The identity at the bottom of the range names a channel and nothing more. It does not say which group that channel belongs to. The group is a separate field in the same configuration, and the page on LCG covers it.

• The bottom of the range names channels : 00001 to 01010 is the identity of the logical channel in both directions.
• The top of the range names control elements : and the two directions put different ones at that end of the range.
• 11111 is padding everywhere : downlink, uplink and MCH alike.
• The uplink has three ways to say CCCH : 00000, 01011 and 01100, chosen by UE category and by coverage.
• A codepoint means nothing on its own : 11010 is a Long DRX Command downlink and a Power Headroom Report uplink.

The Extended LCID

Thirty two codepoints were not enough. The specification answered with an escape rather than a wider field, and the escape costs a second octet only on the subheaders that use it.

36.321 clause 6.2.1 reserves 10000 for the escape. If the LCID field is set to 10000, an additional octet is present in the MAC PDU subheader containing the eLCID field, and that octet follows the one holding the LCID. The eLCID field is 6 bits, so the second octet spends two bits on reserved fields and six on the value.

The new range is barely used so far. 36.321 Table 6.2.1-1a and Table 6.2.1-2a both map codepoints 000000 to 000110 onto indices 32 to 38, and both call them the identity of the logical channel. Everything above that, indices 39 to 95, is reserved. The extension therefore adds seven more logical channel identities in each direction, and nothing else yet.

Those two tables are identical in shape, which is unusual on this page. Everywhere else the downlink and the uplink give the same codepoints different meanings, and Figure 2 shows where the extra octet goes when the escape is taken.

• 10000 is the escape codepoint : 36.321 clause 6.2.1 makes it the value that adds an octet.
• The eLCID field is 6 bits : carried in a second octet behind two reserved bits.
• Indices 32 to 38 are in use : seven more logical channel identities, uplink and downlink alike.
• Indices 39 to 95 are reserved : the extended range still has most of its room left.
• The cost is paid only when the escape is taken : a subheader that does not use it stays one octet long.

Reference

One specification carries almost all of this. The MAC one defines the header, the field widths and every codepoint table quoted above, and the RRC one names the identity that the bottom of the range carries.

[1] 36.321 : 3GPP - E-UTRA; Medium Access Control, v19.3.0. Clause 6.1.2 gives the MAC PDU and the subheader field order. Clause 6.2.1 gives the field widths and the codepoint tables: 6.2.1-1 and 6.2.1-2 for the LCID, 6.2.1-1a and 6.2.1-2a for the eLCID, 6.2.1-3 for the Length field size, and 6.2.1-4 for the MCH.

[2] 36.331 : 3GPP - E-UTRA; Radio Resource Control, v19.3.0. logicalChannelIdentity is the field that fills the bottom of the LCID range, and it is configured per bearer alongside logicalChannelGroup.