MAC PDU, Subheaders & MAC CEs in 5G NR

1. What a MAC PDU Is For, and Why Every Byte Has a Subheader

The physical layer will accept exactly one transport block per HARQ process per transmission occasion, of exactly one size, chosen by the scheduler from a table TS 38.214 cl. 5.1.3.2. MAC's job is to fill that block completely and to make the result parseable by a peer that was told nothing about what is inside it. Those two requirements together produce the whole design: a flat concatenation of self-describing units, plus padding to make the total land on the transport block size with no slack.

There is no MAC header in the sense that IP or Ethernet has one. There is no PDU-level length, no version, no checksum, no next-header pointer and no field that says how many pieces follow. A receiver starts at offset zero, reads one octet, and works out from that octet alone what to do with the next few. It repeats until it runs out of transport block. Everything good and everything fragile about MAC decoding follows from that.

The pieces MAC concatenates are of two kinds. MAC SDUs come from above: one RLC PDU per logical channel, opaque to MAC. MAC Control Elements are generated by MAC itself and consumed by the peer MAC: no RRC message, no ASN.1, no acknowledgement, no retransmission of their own beyond whatever HARQ gives them. A MAC CE is the cheapest signalling in NR, and that cheapness is why so much of the fast control loop -- timing advance, buffer status, power headroom, carrier activation, beam selection, DRX -- was put here rather than in RRC.

The companion 06 Channel Mapping document introduces the LCID field and the subheader in the context of which channel carries what. This document is the authoritative treatment: every subheader shape including the Rel-16 extensions, both complete codepoint tables, the ordering and padding rules, and each control element with its trigger and layout.

2. The subPDU: the Only Unit MAC Actually Handles

A MAC PDU consists of one or more MAC subPDUs TS 38.321 cl. 6.1.2. A subPDU is a subheader plus at most one of: a MAC SDU, a MAC CE, or padding. That is the entire grammar. There is no nesting, no optional second payload, and no subPDU that carries two things.

Table 1. The six things a subPDU can be. Note the third and fifth rows: two cases where the length is carried by prior knowledge rather than by a field, which is exactly where decoders break.

3. The Subheader, All Six Shapes

Every subheader begins with the same two bit positions and a 6-bit LCID. What follows the LCID depends on what the LCID means, which the receiver has to know in advance. Four shapes existed in Rel-15; Rel-16 added two more by turning two LCID values into escapes.

Table 2. Subheader shapes, TS 38.321 cl. 6.1.2. Nothing in the octets distinguishes A/B from C/D except the LCID value, which is why the codepoint tables in the next two sections are the real parsing specification.

4. LCID on DL-SCH: the Complete Codepoint Space

Six bits, 64 codepoints, and Rel-15 spent all but twelve of them. The structure is worth noticing: SDU identities occupy the bottom, control elements the top, and the escapes sit at 33 and 34, immediately above the logical channel range so that no future logical channel can ever be added without a version break.

Table 3. DL-SCH LCID codepoints, TS 38.321 Table 6.2.1-1, with the size class that decides which subheader shape carries them. The companion 06 Channel Mapping document gives the same table from the channel-mapping angle.

5. LCID on UL-SCH: the Complete Codepoint Space

The uplink table has the same shape and one structural oddity: CCCH appears twice, at 0 and 52, for the two possible sizes. That exists purely so a CCCH SDU can use a 1-octet subheader with no length field -- in MSG3 and MSGA, where every bit is expensive, the codepoint carries the length.

Table 4. UL-SCH LCID codepoints. The Rel-16 assignments in 45-51 are the ones most likely to differ between the spec version you are reading and the decoder you are using -- confirm them against TS 38.321 Table 6.2.1-2 of the release in question.

6. eLCID and the Two-Octet Extended Space

