MAC¶

MAC in the Protocol Stack¶

MAC is largely transparent to two logical channels — BCCH and PCCH — meaning it doesn't add any of its own header information to them, even though BCCH-over-DL-SCH still goes through HARQ.¹ Everything else gets full MAC treatment: multiplexed alongside other logical channels, given a MAC subheader, and packed into a Transport Block.

Logical Channels & Transport Channels¶

MAC's most fundamental job is bridging two different worlds — the logical channels RLC deals in, and the transport channels PHY deals in:²

The mapping¶

Core Functions¶

Function Relevance by Link Direction¶

The functions above don't all apply equally everywhere. TS 38.321's Table 4.4-1 breaks down exactly which link direction each function is relevant for — from the perspective of a single UE's MAC entity, so "Downlink" means the UE receiving and "Uplink" means the UE transmitting:²

The pattern makes sense once you notice it: multiplexing and LCP only happen on the transmitting side (you don't need to prioritize or pack data you're receiving), demultiplexing only happens on the receiving side, and HARQ and channel mapping — being symmetric, per-direction concerns — apply everywhere. Sidelink (SL) is UE-to-UE device communication that bypasses the gNB entirely (used for V2X and similar use cases) and isn't otherwise covered on this site; Radio resource selection — the UE autonomously picking its own transmission resources rather than being scheduled — only exists in that sidelink context, which is why it's the one function with just a single ✅.

HARQ¶

HARQ (Hybrid ARQ) combines Forward Error Correction with a fast, PHY-level ACK/NACK retransmission loop — the sender transmits a coded version of the data, the receiver tries to decode it, and if it fails, the receiver keeps the failed attempt and combines it with the retransmission (soft combining) rather than throwing it away. Multiple HARQ processes run in parallel per cell, so the sender doesn't have to sit idle waiting for one ACK before sending the next Transport Block.

Scheduling Info: BSR & PHR¶

Since the gNB decides how much uplink resource each UE gets, the UE needs a way to say how much data it actually has and how much power headroom it has left:

