RLC Protocol in 5G NR
- Venkateshu Kamarthi
- 20 minutes ago
- 14 min read
1. Introduction: Why RLC Still Matters in 5G NR
When discussions around 5G performance arise, attention usually gravitates toward massive MIMO, beamforming, or spectrum efficiency. Yet, in real networks, user experience often degrades due to issues far removed from PHY or antennas. One of the most common root causes lies in the Radio Link Control (RLC) layer.
In 5G NR, RLC sits between PDCP and MAC, just like LTE. But assuming it is “unchanged from LTE” is a mistake. While the core concepts remain stable, the way RLC is used has evolved to support:
Extremely low latency (URLLC) - High throughput (eMBB)
Efficient signaling for massive IoT (mMTC)
Tight interaction with HARQ and scheduler decisions
RLC is neither glamorous nor optional. It is the layer that ultimately decides whether packets are delivered in sequence, delayed, retransmitted, or silently discarded.
In 5G NR, RLC continues to act as the last protocol layer that still understands packet boundaries, while simultaneously adapting to the extremely dynamic behavior of the MAC and PHY layers.
When engineers talk about 5G performance, discussions usually gravitate toward massive MIMO, beamforming, or ultra‑low latency. Hidden beneath those headlines is the Radio Link Control (RLC) layer – quiet, deterministic, and critical. If MAC is the traffic police and PDCP is the packet butler, RLC is the reliability engineer of the radio stack.
Position of RLC in the 5G NR Protocol Stack
In the 5G NR user-plane protocol stack, RLC is positioned between PDCP and MAC. This placement is deliberate: RLC shields higher layers from radio volatility while exposing lower layers to packet-sized data units.
PDCP is policy-aware (QoS, security)
MAC is time-aware (slots, HARQ, scheduling)
RLC is reliability-aware
Any inefficiency at RLC propagates directly into throughput collapse, latency spikes, and jitter — even when radio conditions appear healthy.
Key observation:
RLC is the last layer that still “understands packets.” Everything below RLC is transport‑oriented.
2. Core Responsibilities of RLC
The functional behavior of RLC in 5G NR is specified in 3GPP TS 38.322. While the protocol architecture resembles LTE, its usage patterns in 5G differ significantly due to higher data rates, shorter TTIs, and diverse service requirements.
This section walks through RLC responsibilities with direct references to the specification and practical implications observed in live networks.
Primary specification: 3GPP TS 38.322 – Radio Link Control (RLC) protocol specification
RLC performs four fundamental functions:
2.1 Segmentation and Reassembly
PDCP delivers SDUs of arbitrary length. MAC, however, operates in Transport Block (TB) sizes decided dynamically every TTI.
RLC bridges this mismatch by: - Segmenting large PDCP SDUs - Concatenating multiple small SDUs - Reassembling them at the receiver
RLC segmentation is MAC-size driven, not SDU-size driven. This is why changing MCS immediately alters RLC behavior.
Real-world insight: In poor radio conditions, you will see aggressive RLC segmentation because MAC keeps allocating smaller TB sizes.
2.2 Sequence Numbering
Every RLC PDU carries a Sequence Number (SN) used for reordering, loss detection, and retransmission.
UM mode: 6-bit or 12-bit SN
AM mode: 12-bit or 18-bit SN
SN length is configured by RRC and directly impacts reordering window size and memory usage.
SNs enable:
Reordering
Loss detection
ARQ retransmission
2.3 Reordering
Because HARQ and scheduling are asynchronous, PDUs may arrive out of order.
RLC maintains a reordering window and a reordering timer (t-Reordering) to deliver data in sequence to PDCP.
2.4 Error Correction via ARQ (in AM)
RLC Automatic Repeat reQuest (ARQ) ensures reliable delivery using:
Status reports
Retransmission of missing PDUs
The ARQ Flow:
2. PDU #3 - Lost packet (shown with red X and dashed line)
3. PDU #4 - Continues transmission
4. STATUS PDU (NACK) - Receiver detects missing PDU #3 and sends negative acknowledgment
5. PDU #3 (Retransmission) - Transmitter resends the lost packet (highlighted in purple)
6. STATUS PDU (ACK) - Receiver confirms all packets received successfully
Delivery Complete - In-order delivery to upper
This is where RLC sharply differs from HARQ.
HARQ vs ARQ – Clearing the Confusion
Aspect | HARQ | RLC ARQ |
Layer | MAC | RLC |
Timescale | ~1–8 ms | 10–100+ ms |
Feedback | ACK/NACK | STATUS PDU |
Retransmission | Soft combining | Packet-level |
Reliability | Probabilistic | Deterministic |
Key Insight
HARQ improves probability of correct decoding, while RLC ARQ guarantees logical correctness.
If HARQ fails repeatedly, RLC doesn’t care why – it simply retransmits based on STATUS feedback.
3. RLC Operational Modes in 5G NR
RLC supports three modes:
1. Transparent Mode (TM)
2. Unacknowledged Mode (UM)
3. Acknowledged Mode (AM)
Each exists for a very specific reason.
3.1 RLC Transparent Mode (TM)
TM is used when:
No segmentation
No retransmission
No sequence numbering
Where TM Is Used
In 5G NR: - Broadcast channels (e.g., MIB) - Paging
The data is passed straight through.
TM is rare in UE logs because it is mostly invisible to higher layers.
3.2 RLC Unacknowledged Mode (UM)
UM trades reliability for latency.
No retransmissions
Limited reordering
Faster delivery
Typical Use Cases
Scenario | Reason |
VoNR | Low latency more important than 100% reliability |
URLLC | Deadlines > completeness |
Some DRBs | Application can tolerate loss |
UM PDU Structure (Simplified)
| Header (SN) | Data |
SN size: 6 or 12 bits
No STATUS PDU
UE Log Example – RLC UM
[RLC][UL][UM] SN=245, PDU size=312 bytes[RLC][DL][UM] Reordering timer expired, delivering to PDCP
Interpretation:
Out-of-order packets were tolerated
Missing SNs were ignored
3.3. RLC Acknowledged Mode (AM)
Why AM Is the Backbone of 5G Data
AM provides:
Guaranteed in-order delivery
Loss recovery
Flow control
Used for:
Most data radio bearers (DRBs)
Control-heavy user traffic
AM PDU Types
RLC AM defines two PDU categories:
a) Data PDU
Carries segmented or full SDUs
b) Control PDU (STATUS)
Carries ACK/NACK information
STATUS PDU Explained
A STATUS PDU is a control PDU sent by the receiver to report reception status.
It includes:
ACK_SN: highest SN received in sequence
NACK_SN list: explicitly missing PDUs
STATUS PDU:ACK_SN = 1205NACK_SN = {1208, 1210–1212}
AM uses selective repeat ARQ, not go-back-N. Only missing PDUs are retransmitted.
This minimizes unnecessary retransmissions and improves throughput on good radio links.
This tells the transmitter exactly what to retransmit.
UE Log Example – AM Retransmission
[RLC][DL][AM] STATUS received: ACK_SN=340[RLC][DL][AM] Retransmitting SN=342[RLC][DL][AM] Retransmitting SN=343
Key takeaway:
RLC retransmission is explicit and selective, unlike HARQ.
At a high level:
Control information must never be lost → AMBroadcast information must be simple → TMUser data balances latency vs reliability → UM or AM
1. SRB/DRB mapping to RLC modes
SRB0 → RLC Transparent Mode (TM)
What SRB0 Carries
Broadcast control information:
MIB
SIB1 (via BCCH)
Paging-related signaling
SRB1 and SRB2 → RLC Acknowledged Mode (AM)
What SRB1 / SRB2 Carry
RRC Connection Setup
Security Mode Command
RRC Reconfiguration
Measurement Control
Mobility commands
Why AM Is Mandatory for SRBs
RLC AM provides:
Guaranteed delivery
In-order sequencing
Explicit retransmission
Flow control
These properties are non-negotiable for signaling.
A single lost RRC message can desynchronize UE and gNB state completely.
Practical Example: RRC Reconfiguration
[RLC][DL][AM] TX SN=45 (RRC Reconfiguration)
[RLC][DL][AM] Poll=1
If UE misses it:
[RLC][UL][AM] STATUS: NACK_SN=45
Why UM Is Never Used for SRBs
UM allows:
Packet loss
No retransmission
This is unacceptable for:
Security setup
Bearer configuration
Mobility
DRBs Using RLC AM (Reliability-Oriented DRBs)
Typical Traffic
TCP-based applications
File downloads
Web browsing
Speed tests
Why AM Is Chosen
Applications like TCP already assume:
In-order delivery
Reliable transport
RLC AM:
Hides radio loss from TCP
Prevents TCP congestion window collapse
Stabilizes throughput
DRBs Using RLC UM (Latency-Oriented DRBs)
Typical Traffic
VoNR
Real-time video
URLLC user-plane traffic
Why UM Is Chosen
UM provides:
Bounded latency
Limited reordering
No retransmission delays
For these services:
Late packets are useless
Some loss is acceptable
Timing consistency matters more than completeness
Practical Example: VoNR
[RLC][DL][UM] RX SN=300
[RLC][DL][UM] RX SN=302
(t-Reordering expires)
SN=301 is dropped.
✔ Audio continues
✔ No retransmission delay
✔ Stable jitter
Bearer | RLC Mode | Why |
SRB0 | TM | Broadcast, repetition-based reliability |
SRB1 | AM | State-critical signaling |
SRB2 | AM | Security & mobility control |
DRB (TCP / eMBB) | AM | Reliability, in-order delivery |
DRB (VoNR / URLLC) | UM | Bounded latency, loss tolerance |
5. RLC Timers
Key Timers
1. t-Reordering defines how long the receiver waits for a missing PDU before assuming it is lost and taking action.
Used in:
RLC AM
RLC UM
Example:
Receive SN=101
Receive SN=103
(wait for SN=102)
If SN=102 arrives before t-Reordering expires → OK
If timer expires → treat SN=102 as lost
Typical Field Values
Use Case | Typical t-Reordering |
eMBB / TCP | 20–40 ms |
High mobility | 30–50 ms |
VoNR (UM) | 5–15 ms |
URLLC | Very small (or avoided via UM) |
2. t-StatusProhibit limits how frequently a receiver is allowed to send STATUS PDUs.
Applies to:
RLC AM only
After sending a STATUS PDU:
Receiver must wait for t-StatusProhibit to expire
Even if more gaps are detected
Typical Field Values
Scenario | Typical Value |
High throughput DRB | 20–50 ms |
Control-heavy bearers | 10–20 ms |
Congested UL | Larger values preferred |
3.t-PollRetransmit defines how long the sender waits for a STATUS after polling before re-polling.
Applies to:
RLC AM sender
How it works
Sender sets Poll bit
Waits for STATUS
If timer expires → poll again
Typical Field Values
Use Case | Typical Value |
eMBB | 40–80 ms |
Moderate load | 60–100 ms |
High UL contention | Larger values |
Summary
Timer | Purpose |
t-Reordering | Wait for missing PDUs |
t-StatusProhibit | Avoid STATUS flooding |
t-PollRetransmit | Trigger retransmission |
Polling Mechanism in RLC AM
Polling asks the receiver to send a STATUS PDU.
Without polling, RLC AM would face two extremes:
STATUS on every packet → massive uplink overhead
STATUS only on loss → slow recovery and window stalling
RLC AM defines two independent triggers for polling:
1. Poll bit set in a Data PDU -> The Poll bit is a single bit in an RLC AM data PDU header.
2. PollRetransmit timer expiry -> It expires when:A poll was sent, But no STATUS was received within expected time
When it expires, the sender forces polling again.
Polling is triggered when:
Poll bit set in data PDU
Poll timer expires
This avoids excessive control overhead.
6. Differences Between LTE and 5G NR in the RLC Layer
At first glance, the RLC layer in 5G NR looks deceptively similar to LTE.The same three modes exist (TM, UM, AM), ARQ is still selective-repeat, and segmentation/reassembly remains the core function.
LTE Assumptions
1 ms fixed TTI
Limited bandwidth
Mostly single service per UE
Relatively stable scheduling
Few parallel HARQ processes
5G Reality
Variable slot lengths
Massive bandwidths
Multiple services per UE (VoNR + eMBB + URLLC)
Highly dynamic scheduling
Many parallel HARQ processes
Extreme throughput + extreme latency targets
LTE vs 5G NR RLC Summary
Aspect | LTE RLC | 5G NR RLC |
Core modes | TM / UM / AM | TM / UM / AM |
QoS integration | EPS bearer based | SDAP + multi-DRB |
UM usage | Limited (mainly voice) | Extensive (VoNR, URLLC) |
AM usage | Default choice | Selective, QoS-driven |
Segmentation pressure | Moderate | High |
Reordering complexity | Low | High |
Timer sensitivity | Low | Very high |
Polling role | Loss recovery | State alignment |
HARQ interaction | Sequential | Highly parallel |
HOL blocking risk | Moderate | High if misdesigned |
Configuration impact | Performance | Service viability |
7. RLC and QoS Interaction
Although SDAP handles QoS flows, RLC still impacts QoS via:
Buffering
Retransmission delay
Head-of-line blocking
While RLC does not interpret 5QI values directly, it implements the mechanical rules that determine whether QoS objectives such as latency, throughput stability, and packet loss tolerance are actually met.
Example: One stuck AM bearer can delay PDCP delivery even if MAC resources are available.
Buffering
In an AM bearer:
PDCP sends variable-size SDUs
MAC scheduling fluctuates per TTI
RLC absorbs this volatility and delivers:
In-sequence SDUs
Smooth PDCP throughput
This stabilization effect is why TCP performs dramatically better over AM than UM.
Retransmission Behavior as Reliability Enforcement
Retransmissions at RLC are policy-aligned, not reactive.
Selective ARQ = QoS Efficiency
Only missing PDUs are retransmitted
No blind repetition
Window-based recovery
This ensures:
Minimal overhead for reliable flows
Predictable recovery behavior
In-Order Delivery – Guaranteeing Application Semantics
Many applications assume:
Ordered delivery
No duplication
Complete data streams
RLC AM enforces this strictly.
Even if MAC delivers PDUs out of order:
RLC resequences
PDCP sees a clean stream
QoS policies that depend on application-layer assumptions (e.g., TCP congestion control) require this RLC behavior.
8. Practical Debugging
When throughput drops:
1. Check HARQ BLER
2. Check RLC retransmission rate
3. Inspect STATUS PDU frequency
4. Verify t-Reordering values
This checklist assumes:
UE is RRC Connected
Data radio bearer established
Throughput degradation observed (DL or UL)
Step 1: Check HARQ BLER (MAC Layer Sanity Check)
Why This Comes First
HARQ is the first reliability gate.If HARQ is unstable, everything above it (RLC, PDCP, TCP) will misbehave.
RLC retransmissions are meaningless unless HARQ health is understood.
What “Good” Looks Like
Link | Target BLER |
DL HARQ | ~10% |
UL HARQ | ~5–10% |
BLER ≠ bad radio. BLER ≈ scheduler + MCS tuning quality.
UE Log Example – Healthy HARQ
[MAC][DL] HARQ PID=3 ACK
[MAC][DL] HARQ PID=5 ACK
[MAC][DL] DL BLER = 8.4%
✔ HARQ feedback mostly ACK
✔ Retransmissions limited to 1–2 attempts
UE Log Example – HARQ Problem
[MAC][DL] HARQ PID=2 NACK
[MAC][DL] HARQ PID=2 NACK
[MAC][DL] HARQ PID=2 FAIL
[MAC][DL] DL BLER = 28%
HARQ failures escalate to RLC, RLC will now see logical loss
Real-Time Actions
If BLER is high (>20–25%)
Reduce MCS aggressiveness
Check:
CQI reporting delay
PMI / RI mismatch
Verify scheduler fairness (cell edge starvation)
Do not tune RLC yet — RLC is reacting, not causing.
Step 2: Check RLC Retransmission Rate
HARQ fixes bit errorsRLC fixes packet loss
Excessive RLC retransmissions = scheduler inefficiency or timer mismatch, not poor radio.
UE Log Example – Healthy RLC AM
[RLC][DL][AM] RX SN=1204
[RLC][DL][AM] RX SN=1205
[RLC][DL][AM] STATUS sent: ACK_SN=1206
✔ Minimal STATUS PDUs
✔ No retransmission loops
UE Log Example – RLC Retransmission Loop
[RLC][DL][AM] Missing SN=1207
[RLC][DL][AM] STATUS sent: NACK_SN=1207
[RLC][DL][AM] RX SN=1207 (Retransmission)
[RLC][DL][AM] PollRetransmit timer expired
Same SN retransmitted multiple times
RLC throughput collapses even with good SINR
What to Correlate
RLC retransmission count vs HARQ failures
Scheduler grant gaps
UE buffer occupancy
Real-Time Actions
Symptom | Action |
RLC retransmissions high, HARQ OK | Scheduler starvation |
Repeated retransmission of same SN | t-Reordering too small |
RLC window stalls | Increase SN length (12 → 18 bit) |
Step 3: Inspect STATUS PDU Frequency (Control Plane Noise)
Why STATUS PDUs Matter
STATUS PDUs are control overhead. Too many STATUS PDUs = less room for data + UE processing overload.
STATUS PDUs should be occasional, not rhythmic.
UE Log Example – Normal STATUS Behavior
[RLC][UL][AM] STATUS sent
[RLC][UL][AM] STATUS sent (after poll)
✔ STATUS sent only when polled
✔ No periodic flooding
UE Log Example – STATUS Storm
[RLC][UL][AM] STATUS sent
[RLC][UL][AM] STATUS sent
[RLC][UL][AM] STATUS sent
[RLC][UL][AM] STATUS sent
STATUS every few ms
Uplink capacity wasted
gNB retransmits unnecessarily
Wireshark Confirmation
RLC Control PDU
STATUS
ACK_SN=650
Repeated with identical ACK_SN → useless control traffic
Root Causes
t-StatusProhibit too small
Poll bit set too aggressively
Short t-Reordering causing false loss detection
Real-Time Actions
1. Increase t-StatusProhibit
Example: 5 ms → 25 ms
2. Reduce polling frequency
Poll only:
Window edge
End of burst
After retransmissions
3. Ensure STATUS PDUs are selective, not full-window dumps
Step 4: Verify t-Reordering Values
Why t-Reordering Is Dangerous
t-Reordering decides when delay becomes loss.
Too small → false NACKsToo large → latency inflation
UE Log Example – Premature Reordering Expiry
[RLC][DL][AM] RX SN=880
[RLC][DL][AM] Waiting for SN=879
[RLC][DL][AM] t-Reordering expired
[RLC][DL][AM] STATUS sent: NACK_SN=879
But SN=879 arrives 2 ms later.
HARQ delay mistaken as loss
Unnecessary retransmission triggered
Rule of Thumb
t-Reordering ≥ (Max HARQ RTT) × (Max HARQ retransmissions) + Scheduler jitter
Typical values:
15–40 ms (eMBB)
Smaller for URLLC (with caution)
Real-Time Actions
Scenario | Recommendation |
Good SINR, delayed scheduling | Increase t-Reordering |
High-speed UE | Increase t-Reordering |
URLLC | Keep small, accept loss |
TCP throughput | Favor larger t-Reordering |
Putting It All Together – Debug Order
Skipping steps leads to wrong conclusions and bad fixes.
9. Common Field Issues
9.1 Excessive RLC Retransmissions Despite Good SINR
What Engineers Observe
SINR: 20–30 dB (excellent radio)
BLER (HARQ): within target
Yet:
RLC AM retransmissions keep increasing
Throughput fluctuates or collapses
TCP sessions stall intermittently
This is one of the most confusing field issues because radio KPIs look clean.
Typical UE / gNB Log Symptoms
UE log
[RLC][DL][AM] STATUS sent: ACK_SN=1240
[RLC][DL][AM] NACK_SN=1242, 1243
[RLC][DL][AM] Reordering timer expired
gNB log
[RLC][DL][AM] Retransmission triggered for SN=1242
[RLC][DL][AM] PollRetransmit timer expired
Wireshark
Repeated STATUS PDUs
Same SN retransmitted multiple times
Why This Happens (Root Causes)
Even with good SINR, RLC can fail logically due to:
Root Cause 1: MAC Scheduling Starvation
Scheduler prioritizes other bearers (e.g., URLLC, control)
RLC PDUs are delayed beyond t-Reordering
Receiver assumes loss → sends NACK
RLC interprets delay as loss
Root Cause 2: Over-segmentation of PDUs
High MCS fluctuations
PDCP SDU split into many RLC segments
Losing one segment blocks SDU reassembly
This creates head-of-line blocking at RLC.
Root Cause 3: Misaligned HARQ ↔ RLC Timing
HARQ retransmissions consume multiple TTIs
RLC timers expire before HARQ completes
Duplicate recovery mechanisms conflict
Real-Time Remediation Actions
Immediate Actions (During Trials / Optimization)
Increase t-Reordering slightly
Typical values: 5–15 ms → try 20–35 ms
Prevents premature NACKs
Ensure RLC retransmissions are prioritized
Scheduler should boost logical channels with pending RLC retransmissions
Especially for AM bearers
Reduce unnecessary segmentation
Stabilize MCS (avoid aggressive link adaptation)
Prefer fewer, larger PDUs
9.2 STATUS Storms Due to Wrong Timer Tuning
What Engineers Observe
STATUS PDUs flooding uplink
Control-plane utilization spikes
Downlink throughput collapses
UE power consumption increases
UE Log Symptoms
[RLC][UL][AM] STATUS sent
[RLC][UL][AM] STATUS sent
[RLC][UL][AM] STATUS sent
STATUS PDUs appear every few milliseconds.
Why This Happens
STATUS storms are almost always self-inflicted by configuration.
Root Cause 1: t-StatusProhibit Too Small
Receiver allowed to send STATUS too frequently
Every minor gap triggers STATUS
Root Cause 2: Aggressive Polling by gNB
Poll bit set on almost every PDU
Forces STATUS response even when unnecessary
Root Cause 3: Short t-Reordering
Out-of-order PDUs declared “lost” too early
STATUS triggered unnecessarily
Wireshark Confirmation
RLC Control PDU
STATUS
ACK_SN=540
Repeated within the same scheduling cycle.
Real-Time Remediation Actions
Immediate Fixes
Increase t-StatusProhibit
Example: 5 ms → 20–50 ms
Limits STATUS frequency
Reduce Poll Bit Frequency
Poll only:
At window edge
After large bursts
On retransmission boundaries
Tune t-Reordering
Ensure it is longer than typical HARQ RTT × max retransmissions
Best-Practice Configuration Guidance
Parameter | Anti-Pattern | Recommended |
t-StatusProhibit | Very small | Moderate, bearer-aware |
Polling | Every PDU | Conditional |
STATUS size | Many NACKs | Sparse selective NACKs |
9.3 UM Bearers Misused for TCP Traffic
What Engineers Observe
Very low latency
Very poor throughput
TCP retransmissions explode
Application blames “network instability”
Why This Happens
UM mode does not retransmit at RLC.
TCP, however:
Assumes in-order delivery
Treats loss as congestion
Drastically reduces congestion window
When TCP runs over UM:
One lost RLC PDU can stall the entire TCP flow
UE / Network Symptoms
UE log
[RLC][DL][UM] SN=234 missing
[RLC][DL][UM] Reordering timer expired
TCP trace
Duplicate ACKs
Congestion window collapse
Slow recovery
Real-World Example
VoNR bearer configured correctly as UM → works fine
Data DRB accidentally configured as UM
Speed test:
Ping: excellent
Throughput: <10 Mbps despite good SINR
Real-Time Remediation Actions
Immediate Fix
Move TCP traffic to RLC AM
Guaranteed in-order delivery
RLC ARQ hides radio loss from TCP
TCP congestion window remains stable
Architectural Best Practices
Traffic Type | RLC Mode |
TCP (HTTP, FTP, Speedtest) | AM |
VoNR | UM |
URLLC (tight deadlines) | UM |
Control / signaling | AM |
Advanced Optimization
Separate bearers for:
Latency-sensitive traffic
Throughput-sensitive traffic
Avoid multiplexing TCP and voice in same RLC instance
10. Wireshark Analysis: Decoding RLC PDUs
Protocol analysis is incomplete without correlating specifications to real packets. Wireshark, when equipped with NR dissectors, provides deep visibility into RLC behavior over NG-U and F1-U interfaces.
The following examples illustrate how RLC PDUs appear in packet captures and how they map to UE and gNB behavior.
The examples below assume NR RLC over UDP (F1-U or NG-U) captured and decoded using Wireshark with NR dissectors enabled.
10.1 RLC AM Data PDU – Downlink Example
Wireshark View (Decoded):
RLC NR RLC mode: Acknowledged Mode (AM) Sequence Number: 342 Poll bit: 1 FI: 01 (Last segment of SDU) PDU Length: 512 bytes
Interpretation:
SN 342 is the final segment of a higher-layer SDU
Poll bit set → receiver is expected to respond with STATUS
FI=01 indicates segmented SDU boundary
10.2 RLC AM STATUS PDU – Uplink Example
RLC NR Control PDU Control PDU Type: STATUS ACK_SN: 340 NACK_SN: 342, 343
What is happening:
UE has correctly received PDUs up to SN=340
PDUs 342 and 343 are missing or corrupted
gNB will retransmit only those PDUs
10.3 RLC UM PDU – VoNR Bearer Example
RLC NR RLC mode: Unacknowledged Mode (UM) Sequence Number: 118 Reordering: Enabled
Key observation:
No STATUS PDUs
Missing SNs are silently dropped after t-Reordering expiry
This is exactly why UM is preferred for real-time voice.
11. Conclusion
RLC rarely appears in marketing material, yet it is one of the strongest determinants of real-world 5G performance. When PHY and MAC are well optimized but RLC timers, modes, or polling behavior are misaligned, the user still experiences buffering, latency, and inconsistent throughput.
For engineers designing, testing, or troubleshooting 5G networks, a deep understanding of RLC is not optional. It is the layer where theoretical radio performance either translates into user satisfaction—or silently collapses.
RLC is not flashy, but it is where radio theory meets reality.
If PHY is perfect and MAC is efficient but RLC is misconfigured, the user still experiences: - Lag - Buffering - Packet loss
13. References
1. 3GPP TS 38.322 – Radio Link Control (RLC) protocol
2. 3GPP TS 38.321 Medium Access Control (MAC) Protocol Specification
3. 3GPP TS 38.300 NR Overall Description
4. 5G NR: The Next Generation Wireless Access Technology – Erik Dahlman, Stefan Parkvall, Johan Sköld