By the end of Rel-15 the downlink table had twelve free codepoints and the uplink had seventeen, against a Rel-16 work programme that added beam-failure reporting, LBT failure reporting, IAB power and guard-symbol signalling, positioning, multi-TRP beam management and unified TCI. Reusing reserved values was not an option, because a receiver that meets an unrecognised fixed-size codepoint cannot find the next subheader -- there is no length to skip. So Rel-16 spent two of the remaining codepoints on escapes.

As of Rel-18 the two-octet space is entirely reserved: nothing has been assigned there yet. Every real extended control element lives in the one-octet space reached through LCID 34. The two-octet escape exists so that the next twenty years of MAC CEs do not require another format change.

Table 5. Representative contents of the one-octet extended space. Codepoints are deliberately not listed: assignments are added from the top of the range downward as features land, and differ between releases. Read them from Table 6.2.1-1b (DL) or 6.2.1-2b (UL) of the exact TS 38.321 version you are decoding against.

7. subPDU Ordering, and Why It Is Asymmetric

The order of subPDUs inside a MAC PDU is fixed by the spec, and it is different in the two directions TS 38.321 cl. 6.1.2.

Table 6. Ordering rules. The uplink exception for Pre-emptive BSR came in with Rel-16 IAB; verify it against the release you are decoding.

Within each of those groups the order is not arbitrary either, but it is decided by a different rule: the relative priority of control elements and logical channel data, defined for the uplink in TS 38.321 cl. 5.4.3.1.3 and covered in the companion 09 LCP document. The short version is that a C-RNTI MAC CE and UL-CCCH data sit above everything, a BSR included as padding sits below everything, and the rest fall between.

8. Padding, and the Single-Byte Case

A transport block size comes from a table; the sum of the subPDUs MAC wants to send almost never equals one of those sizes. The difference is padding, and it goes at the end. NR has no equivalent of LTE's front-placed one- and two-byte padding: the padding subPDU is last, always.

• Zero padding. The subPDUs fill the block exactly. There is no padding subheader at all -- not a padding subheader with L = 0, nothing. This is the normal case for a large data-only PDU where RLC was asked for exactly the right segment size.
• One octet of padding. The padding subPDU is a single R/LCID subheader with LCID 63 and no payload. One octet in, one octet of transport block consumed, nothing wasted on a length field. This is the single-byte case, and it is why the padding subheader has no L field: with one, one byte of slack would be unrepresentable.
• Two or more octets. One padding subheader, then padding octets to the end of the block. The receiver does not need to be told how many: LCID 63 means everything from here on.

One more rule that catches people: MAC does not transmit a PDU consisting only of a padding BSR and padding. If there is nothing else to send, the grant goes unused rather than being spent on a report the network can get another way.

9. How a Receiver Walks a PDU -- and What Happens When It Cannot

Three of the branches above are worth dwelling on, because each corresponds to a distinct log signature.

9.1 Unknown variable-size codepoint

The receiver does not recognise the LCID but the codepoint is in a range it knows to be variable-size, so it reads L and skips L octets. It has lost one subPDU and can continue. In a log this appears as a single "unknown LCID" line followed by correctly decoded subPDUs. Annoying, recoverable, usually a bearer that RRC configured on one side only.

9.2 Unknown fixed-size codepoint

The receiver does not recognise the LCID and there is no length field. It cannot skip, cannot resynchronise, and must discard the remainder of the transport block. Everything after that point is lost -- including, commonly, the data SDUs, since in the downlink CEs come first. One unknown control element costs the whole PDU.

9.3 Length field longer than the remaining transport block

An L value that runs past the end of the block means the parse has already gone wrong upstream -- a mis-parsed subheader, a wrong-direction codepoint table, or a corrupt octet that HARQ CRC should have caught but did not because the corruption is in the decoder's own byte accounting rather than on the air. The PDU is discarded.

10. The Control Element Catalogue

Every MAC CE in NR is listed below by function, with the LCID, the direction, whether the size is fixed, and -- the part that is hardest to find in the spec -- what actually causes one to be emitted. The clause numbers in the last column point at the procedure that triggers the CE, not at its format.

