UE delay in receiving direction

Description

TR, formally defined as 'UE delay in receiving direction,' is a fundamental Quality of Service (QoS) performance metric standardized across numerous 3GPP technical specifications. It quantifies the packet transfer delay specifically in the downlink direction—from a network application server (or a reference point within the core network) to the User Equipment (UE). This delay is an end-to-end measurement, encompassing all processing, queuing, transmission, and propagation latencies incurred as a packet traverses the core network, the Radio Access Network (RAN), and the air interface before being successfully delivered to the UE's application layer. The measurement is typically defined for a specific QoS Flow or bearer, reflecting the performance experienced by a particular service data stream.

The measurement methodology for TR is carefully defined to ensure consistency. It involves time-stamping packets at a defined measurement point, often at the ingress of the core network (e.g., at the User Plane Function - UPF) or at a service endpoint. A corresponding time-stamp or acknowledgment is captured when the packet is successfully received and processed by the target application on the UE. The difference between these timestamps yields the TR value. In practice, this is often measured statistically, reporting values like the 95th or 99th percentile delay to characterize the worst-case latency experienced by most packets, which is more relevant for service guarantees than average delay. The UE or network elements may collect these measurements and report them to management systems like the Network Data Analytics Function (NWDAF) or Operation, Administration, and Maintenance (OAM) systems for performance monitoring and assurance.

TR plays a central role in the 3GPP QoS architecture. It is directly linked to QoS Class Identifier (QCI) and 5G QoS Identifier (5QI) values, which define standardized packet forwarding behaviors. For example, a 5QI value for Ultra-Reliable Low-Latency Communication (URLLC) services will have a stringent associated TR requirement (e.g., a maximum of a few milliseconds). The network uses these requirements to make resource management decisions. The RAN scheduler, aware of the QoS profile of a bearer, can prioritize packets belonging to flows with tight TR constraints, granting them immediate radio resources, using shorter transmission time intervals (TTIs), or employing more robust modulation and coding schemes to reduce retransmissions. Thus, TR is not just a measurement but a service-level objective that drives real-time radio and network resource allocation to ensure user experience for delay-critical applications.

Purpose & Motivation

The concept and precise definition of UE delay in receiving direction (TR) have been integral to 3GPP standards since the early releases to address the fundamental challenge of managing and guaranteeing service quality in packet-switched networks. As cellular networks evolved from circuit-switched voice (where delay was inherently controlled) to all-IP networks carrying diverse services, a standardized way to quantify and specify delay became essential. Different applications have vastly different tolerance to latency; interactive voice and video require low delay, while email or file downloads are less sensitive. Without a standardized metric like TR, it would be impossible to define clear service level agreements (SLAs), design effective QoS mechanisms, or objectively compare network performance.

Its ongoing evolution through every 3GPP release underscores its critical importance. Each new generation of technology (3G, 4G, 5G) and new service category (e.g., MBB, MTC, URLLC) introduced more stringent and varied delay requirements. TR provides the common yardstick. For 4G LTE, it was key for defining QoS for Voice over LTE (VoLTE). For 5G, it is absolutely central to enabling mission-critical services like factory automation, remote surgery, and autonomous vehicle control, where millisecond-level delays are non-negotiable. The purpose of TR is thus to translate abstract service requirements ('low latency') into concrete, measurable technical parameters that can be engineered into the network architecture, used for performance validation, and enforced by QoS control mechanisms, ensuring the network can deliver on its promises for both existing and future latency-sensitive applications.