RSN

Retransmission Sequence Number

Protocol →
Introduced in Rel-6 Also in: Radio Access Network, User Equipment

RSN is the sequence number used in 3GPP radio link protocols to identify and order data packets for retransmission, enabling reliable delivery by tracking missing packets.

Category
Protocol
Introduced
Rel-6
Where
Core Network › 5G Core
Also touches
2 segments
Specifications
19 specs
RSN Description Purpose Related Classification Detected Changes Specifications

Description

The Retransmission Sequence Number (RSN) is a fundamental mechanism within the data retransmission protocols of the 3GPP radio interface, specifically in the Packet Data Convergence Protocol (PDCP) layer and the Radio Link Control (RLC) layer. Its primary function is to uniquely identify data packets (or segments) that are eligible for or undergoing retransmission, enabling orderly and efficient recovery from transmission errors.

In architecture, both PDCP and RLC layers manage the transmission of data between the UE and the base station (gNB/eNB). They employ acknowledgment-based protocols (like RLC Acknowledged Mode (AM)) to ensure reliability. When a packet is transmitted, it is assigned a sequence number (SN). If the receiver fails to acknowledge it (due to error, loss), the packet may need retransmission. The RSN is a separate sequence space or a sub-field used specifically to track the retransmission instances of such packets. In some implementations, the RSN is a counter incremented each time a particular packet is retransmitted.

How it works: Upon initial transmission, a packet is sent with its primary SN. If a negative acknowledgment (NACK) is received or a timer expires, the transmitter schedules a retransmission. For this retransmission, the packet is marked with an RSN value (e.g., RSN=1 for first retransmission). The receiver uses this RSN to understand that this is a retransmission of a previously seen packet (identified by its primary SN). This helps the receiver in reassembly and deduplication. In protocols supporting multiple retransmissions (like HARQ at MAC or RLC), the RSN may increment with each retry, allowing both ends to track the retransmission count, which can be used for adaptive strategies like modifying modulation or power.

Its role in the network is critical for maintaining data integrity over the unreliable wireless channel. By clearly labeling retransmissions, the RSN prevents the receiver from misinterpreting a retransmitted packet as a new packet, which would cause duplication and sequence gaps. It also aids in buffer management at both transmitter and receiver. For the transmitter, tracking RSN helps implement retransmission limits and prioritize retries. For the receiver, it assists in correctly reordering packets before delivering them to higher layers. This mechanism is essential for services requiring high reliability, such as VoIP, online gaming, and critical IoT communications, ensuring seamless data flow despite intermittent radio errors.

Purpose & Motivation

The RSN concept exists to address the inherent unreliability of the wireless medium in mobile communications. Radio links suffer from fading, interference, and noise, causing packets to be lost or corrupted. To guarantee data delivery, retransmission protocols are necessary. However, simple retransmission without proper labeling leads to problems: the receiver might accept a retransmitted packet as a new, duplicate packet, corrupting the data stream; the transmitter might lose track of how many times a packet has been retried, potentially wasting resources on persistently failing packets.

Historically, early wireless data protocols used simple sequence numbers for ordering but lacked dedicated retransmission tracking. The introduction of RSN in 3GPP protocols (evident from Rel-6 onwards) provided a refined tool for managing retransmissions. It solved the duplication issue by allowing the receiver to distinguish between a new packet and a retransmission of an old packet, even if they carry the same user data. This is crucial for protocols like RLC AM, which may deliver large data blocks segmented into many packets.

The motivation was to enhance the efficiency and reliability of the radio link layer, especially as data rates and service demands increased with HSPA, LTE, and 5G. By incorporating RSN, the protocols could support more sophisticated retransmission strategies, including incremental redundancy (where retransmissions send complementary encoding) and adaptive retransmission based on count. It also facilitates clearer status reporting (e.g., in RLC status reports) and better radio resource management. Ultimately, RSN is a key component enabling the high reliability and quality of service that modern cellular data services provide, even under challenging radio conditions.

Classification