10.1 Identity, contention resolution and grant confirmation

Table 7. Identity CEs. The C-RNTI CE is the one people forget exists: its presence in a MSG3 tells you immediately that this was not an initial access.

10.2 Uplink reporting: buffer, power, rate

Table 8. Reporting CEs. All of these are covered in depth in the companion 10 BSR, PHR, SR document, including the buffer size and power headroom quantisation tables.

10.3 Timing, sleep and carrier control

Table 9. Timing, DRX and carrier CEs. See the companion 04 Timing Advance and 11 DRX documents for the procedures these drive.

10.4 Beam, CSI and SRS control

Table 10. Beam and CSI CEs. Note the split of labour: for data, the CE activates a candidate set and DCI chooses; for control, the CE chooses outright. That is why a PDCCH beam change is a MAC round trip and a PDSCH beam change is not.

10.5 Failure recovery and channel access

Table 11. Recovery CEs, all post-Rel-15. Beam failure on the SpCell is not reported this way -- it uses Random Access. See the companion 12 Beam Failure Recovery document.

11. Bit Layouts of the CEs You Will Actually Meet

Five figures, covering the control elements that appear in ordinary traffic. The rest follow the same conventions: reserved bits are zero, multi-bit fields are big-endian within and across octets, and bitmaps index from bit 0 upward.

11.1 The small fixed-size CEs

Table 12. Fields of the small fixed-size CEs. The 31-is-zero encoding of the TA command is the most commonly mis-read field in MAC: a logged value of 31 is not a missing command.

11.2 SCell Activation/Deactivation

11.3 The two TCI control elements

11.4 BFR and Truncated BFR

11.5 Multiple Entry PHR

The Multiple Entry PHR is the most structurally complicated CE in NR: a bitmap of one or four octets, then one or two octets per reported entry depending on a bit inside the entry itself. Its layout, the PH and P_CMAX,f,c encodings and the virtual-versus-real distinction are covered in full in the companion 10 BSR, PHR, SR document, which also gives the Single Entry PHR layout.

12. What Each CE Tells You When You See It in a Log

A control element in a trace is evidence about state you cannot see directly. This table is the inference, not the definition.

Table 13. Inference table. Every row here is something you can conclude from the presence of a control element without any other information in the log.

13. What Control Costs: Overhead Arithmetic

Table 14. Control overhead against transport block size. Transport block sizes are illustrative values from the TBS table for common PRB/MCS combinations.

The design consequence runs the other way too. Because a fixed-size CE costs exactly one subheader octet and no length field, the marginal cost of adding MAC signalling to NR was almost zero, and that is why so many features that could have been RRC procedures were built as control elements instead. A beam switch that would take an RRCReconfiguration round trip -- tens of milliseconds, an ASN.1 encode and decode, and an acknowledgement -- takes 2 octets and one slot as a MAC CE.

14. Failure Modes and What Each One Means

Table 15. MAC PDU failure modes. Note how many are detected by nobody: MAC has no error reporting toward its peer, so a malformed PDU produces missing behaviour rather than an error message.

15. Where the Configuration Comes From

MAC PDU format is not configurable -- it is fixed by the spec. What is configurable is which control elements are enabled, which logical channel identities exist, and the timers that make CEs fire. Those live in MAC-CellGroupConfig and RLC-BearerConfig inside the cell group configuration TS 38.331.

MAC-CellGroupConfig ::= SEQUENCE {
    drx-Config                 SetupRelease { DRX-Config }      OPTIONAL,
    schedulingRequestConfig    SchedulingRequestConfig          OPTIONAL,
    bsr-Config                 BSR-Config                       OPTIONAL,
    tag-Config                 TAG-Config                       OPTIONAL,
    phr-Config                 SetupRelease { PHR-Config }      OPTIONAL,
    skipUplinkTxDynamic        BOOLEAN,
    ...,
    [[ csi-Mask                BOOLEAN                          OPTIONAL,
       dataInactivityTimer     SetupRelease { DataInactivityTimer } OPTIONAL ]],
    [[ usePreBSR-r16           ENUMERATED {true}                OPTIONAL,
       schedulingRequestID-LBT-SCell-r16 SchedulingRequestId     OPTIONAL,
       lch-BasedPrioritization-r16       ENUMERATED {enabled}    OPTIONAL,
       schedulingRequestID-BFR-SCell-r16 SchedulingRequestId     OPTIONAL ]],
    ...
}

