RLC-NR Acknowledged Mode in a Real 5G Capture

The RLC-NR layer of the 5G NR attach walkthrough, followed on its own. Two annotated diagrams caption every RLC-AM PDU on both of the connection's bearers — the signaling bearer and the data bearer — and this walk follows them from the first sequence number to the last acknowledgment.

💡 Read the walkthrough and the diagram side by side. This page carries two diagrams — one per bearer. The signaling bearer's is linked above and walked in Act One; the data bearer's is linked further down, where Act Two begins. Open whichever act you are reading in a split-screen window so the captions stay in view. On macOS, prefer Chrome or Firefox — Safari has no in-browser split screen.

Where RLC sits

RLC appears in both planes of the 5G radio stack, and this page walks one bearer in each.

Control plane — the signaling bearer

Under PDCP, itself under RRC, carrying the signaling that sets the connection up. This is the stack Act One walks on SRB 1.

User plane — the data bearer

The same position in the stack, but with SDAP above PDCP instead of RRC, and the traffic continuing past the gNB to the UPF. This is the stack Act Two walks, on DRB 1.

The SRB and DRB RLC entities differ only in sequence number space and timer configuration. Nothing in the capture configures the signaling bearer, so it takes a 12-bit sequence number and the TS 38.331 default t-PollRetransmit of 45 ms. Frame 38 configures the data bearer outright: an 18-bit sequence number in both directions, and an 80 ms t-PollRetransmit — signaled in the ul-AM-RLC block only, so it governs the UE's transmitting entity and nothing else. Both timers turn up on the wire later in this page.

What RLC does

RLC — Radio Link Control (TS 38.322) is the layer that makes the radio link look reliable to everything above it. It takes an SDU (Service Data Unit — one packet handed down from PDCP), gives it an SN (Sequence Number), cuts it into as many pieces as the scheduler's grant will hold, and refuses to consider it delivered until the peer says so.

RLC has three modes, and the mode is chosen per bearer when the bearer is created:

• TM (Transparent Mode) adds no header at all. It carries broadcast, paging, and the common control channel — traffic that has no peer entity to talk to yet.
• UM (Unacknowledged Mode) numbers and segments, but never retransmits. It suits traffic that would rather lose a packet than wait for it.
• AM (Acknowledged Mode) numbers, segments, retransmits, and reorders. Both bearers in this capture run AM, and every PDU on this page is an AM PDU.

The obvious question is why a layer above MAC needs its own retransmission scheme at all, given that MAC already runs HARQ (Hybrid Automatic Repeat reQuest) and retransmits failed transport blocks within a few slots. The answer is that the two loops solve different problems. HARQ is fast, physical-layer-adjacent, and per transport block; its feedback is a single bit, which can itself be misread, and it gives up after a small, fixed number of attempts. What survives that loop is a small but non-zero residual error rate — and a stream of transport blocks that may now be out of order. RLC-AM is the slower, per-SDU backstop that catches the residue: it tracks delivery by sequence number rather than by transmission, reassembles segments, restores order, and asks again for anything the peer never confirms. HARQ makes the link fast enough; RLC-AM makes it reliable enough.

One detail makes this walkthrough possible at all. The capture is genuinely ciphered — NEA2 (AES) on the access stratum — but RLC headers are never ciphered. Ciphering is a PDCP function, and it starts below the PDCP header, so the sequence number, the segmentation fields, and the poll bit stay in the clear on every frame. The peer's ARQ (Automatic Repeat reQuest) machinery has to work without keys, so RLC's own bookkeeping is readable even when the payload is not.

Four header fields carry the entire story, and they are worth learning before the walk:

And one control message: the STATUS PDU, carrying ACK_SN and E1. With no NACK block it is three bytes on the wire — for both sequence number widths, since ACK_SN and the reserved bits trade places to fill the same 24 bits — and every status report in this capture is that size. Each NACK block appended after E1 adds two bytes on a 12-bit bearer, three on an 18-bit one. ACK_SN is cumulative and reads as "the next SDU I am still waiting for" — so ACK_SN=6 means everything below 6 is safely in, not that SDU 6 arrived. E1 says whether a NACK block follows; a NACK (negative acknowledgment) is how a receiver names a specific sequence number it never got.

Both bearers lay those 24 bits out differently, and the two diagrams below are the whole reason a 12-bit and an 18-bit bearer produce the same three-byte PDU — the reserved field gives up exactly the six bits the wider ACK_SN needs.

