RLC-LTE Acknowledged and Unacknowledged Mode in a Real VoLTE Capture

The RLC layer of the LTE attach and VoLTE walkthrough, followed on its own. One phone, UE 70, holds two radio bearers that matter here: DRB 2 carries its SIP signaling in RLC acknowledged mode, and DRB 3 carries its call-1 voice in RLC unacknowledged mode. Two annotated diagrams caption every RLC PDU of each, and this page reads them side by side.

💡 Read the walkthrough and the diagram side by side: this page has two diagrams, one per bearer. The SIP bearer's is linked above for Act One, the voice bearer's further down for Act Two. Open the one you are reading in a split-screen window, or open it in a new tab.

Where RLC sits

RLC (Radio Link Control, TS 36.322) sits between PDCP above and MAC below, and talks only to its peer RLC entity in the eNB. Both bearers on this page are user-plane bearers: the SIP messages and the voice packets are IP packets, carried to the IMS core beyond the gateway.

The capture is the same srsRAN eNB log as the main walkthrough, in its re-tagged form: srsRAN marks every frame with UE identity 0, which makes Wireshark merge both phones' RLC state and invent retransmissions. The copy used here sets each frame's identity to its C-RNTI and changes nothing else. Why the capture was re-tagged explains the fix. Every sequence-number claim below depends on it.

What RLC does

RLC takes an SDU (Service Data Unit: one packet handed down by PDCP) and fits it into whatever space MAC's scheduler offers in the next transmission. It can cut one SDU into pieces, pack several SDUs into one PDU (Protocol Data Unit), or both. It has three modes, chosen per bearer when the bearer is created:

• TM (Transparent Mode) adds no header. It carries broadcast, paging, and the first RRC messages.
• UM (Unacknowledged Mode) numbers, segments, concatenates, and reorders, but never retransmits. The receiver never reports back.
• AM (Acknowledged Mode) does everything UM does and retransmits whatever the peer doesn't confirm. The sender asks for a report with a poll bit; the receiver answers with a Status PDU.

MAC already retransmits failed transport blocks with HARQ (Hybrid Automatic Repeat reQuest) within a few milliseconds. AM adds a slower, per-PDU backstop for what HARQ misses. Whether that backstop helps depends on the traffic. SIP signaling must arrive intact, however late, so DRB 2 runs AM. A voice frame that arrives late is useless, so DRB 3 runs UM.

The headers

Both bearers use a 10-bit sequence number, and both headers are 2 bytes. The difference is what fills them.

Four fields carry most of the story:

ACK_SN in a Status PDU is cumulative and reads as "the next SN I am still waiting for". ACK_SN=25 means every PDU below 25 arrived, not that PDU 25 did.

One difference from 5G is worth fixing before the walk. In 5G NR, RLC numbers SDUs, so every segment of one SDU carries the same SN (see the RLC-NR page). In LTE, RLC numbers PDUs. A split SDU spreads across PDUs with consecutive SNs, and FI says how the pieces join.

Two bearers, two entities

UE 70's DRB 2 and DRB 3 are separate RLC entities with separate sequence-number spaces. Within each bearer, the uplink and downlink are separate transmitting entities with their own counters too. RRC configured both bearers in the capture:

A different AM configuration in frame 24 (t-PollRetransmit 120 ms, pollPDU 64, pollByte 750 kB, maxRetxThreshold 16, t-StatusProhibit 50 ms) belongs to DRB 1, the internet bearer, which this page doesn't follow.

The RRC message only configures the UE's side. The eNB's own transmitter timers on DRB 2 are never sent over the air, which matters in Act One.

Act One — DRB 2, acknowledged mode

DRB 2 carries 452 RLC messages over the whole capture, so its diagram keeps four windows, with the original frame numbers: the IMS registration (frames 36–68), call 1 (frames 814–1164), the one retransmission (frames 2919–2953), and an out-of-order pair (frames 3020–3036).

The first PDUs

Frame 36 — the bearer opens. Uplink SN=0: a 68-byte PDU carrying the TCP SYN that opens the UE's SIP connection to the P-CSCF on port 5060. FI is 00, so one whole SDU, and P is set. The eNB's Status PDU, ACK_SN=1, comes back 0.7 ms later in frame 37.