RLC-BearerConfig ::= SEQUENCE {
    logicalChannelIdentity           LogicalChannelIdentity,  -- INTEGER (1..32)
    servedRadioBearer                CHOICE {
        srb-Identity                     SRB-Identity,
        drb-Identity                     DRB-Identity
    }                                                          OPTIONAL,
    reestablishRLC                   ENUMERATED {true}         OPTIONAL,
    rlc-Config                       SetupRelease { RLC-Config } OPTIONAL,
    mac-LogicalChannelConfig         SetupRelease { LogicalChannelConfig } OPTIONAL,
    ...
}

TAG-Config ::= SEQUENCE {
    tag-ToReleaseList  SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG-Id  OPTIONAL,
    tag-ToAddModList   SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG     OPTIONAL
}

TAG ::= SEQUENCE {
    tag-Id                 TAG-Id,        -- INTEGER (0..3), the TAG ID field
    timeAlignmentTimer     TimeAlignmentTimer,
    ...
}

Listing 1. Abridged from TS 38.331. ... marks omitted fields and extension markers. maxNrofTAGs is 4, which is why the TAG ID field in the Timing Advance Command CE is exactly 2 bits.

logicalChannelIdentity

RLC-BearerConfig

logicalChannelGroup

LogicalChannelConfig

multiplePHR

PHR-Config

tag-Id

TAG-Config

drx-Config

MAC-CellGroupConfig

usePreBSR

MAC-CellGroupConfig

lch-BasedPrioritization

MAC-CellGroupConfig

skipUplinkTxDynamic

MAC-CellGroupConfig

Table 16. Configuration that changes what a MAC PDU looks like on the wire.

16. Illustrative Message Traces

16.1 A five-subPDU downlink MAC PDU, octet by octet

09:41:18.204  [MAC-DL] PDSCH, C-RNTI 0x4C0D, TBS 64 octets, HARQ pid 3, NDI 1

  off  hex   binary      decode
  ---  ---   --------    --------------------------------------------------
  0    3D    0011 1101   R=0 R=0 LCID=61   -> Timing Advance Command, fixed 1 oct
  1    23    0010 0011   TAG ID=0  TA Command=35   -> +4 steps, ~1.04 us at 30 kHz
  2    3A    0011 1010   R=0 R=0 LCID=58   -> SCell Activation/Deactivation, 1 oct
  3    06    0000 0110   C7..C1 = 0000011, R=0   -> SCell 1 and SCell 2 ACTIVE,
                                                    SCells 3..7 DEACTIVE
  4    34    0011 0100   R=0 R=0 LCID=52   -> TCI State Indication for UE-specific
                                               PDCCH, fixed 2 oct
  5    00    0000 0000   ServingCellId=0  CORESET ID bits 3..1 = 000
  6    89    1000 1001   CORESET ID bit 0 = 1 -> CORESET 1;  TCI State ID = 9
  7    01    0000 0001   R=0 F=0 LCID=1    -> DCCH (SRB1), 8-bit length follows
  8    16    0001 0110   L = 22 octets
  9-30 ..    (22 octets) RLC AM PDU -> PDCP -> RRCReconfiguration segment
  31   04    0000 0100   R=0 F=0 LCID=4    -> DTCH (DRB1), 8-bit length follows
  32   1A    0001 1010   L = 26 octets
  33-58 ..   (26 octets) RLC AM PDU -> PDCP -> SDAP -> IP
  59   3F    0011 1111   R=0 R=0 LCID=63   -> Padding, to end of transport block
  60-63 00   (4 octets)  padding

  accounting: 2 + 2 + 3 + 24 + 28 + 5 = 64 octets = TBS         [consistent]