Part ofHARQ

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (117 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-6, normative work from Rel-15.

Rel-15 28 changes

In Release 15, the RSN function was enhanced to manage retransmissions for specific 5GS session management procedures. This included defining mechanisms for the retransmission of PDU SESSION ESTABLISHMENT REQUEST, PDU SESSION MODIFICATION REQUEST, and PDU SESSION RELEASE REQUEST messages. These additions ensure reliable delivery and handling of these critical session control signals between the UE and the network.

  • How to determine the maximum number of established PDU sessions TS 24.501CR0077
  • Addition of the extended emergency number list in AT-command +CEN TS 27.007CR0564
  • Complete of IMS Emergency support in 5G including slice and local numbers TS 23.501CR0052
  • Number of packet filters supported by UE TS 23.501CR0481
  • Pass (Extended) Emergency Number List to upper layers TS 24.501CR0003
  • Adding procedures for updating local emergency numbers in other modes TS 24.501CR0272

+ 22 more changes

Rel-16 17 changes

In Release 16, the RSN (Retransmission Sequence Number) function was introduced as the "Redundancy Sequence Number for Dual Connectivity based end to end Redundant User Plane Paths." This enhancement specifically supports redundant data transmission over dual connectivity paths by providing a sequence number to manage retransmissions and ensure packet ordering. It is a key component for enabling reliable, low-latency communication through redundant user plane paths.

  • IMS related P-CSCF procedures, setting flow status and flow number TS 29.514CR0118
  • Awareness of UE PMF port number and MAC address in UPF TS 23.501CR1469
  • Number of EBIs TS 23.501CR1941
  • Fix terminology on maximum number of CAGs per cell instead of per NG-RAN node TS 23.501CR2217
  • Updates to N4 for NW-TT port number reporting TS 23.501CR2511
  • Correction of typos in octet numbering for AMF Set ID TS 24.501CR1038

+ 11 more changes

Rel-17 42 changes

In Release 17, the RSN (Retransmission Sequence Number) function was enhanced to support the association of a PDU session with a PDU Session Pair ID and RSN, enabling more sophisticated session management. This capability was also integrated into the URSP (UE Route Selection Policy) rule framework, allowing the network to provide routing policies based on these identifiers. These additions facilitate improved handling of specific PDU session pairs, particularly for scenarios requiring coordinated retransmission or redundancy.

  • S-NSSAI rejected due to maximum number of UEs reached and BO timer value TS 24.501CR3123
  • Maximum number of established PDU sessions already reached for a NW slice TS 24.501CR3213
  • PDU session associating with PDU session pair ID and RSN TS 24.501CR3919
  • Support of RSN and PDU Session Pair ID in the URSP Rule TS 29.525CR0181
  • Clarification on the number of Subscribed S-NSSAIs TS 23.501CR2945
  • Indicate the number of supported packet filters for signalled QoS rules only if the UE supports more than 16 packet filters for the PDU session TS 23.501CR3222

+ 36 more changes

Rel-18 26 changes

In Release 18, the RSN function was not a primary focus of the specified enhancements. The provided CR titles and grounding context indicate that Release 18 work concentrated on other areas, such as refinements to Network Slice-Specific Authentication and Authorization (NSAC) procedures, clarifications on handling the maximum number of UEs and PDU sessions per network slice, and corrections to parameters like the maximum number of S-NSSAIs in various NSSAI information elements. Therefore, no specific update to the Retransmission Sequence Number (RSN) function is described in the given materials for this release.

  • Reference point numbers for charging TS 23.501CR3752
  • Update to Annex O to correct referenced clause number and add an optional condition for setup of the QoS flow TS 23.501CR4541
  • Equivalent SNPNs: NSSAIs, network-assigned UE radio capability ID, maximum number of established PDU sessions and 5GMM parameters in annex C stored per selected entry TS 24.501CR5027
  • Number of S-NSSAIs in Partially Allowed NSSAI TS 23.501CR4586
  • Clarifications on NSAC for maximum number of UEs with at least one PDU SessionPDN Connection TS 23.501CR4839
  • Move text on providing a back-off timer to the UE during NSAC for maximum number of PDU Sessions TS 23.501CR5062

+ 20 more changes

Rel-19 4 changes

In Release 19, the RSN function was enhanced to allow the UPF to provide the NATed public UE IP address and port number to a Network Function consumer via the event exposure service, based on the UE's private IP address. This enables functions like AF-specific UE identification and EAS relocation support using IP address and port number replacement information. The mechanism leverages the existing `Nupf_GetUEPrivateIPaddrAndIdentifiers` service for retrieval.

  • Enhancement of getting public UE IP address and port number TS 23.501CR5445
  • Correction of faulty bit number for NSAG TS 24.501CR6617
  • On the order of sequence of new subclauses in layer 3 message descriptions TS 24.501CR6800
  • Correction to the maximum number of reference to QosMonitoringData TS 29.512CR1425

Explore further

Broader topics and technologies where RSN plays a role.

Topics
MEC (Edge Computing)LTE / LTE-Advanced5G NR (New Radio)Lawful InterceptIoT & MTCManagement & Operations
Technologies
LTE5G

Defining Specifications

3GPP specifications that define or reference RSN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 23.725 vg20 Study on URLLC Architecture Enhancements Rel-16
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 24.526 vj30 UE Policies for 5GS; Stage 3 Rel-19
TS 25.222 vj00 UTRA TDD Multiplexing & Channel Coding Rel-19
TS 25.309 v1600 FDD Enhanced Uplink Support Rel-6
TS 25.319 vj00 Enhanced Uplink for UTRA FDD/TDD Rel-19
TS 25.321 vj00 MAC Protocol Specification for UTRAN Rel-19
TS 25.331 vj00 UTRAN RRC Protocol Specification Rel-19
TS 25.705 vd00 UMTS Small Data Transmission Enhancements Study Rel-13
TS 27.007 vj40 AT Command Set for UE Rel-19
TS 29.502 vj50 5G System; Nsmf Service Based Interface; Stage 3 Rel-19
TS 29.512 vj40 5G Session Management Policy Control Service Rel-19
TS 29.514 vj40 5G System; Policy Authorization Service; Stage 3 Rel-19
TS 29.525 vj40 5G UE Policy Control Service Stage 3 Rel-19
TS 29.561 vj30 5G Interworking with External Data Networks Rel-19
TS 38.413 vj10 NG Application Protocol (NGAP) Rel-19
TS 38.423 vj10 Xn Application Protocol (XnAP) specification Rel-19
TS 48.018 vj00 BSS-SGSN Interface for GPRS Control Rel-19