Frame 38 — the downlink starts its own count. The SYN-ACK goes down as downlink SN=0. It has nothing to do with frame 36's SN 0. The eNB polls here, and it polls on every one of its 128 data PDUs on this bearer. TS 36.322 (§5.2.2.1) sets the poll when a PDU empties the transmit buffer, after pollPDU PDUs or pollByte bytes without a poll, or when the transmit window stalls, and on a retransmission when t-PollRetransmit expires. The eNB polls even on SN=105 in frame 3020, which leaves part of an SDU still to send, so it either polls more eagerly than the UE or runs poll counters that aren't signaled. The UE polls on 103 of its 157 data PDUs.

Frame 39 — segmentation and concatenation in one PDU. Uplink SN=1 is 526 bytes with FI = 01: it starts with the start of an SDU and ends in the middle of one. A length indicator, LI=54, closes the first SDU, a 54-byte packet holding the handshake's final TCP ACK. The remaining 468 bytes begin a 1452-byte SDU, the first TCP segment of the SIP REGISTER. Frame 40's SN=2, FI = 10, carries the other 984 bytes, and Wireshark reassembles the SDU from SN 1 and SN 2.

Frames 50 and 55 — t-StatusProhibit at work. The UE sends a Status PDU in frame 50. The eNB polls again in frame 52, but the UE's answer, frame 55, comes 78 ms later. t-StatusProhibit stops the UE from sending another Status PDU for 60 ms after the last, and the UE then has to wait for an uplink grant: frames 50 and 55 are 80 ms apart. With one exception, covered below, UE Status PDUs arrive 14 to 78 ms after the data they acknowledge; the eNB's arrive as little as 0.03 ms after. The UE has to ask for uplink time before it can send even 2 bytes, while the eNB schedules its own downlink.

Frames 56–68 — the protected REGISTER. The unprotected TCP connection closes, and a new one opens inside IPsec ESP to the P-CSCF's protected port 6100. RLC doesn't notice: an ESP packet is just another SDU. The second REGISTER goes up as four PDUs, SN 8 to 11, and ACK_SN=12 in frame 66 confirms all of uplink SN 0 to 11 without a single NACK. The 200 OK comes down whole in one 1144-byte PDU.

The INVITE in four PDUs

Twenty-one seconds later UE 70 dials. The same entity continues its count: the SYN for the INVITE's TCP connection goes up as SN=20 in frame 814. The INVITE itself is 2187 bytes of TCP in two segments, two SDUs of 1322 and 1018 bytes. The uplink grants are smaller than either, so RLC spreads them across four PDUs:

SN=22 sets the poll bit in the middle of the INVITE. Of the four triggers, only "this PDU empties the buffer" can fire there (pollPDU 128 and pollByte 125 kB are far off), so the INVITE's second TCP segment had most likely not reached RLC yet. The four PDUs leave the UE over 17 ms.

Frames 847 to 852 show the third FI value. The PRACK goes up as three PDUs, and the middle one, SN=27 in frame 851, has FI = 11: it begins mid-SDU and ends mid-SDU. Its first 995 bytes finish one SDU, and LI=995 marks where the next one starts.

The downlink packs instead of splitting

Frame 845 — the 183 in one PDU. Downlink SN=22 is 2164 bytes, FI = 00, and holds the whole 183 Session Progress: both TCP segments as two SDUs of 1322 and 838 bytes, divided by LI=1322. The 180 Ringing (frame 891), the 200 OK to the UPDATE (frame 892), and the 200 OK to the INVITE (frame 976) arrive the same way. Across the capture, 54 uplink PDUs end partway through an SDU, against 5 downlink. Segmentation depends on the grant, not on the protocol.

Frame 991 — then silence. ACK_SN=30 rides in the same transport block as a voice packet on DRB 3. For the next 4.5 seconds voice flows on DRB 3, and DRB 2 sends nothing at all: an AM entity with an empty buffer is silent.

Frame 1152 — a voice packet on the AM bearer. After the BYE, the eNB releases DRB 3 in frame 1146. About 40 ms later UE 70 sends its next comfort-noise packet, RTP sequence 36, on schedule 160 ms after the last one. With the voice bearer's packet filters gone, the packet falls through to the IMS PDN's default bearer: it rides inside DRB 2's SN=34, ahead of the UE's 200 OK to the BYE.

