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

Home / 5G / Protocols / RLC / Variables, Constants and Timers

5G RLC Variables, Constants and Timers

This page is the RLC control-value reference. It covers state variables, fixed constants such as window sizes, timers, and configurable parameters supplied by RRC configuration.

Use it to check AM and UM sequence arithmetic, transmit-side and receive-side progress variables, timer behavior, and the parameter values that shape polling, retransmission, STATUS pacing, and reassembly handling.

Quick facts

Technology 5G NR
Topic RLC variables, constants, timers, and configurable parameters
Main spec 3GPP TS 38.322
Release Release 18
Normative status RLC state variables are normative and all state variables and counters are non-negative integers
Main timers t-PollRetransmit, t-Reassembly, t-StatusProhibit
Configured by TS 38.331 for timers and configurable parameters

Contents

  1. Introduction to RLC Variables, Constants, and Timers
  2. How the Control Values Are Organized
  3. Arithmetic, Sequence Spaces, and Modulus Rules
  4. AM Transmit-Side State Variables and Counters
  5. AM Receive-Side State Variables
  6. UM State Variables
  7. Constants: Window Sizes
  8. Timers
  9. Configurable Parameters
  10. How Variables, Timers, and Parameters Drive Procedures
  11. Troubleshooting Notes from Variables and Timers
  12. References
  13. FAQ
  14. Related Pages / Next Reading

Introduction to RLC Variables, Constants, and Timers

This is the runtime-control reference for RLC behavior. The procedures and the PDU handling in other parts of the spec rely on state variables, counters, fixed constants, timers, and configurable thresholds to decide what an entity does next.

This matters because many practical trace questions are really control-value questions. A repeated poll, a stalled receive window, a delayed STATUS, a reassembly timeout, or a max retransmission event cannot be understood well without the control values that govern the entity state.

RLC control values Runtime behavior State variables Live entity state Constants Window sizes Timers Wait and trigger logic Parameters Configured thresholds Feeds procedures and traces Poll generation Receive-window movement STATUS pacing and reassembly Retransmission limits
Show the four main control-value groups: state variables, constants, timers, and configurable parameters, and how they feed into RLC procedures.

How the Control Values Are Organized

The control-value model is organized into four main parts. First come the normative state variables. Then the fixed constants such as AM and UM window sizes. After that come the timers, followed by configurable parameters that are supplied through RRC configuration as defined by TS 38.331.

Control-value group What it covers Why it matters
State variables Transmit-side and receive-side progress markers, counters, and status-construction values. These values describe the live state of the entity.
Constants Window sizes derived from sequence-number length. These define operational ranges for transmit and receive behavior.
Timers t-PollRetransmit, t-Reassembly, and t-StatusProhibit. These control waiting, feedback pacing, and reassembly progression.
Configurable parameters maxRetxThreshold, pollPDU, and pollByte. These tune retransmission limits and poll generation behavior.

Arithmetic, Sequence Spaces, and Modulus Rules

RLC relies on modular sequence arithmetic because sequence numbers wrap. For AM, the modulus is 0..4095 when 12-bit sequence numbering is used and 0..262143 when 18-bit sequence numbering is used. For UM, the modulus is 0..63 with 6-bit sequence numbering and 0..4095 with 12-bit sequence numbering.

The practical point is not the math itself, but how comparisons are made across wrap-around. AM transmit-side comparisons use TX_Next_Ack as the modulus base, while AM receive-side comparisons use RX_Next. UM receive-side comparisons use RX_Next_Highest - UM_Window_Size as the modulus base. These base rules are what keep window checks consistent even when raw sequence values wrap.

AM sequence space 12-bit SN -> modulus 0..4095 AM_Window_Size = 2048 18-bit SN -> modulus 0..262143 AM_Window_Size = 131072 UM sequence space 6-bit SN -> modulus 0..63 UM_Window_Size = 32 12-bit SN -> modulus 0..4095 UM_Window_Size = 2048
Compare AM 12-bit versus 18-bit sequence space and UM 6-bit versus 12-bit sequence space together with their corresponding window sizes.

AM Transmit-Side State Variables and Counters

AM transmit-side variables track what has been sent, what is acknowledged, where polling currently points, and how often the sender has transmitted data without polling. Together they drive transmit-window progress, polling decisions, and retransmission handling.