Set E1 and a NACK block follows, one per missing SDU, each naming a sequence number the receiver never got. It is drawn here for completeness only — E1 is zero on every status report in this capture, so not one of these blocks appears on either bearer. The two optional tails are rarer still: SOstart and SOend pin the loss to a byte range inside a segmented SDU when E2 is set, and NACK range covers a run of consecutive missing SDUs in one block when E3 is set.

Put those pieces together and the whole protocol is one loop: the sender numbers each SDU, segments it to fit whatever grant it was given, and sets the poll bit when it wants an answer. The receiver replies with a single cumulative ACK_SN. Below is that loop as it actually ran on the data bearer, and Act Two walks it frame by frame.

One thing to keep in mind: there is not a single NACK anywhere in this capture, on either bearer. Every status report you are about to see is a pure cumulative acknowledgment. Whatever retransmissions happen here, nothing ever reported a loss.

Two bearers, two RLC entities

One UE. One radio connection and two completely independent RLC entities.

The trace carries an SRB (Signaling Radio Bearer) for control messages and a DRB (Data Radio Bearer) for user traffic, and both happen to be numbered 1. They are not two halves of one conversation. They are two separate state machines with separate sequence-number spaces, separate transmit windows, separate retransmission buffers, and separate timers:

That is why this page carries two diagrams instead of one timeline. A sequence number means nothing across the boundary. SRB 1's SN=5 and DRB 1's SN=5 are unrelated packets that happen to share a small integer, and no acknowledgment on one bearer ever says anything about the other.

There is a second, finer split inside each bearer. An AM bearer is really two transmitting entities — one per direction — each with its own counter, its own poll timer, and its own retransmission buffer. So the uplink SN=0 and the downlink SN=0 on the same bearer are also unrelated. Four independent counters open these two diagrams — and, as you will see at frame 133, a new connection mints two more.

Act One — SRB 1, the signaling bearer

52 messages, frames 4 to 146, 12-bit sequence numbers on LCID 1. This is the diagram linked at the top of the page. It teaches the mechanism, and it is the one where ARQ actually fires.

Frame 4 — the bearer opens. The first RLC PDU (Protocol Data Unit) of the capture, and the first sight of those header fields doing their job: SN=0, the first sequence number on this transmitting entity; SI = "all bytes of an RLC SDU", so nothing was split; and P set, demanding a status report back. The SDU is an RRCSetupComplete carrying an initial NAS Registration Request. The PDU is 108 bytes — a 2-byte AM header plus a 106-byte SDU.

Frame 5 — the first acknowledgment, 0.8 ms later. A 3-byte STATUS PDU with ACK_SN=1 and E1=0. Everything below 1 — that is, SN 0 — is in, and nothing is missing.

Frame 7 — the downlink has its own counter. The gNB now sends its SN=0, wrapping a NAS Authentication Request in a DLInformationTransfer. This is not a repeat of frame 4; it is the other direction's entity opening its own count.

Frame 8 — the latency asymmetry, fourteen times over. ACK_SN=1 confirms the downlink SN 0 of frame 7, but it takes 11.2 ms, whereas the gNB answered frame 4 in 0.8 ms. RLC is not the cause. The gNB schedules its own downlink instantly; the UE cannot transmit even three bytes until it has been granted uplink airtime. The pattern holds for the whole session: every downlink status lands within 0.8 ms, every uplink status takes 10 to 19 ms. It is the clearest single reminder that what you are watching is a scheduler as much as a protocol.

Frame 9 — why almost every PDU here polls. Uplink SN=1, poll set. Signaling is bursty and arrives one message at a time, so on this bearer nearly every data PDU is also the last thing in the transmit buffer — which is precisely the condition that makes RLC set the poll bit (TS 38.322 §5.3.3.2). Watch that same rule produce the opposite behavior on the data bearer in Act Two.

Frame 12 — two RLC PDUs, one radio transmission. A single MAC transport block carries both a 3-byte STATUS PDU (ACK_SN=2, clearing downlink SN 0 and 1) and an 85-byte data PDU (uplink SN=2, poll set, an 83-byte SDU). Piggybacking control onto a data grant is the normal case, not an optimization: RLC hands MAC whatever it has, and MAC packs the transport block. The diagram splits the two into separate arrows so each can be read on its own.