The one retransmission

Wireshark flags one retransmission on this bearer: "AM SN Repeated", downlink SN 102, in frame 2940, at the end of call 5. It is real in the sense that the eNB really sent SN 102 twice. It was also unnecessary, and the radio timing shows why.

Four facts settle it:

• No NACK caused it. Not one Status PDU anywhere in the capture carries a NACK. The resend has to be timer-driven.
• The timer is 80 ms. The original went out in SFN 141 subframe 0 and the copy in SFN 149 subframe 0, exactly 80 subframes later. Frame 32 gives the UE's transmitter t-PollRetransmit 80 ms. The eNB's own value isn't signaled, but the interval fits the same 80 ms.
• The copy is byte-identical. Same RLC SN, same PDCP SN 126, same ESP sequence 78, same bare TCP ACK. Wireshark's ESP "repeated sequence" and TCP "duplicate ACK" warnings in frame 2940 follow from seeing one packet twice.
• The UE already had the first copy. Its Status PDU ACK_SN=103 went up in SFN 148 subframe 8, two subframes before the retransmission went down. The capture lists frame 2940 first, but the radio frame numbers give the order on the air. Every other uplink Status PDU on this bearer arrives at least 14 ms after the data it acknowledges; this one is logged 2 ms after the retransmission.

Frame 2927 could not include SN 102: SN 102 reached the UE only 3 subframes earlier, and an LTE FDD uplink transmission is built from a grant 4 subframes ahead. Frame 2927 did start the UE's 60 ms t-StatusProhibit. From then on the UE had SN 102 and a poll to answer, but wasn't allowed to answer until the timer ran out, and then had to wait for a grant. Its report and the eNB's poll timer crossed on the air: the report went up 2 subframes before the copy came down. The UE discards the duplicate (TS 36.322 §5.1.3.2.2).

So Wireshark's own wording, "probably because didn't receive Status PDU?", is right: the eNB resent because no Status PDU had arrived in time, not because anything was lost. When a UE's t-StatusProhibit plus its uplink scheduling delay comes close to the eNB's t-PollRetransmit, expect occasional resends like this one.

SN 131 before SN 130

The last window shows two Wireshark flags that look like a loss and aren't. During call 6, UE 70 sends two SDUs as four PDUs. Wireshark logs SN=131 (frame 3027, SFN 811 subframe 8) before SN=130 (frame 3028, SFN 812 subframe 5). It flags SN 130 as missing at frame 3027, then calls frame 3028 "retransmitted, most likely in response to NACK".

Neither flag holds up. SN 130 appears once in the capture, and no NACK exists anywhere. The likely cause is HARQ below RLC. In LTE FDD an uplink HARQ retransmission comes 8 subframes after the first attempt, which would put a failed first try of SN 130 in SFN 811 subframe 7, one subframe before SN 131 went up. The eNB's RLC receiver holds SN 131 until SN 130 arrives, which is what its reordering window and t-Reordering timer exist for. Its Status PDU in frame 3036, ACK_SN=133, has no NACK. Wireshark's reassembly doesn't reorder, so it never rebuilds these two SDUs, and the SIP message they carry stays undecoded. It is almost certainly UE 70's 183 Session Progress: the 183 reaches UE 71 in frame 3039, and UE 70 receives a PRACK for it in frame 3046.

Over the whole capture, DRB 2 carried 157 uplink and 128 downlink data PDUs and 166 Status PDUs. No Status PDU carried a NACK, and the eNB sent one PDU twice.

Act Two — DRB 3, unacknowledged mode

Call 1's voice bearer exists from frame 846 to frame 1146. Its RLC session is 71 PDUs, frames 985 to 1140, and its diagram shows all of them.

Frame 985 — the first voice PDU. Uplink SN=0, 77 bytes: the 2-byte UM header, a 2-byte PDCP header, and a 73-byte IP packet with RTP sequence 1 from UE 70 (192.168.101.2) to the media relay (172.22.0.16). FI is 00, one whole SDU. The header has no poll bit to set, and nothing answers.

