NR MAC Scheduling: PDCCH Allocation, BSR, DRX, Configured Grant Interview Prep

NR Uplink Grant Mechanisms — Latency, Flexibility, Best Use

Sample interview questions

1. A UE has data in its uplink buffer but no scheduled grant. It needs to request resources from the gNB. What is the difference between SR (Scheduling Request) and BSR (Buffer Status Report), and when does each fire?
   • A. SR and BSR are synonyms; the naming is historical.
   • B. SR is for control data only; BSR is for user data only.
   • C. SR is a single-bit indication on a configured PUCCH resource that tells the gNB "I have data to send" — fires when the UE has data in its buffer but no valid uplink grant and no configured grant to use. BSR is a MAC Control Element carried inside PUSCH (after the UE has an uplink grant) reporting per-Logical-Channel-Group buffer occupancy so the gNB can size subsequent grants. SR triggers the grant; BSR refines the gNB's view of how much to grant. ✓
   • D. BSR fires first; SR follows.

   Option C is correct. The two procedures play distinct roles in the uplink-grant lifecycle: - SR (Scheduling Request) is the first-contact signal. When a UE has uplink data in its buffer but no valid uplink grant and no configured grant available, it transmits SR on a UE-configured PUCCH resource (PUCCH Format 0 or 1). SR carries a single bit — "I have data to send." The gNB receives SR, assigns the UE a small uplink grant for an initial PUSCH transmission, and the UE uses that grant to send a BSR. - BSR (Buffer Status Report) is a MAC Control Element (MAC CE) carried inside a PUSCH transmission. It reports per-Logical-Channel-Group (LCG) buffer occupancy using either a Short BSR (one LCG, 5-bit buffer-size index) or Long BSR (multiple LCGs, 8-bit indices). The gNB uses the BSR to size subsequent grants more accurately. The flow: SR fires when no grant exists → gNB issues a small grant → UE sends MSG3-like initial PUSCH carrying BSR → gNB issues larger grants sized to the BSR-reported buffer. If the UE has a configured grant (Type 1 or Type 2 — see the next FAQ) covering its small periodic uplink traffic, it can skip SR/BSR entirely and just transmit on the pre-configured resources. This is the latency optimization that URLLC and IoT-style traffic rely on. Option A misses real procedural differences. Option B is wrong — both SR and BSR concern user-data buffer state, not control vs data. Option D inverts the order — SR fires first to request a grant; BSR follows once the UE has a grant. Production reality: PUCCH SR-resource configuration is a per-UE RRC parameter; operators tune SR periodicity and resource count based on UE density and expected uplink burst rate.

2. What is the difference between Configured Grant Type 1 and Type 2 in 5G NR, and which is better suited for periodic small URLLC uplink transmissions?
   • A. Type 1 and Type 2 are identical; the naming distinction is historical.
   • B. Type 1 is for downlink only; Type 2 is for uplink only.
   • C. Type 2 is older and is being deprecated.
   • D. Type 1 is fully RRC-configured: the gNB sends an RRC reconfiguration message with all grant parameters (periodicity, frequency-time resources, MCS, HARQ process IDs); the UE starts using the grant immediately at the next periodic occasion. Type 2 is RRC-configured-plus-DCI-activated: RRC provides the configuration framework but the grant is activated and deactivated by a PDCCH/DCI addressed to the CS-RNTI (the UE then sends a Configured Grant Confirmation MAC CE), giving the gNB faster dynamic control over when the grant is in use. Type 1 wins for predictable always-on periodic traffic; Type 2 wins when the gNB needs to activate/deactivate grants on demand without full RRC reconfiguration. ✓

   Option D is correct. Both configured-grant types provide pre-allocated periodic uplink resources that the UE can use without a per-transmission scheduling DCI — cutting the latency of small periodic uplink transmissions to one slot regardless of PDCCH scheduling delay. The difference is in activation semantics: - **Type 1**: Fully RRC-configured. The RRCReconfiguration message carries the full configured-grant configuration — periodicity (per 14 symbols, per slot, per N slots), time-frequency resources, MCS, HARQ process count, repetition count. The UE starts using the grant at the next configured occasion as soon as the RRC reconfiguration completes. Deactivation requires another RRC reconfiguration. - **Type 2**: RRC-configured framework + DCI activation. RRC configures the structural parameters; the actual grant is activated by an "Activation" DCI (DCI 0_0 or 0_1 with specific scheduling fields and the CS-RNTI) and deactivated by a Deactivation DCI. The UE responds to each with a Configured Grant Confirmation MAC CE, so the MAC CE confirms the activation/deactivation rather than commanding it. This gives the gNB faster control to start and stop the grant without RRC reconfiguration cost. When each wins: - **Type 1** is the right choice for traffic that is predictable and always-on: voice streams, periodic sensor data, periodic CSI reporting. The grant is provisioned at session setup and stays in use. - **Type 2** is the right choice for bursty or intermittent traffic where the gNB wants the grant available but not always active: gaming control bursts, intermittent IoT, low-utilization URLLC sessions. The fast activation/deactivation cycle saves UL airtime when traffic is idle. Both are URLLC-friendly because both remove the PDCCH-scheduling round-trip from the uplink path. Combined with mini-slot scheduling and high SCS, configured grants enable the 1 ms uplink latency targets. Option A misses real activation-mode differences. Option B confuses configured-grant uplink with downlink Semi-Persistent Scheduling (SPS) — both PDSCH-SPS and CG-PUSCH exist with similar Type 1/Type 2 split. Option C is wrong — both are current and widely deployed for URLLC and IoT. Production reality: 5G URLLC deployments rely heavily on configured grants; the choice between Type 1 and Type 2 is a per-service-class decision based on the activity pattern.