Variable or counter Practical meaning Why it matters
TX_Next_Ack The AM transmit-side reference for the next data not yet cumulatively acknowledged. It is the modulus base for AM transmit-side comparisons and anchors the sending window.
TX_Next The next sequence number to assign to newly generated AMD data. Shows how fresh AM transmission advances.
POLL_SN The sender's tracked sequence point associated with an outstanding poll. Important when deciding whether received STATUS covers the issued poll.
PDU_WITHOUT_POLL Count of transmitted PDUs since the last poll-related reset point. Used with pollPDU to decide when another poll is needed.
BYTE_WITHOUT_POLL Count of transmitted bytes since the last poll-related reset point. Used with pollByte to avoid long byte bursts without feedback requests.
RETX_COUNT Retransmission count associated with retransmission handling. Used to detect when maxRetxThreshold has been reached.
AMD PDU creation TX_Next update PDU_WITHOUT_POLL and BYTE_WITHOUT_POLL update Poll decision POLL_SN update
Sending window anchor TX_Next_Ack TX_Next Poll tracking POLL_SN Poll counters PDU_WITHOUT_POLL, BYTE_WITHOUT_POLL Retransmission control RETX_COUNT maxRetxThreshold check
Show TX_Next_Ack, TX_Next, POLL_SN, PDU_WITHOUT_POLL, BYTE_WITHOUT_POLL, and RETX_COUNT around the sender window and poll logic.

AM Receive-Side State Variables

AM receive-side variables describe where the receiver has fully advanced, where STATUS reporting may be triggered, what the highest status-related point is, and how far received data has reached even if delivery is not yet complete. These variables are central to receive-window progress and STATUS construction.

Variable Practical meaning Why it matters
RX_Next The receive-side reference for the next data expected in sequence. It is the modulus base for AM receive-side comparisons and anchors receive-window progress.
RX_Next_Status_Trigger The receive-side reference point associated with STATUS-trigger conditions. Helps explain why and when STATUS generation is required.
RX_Highest_Status The highest status-related boundary already considered in receive-side control logic. Useful when explaining STATUS construction boundaries and receive-side progress.
RX_Next_Highest The highest sequence position seen in the current receive context. Important for gap detection, receive-window movement, and t-Reassembly behavior.
Gap detected RX_Next_Highest advances t-Reassembly becomes relevant RX_Next and RX_Highest_Status move with receive progress STATUS construction follows from that movement
AM receive window RX_Next RX_Next_Status_Trigger RX_Highest_Status RX_Next_Highest
Show RX_Next, RX_Next_Status_Trigger, RX_Highest_Status, and RX_Next_Highest across the AM receive window and STATUS generation boundaries.

UM State Variables

UM uses a smaller state set because it does not perform ARQ. There is one transmit-side variable for outgoing sequence progress and three receive-side variables that explain how reassembly and waiting behavior advance.

Variable Mode side Practical meaning
TX_Next UM transmit side The next sequence number to use for newly generated UMD data.
RX_Next_Reassembly UM receive side The next point from which reassembly or delivery is expected to progress.
RX_Timer_Trigger UM receive side The receive-side reference tied to t-Reassembly behavior.
RX_Next_Highest UM receive side The highest receive progress point observed so far.

UM receive behavior is easiest to understand as reassembly-window movement. A received UMD PDU can move RX_Next_Highest, start or interact with t-Reassembly, and eventually allow RX_Next_Reassembly to advance when the receive-side conditions are satisfied.

UMD PDU received RX_Next_Highest update Reassembly-window movement RX_Next_Reassembly progresses when possible t-Reassembly remains the receive-side guard
UM transmit side TX_Next UM receive-side variables RX_Next_Reassembly RX_Timer_Trigger RX_Next_Highest
Show TX_Next on the transmit side and RX_Next_Reassembly, RX_Timer_Trigger, and RX_Next_Highest on the receive side.

Constants: Window Sizes

RLC defines fixed window-size constants derived from the configured sequence-number length. These constants matter because they define the operational span of AM and UM sequence handling, which directly affects window checks, gap interpretation, and wrap-around-safe comparisons.

Constant SN length Value
AM_Window_Size 12-bit 2048
AM_Window_Size 18-bit 131072
UM_Window_Size 6-bit 32
UM_Window_Size 12-bit 2048