Frames 17–19 — security comes up, and RLC does not notice. Downlink SN=3 carries the RRC SecurityModeCommand; uplink SN=4 returns the SecurityModeComplete as an 8-byte SDU inside a 10-byte RLC PDU. From here, access-stratum ciphering is on, and the RLC headers keep reading exactly as before. Note the scale of signaling traffic while you are here: an 8-byte SDU riding a transport block with hundreds of bytes of padding.

The segmentation set piece — frames 20 to 24

Frame 20 is an RRC UECapabilityEnquiry. The answer is the largest signaling message on the bearer, and it is what forces the session's one segmentation run. By frame 21, the UE has a 1667-byte capability report to send and a grant nowhere near big enough.

Frame 21 — part 1 of 3. SI = first segment, and P is not set. Both facts come from the same pair of rules: RLC splits an SDU only because the grant is smaller than the SDU, and it polls only when the buffer is about to run dry. Here 1058, bytes are still queued, so no poll. The PDU is 611 bytes: a 2-byte header — a first segment carries no SO, because the offset is zero by definition — plus 609 bytes of payload.

Frame 22 — part 2 of 3. SI = neither first nor last, SO=609, exactly where frame 21 stopped. The header is now 4 bytes rather than 2, because a non-first segment must carry the 16-bit SO field, so 619 bytes on the wire means 615 bytes of payload, covering bytes 609 through 1223. Still no poll: more of the SDU remains.

Frame 23 — part 3 of 3, and the point of the exercise. SI = last segment, SO=1224, which is 609 + 615: the three segments tile the SDU with no gap and no overlap. Wireshark confirms the reassembly — 3 fragments, 1667 bytes, contributed as 609 + 615 + 443. Two things to take away:

• All three segments carry the same sequence number, SN=5. The number belongs to the SDU; segmentation is described entirely by SI and SO.
• The poll bit is set only here, on the last segment, because only now is the buffer empty.

Frame 24 — one acknowledgment for three transmissions. ACK_SN=6. SN 5 counts as delivered only because all three of its segments arrived, and the receiver reports it once, not three times. This is the payoff of the whole run: ARQ state is per SDU, so a 1667-byte message costs exactly one entry in the retransmission buffer and one line in the status report, however many pieces the scheduler forced it into.

Frame 38 — the hinge

Downlink SN=6 is an RRC Reconfiguration, and decoded it adds DRB 1 on logical-channel ID 4, with its own RLC entity configured as:

• sn-FieldLength — size18, in both directions
• t-PollRetransmit — ms80 (uplink)
• pollPDU / pollByte — p32768 / kB750 (uplink)
• t-Reassembly — ms80 (downlink)
• t-StatusProhibit — ms30 (downlink)

A signaling message on one bearer, visibly creating the entity the other diagram is about. Act Two opens three frames later. (The RRC companion reads the rest of that message — it configures SDAP, PDCP and MAC in the same 235 bytes.)

It matters for a second reason, which the last section of this page is built on. Frame 38 is the only frame in the entire capture that signals any RLC configuration at all. SRB 1 is never configured explicitly, anywhere.

Frames 39–40 — the act's first close. Uplink SN=8 returns the RRCReconfigurationComplete, and ACK_SN=9 acknowledges uplink SN 0 through 8 — every SDU sent since frame 4, including the three-segment capability report — with no NACK ever raised. The retransmission buffer is empty.

Then a 10.3-second gap on this diagram. The connection is not idle: the data bearer that frame 38 just created is carrying traffic for the whole of it. The signaling bearer has nothing to say, and an AM entity with an empty buffer is completely silent — no keepalives, no periodic status, nothing. That silence is Act Two, and we will come back to it.

Frames 128 to 146 — the release, and ARQ firing twice

Frame 128 — the bearer speaks again to end the connection. SN=7 continues directly from the SN=6 of frame 38, ten seconds earlier. This is still the same transmitting entity, and it kept its full state across the silence. The SDU is an RRC Release, with the poll set as on every data PDU of this bearer. Nothing answers it.

Frame 129 — the first retransmission, and it is a timer, not a NACK. PDCP flags the arriving SDU as a repeat of PDCP SN 7 — the tell that RLC re-sent frame 128's PDU unchanged: same SN=7, same 8-byte payload, poll set again. The interval from frame 128 is 44.9 ms. t-PollRetransmit is the timer RLC starts when it sends a polling PDU; if no status arrives before it expires, the PDU goes back on the wire (TS 38.322 §5.3.3.4). For contrast, every answered poll on this bearer came back within 19.2 ms — comfortably inside the timer. The UE never does answer this one; it is already releasing the connection.

