3GLTEInfo Text-based logo for the 3GLTEInfo telecom engineering reference platform. 3GLTE INFO TELECOM ENGINEERING REFERENCE
Menu

Home / 5G / Protocols / RLC / Procedures

5G RLC Procedures

5G NR RLC procedures describe how an RLC entity behaves over time once its architecture and mode are already defined. This includes entity handling, data transfer behavior for TM, UM, and AM, ARQ in AM, SDU discard, data volume calculation, and the handling of invalid or erroneous protocol data.

This page sits between RLC architecture and the deeper topic pages for ARQ procedures, PDU formats and parameters, and variables, constants, and timers. Use it as the procedure map for entity lifecycle, runtime data transfer, recovery behavior, discard rules, and buffer-side accounting.

Quick facts

Technology 5G NR
Topic RLC procedures
Main spec 3GPP TS 38.322 clause 5
Release Release 18
Procedure scope Entity handling, data transfer, ARQ, SDU discard, data volume calculation, and protocol error handling
Modes covered TM, UM, AM
Most procedure-heavy mode AM, because it adds STATUS reporting and retransmission handling

Contents

  1. Introduction to 5G RLC Procedures
  2. How TS 38.322 Organizes RLC Procedures
  3. RLC Entity Handling
  4. Data Transfer Procedures Overview
  5. TM Data Transfer Procedures
  6. UM Data Transfer Procedures
  7. AM Data Transfer Procedures
  8. ARQ Procedures Overview
  9. SDU Discard Procedures
  10. Data Volume Calculation
  11. Handling Invalid or Erroneous Protocol Data
  12. Troubleshooting Notes from Procedures
  13. Related Pages / Next Reading
  14. References
  15. FAQ

Introduction to 5G RLC Procedures

In the RLC context, procedures describe runtime behavior. Architecture explains what the entity is and which blocks exist. Procedures explain what that entity does when it is established, when it receives an SDU, when it builds a PDU, when reassembly cannot progress, when discard is requested, or when invalid protocol data arrives.

TM, UM, and AM do not share the same runtime model. TM stays close to transparent forwarding, UM adds buffer- and timer-driven receive behavior without retransmission, and AM adds the richest procedure set because reliable delivery requires retransmission context, polling, STATUS reporting, and receive-side gap handling.

What this page covers

  • How the main RLC procedure families are organized.
  • How entity establishment, re-establishment, and release affect runtime state.
  • How TM, UM, and AM data transfer differ.
  • How ARQ, discard, data volume reporting, and invalid protocol handling fit into the same procedure model.
Clause 5 procedures map Diagram showing entity handling, data transfer, ARQ, discard, data volume calculation, and erroneous protocol-data handling as the main clause 5 procedure areas. Entity handling establish / reset / release Data transfer TM / UM / AM runtime paths ARQ AM polling and STATUS Discard SDU cleanup rules Errors invalid PDUs Data volume calculation pending data + retransmission + STATUS view toward MAC
Show a compact clause map from entity handling to data transfer, ARQ, discard, data volume calculation, and erroneous-protocol-data handling.

How TS 38.322 Organizes RLC Procedures

Clause 5 is easier to read when treated as a procedure map rather than a long list. It starts with RLC entity handling, then separates data transfer by mode, then adds AM-specific ARQ behavior, discard handling, data volume calculation, and the handling of unknown, unforeseen, or erroneous protocol data.

Clause 5 area What it covers Why it matters
RLC entity handling Establishment, re-establishment, and release of RLC entities. Defines how runtime state starts, resets, and ends.
Data transfer procedures Mode-specific transmit and receive behavior for TM, UM, and AM. Shows how the same architecture behaves differently at runtime.
ARQ procedures AM retransmission, polling, and STATUS-based recovery behavior. Explains reliable RLC delivery above HARQ.
SDU discard procedures Upper-layer discard requests and eligibility checks inside transmitting entities. Important for latency control and buffer cleanup without violating SN continuity rules.
Data volume calculation What counts as pending RLC data toward MAC-facing buffer reporting. Important for scheduling and practical queue interpretation.
Erroneous protocol data handling Discard behavior for reserved, invalid, or otherwise unacceptable protocol content. Important when traces contain malformed or unusable PDUs.
Clause 5 procedure flow Upper-layer request flows through entity handling, mode-specific data transfer, AM ARQ when needed, discard and buffer accounting, and invalid data rejection. Upper-layer request Entity handling Mode-specific data transfer AM ARQ when needed Discard and buffer accounting Invalid data reject
Clause 5 can be read as one procedure path from upper-layer requests through runtime handling, recovery, accounting, and rejection of unusable data.