Frame 1003 — the downlink's own SN 0. The relay's stream from UE 71 starts at downlink SN=0. UE 71 encodes at AMR-WB frame type 8 (23.85 kbit/s) and UE 70 at frame type 2 (12.65 kbit/s), so downlink speech PDUs are 105 bytes against the uplink's 77.

What never appears. All 71 PDUs on this bearer are data PDUs. There is no Status PDU, no ACK_SN, and no poll bit in either direction, and no PDU is ever sent twice. Compare frame 991: the same transport block carries uplink voice SN=2 on DRB 3 and a Status PDU for DRB 2. Two entities share one MAC PDU and follow different rules.

Speech, then silence

The uplink sends seven speech packets 20 ms apart, as the SDP's ptime:20 asked. Then UE 70 stops talking, and AMR-WB silence suppression (TS 26.193) takes over:

AMR-WB marks a silence descriptor (SID) frame with frame type 9 and tells the two kinds apart with its STI bit: 0 for SID_FIRST, 1 for SID_UPDATE. Each update carries comfort-noise parameters so the far end can play matching background noise. The packets shrink from 53 bytes of UDP to 27, and the PDUs from 77 bytes to 51. The downlink follows the same pattern from frame 1021: SID_FIRST, then a SID_UPDATE 59 ms later, then one every 160 ms.

Frames 1119 and 1121 — two packets in one UM PDU. UE 71 speaks again briefly. Downlink SN=29 carries a speech packet with the RTP marker bit set, the start of a talk spurt. Downlink SN=30, 156 bytes, carries two SDUs: RTP 30 (speech, 103 bytes with its PDCP header) and RTP 31 (SID_FIRST, 49 bytes), divided by LI=103. RTP 31 was already waiting at the eNB when it built the PDU, so RLC packed both. From here the downlink RLC SN runs one behind the RTP and PDCP sequence numbers, a reminder that RLC numbers PDUs.

Frame 1140 — the end. Uplink SN=34, RTP 35. In 4.4 s the bearer carried 35 uplink and 36 downlink PDUs, 16 of them carrying speech. In frame 1146 the eNB releases DRB 3 and the entity disappears with no closing exchange: UM keeps no state the peer needs to confirm.

What the sequence number is for in UM

UM keeps the sequence number so the receiver can put PDUs back in order, drop duplicates, and spot gaps. The UE's downlink receiver uses a 512-SN reordering window (half the 10-bit space). When an SN is missing, it waits up to t-Reordering, 50 ms here, for the PDU to arrive late, perhaps after a HARQ retransmission. When the timer runs out it gives up on the missing PDU and passes on what it has. It never asks for the PDU again. In this call no SN is skipped in either direction, so the timer never expires.

Two other settings point the same way. PDCP's discardTimer drops any voice packet not sent within 100 ms, and each AMR-WB frame covers only 20 ms of audio. A packet recovered after an AM-style poll and retransmission, 80 ms or more later, would arrive too late to play. For voice, a short gap filled by the codec is better than a late packet.

AM and UM side by side

Takeaways

1. The mode follows the traffic. SIP must arrive intact, so its bearer acknowledges and retransmits. Voice must arrive on time, so its bearer does neither.
2. LTE RLC numbers PDUs. One SDU can span several sequence numbers, and one PDU can hold several SDUs. FI and the length indicators describe the joins.
3. Segmentation depends on the grant. The UE cut the INVITE into four PDUs; the eNB sent the 183 in one.
4. A duplicate SN isn't automatically a loss. The one retransmission came from t-PollRetransmit expiring while the UE's Status PDU, held back by t-StatusProhibit, was already on its way. Check for a NACK first; here there was none.
5. Wireshark's RLC flags assume in-order logging. HARQ can reorder PDUs below RLC, and the flags "missing" and "retransmitted in response to NACK" then describe the log, not the link.

Where this sits in the stack

• An LTE Attach and a VoLTE Call on the Air Interface: the full walkthrough this page is a slice of, with every layer on one timeline.
• S1AP: Attach, E-RABs, and Six VoLTE Calls: the core network's side, including the E-RAB setup and release behind each voice bearer.
• RLC-NR Acknowledged Mode: the same layer in 5G, where sequence numbers count SDUs and segments carry an offset.