One reading note: frames 129 and 146 each appear as two arrows on the diagram but one PDU on the wire. The retransmission template and the generic data-PDU template both match the same transmission, so you see it twice — once labeled as a retransmission, once with its fields laid out.

Frame 133 — a second connection, the same C-RNTI, a brand-new entity. SN=0 on SRB 1 again. This reset is not a reconfiguration: the trace shows a new UE context (UEId 2) reusing C-RNTI 0x8000 — the Cell Radio Network Temporary Identifier, the short handle the cell uses to address one connected UE. An RLC entity is created and destroyed with its bearer, so its sequence numbers, transmit window, and retransmission buffer all start from nothing. Frame 134 acknowledges it 0.8 ms later, exactly as frame 5 did, and everything the first 130 frames taught applies unchanged to a bearer one frame old.

Frame 143 — the last clean acknowledgment. ACK_SN=3, E1=0. Every status report in the session has now been a pure cumulative ACK — 22 of them, not one NACK between them.

Frames 145–146 — the second retransmission closes the session, and confirms the first. Downlink SN=3 goes out with the poll set; the status that would clear it never arrives. PDCP flags a repeat of PDCP SN 3, and the interval from frame 145 is 44.9 ms — the same figure, to within 21 microseconds, as the gap between frames 128 and 129. Two independent firings of the same timer, on two different RRC connections, with no NACK anywhere in between. The session ends here, mid-ARQ, with one PDU still outstanding, its retransmission timer already reloaded, and nothing further arriving on this connection.

Act Two — DRB 1, the data bearer

Now rewind. While the signaling bearer sat silent through that 10.3-second gap, the entity frame 38 created was doing the actual work: 67 messages, frames 41 to 115, 18-bit sequence numbers on LCID 4. It has its own RLC with a sequence-number space starting from zero.

Frame 41 — a counter that did not exist a moment ago. SN=0, and the sequence-number field is 18 bits wide — the packet trace confirms bearer type DRB, bearer id 1, sequence-number length 18. SI = all bytes, P set. Frame 38's sn-FieldLength size18 is the named cause, three frames back, on the other diagram.

The wider counter is not decoration. Eighteen bits gives a 262144-value sequence space against 4096 for the 12-bit form used on signaling bearers — what a high-throughput bearer needs so its transmit window never wraps around data that is still unacknowledged.

Frames 42–44 — the same two beats as Act One. ACK_SN=1 comes back in 0.8 ms, three bytes, E1=0; and note that ACK_SN is itself 18 bits wide here, because a STATUS PDU's format follows the entity's configured sequence-number length. The gNB's own SN=0 follows on frame 43, and the uplink status confirming it takes 14.2 ms — eighteen times slower, for the same grant-scheduling reason as frame 8. Every uplink status on this bearer costs 11 to 20 ms.

Burst discipline — frames 50 to 55

This is where the data bearer stops looking like the signaling bearer.

Frame 50 packs three RLC PDUs into one radio transmission. The status comes out first (ACK_SN=2), then uplink SN=2 — a complete 64-byte SDU with P not set, the first data PDU on this bearer without a poll — then uplink SN=3, SI = first segment, 539 bytes of a 1264-byte SDU, still no poll.

With pollPDU at p32768 and pollByte at kB750, the counter-based poll triggers will effectively never fire in a trace this size, so a poll happens only when the transmit buffer is about to run dry. On the signaling bearer, that condition was true almost every time; here it is true only at the end of a burst.

Frames 51–52 finish SN=3. SO=539, then SO=1153; the header is 5 bytes on a non-first segment here — 3 for the 18-bit sequence-number fields plus 2 for SO — so 619 bytes on the wire mean 614 of payload. Wireshark reassembles 3 fragments totaling 1264 bytes as 539 + 614 + 111. Immediately behind it, in the same transport block, uplink SN=4 starts with 498 bytes of a 514-byte SDU: two different SDUs mid-flight in one frame, told apart only by their sequence numbers.

Frame 53 — the poll finally goes up. SN=4 completes with SO=498 and 16 bytes of payload, a 2-fragment 514-byte reassembly, and now the buffer is empty.

