Same link, same rules, same capture: over 144 frames of one 5G NR MAC session, the uplink threw away 30,955 bytes on padding, and the downlink threw away none. That asymmetry is the whole MAC layer explaining itself.
What the capture shows
MAC runs one entity per UE, not one per bearer. PDCP and RLC genuinely run one entity per bearer, each with its own sequence-number space. Both chains end at a single scheduler, keyed here on C-RNTI 0x8000, which tells them apart only by the LCID on each subheader — so signaling and user data ride the same transport blocks.
Contention resolution is an identity echo, not an identifier change. Msg3 goes out anonymous on LCID 52; 0.708 ms later Msg4 replays the same six bytes back. The UE that recognizes them wins; every UE that sent a different Msg3 loses and starts again.
One transport block carries MAC's entire repertoire. Frame 4 holds a 108-byte signaling SDU, a Buffer Status Report, a Power Headroom Report, and 508 bytes of padding — four subheaders, four independent things, one transmission.
Direction decides both the ordering and the meaning. Uplink puts control elements after the SDUs and downlink before them, and both orders hold across all 144 frames without one exception. LCID 61 is a Short BSR going up and a Timing Advance Command coming down.
A BSR reports the leftovers, not the payload. 55 of the 66 reports here read zero, because the grant that carried the report also carried the data it would have described.
Padding measures the scheduler's uncertainty. The gNB sizes a downlink block against a buffer it owns and can read directly, and an uplink grant from a report describing the past. One side guesses, and that side wastes 30,955 bytes.
Worth being precise about why any of this is legible: ciphering is a PDCP function that begins below the PDCP header, so LCIDs, lengths, control elements, and padding are read without keys even though this capture is genuinely NEA2-ciphered. That applies to the MAC layer. The payloads above it are a separate question.
The full walkthrough follows every MAC-NR subheader and control element on one UE, from Msg3 to the last scheduled transmission, and closes on the mac-CellGroupConfig in frame 3 that turns out to explain the rest of the session.
Full walk-through: https://www.eventhelix.com/5G/nr-attach-air-interface/mac-nr-scheduling-and-multiplexing/
Top comments (0)