RLC Entity Handling

Entity handling covers the lifecycle of an RLC entity. At establishment, the mode-specific entity is created and initialized with its configuration, buffers, windows, variables, and timer context. At re-establishment, runtime state is reset so the entity starts again from a clean procedure state. At release, the entity and its remaining runtime context are discarded.

This lifecycle matters because many later trace questions are actually entity-handling questions. A sudden reset in sequence progression, empty buffers after reconfiguration, or loss of retransmission context can come from re-establishment rather than ordinary data transfer behavior.

Entity lifecycle step Procedure meaning Typical runtime effect
Establishment Create the RLC entity with configured mode and initial procedure state. Buffers and variables begin from initialized values.
Re-establishment Reset mode-specific runtime state and discard transient procedure context. Old transmission or reassembly progress is cleared.
Release Remove the entity and clear its procedure context. No further data transfer occurs through that entity.
RLC entity lifecycle Lifecycle diagram showing establishment, re-establishment, and release with their effects on buffers and state. Establishment create entity and initialize state Re-establishment reset buffers, variables, and procedure progress Release clear entity and discard runtime context lifecycle transitions change whether runtime state begins, resets, or ends
Show establish, re-establish, and release as lifecycle states with reset and discard effects on buffers and variables.

Configuration detail belongs on the RLC architecture and variables, constants, and timers pages, but procedure reading should always keep lifecycle transitions in mind.

Data Transfer Procedures Overview

TS 38.322 separates TM, UM, and AM data transfer because each mode has a different runtime model. TM is the simplest. UM adds receive-side ordering and reassembly behavior. AM adds both richer data-transfer behavior and the bridge into ARQ handling.

The practical comparison is simple: TM has minimal procedure logic, UM adds buffer- and timer-driven completion behavior without retransmission, and AM adds windows, duplication checks, retransmission context, and control- feedback interaction.

Mode Data transfer complexity Main procedural features
TM Low Simple transmit and receive forwarding behavior.
UM Medium Receive buffering, reassembly progression, and t-Reassembly-driven cleanup.
AM High Transmit and receive windows, duplicate handling, reassembly progression, and ARQ bridge.
TM versus UM versus AM procedures comparison Diagram comparing procedure complexity across TM, UM, and AM, including forwarding, buffering, timers, and ARQ participation. TM simple forward and deliver minimal runtime logic no timer-driven recovery UM receive buffering reassembly progression t-Reassembly cleanup no ARQ AM transmit and receive windows duplicate and gap handling reassembly + t-Reassembly polling and STATUS bridge procedure depth increases from TM to UM to AM
Compare forwarding, buffering, reassembly, timer handling, and ARQ participation across the three modes.

TM Data Transfer Procedures

TM data transfer is intentionally simple. On the transmitting side, the entity takes incoming data and forwards it toward lower layers without segmentation, sequence-number processing, or retransmission logic. On the receiving side, the entity performs the corresponding simple delivery behavior upward.

TM should therefore be read as a minimal procedure path. If a trace question involves sequence progress, reassembly windows, or STATUS-driven recovery, it is not a TM question.

Upper-layer request -> TM transmit -> lower layers -> TM receive -> upper-layer delivery

UM Data Transfer Procedures

UM data transfer adds a real receive-side procedure model. The transmitting side accepts upper-layer SDUs, creates UMD PDUs, and performs segmentation when needed. The receiving side interprets received UMD PDUs, places suitable content into the reception buffer, and advances reassembly and delivery when the required data is available.

When a UMD PDU is received, the entity checks whether it is acceptable for the current receive context. When a PDU is placed in the reception buffer, reassembly progress may advance. When t-Reassembly expires, the receiving side stops waiting indefinitely for missing content, updates receive progress, and clears state so delivery can continue as defined by the UM procedure rules.

UM receive, reassembly, and t-Reassembly flow Diagram showing UMD PDU arrival, acceptance checks, reception buffering, reassembly, and the timer-expiry branch when missing data blocks completion. UMD arrival Acceptance checks Reception buffer Reassembly Delivery t-Reassembly expiry update receive progress and clear waiting state
Show UMD PDU arrival, acceptance checks, placement into the reception buffer, reassembly attempts, and the timer-expiry branch when missing data prevents completion.