Frame 55 — one status for five SDUs. ACK_SN=5 acknowledges uplink SN 0 through 4 in a single 3-byte control PDU, 2.8 ms after the poll — including SN 3 and SN 4, which between them cost five separate transmissions across frames 50 to 53. Hold the poll until the buffer drains, and one status closes the entire burst.

Frames 68–70 — two polls, one answer. Downlink SN=4 and SN=5 go out a millisecond apart, both polling, and the UE cannot reply to either until it is granted uplink airtime. ACK_SN=6 on frame 70 then covers downlink SN 0 through 5, satisfying both polls at once. A STATUS PDU always describes the receiver's complete state up to ACK_SN, so a backlog of polls never means a backlog of statuses — which is exactly why RLC's control overhead stays flat as throughput rises. Remember this frame; it is why the bearer's poll count and its status count differ.

Frames 78 to 84 — frames 50 to 53 run again, and one status to close it. Six transmissions carry three SDUs: SN=10 whole (88 bytes), SN=11 in three fragments of a 1288-byte SDU (515 + 614 + 159), SN=12 in two fragments of a 988-byte SDU (450 + 538). It is the same three-PDU shape frame 50 opened with, produced by the same rule — fill the grant, split whatever does not fit, poll only at the end. Exactly one of the six asks for a report, and it is the last — the poll rides frame 81, the closing segment of SN=12. Frame 84 answers with ACK_SN=13, 2.8 ms later: thirteen SDUs acknowledged in three bytes.

Segmentation is a property of the grant — frames 90 and 109

Put these two frames side by side, and the rule stops being abstract.

Frame 90 is downlink SN=8 with SI = "all bytes": a 1226-byte PDU carrying a 1223-byte SDU whole, because the grant was large enough to take it.

Frame 109 is downlink SN=11 with SI = first segment: a 1499-byte SDU meets a grant with room for a 1438-byte RLC PDU, so 1435 bytes go now, and 64 bytes wait for frame 110. The second SDU is 276 bytes larger than the first. That is the entire difference between the two cases — not the data, not the bearer, not the direction. Just how much room the scheduler happened to offer.

Frames 109 to 112 also show the gNB segmenting, which the uplink runs had not yet proved. SN=11 completes at SO=1435 with its remaining 64 bytes; SN=12 starts in the same transport block with 1364 bytes of another 1499-byte SDU and completes at SO=1364 with 135; SN=13 follows whole, and carries the poll. Frame 112's ACK_SN=14 closes downlink SN 0 through 13 in one status. Same discipline, same fields, opposite direction — both ends run identical AM logic against whatever their own scheduler offers.

Every status report on this page has so far appeared as a number in prose. This is one of them as the dissector sees it:

Frame 112's field tree — a STATUS PDU rather than a data one. D/C marks it a control PDU, CPT selects STATUS, and ACK_SN=14 is the cumulative acknowledgment covering downlink SN 0 through 13. Below it, Wireshark spells out what E1=0 means: a set of NACK_SN, E1, E2 and E3 does not follow. That absence is the argument of this whole page.

Frames 113–115 — the bearer's closing acknowledgment. The last segmentation run splits a 984-byte SDU as 613 + 371, with the poll on the final piece, and frame 115 answers 0.8 ms later: ACK_SN=18, E1=0. Uplink SN 0 through 17 — every SDU the UE sent on this bearer since frame 41, including six multi-segment SDUs — confirmed delivered, and not one of them ever had to be reported missing.

The headline numbers for DRB 1: 18 uplink SDUs across 27 data PDUs, 14 downlink SDUs, 25 polls answered by 24 status reports, zero NACKs — and zero retransmissions. The polls outnumber the statuses for the reason frame 70 showed: one status report can answer several outstanding polls at once.

Acknowledged Mode did its job so quietly here that the only evidence it was working is the absence of gaps. To see it actually intervene, you have to go back to the signaling bearer — which is the subject of the next section.

Why SRB 1 retransmits, and DRB 1 never does

Two bearers, one radio link, the same protocol and the same rules. One of them retransmitted twice; the other never retransmitted at all. The trace explains the difference completely.

Start with DRB 1, because it is the simple case: every poll it sent was answered, and nothing was ever re-sent.

Read the 80 ms in that table carefully before using it, though. Frame 38 signals t-PollRetransmit in the ul-AM-RLC block, so the value governs the UE's transmitting entity and nothing else. The dl-AM-RLC block carries only t-Reassembly and t-StatusProhibit — the gNB's own poll-retransmit timer is never signaled on this bearer, so the downlink polls on the DRB diagram are running a value the trace does not show.