• Buffer Status Report (BSR) — reports how much data is buffered, grouped into up to 8 Logical Channel Groups (LCGs) rather than per individual logical channel. Triggered three ways: Regular (new higher-priority data arrives), Periodic (a configured timer), and Padding (there's leftover space in a Transport Block too small for anything else useful).
• Power Headroom Report (PHR) — reports how much extra transmit power the UE has available beyond what it's currently using, helping the gNB avoid granting more uplink resource than the UE can actually transmit at.

Logical Channel Prioritization (LCP)¶

When a UE gets an uplink grant, it has to decide which of its own logical channels get served first. Each logical channel is configured via RRC's LogicalChannelConfig⁴ with a priority (1–16, lower number = higher priority), a Prioritized Bit Rate (PBR), and a Bucket Size Duration (BSD) — a token-bucket mechanism that guarantees every logical channel gets at least its configured rate before any leftover grant is handed to the highest-priority channel first.²

Within one UE's grant, the overall priority order is:²

1. MAC CE for C-RNTI, or data from UL-CCCH
2. MAC CE for BSR (except a BSR sent purely for padding)
3. MAC CE for PHR
4. Data from any other logical channel
5. MAC CE for BSR sent purely for padding

MAC Control Elements¶

Not everything MAC sends is user or signalling data — some of it is MAC talking to MAC, using MAC Control Elements (CEs), identified by reserved LCID values in the MAC subheader:¹

MAC PDU Structure¶

A MAC PDU is a sequence of MAC subheaders, each immediately followed by the MAC SDU, MAC CE, or padding it describes. Subheaders carry an LCID (identifying which logical channel, or which CE, the payload is) and, for variable-length payloads, a length field — this is what lets multiple SDUs from different logical channels, and multiple CEs, all ride together in a single Transport Block.

Scheduling: What 3GPP Does — and Doesn't — Specify¶

Every TTI, the gNB's scheduler has to decide which UEs get which time/frequency resources, using exactly the inputs covered above: BSR (who has data to send), PHR (who has the power budget to send it), and channel quality feedback (CQI, not covered on this page) telling it who's likely to get a clean decode right now.

Common approaches vendors implement, none of them mandated by spec:

• Round Robin — cycles through UEs with pending data in a fixed order, regardless of radio conditions. Simple and fair, but ignores channel quality entirely.
• Max C/I (Maximum Carrier-to-Interference) — always schedules whoever currently has the best channel quality. Maximizes total cell throughput, but can starve UEs with persistently poor conditions (e.g., cell-edge users).
• Proportional Fair (PF) — schedules based on a UE's instantaneous channel quality relative to its own recent average throughput, rather than its absolute quality. This is the common middle ground: it still favors good conditions, but doesn't let a consistently strong UE monopolize the cell the way Max C/I would.

Whichever algorithm a vendor picks, it consumes the same BSR/PHR/CQI inputs and still has to respect each UE's own LCP configuration once that UE's grant is decided — scheduling decides how much resource a UE gets; LCP decides what that UE does with it.

Logical Channel Information Elements¶

The LogicalChannelConfig IE (below) is what actually configures a logical channel's LCP behavior — priority, PBR, BSD, and its assigned LCG.⁴

BCCH-BCH-Message ::=            SEQUENCE {
    message                         BCCH-BCH-MessageType
}

BCCH-BCH-MessageType ::=        CHOICE {
    mib                             MIB,
    messageClassExtension           SEQUENCE {}
}

BCCH-DL-SCH-Message ::=         SEQUENCE {
    message                         BCCH-DL-SCH-MessageType
}

BCCH-DL-SCH-MessageType ::=     CHOICE {
    c1                              CHOICE {
        systemInformation               SystemInformation,
        systemInformationBlockType1     SIB1
    },
    messageClassExtension           SEQUENCE {}
}

DL-CCCH-Message ::=             SEQUENCE {
    message                         DL-CCCH-MessageType
}

DL-CCCH-MessageType ::=         CHOICE {
    c1                              CHOICE {
        rrcReject                       RRCReject,
        rrcSetup                        RRCSetup,
        spare2                          NULL,
        spare1                          NULL
    },
    messageClassExtension           SEQUENCE {}
}

UL-CCCH-Message ::=             SEQUENCE {
    message                         UL-CCCH-MessageType
}

UL-CCCH-MessageType ::=         CHOICE {
    c1                              CHOICE {
        rrcSetupRequest                 RRCSetupRequest,
        rrcResumeRequest                RRCResumeRequest,
        rrcReestablishmentRequest       RRCReestablishmentRequest,
        rrcSystemInfoRequest            RRCSystemInfoRequest
    },
    messageClassExtension           SEQUENCE {}
}

UL-CCCH1-Message ::=            SEQUENCE {
    message                         UL-CCCH1-MessageType
}

UL-CCCH1-MessageType ::=        CHOICE {
    c1                              CHOICE {
        rrcResumeRequest1               RRCResumeRequest1,
        spare3 NULL,
        spare2 NULL,
        spare1 NULL

    },
    messageClassExtension SEQUENCE {}
}

DL-DCCH-Message ::=                  SEQUENCE {
    message                             DL-DCCH-MessageType
}

DL-DCCH-MessageType ::=             CHOICE {
    c1                                  CHOICE {
        rrcReconfiguration                  RRCReconfiguration,
        rrcResume                           RRCResume,
        rrcRelease                          RRCRelease,
        rrcReestablishment                  RRCReestablishment,
        securityModeCommand                 SecurityModeCommand,
        dlInformationTransfer               DLInformationTransfer,
        ueCapabilityEnquiry                 UECapabilityEnquiry,
        counterCheck                        CounterCheck,
        mobilityFromNRCommand               MobilityFromNRCommand,
        dlDedicatedMessageSegment-r16       DLDedicatedMessageSegment-r16,
        ueInformationRequest-r16            UEInformationRequest-r16,
        dlInformationTransferMRDC-r16       DLInformationTransferMRDC-r16,
        loggedMeasurementConfiguration-r16  LoggedMeasurementConfiguration-r16,
                spare3 NULL, spare2 NULL, spare1 NULL
    },
    messageClassExtension   SEQUENCE {}
}

UL-DCCH-Message ::=             SEQUENCE {
    message                         UL-DCCH-MessageType
}

UL-DCCH-MessageType ::=         CHOICE {
    c1                              CHOICE {
        measurementReport               MeasurementReport,
        rrcReconfigurationComplete      RRCReconfigurationComplete,
        rrcSetupComplete                RRCSetupComplete,
        rrcReestablishmentComplete      RRCReestablishmentComplete,
        rrcResumeComplete               RRCResumeComplete,
        securityModeComplete            SecurityModeComplete,
        securityModeFailure             SecurityModeFailure,
        ulInformationTransfer           ULInformationTransfer,
        locationMeasurementIndication   LocationMeasurementIndication,
        ueCapabilityInformation         UECapabilityInformation,
        counterCheckResponse            CounterCheckResponse,
        ueAssistanceInformation         UEAssistanceInformation,
        failureInformation              FailureInformation,
        ulInformationTransferMRDC       ULInformationTransferMRDC,
        scgFailureInformation           SCGFailureInformation,
        scgFailureInformationEUTRA      SCGFailureInformationEUTRA
    },
    messageClassExtension           CHOICE {
        c2                              CHOICE {
            ulDedicatedMessageSegment-r16    ULDedicatedMessageSegment-r16,
            dedicatedSIBRequest-r16         DedicatedSIBRequest-r16,
            mcgFailureInformation-r16       MCGFailureInformation-r16,
            ueInformationResponse-r16       UEInformationResponse-r16,
            sidelinkUEInformationNR-r16     SidelinkUEInformationNR-r16,
            ulInformationTransferIRAT-r16   ULInformationTransferIRAT-r16,
            iabOtherInformation-r16         IABOtherInformation-r16,
            mbsInterestIndication-r17       MBSInterestIndication-r17,
            uePositioningAssistanceInfo-r17 UEPositioningAssistanceInfo-r17,
            measurementReportAppLayer-r17   MeasurementReportAppLayer-r17,
                                            spare6 NULL, spare5 NULL, spare4 NULL, spare3 NULL, spare2 NULL, spare1 NULL
        },
        messageClassExtensionFuture-r16    SEQUENCE {}
    }
}

MCCH-Message-r17 ::= SEQUENCE {
    message              MCCH-MessageType-r17
}

MCCH-MessageType-r17 ::= CHOICE {
    c1                       CHOICE {
        mbsBroadcastConfiguration-r17     MBSBroadcastConfiguration-r17,
        spare1                            NULL
    },
    messageClassExtension   SEQUENCE {}
}

PCCH-Message ::=                SEQUENCE {
    message                         PCCH-MessageType
}

PCCH-MessageType ::=            CHOICE {
    c1                              CHOICE {
        paging                          Paging,
        spare1  NULL
    },
    messageClassExtension       SEQUENCE {}
}

Useful Resources¶

• 3GPP TS 38.321 — NR MAC protocol specification: channels, functions, HARQ, LCP, MAC CEs, and Random Access (Clause 5.1)
• 3GPP TS 38.331 — RRC protocol specification, including LogicalChannelConfig
• 3GPP TS 38.300 — NR overall description, protocol stack overview
• ShareTechnote — 5G/NR: MAC Control Elements
• ShareTechnote — 5G/NR: HARQ