Operationally, larger SN length means a larger window and therefore a wider span of valid in-flight or pending receive context. This matters in trace reading because the same raw sequence gap can mean very different things depending on the configured SN length.

Timers

These timers govern how long the entity waits before taking new action. In Release 18, the main timers are t-PollRetransmit, t-Reassembly, and t-StatusProhibit. The values are configured through TS 38.331.

Only one t-Reassembly per RLC entity can run at a time. This matters because it keeps receive- side waiting behavior anchored to one active reassembly context rather than multiple overlapping timers.

Timer Main control role Practical effect
t-PollRetransmit Sender-side waiting limit after polling. Prevents AM from waiting indefinitely for feedback.
t-Reassembly Receive-side waiting limit for missing sequence progress. Drives receive progression when missing data blocks completion.
t-StatusProhibit Receiver-side pacing of STATUS transmission. Prevents excessive STATUS traffic while still allowing later feedback.
Poll sent POLL_SN update t-PollRetransmit start STATUS arrives or timer expires Gap detected t-Reassembly start Receive progress update after timeout or missing-data resolution
t-PollRetransmit Sender waits for feedback Poll and STATUS loop t-Reassembly Receiver waits across gaps Delivery progression t-StatusProhibit Receiver paces STATUS Feedback throttling
Show how t-PollRetransmit, t-Reassembly, and t-StatusProhibit interact with polling, receive gaps, and STATUS emission.

Configurable Parameters

The configurable parameters tune how aggressively AM requests feedback and how long retransmission can continue before upper layers are informed. As with the timers, these parameters are configured by TS 38.331.

Parameter Main role Operational effect
maxRetxThreshold Retransmission limit for AM recovery handling. Triggers upper-layer indication when repeated retransmission fails to resolve the problem.
pollPDU PDU-count threshold for poll generation. Controls how many PDUs may be sent before another poll is required.
pollByte Byte-count threshold for poll generation. Controls how many bytes may be sent before another poll is required.
RETX_COUNT increments maxRetxThreshold reached Upper-layer indication

How Variables, Timers, and Parameters Drive Procedures

These control values are what turn RLC from a static architecture into a live procedure system. State variables drive transmit and receive progression. Timers decide when waiting becomes action. Configurable parameters tune when polls are generated and how long retransmission is tolerated.

In practice, these values feed directly into data transfer procedures, ARQ procedures, STATUS generation, receive reassembly, and troubleshooting of stalled AM or UM operation. This is why this page should be read as the control layer behind the procedure layer.

Troubleshooting Notes from Variables and Timers

These values often explain behavior that otherwise looks mysterious in traces. Repeated polls often point to poll counters and timer restart logic. A receive window that does not move usually points to RX-side variables and outstanding missing data. Reassembly problems often reduce to t-Reassembly behavior. Persistent retransmission can end in a maxRetxThreshold indication. Sparse or delayed STATUS traffic can be explained by t-StatusProhibit.

Symptom pattern Likely control-value cause Best next page
Repeated poll behavior pollPDU or pollByte threshold behavior and t-PollRetransmit interaction. ARQ Procedures
Stalled receive window RX-side variables show unresolved gaps or incomplete receive progression. RLC Procedures
t-Reassembly-driven delivery problems Receive-side waiting and timeout progression are controlling when data can advance. Unacknowledged Mode
maxRetxThreshold event RETX_COUNT has reached the configured retransmission limit. Acknowledged Mode
STATUS generation looks throttled t-StatusProhibit is limiting immediate STATUS transmission. Troubleshooting and Trace Analysis

References

FAQ

Are these variables just implementation hints?

No. These state variables are normative and describe the control state the entity uses for standard behavior.

Why does sequence-number length matter so much?

Because it determines the modulus and the associated window size, which directly affect comparison rules, receive-span interpretation, and transmit or receive progression.

Why is only one t-Reassembly allowed per RLC entity?

Because receive-side reassembly waiting is controlled as one active entity-level context, not as multiple parallel timers for different missing fragments.

Do timers and configurable parameters come from TS 38.322 alone?

No. This page identifies them, but their configured values are provided through TS 38.331 RRC configuration.

Related Pages / Next Reading

Related Content