The deeper state-variable and timer interpretation belongs on the variables, constants, and timers page. This page keeps the procedure view readable and centered on how UM behaves over time.

AM Data Transfer Procedures

AM data transfer is the most detailed because the mode must support reliable delivery. The transmitting side accepts SDUs, segments as needed, builds AMD PDUs, maintains transmission context, and decides when polling should be triggered. The receiving side validates incoming AMD PDUs, places them in the reception buffer, detects duplicates and gaps, advances reassembly when possible, and contributes to STATUS-based recovery.

When an AMD PDU is received, the entity interprets it against the current receive window. When it is placed in the reception buffer, reassembly and delivery may progress, but only if the missing-data conditions allow it. When t-Reassembly expires, the receive side updates its view of what can no longer wait and drives forward the next stage of receive progression.

This page keeps detailed ARQ timer logic short. The point here is the runtime map: AM uses transmit windows, receive windows, prioritization between new data and retransmission, duplicate handling, and reassembly rules. The dedicated ARQ procedures page should be read next for the full recovery flow.

AM data transfer and ARQ bridge Diagram showing AM transmit flow, receive buffering, gap detection, STATUS feedback, and retransmission bridge. AM transmit AMD PDUs Receive buffer Gap or duplicate interpretation STATUS feedback Retransmission decision
Show transmit-side data flow, receive buffering, duplicate or gap detection, STATUS feedback, and the bridge into retransmission behavior.

ARQ Procedures Overview

ARQ applies only to AM. TM and UM do not use RLC retransmission based on polling and STATUS reporting. In AM, ARQ is the procedure family that turns receive-side missing-data detection into actual recovery behavior on the transmitting side.

At overview level, ARQ means three linked behaviors: the transmitting side decides when to poll, the receiving side builds STATUS information when required, and the transmitting side uses that feedback to prioritize retransmission. This is distinct from HARQ because it occurs at RLC level and follows the state of the RLC entity rather than only the lower-layer transmission attempt.

AM ARQ overview flow AM transmit leads to poll, peer STATUS reporting, retransmission decision, and retransmit if needed. AM transmit Poll Peer STATUS reporting Retransmission decision Retransmit if needed
AM ARQ turns polling and peer STATUS reporting into a retransmission decision path when reliable delivery needs recovery.

Keep this page as the ARQ map, then move to RLC ARQ Procedures for deeper handling of retransmission conditions, polling triggers, and STATUS content.

SDU Discard Procedures

SDU discard procedures explain how an upper-layer discard request is handled by the transmitting entity. The key point is that UM and AM transmitting entities discard SDU data only when the relevant data has not yet been submitted to lower layers. Once lower-layer submission has already happened, the discard decision is constrained by the state of transmitted procedure progress.

AM adds another important restriction: discard behavior must not create a sequence-number gap that breaks the AM data transfer model. That is why discard rules in AM are more constrained than a simple "drop the pending SDU" interpretation would suggest.

SDU discard procedure flow Upper-layer discard request leads to discard eligibility checking, discard if still eligible, and preservation of sequence continuity rules. Upper-layer discard request Discard eligibility check Discard if still eligible Preserve sequence continuity rules
Discard handling begins with the upper-layer request, but the final action still depends on eligibility and on preserving the sequence continuity rules of the active mode.

Data Volume Calculation

Data volume calculation explains what the RLC entity counts as pending data toward MAC-facing buffer reporting. This is not just "new SDUs waiting above RLC." It includes several categories of work that still represent data pressure from the point of view of the RLC entity.

Included contribution Meaning in practice
SDUs or segments not yet included in an RLC data PDU Fresh upper-layer data still waiting for RLC-side packaging.
Data PDUs pending initial transmission RLC data already prepared but still waiting for lower-layer sending opportunity.
Data PDUs pending retransmission in AM Reliable-delivery work that still occupies queue pressure even after a first send attempt.
Pending STATUS reporting when relevant AM control feedback that still consumes RLC-to-MAC transmission need.
RLC data volume calculation map Diagram showing new data, pending first transmission, pending retransmission, and pending STATUS reporting feeding into RLC data volume calculation toward MAC. Fresh SDUs or segments not packaged Pending first transmission Pending retransmission Pending STATUS reporting RLC data volume calculation buffer pressure view toward MAC scheduling
Show pending new data, pending first transmission, pending retransmission, and pending STATUS reporting as the main contributors to the reported data volume.
Pending data + pending STATUS -> RLC data volume calculation -> MAC buffer reporting view