That is exactly the caveat the bearer's slowest answer needs. It took 20.2 ms, and it belongs to a downlink poll — frame 55's, answered by the UE at frame 59 — so the 80 ms was never the timer it was racing. The uplink polls the 80 ms does govern close far sooner: frames 53 and 81 both get their status 2.8 ms later. Nothing timed out in either direction. The zero is not luck; it is measurable.

SRB 1 is the interesting one, because nothing in the capture configures it. Frame 38 is the only frame that signals any RLC configuration at all, and everything it configures belongs to DRB 1. SRB 1 therefore runs the default acknowledged-mode profile of TS 38.331 §9.2.1 — 12-bit sequence numbers, and a t-PollRetransmit of ms45.

That default is not written anywhere in the trace. But it is visible in it, twice:

• Frame 128 polls and gets no answer. Frame 129 re-sends the identical PDU 44.894 ms later.
• Frame 145 polls and gets no answer. Frame 146 re-sends the identical PDU 44.915 ms later.

Two firings of the same timer, on two different RRC connections, with no NACK anywhere in between — and they agree to within 21 microseconds. A spec default that is never transmitted, measured twice off the wire.

Two things this is not, both worth stating plainly because they are the usual misreadings:

• It is not NACK-driven ARQ. There is not one NACK_SN in the capture; E1 is zero on all 22 SRB status reports and on all 24 DRB ones. Nothing was ever reported missing.
• It is not a bad radio link. Both retransmissions were driven by silence, not by loss. Frame 128's poll went unanswered because the UE was already releasing the connection. Frame 145's met the same silence at the end of connection 2. Nothing followed it: the next frame on the air is a fresh random access 32 seconds later, opening a third connection. The link itself never dropped a single PDU on either bearer.

Which leaves the honest one-line answer to the section's question: SRB 1 retransmitted because two of its polls got no reply at all, and it gave up waiting after 45 ms because nobody had ever told it to wait longer. DRB 1 never retransmitted because every poll it sent came back — well inside the 80 ms that frame 38 gave the UE's uplink entity.

If you take one diagnostic habit from this page, take that one. When you see a duplicated sequence number on an AM bearer, the first question is not "what was lost?" — it is "was anything ever reported lost?" Check E1 and NACK_SN first. If they are clean, you are looking at a poll that went unanswered, and the interval between the two transmissions will tell you which t-PollRetransmit the bearer is running.

Takeaways

1. RLC counts SDUs, not transmissions. One sequence number covers every segment of one SDU, so a 1667-byte message split three ways costs one buffer entry and one line in the status report.
2. The poll bit follows the buffer, not the clock. RLC polls when its transmit buffer is about to drain. On bursty signaling, that means almost every PDU; on a loaded data bearer it means the last PDU of a burst — the same rule producing opposite-looking traces.
3. Cumulative acknowledgment is why AM scales. ACK_SN=13 closes thirteen SDUs in three bytes, and one status can answer several outstanding polls. Control overhead does not grow with throughput.
4. Segmentation is a property of the grant, not the data. A 1223-byte SDU went whole; a 1499-byte SDU on the same bearer, same direction, was cut in two. Only the scheduler's offer changed.
5. A duplicate sequence number is not automatically a loss. With no NACK anywhere in this capture, both retransmissions were timer-driven — and their 44.9 ms interval identifies the timer as the TS 38.331 default that nothing in the trace ever configured.

Where this sits in the stack

This page follows one layer of a much larger trace. The layers around it tell different parts of the same story:

• A 5G NR Attach on the Air Interface, Layer by Layer — the full walkthrough this article is a slice of: random access through to two mobile-terminated returns, all six layers on one timeline.
• PDCP-NR: sequence numbers, COUNT, and ciphering — the layer directly above. Every RLC SDU on this page is one PDCP PDU; PDCP is where the ciphering that keeps the payloads dark actually happens.
• MAC-NR: scheduling and multiplexing — the layer directly below, and the one that decides the grants. Every segmentation decision on this page was really a MAC decision.
• Decrypting a 5G NR radio capture — how the trace was opened up in the first place, and why RLC stays readable even when it is not.

Try it on your own capture

Every arrow in both diagrams was decoded and captioned by VisualEther from a raw Wireshark PCAP — including the session split that separated the two RLC entities onto their own timelines. Point it at your own 5G, LTE, or IMS trace and read it the same way.