3. A UE is configured for DRX with short-DRX cycle 20 ms, on-duration 2 ms, inactivity-timer 8 ms. What is the on-duration's role, what does the inactivity-timer do, and how do they trade against latency and power?
   • A. On-duration is the period within each DRX cycle when the UE actively monitors PDCCH for scheduling grants. Inactivity-timer starts on every PDCCH decode that schedules new data; while it is running, the UE keeps monitoring PDCCH beyond the on-duration. When the timer expires without a new grant, the UE returns to DRX-sleep until the next on-duration. Longer on-duration / longer inactivity-timer = lower scheduling latency, higher power; shorter values = higher latency, lower power. Operators tune per UE traffic profile. ✓
   • B. On-duration is the time the UE must transmit continuously; inactivity-timer is the time before sleep.
   • C. On-duration and inactivity-timer are both expressed in seconds.
   • D. DRX disables the UE's data plane; it only wakes for paging.

   Option A is correct. DRX (Discontinuous Reception) is the MAC-layer mechanism that lets RRC_CONNECTED UEs sleep most of the time while still being reachable for scheduling. The configuration: - **DRX cycle**: the period at which the UE wakes (e.g., 20 ms short-DRX, longer for long-DRX). - **On-duration**: the time within each cycle when the UE actively monitors PDCCH (e.g., 2 ms, set by drx-onDurationTimer). - **Inactivity-timer**: when the UE decodes a PDCCH that schedules new data, the inactivity-timer starts. While the timer runs, the UE keeps monitoring PDCCH beyond the on-duration. The timer resets on every new-data PDCCH; the UE returns to DRX-sleep only when the timer expires without a new grant. This combination is the trade-off knob: - Long on-duration + long inactivity-timer → UE monitors more often → lower scheduling latency → higher UE power - Short on-duration + short inactivity-timer → UE monitors less → higher latency → lower power The configuration applies to user-data scheduling only; DRX does not change the UE's RRC state (it stays in RRC_CONNECTED) and does not affect paging behavior (paging is governed by separate timers in RRC_IDLE/RRC_INACTIVE — see /topics/nr-rrc-states). Production tuning examples: - Always-on heavy-throughput data (browsing, streaming): long on-duration + long inactivity-timer minimize per-slot latency at the cost of power - Bursty interactive traffic (gaming, chat): mid values - Periodic low-rate IoT: very short on-duration with carefully-aligned cycle to wake just when sensor data arrives Option B misreads on-duration as a transmit obligation; it is a receive-monitoring period. Option C is wrong — drx-onDurationTimer and drx-InactivityTimer are configured in milliseconds (with some short sub-millisecond values), not seconds. Option D is wrong — DRX is a within-RRC_CONNECTED MAC feature; paging is unrelated. Production reality: DRX tuning is one of the largest UE-power levers. The MAC scheduler and DRX-config interact closely; operators tune per service class and per UE capability category.

Frequently asked questions

What is NR MAC scheduling?

NR MAC scheduling is the function that decides which UEs get which time-frequency resources on the PDSCH and PUSCH every slot. The MAC scheduler runs in the gNB (specifically the DU in CU/DU split deployments) and considers per-UE channel quality (CSI reports, see /topics/nr-reference-signals), buffer state (BSR for uplink, gNB-internal queues for downlink), QoS requirements (5QI per bearer, latency targets), HARQ retransmissions pending, and scheduler policy (proportional-fair, round-robin, latency-priority, etc.). The scheduler emits per-slot DCI messages on PDCCH telling each UE which resources are allocated to it.

What is SR (Scheduling Request)?