Handling Invalid or Erroneous Protocol Data

RLC procedures also define what the entity should do when received protocol data cannot be interpreted correctly. In reference terms, this covers content that is unknown, reserved, malformed for the expected mode, or otherwise unusable for normal RLC processing. The practical rule is straightforward: the entity protects its runtime state by rejecting or discarding protocol data that does not fit valid RLC interpretation.

This matters because malformed protocol content should not be mixed up with ordinary loss, delay, or reassembly failure. If a trace contains an invalid header interpretation, an unexpected control format, or a mode-inconsistent PDU, the first question is whether the data is acceptable at all. Only after that does it make sense to continue with normal TM, UM, or AM procedure reading.

Invalid-data situation Procedure meaning Why it matters in traces
Reserved or unknown protocol content The received data does not match a valid RLC interpretation path. This should be read as invalid protocol input, not as normal RLC progression.
Mode-inconsistent PDU view The content does not fit the configured TM, UM, or AM procedure model. It helps separate malformed input from genuine mode-specific buffering or ARQ behavior.
Unusable received control or data content The entity should discard the content instead of letting it corrupt procedure state. This protects sequence progress, reassembly context, and control behavior from bad input.

Example

Assume an AM bearer is active and a received PDU appears in the trace, but the header interpretation does not fit a valid AMD or STATUS view for that context. The first read should not be "why did reassembly stall?" or "why did retransmission not fix this?" The first read is that the entity received protocol data it cannot use. The relevant procedure outcome is discard of the unusable content, then troubleshooting continues from the surrounding valid PDUs rather than from the malformed one.

Example of invalid AM protocol data handling Trace sequence with valid AM data, one malformed received PDU that cannot be interpreted, discard of that PDU, and continuation from surrounding valid PDUs. Valid received AM PDU Malformed or invalid received PDU Discard unusable protocol data Continue reading from surrounding valid PDUs Do not treat the malformed PDU as normal reassembly or ARQ evidence First classify it as unusable protocol input, then continue troubleshooting from the valid sequence around it.
A malformed received PDU should be classified as unusable protocol input first, then discarded, instead of being treated as ordinary AM reassembly or retransmission behavior.

Troubleshooting and Trace Analysis

Use this next when invalid or malformed RLC content needs to be separated from normal loss or delay behavior.

PDU Formats and Parameters

Open this when the trace question is whether the received content matches a valid TM, UM, or AM format.

Troubleshooting Notes from Procedures

Many RLC trace symptoms map directly to procedure families. If the mode is TM, troubleshooting is usually about simple forwarding and bearer context rather than sequence-driven recovery. If the mode is UM, the main questions are usually around reassembly progress, missing data, and t-Reassembly. If the mode is AM, the main questions usually involve retransmission buildup, polls, STATUS traffic, receive-window progress, or stalled delivery.

Symptom pattern Likely procedure area Best next page
Data seems to pass with almost no internal RLC state TM forwarding behavior Transparent Mode
Reassembly stalls or delivery advances only after timeout UM or AM receive-side buffering and t-Reassembly behavior Variables, Constants, and Timers
Repeated poll and STATUS activity with delayed delivery AM data transfer plus ARQ ARQ Procedures
Unexpected reset in sequence progress or buffered context Entity re-establishment or release behavior RLC Architecture
Queue pressure does not match only fresh SDU arrival Data volume calculation and pending retransmission or STATUS work Troubleshooting and Trace Analysis

Related Pages / Next Reading

Related Content

References

FAQ

What is the difference between RLC architecture and RLC procedures?

Architecture explains the entity model and mode structure. Procedures explain how that entity behaves during establishment, data transfer, recovery, discard, and error handling.

Why are UM and AM procedures more complex than TM?

Because UM and AM must manage receive-side buffering and reassembly, while AM also adds retransmission and STATUS-based recovery behavior.

Does this page replace the dedicated ARQ page?

No. This page gives the clause 5 map and the ARQ overview only. The dedicated ARQ page should be used for the deeper retransmission, polling, and STATUS procedure detail.

What does data volume calculation mean in RLC?

It means the RLC-side accounting of pending work toward MAC, including unsent data, pending first transmissions, AM retransmissions, and pending STATUS reporting when relevant.