5G PDCP State Variables, Constants and Timers
This page is the PDCP runtime-control reference. It explains the normative state variables, constant, and timers that describe how PDCP transmit progression, receive progression, reordering, and discard timing work.
It is the control-reference companion to the PDCP data-transfer page. That page describes the behavior flow. This page explains the runtime values that make the flow precise: TX_NEXT, RX_NEXT, RX_DELIV, RX_REORD, Window_Size, discardTimer, discardTimerForLowImportance, and t-Reordering.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | PDCP state variables, constants, and timers |
| Main spec areas | TS 38.323 sections 7, 7.1, 7.2, and 7.3 |
| Page role | Runtime-control reference for PDCP transmit progression, receive progression, reordering, and discard timing |
| Transmit-side controls | TX_NEXT, discardTimer, and discardTimerForLowImportance |
| Receive-side controls | RX_NEXT, RX_DELIV, RX_REORD, Window_Size, and t-Reordering |
| Value domain | State variables are normative non-negative integers in the range 0 to 2^32 - 1 |
Contents
- Introduction to PDCP State Variables, Constants, and Timers
- Why the Runtime-Control Model Matters in PDCP
- How the Runtime-Control Model Is Organized
- PDCP Sequence Space and Runtime Control Basics
- TX_NEXT: Transmit-Side State Variable
- RX_NEXT, RX_DELIV, and RX_REORD: Receive-Side State Variables
- Window_Size and the PDCP Receive Window
- discardTimer and discardTimerForLowImportance
- t-Reordering and Receive-Side Loss Detection
- How Runtime-Control Values Drive PDCP Data Transfer and Delivery
- Practical Meaning of PDCP Runtime Variables
- References
- FAQ
- Related PDCP Pages / Next Reading
Introduction to PDCP State Variables, Constants, and Timers
The runtime-control section is the part of the PDCP specification that defines the values used to describe PDCP protocol behavior. Instead of focusing on packet formats or full step-by-step procedures, it defines the values that keep the transmit side, receive side, reordering logic, and discard timing synchronized with the protocol rules.
In practice, this page is the control reference engineers open when the PDCP behavior model mentions how PDCP progresses, waits, discards, or delivers. The variables and timers here are short in number, but they are central to how PDCP behaves while traffic is moving.
Why the Runtime-Control Model Matters in PDCP
Engineers need the runtime-control model because PDCP behavior is hard to read cleanly without the underlying values. The data-transfer procedures describe what the protocol does during data transfer, but the logic becomes readable only when the state variables and timers are understood.
In short, data-transfer and reordering behavior depend on this model. TX_NEXT explains transmit progression, RX_NEXT and RX_DELIV explain receive and delivery progression, RX_REORD explains the current reordering boundary, and the timers explain why PDCP waits, discards, or advances.
How the Runtime-Control Model Is Organized
The runtime-control model is compact. It is organized into three blocks: state variables, constants, and timers. Together they form the control language used by the rest of the PDCP procedure clauses.
| Control block | Scope | Main items |
|---|---|---|
| State variables | Normative runtime values that track PDCP transmit progression, receive expectation, delivery edge, and reordering reference. | TX_NEXT, RX_NEXT, RX_DELIV, RX_REORD |
| Constants | Fixed runtime constant used in receive-side COUNT and window interpretation. | Window_Size |
| Timers | Transmit-side and receive-side time controls that shape discard and loss-detection behavior. | discardTimer, discardTimerForLowImportance, t-Reordering |
PDCP Sequence Space and Runtime Control Basics
PDCP Data PDUs are numbered in an integer sequence-number space that cycles through the configured PDCP SN field. That visible SN field is what travels in the PDU. The runtime control model, however, is expressed using COUNT, which gives PDCP a larger progression context than the bare SN field alone.
This page keeps the difference practical rather than mathematical. Think of PDCP SN as the sequence label carried in the PDU, while COUNT is the runtime value PDCP uses to track ongoing progression across transmit and receive operation. These variables refer to COUNT values because PDCP needs more than the visible SN field to reason about ordering, window placement, and delivery progression.
All state variables in this model are normative, are defined as non-negative integers, and take values in the range 0 to 2^32 - 1. That definition matters because it keeps the runtime-control model consistent even though the configured PDCP SN field cycles through a smaller visible space.
TX_NEXT: Transmit-Side State Variable
TX_NEXT is maintained by the transmitting PDCP entity. It indicates the COUNT value of the next PDCP SDU to be transmitted. That makes it the main transmit-side progression variable in the runtime-control model.
In practical terms, TX_NEXT is the runtime value that tells PDCP which outgoing SDU gets the next sequence context. During data transfer, the transmitting PDCP entity associates the COUNT value corresponding to TX_NEXT with the incoming PDCP SDU, then continues through the transmit path toward protection, header construction, and lower-layer submission.
This is why TX_NEXT is best read together with the data-transfer page. This page defines the variable. The behavior page shows how the variable is consumed during transmit operation.
RX_NEXT, RX_DELIV, and RX_REORD: Receive-Side State Variables
The receiving PDCP entity maintains three core state variables: RX_NEXT, RX_DELIV, and RX_REORD. Together they describe where the receiver expects the stream to continue, where upper-layer delivery currently stands, and where the active reordering reference sits.
| State variable | Maintained by | Definition | Practical role |
|---|---|---|---|
| TX_NEXT | Transmitting PDCP entity | COUNT value of the next PDCP SDU to be transmitted. | Advances transmit-side PDCP sequence context and drives COUNT association before lower-layer submission. |
| RX_NEXT | Receiving PDCP entity | COUNT value of the next PDCP SDU expected to be received. | Marks the forward receive progression point as new PDCP Data PDUs arrive. |
| RX_DELIV | Receiving PDCP entity | COUNT value of the next PDCP SDU to be delivered to upper layers. | Defines the current delivery edge and helps identify already delivered or too-old data. |
| RX_REORD | Receiving PDCP entity | COUNT value following the PDCP Data PDU that triggered t-Reordering. | Provides the current reordering reference used when t-Reordering is running or expires. |
RX_NEXT indicates the COUNT value of the next PDCP SDU expected to be received. It therefore marks the forward receive progression point. RX_DELIV indicates the COUNT value of the next PDCP SDU to be delivered to upper layers, so it acts as the current delivery boundary. RX_REORD indicates the COUNT value following the COUNT value associated with the PDCP Data PDU that triggered t-Reordering, which makes it the key reference point for timer-driven reordering decisions.
These variables work together during receive buffering, reordering, and delivery. RX_NEXT advances as valid later data extends the receive progression. RX_DELIV advances only when the receiver can release data upward. RX_REORD is used when a gap has triggered waiting and PDCP must remember the reordering reference that defines what the timer is waiting around.
Window_Size and the PDCP Receive Window
The PDCP constant Window_Size gives the receiving PDCP entity a stable receive-window view for interpreting incoming sequence context.
Conceptually, Window_Size is used for receive-side COUNT and PDCP SN interpretation and therefore affects reordering behavior. It helps the receiver place an arriving PDU into the correct receive context instead of treating the visible SN field in isolation.
This page keeps the explanation readable on purpose. Engineers mainly need to remember that Window_Size is the constant that supports the receive window model behind COUNT reconstruction and receive-side progression.
discardTimer and discardTimerForLowImportance
discardTimer and discardTimerForLowImportance are maintained by the transmitting PDCP entity. They are transmit-side timers, not receive-side timers, and they shape how long a PDCP SDU is kept eligible on the transmit side before discard behavior is applied.
discardTimer is the general transmit-side discard timer. discardTimerForLowImportance is configured only for DRBs and exists so lower-importance traffic can follow a dedicated transmit-side discard policy. The detailed trigger points belong in the data-transfer and entity-handling procedures, but at runtime-model level the key point is simple: both timers are part of the transmit control logic that decides whether buffered SDUs remain worth sending.
| Timer | Maintained by | Configuration scope | Runtime purpose |
|---|---|---|---|
| discardTimer | Transmitting PDCP entity | Configured by upper layers | Limits how long a transmit-side PDCP SDU remains eligible before discard handling is applied. |
| discardTimerForLowImportance | Transmitting PDCP entity | Configured only for DRBs | Applies a dedicated discard policy for low-importance transmit-side traffic on the relevant DRB context. |
| t-Reordering | Receiving PDCP entity | Configured by upper layers, with sidelink-specific exceptions in the spec | Detects loss of PDCP Data PDUs and controls when receive-side delivery can advance across a gap. |
The timer durations are configured by upper layers through the TS 38.331 configuration framework. That same configuration rule also applies to t-Reordering, with the specification noting a sidelink-related exception for that timer. Sidelink and MRB-specific cases exist, but they stay brief on this page because the main purpose here is the baseline runtime model.
t-Reordering and Receive-Side Loss Detection
t-Reordering is maintained by the receiving PDCP entity. It is used to detect loss of PDCP Data PDUs and to control when receive-side delivery should keep waiting versus when it should advance.
Only one t-Reordering per receiving PDCP entity can run at a given time. That design matters because it keeps the receive-side reordering state tied to one active reordering reference instead of allowing multiple independent wait contexts to exist for the same PDCP entity.
At overview level, the timer starts when a gap matters, continues while PDCP is waiting for missing data, and on expiry lets the receiver stop waiting indefinitely and advance delivery according to the PDCP data-transfer rules. Deep step-by-step procedure detail belongs on the data-transfer page, but the key runtime interpretation belongs here: t-Reordering is the receive-side time boundary for loss detection.
How Runtime-Control Values Drive PDCP Data Transfer and Delivery
The runtime-control model is the compact control layer behind the PDCP behavior flow. TX_NEXT drives transmit-side COUNT progression. RX_NEXT, RX_DELIV, and RX_REORD drive receive-side progression, buffering, and delivery decisions. Window_Size shapes receive-side interpretation of sequence context. The timers determine how long PDCP waits before discarding transmit-side data or advancing receive-side delivery across a gap.
| Runtime control | Behavior area | Why it matters |
|---|---|---|
| TX_NEXT | Transmit progression | Explains which COUNT context is associated with the next outgoing PDCP SDU. |
| RX_NEXT | Receive progression | Shows the next COUNT the receiver still expects as new PDCP Data PDUs arrive. |
| RX_DELIV | Upper-layer release boundary | Shows which COUNT value is next eligible for delivery and helps classify late data as too old. |
| RX_REORD | Reordering reference | Marks the reordering boundary that t-Reordering uses when waiting for a missing PDU. |
| Window_Size | Receive-window interpretation | Keeps receive-side COUNT and SN interpretation aligned with the active PDCP window. |
| discardTimer | Transmit discard timing | Explains why a pending PDCP SDU may be removed instead of being sent indefinitely. |
| discardTimerForLowImportance | Priority-sensitive discard timing | Shows how lower-importance DRB traffic can have dedicated discard timing. |
| t-Reordering | Receive-side loss detection and delivery advance | Explains why delivery may pause at a gap, then advance when waiting long enough no longer makes sense. |
Practical Meaning of PDCP Runtime Variables
For trace reading and protocol reasoning, these variables are best treated as short labels for runtime state. TX_NEXT helps explain transmit progression. RX_NEXT shows what the receiver still expects. RX_DELIV shows what can move upward next. RX_REORD shows the current reordering boundary. t-Reordering explains why delivery may still be waiting or why it has started to advance after a loss indication window has ended.
This is not a troubleshooting page, but the variables are still useful for practical reasoning. If a receiver looks stalled, the likely explanation is not a mystery field in the PDU. It is usually the current relationship between RX_DELIV, RX_NEXT, RX_REORD, Window_Size, and the state of t-Reordering.
References
- 3GPP TS 38.323 V18.1.0, NR Packet Data Convergence Protocol (PDCP) specification
- ETSI TS 138 323 V18.1.0 (2024-05), PDCP publication
- 3GPP TS 38.331 V18.5.1, NR RRC specification for bearer and timer configuration context
- 3GPP TS 38.300 V19.2.0, overall NR architecture context
FAQ
Why does PDCP use COUNT-based state variables instead of only the visible PDCP SN?
Because the visible PDCP SN field cycles through the configured SN space, while the runtime-control model needs a broader progression context for transmit handling, receive interpretation, reordering, and delivery.
Is Window_Size a timer or a state variable?
No. Window_Size is the PDCP receive-window constant. It supports receive-window interpretation and helps the receiver place incoming data into the right runtime context.
Can more than one t-Reordering run for the same receiving PDCP entity?
No. Only one t-Reordering per receiving PDCP entity can run at any time.
Is discardTimerForLowImportance used for every bearer type?
No. The specification states that discardTimerForLowImportance is configured only for DRBs.