SR is a single-bit indication transmitted on a UE-configured PUCCH resource (Format 0 or 1) telling the gNB "I have uplink data to send." The UE fires SR when it has data in its buffer but no valid uplink grant and no configured grant available. The gNB receives SR and assigns the UE a small initial uplink grant, which the UE uses to send a BSR (Buffer Status Report) carrying its actual buffer occupancy. SR has its own configured periodicity per UE — typical values are 5 ms, 10 ms, 20 ms — and operators tune the periodicity based on UE density and expected uplink burst rate. Aggressive (short-period) SR cuts uplink latency but consumes more PUCCH resources.

What is BSR (Buffer Status Report)?

BSR is a MAC Control Element (MAC CE) carried inside a PUSCH transmission that reports per-Logical-Channel-Group (LCG) buffer occupancy at the UE. Two formats: Short BSR (one LCG, 5-bit buffer-size index) for compact reporting when one LCG dominates, and Long BSR (up to 8 LCGs, 8-bit indices each) for full reporting. The gNB uses the BSR to size subsequent uplink grants accurately rather than guessing. BSR triggers include: new data arriving in a higher-priority LCG than currently allocated, periodic BSR timer expiry, padding-BSR when an existing PUSCH has spare capacity for the MAC CE, and retx-BSR after a buffer drain.

What is DRX (Discontinuous Reception)?

DRX is the MAC-layer power-saving feature that lets RRC_CONNECTED UEs sleep most of the time while still being reachable for scheduling. The configuration: DRX cycle (period the UE wakes), on-duration (time within each cycle the UE monitors PDCCH), and inactivity-timer (extends monitoring when a new-data grant was just decoded). DRX has short-DRX and long-DRX variants for bursty-active vs low-activity traffic. DRX is orthogonal to RRC state — the UE stays in RRC_CONNECTED throughout. The configuration is one of the largest UE-power levers; operators tune it per service class.

What is configured grant (Type 1 vs Type 2)?

Configured grant is the pre-allocated periodic uplink resource that the UE can use without per-transmission scheduling DCI — cutting uplink latency for periodic small transmissions. Type 1 is fully RRC-configured: the RRCReconfiguration carries all grant parameters and the UE starts using it immediately at the next periodic occasion. Type 2 is RRC-configured-plus-DCI-activated: RRC sets the structural parameters but the grant is activated and deactivated by a PDCCH/DCI addressed to the CS-RNTI (with the UE returning a Configured Grant Confirmation MAC CE), giving the gNB faster dynamic control. Type 1 wins for predictable always-on traffic; Type 2 wins for bursty traffic where the gNB wants to provision the grant but turn it on and off without RRC reconfiguration overhead. Both are core mechanisms for URLLC and IoT uplink-latency reduction.

What is a MAC Control Element (MAC CE)?

A MAC CE is a control message carried at the MAC layer between the gNB and UE, multiplexed alongside data in a MAC PDU. MAC CEs cover a wide range of functions: BSR (uplink buffer status), PHR (power headroom report — tells the gNB how much more uplink transmit power the UE has available), C-RNTI (used during contention-free RACH for context confirmation), Activation/Deactivation of various features (SCells in CA, configured grants Type 2, semi-persistent scheduling), TCI state activation (selecting active TCI states from the RRC-configured pool — see /topics/nr-beam-management), and SRS-trigger. MAC CEs use Logical Channel IDs (LCIDs) to identify themselves; the gNB and UE both maintain LCID-to-MAC-CE mapping tables. MAC CEs are the layer-2 control plane that complements DCI on PDCCH.

How does the scheduler trade off latency, throughput, and fairness?

A typical NR scheduler runs a proportional-fair (PF) algorithm at the base. PF assigns priority to each UE per-slot based on the ratio of its instantaneous achievable rate to its average historical rate — high-priority UEs are those with currently-good channels relative to their long-run history. Modifications to base PF: latency-priority adjustments for URLLC and time-critical bearers (latency budget enters the priority calculation), QoS-aware weighting (5QI weights enter the priority), CA optimization across cells, and HARQ-retx priority (retransmissions usually get scheduled before new initial transmissions). The scheduler also handles the per-cell aggregate constraints — fronthaul bandwidth (in CU/DU split), PRB exhaustion under high load, and PA power-saving modes. Schedulers in 2026 are heavily customized per operator and per vendor; this is one of the most competitive pieces of RAN IP.

How does MAC scheduling interact with HARQ?

HARQ retransmissions in 5G NR are scheduled into the same resource grid as initial transmissions, so the MAC scheduler decides slot-by-slot whether to retransmit a failed packet or schedule new data. Each UE has a configured number of HARQ processes (typically 8 or 16) running in parallel; the scheduler tracks per-process state and decides retx priority. The scheduler may allocate more bandwidth to a retransmission than the original (for combining gain), or schedule it on a different frequency for diversity. HARQ-retx generally gets priority over initial transmissions for the same UE because the retransmission completes a previously-started transmission; new data can wait one more slot. See /topics/harq for the HARQ-combining context and /topics/nr-channel-coding for the channel-coding-side detail.

Related topics