09:41:18.204  [MAC] applied TA +4 on TAG 0, restarted timeAlignmentTimer
09:41:18.204  [MAC] SCell 1, SCell 2 -> activated; activation delay pending
09:41:18.204  [MAC] CORESET 1 TCI state -> 9
09:41:18.205  [RLC] DCCH SDU (22) and DTCH SDU (26) delivered upward

Listing 2. Three control elements and two SDUs in one 64-octet block. Note the accounting line: 64 octets of subPDU against a 64-octet TBS is the check described in §14.

16.2 An uplink MAC PDU: data, a BSR, and padding

09:41:22.617  [MAC-UL] grant from DCI 0_1: TBS 68 octets, C-RNTI 0x4C0D,
                       HARQ pid 5, k2 = 4, PUSCH slot 1082.7
09:41:22.617  [MAC]    LCP: Regular BSR pending (triggered 09:41:22.611)
                       DTCH LCID 4: 812 octets available
                       DCCH LCID 1: 0 octets

  off  hex   binary      decode
  ---  ---   --------    --------------------------------------------------
  0    04    0000 0100   R=0 F=0 LCID=4    -> DTCH (DRB1), 8-bit length
  1    3E    0011 1110   L = 62 octets
  2-63 ..    (62 octets) RLC AM PDU, SO=0, 62-octet segment of a 812-octet SDU
  64   3D    0011 1101   R=0 R=0 LCID=61   -> Short BSR, fixed 1 oct
  65   4F    0100 1111   LCG ID=2  Buffer Size index=15  -> > 745 and <= 1038 oct
  66   3F    0011 1111   R=0 R=0 LCID=63   -> Padding
  67   00    0000 0000   1 padding octet

  accounting: 64 + 2 + 2 = 68 octets = TBS                      [consistent]

09:41:22.617  [MAC]    BSR sent -> cancel triggered BSR, restart periodicBSR-Timer
                       (812 - 62 = 750 octets still queued on LCG 2)
                       -- 750 falls in 5-bit level 15, whose range is 746 .. 1038.
                       -- Level 14 (536 .. 745) would UNDER-state it by 5 octets, so
                       -- the UE reports 15 and the gNB learns only 746 <= BS <= 1038.
09:41:22.617  [MAC]    retxBSR-Timer restarted on grant reception

Listing 3. One SDU, one Regular BSR, one octet of padding, exactly filling a 68-octet grant. The uplink order -- SDU first, CE second -- is what makes the reported buffer size describe the queue after this PDU.

16.3 An extended-LCID control element

09:44:03.881  [MAC-DL] PDSCH, C-RNTI 0x4C0D, TBS 16 octets, HARQ pid 1

  off  hex   binary      decode
  ---  ---   --------    --------------------------------------------------
  0    22    0010 0010   R=0 R=0 LCID=34   -> one-octet eLCID escape
  1    E6    1110 0110   eLCID = 230  ->  codepoint 64 + 230 = 294
                         -- this decoder's Rel-17 table resolves 294 to
                         -- Enhanced SCell Activation/Deactivation, 1-octet Ci
  2    06    0000 0110   C7..C1 = 0000011, R=0   -> activate SCell 1, SCell 2
  3    80    1000 0000   entry for SCell 1: TCI state field present, id = 0
  4    82    1000 0010   entry for SCell 2: TCI state field present, id = 2
  5    3F    0011 1111   R=0 R=0 LCID=63   -> Padding
  6-15 00    (10 octets) padding

  accounting: 5 + 11 = 16 octets = TBS                          [consistent]

-- The same event through a decoder that predates the escape:

  0    22    0010 0010   R=0 F=0 LCID=34   *** RESERVED ***
                         decoder assumes shape A and reads the next octet as L
  1    E6                L = 230 octets  -- but only 14 octets remain in the TB
  --   ---   PDU DISCARDED: length exceeds transport block
  -- The SCells are never activated. Nothing is logged as an error on either
  -- side. The gNB's scheduler proceeds as if two carriers are live.

Listing 4. An extended-LCID CE decoded correctly, then the same octets through a decoder that does not know LCID 34. The failure is total and silent.

16.4 A failure: unknown fixed-size codepoint mid-PDU

09:52:47.115  [MAC-DL] PDSCH, C-RNTI 0x4C0D, TBS 96 octets, HARQ pid 7
              CRC ....................... PASS      -- HARQ succeeded

  off  hex   binary      decode
  ---  ---   --------    --------------------------------------------------
  0    3D    0011 1101   R=0 R=0 LCID=61   -> Timing Advance Command
  1    21    0010 0001   TAG ID=0  TA Command=33   -> +2 steps        [applied]
  2    31    0011 0001   R=0 R=0 LCID=49   -> PUCCH spatial relation
                                               Activation/Deactivation
                         *** codepoint not supported by this UE release ***
                         *** fixed-size CE: length is not on the wire   ***
  --   ---   MAC: cannot determine subPDU length -> discard remainder of TB
  --   ---   octets 3..95 (93 octets) LOST, including:
  --   ---     one DCCH subPDU  (RRCReconfiguration, 40 octets)
  --   ---     one DTCH subPDU  (48 octets)

09:52:47.115  [MAC]    no HARQ retransmission requested -- CRC passed
09:52:47.115  [RLC-DL] no SDU delivered
09:52:52.115  [RLC-DL] t-Reassembly expired, gap at SN 1204 -> STATUS PDU (NACK)
09:52:52.117  [RRC]    T310 not started; RRCReconfiguration never arrived
09:53:07.118  [RRC]    RRCReconfiguration not completed -> reconfiguration failure

Listing 5. One unsupported control element costs 93 octets, an RRCReconfiguration and, five seconds later, an RLC status report that looks like a radio problem. The CRC passed.

17. Release Deltas: Rel-15 to Rel-18

Table 17. MAC PDU and CE changes by release. Feature presence should always be confirmed against the UE capability exchange -- see the companion 26 UE Capability document.

18. Reading MAC PDUs in Logs: a Checklist

1. Check the accounting first. Sum every subPDU -- subheaders, payloads, padding -- and compare against the transport block size from the DCI. If they disagree the decode is wrong, and the first subPDU where the running total goes bad is where it broke (§14).

2. Confirm the direction of the codepoint table. LCID 59-62 mean completely different things in each direction and both parse cleanly. If the decode looks impossible -- a UE that sent a DRX Command, a gNB that sent a BSR -- this is why.

3. Read the whole subheader, not just the LCID. The F bit only exists in shapes A and B. If your tool prints an F bit for a fixed-size CE, it is printing a reserved bit and you should not trust the rest of that line.

4. Look for LCID 33 and 34 before believing anything downstream. One unrecognised escape produces one plausible subPDU followed by nonsense. Check the decoder's spec version against the gNB's release (§6).

5. Verify the ordering. Downlink: CEs, then SDUs, then padding. Uplink: SDUs, then CEs, then padding, with Pre-emptive BSR the one exception. A violation is a transmitter bug that produces no error anywhere (§7).

6. Treat a CRC pass with nothing delivered upward as a MAC problem. No HARQ retransmission plus no SDU means the block decoded and the parse failed. Do not go looking at the radio (§16.4).

7. Read SCell Activation bitmaps in full. They are absolute state, not deltas. Compare against the set of SCells you believe were active before (§11.2).

8. Distinguish 1-octet padding from a padding BSR. If two or more octets of padding remain and no BSR was inserted, either no BSR was pending or the padding-BSR logic is not running -- the second is a real finding (§8).

9. Search for zero-length CEs by their subheader octet. DRX Command (0x3C), Long DRX Command (0x3B) and Configured Grant Confirmation (0x37) have no payload and are invisible to any payload-oriented filter.

10. Correlate every CE you see against the configuration that should have enabled it. A DRX Command to a UE with no drx-Config, a Multiple Entry PHR with multiplePHR absent, or a BFR CE with no schedulingRequestID-BFR-SCell are all configuration mismatches, and all of them look like UE misbehaviour until you check.

19. Glossary

20. References

• 3GPP TS 38.321 -- NR MAC protocol specification. Clause 6.1.2 (MAC PDU for DL-SCH and UL-SCH, subPDU and subheader formats, ordering and padding), 6.1.3 (all MAC CE formats -- 6.1.3.1 BSR, 6.1.3.2 C-RNTI, 6.1.3.3 UE Contention Resolution Identity, 6.1.3.4 Timing Advance Command, 6.1.3.5/6 DRX Commands, 6.1.3.7 Configured Grant Confirmation, 6.1.3.8 Single Entry PHR, 6.1.3.9 Multiple Entry PHR, 6.1.3.10 SCell Activation/Deactivation, 6.1.3.11 Duplication Activation/Deactivation, 6.1.3.14/6.1.3.15 TCI CEs, 6.1.3.20 Recommended bit rate, 6.1.3.22/23 BFR), 6.2.1 (subheader formats), Tables 6.2.1-1 and 6.2.1-2 (LCID values), Tables 6.2.1-1a/-1b and -2a/-2b (eLCID values).
• 3GPP TS 38.321 -- the procedures that emit the CEs: clause 5.1.4/5.1.5 (Random Access, C-RNTI and Contention Resolution CEs), 5.2 (timing advance), 5.4.3.1 (logical channel prioritisation and CE priority order), 5.4.5 (BSR), 5.4.6 (PHR), 5.7 (DRX), 5.8.2 (configured grant confirmation), 5.9 (SCell activation), 5.17 (SCell beam failure recovery).
• 3GPP TS 38.331 -- RRC protocol specification. MAC-CellGroupConfig, RLC-BearerConfig, LogicalChannelConfig, TAG-Config, PHR-Config, BSR-Config, DRX-Config.
• 3GPP TS 38.213 -- Physical layer procedures for control. Clause 4.2 (timing advance application), clause 7.7 (power headroom definitions for Types 1, 2 and 3).
• 3GPP TS 38.214 -- Physical layer procedures for data. Clause 5.1.3.2 (transport block size determination -- the sizes MAC must fill exactly).
• 3GPP TS 38.133 -- Requirements for support of radio resource management. Clause 8.3 (SCell activation delay), and the power headroom and P_CMAX reporting ranges.
• 3GPP TS 38.300 -- NR overall description. Clause 6.2 and 6.4 for where MAC sits and what it is responsible for.

Companion documents in this set

• 03 Random Access -- the RAR MAC PDU, which uses a different subheader format entirely, and the UE Contention Resolution Identity and C-RNTI CEs in context.
• 04 Timing Advance -- what the 1-octet relative Timing Advance Command CE does to N_TA, and how it differs from the RAR's absolute command.
• 05 HARQ -- the transport block and CRC layer beneath everything here; essential for separating radio failures from parse failures.
• 06 Channel Mapping -- the LCID tables from the channel-mapping angle, and where logical channel identities come from.
• 08 Scheduling -- who chooses the transport block size MAC has to fill.
• 09 LCP -- how MAC decides which SDUs and which CEs go into a given grant, and the fixed CE priority order.
• 10 BSR, PHR, SR -- the BSR and PHR control elements in full, including the buffer size and power headroom quantisation tables.
• 11 DRX -- what the DRX Command and Long DRX Command CEs actually do.
• 12 Beam Failure Recovery -- the procedure behind the BFR CE, and the SpCell case that uses RACH instead.
• 26 UE Capability -- how to establish which control elements a particular UE will accept.