Description
Frame Loss Ratio (FLR) is a fundamental performance parameter within the 3GPP Quality of Service (QoS) framework, specifically for conversational and streaming traffic classes. It quantifies the reliability of a packet data flow by calculating the ratio of lost frames to the total number of frames expected within a specific measurement period. A 'lost frame' is typically defined as a packet that does not arrive at the receiver within a maximum allowed transfer delay, or a packet that arrives but is too corrupted to be used. This metric is essential for applications sensitive to packet loss, such as Voice over IP (VoIP), video conferencing, and live streaming, where lost packets directly degrade perceived audio/video quality.
Architecturally, FLR is monitored end-to-end between defined measurement points, often between the user equipment (UE) and a peer entity like a media server or another UE. The 3GPP specifications define the methodologies and protocols for measuring FLR. For instance, in the IP Multimedia Subsystem (IMS), FLR can be measured using Real-time Transport Protocol (RTP) control protocol (RTCP) reports exchanged between endpoints. These reports carry statistics on packets sent, packets lost, and jitter, allowing each end to compute the FLR experienced in the reverse direction. Network elements like the Policy and Charging Rules Function (PCRF) and Policy and Charging Enforcement Function (PCEF) may also use FLR metrics to make dynamic policy decisions, such as adjusting bearer characteristics or triggering corrective actions.
FLR works in conjunction with other QoS parameters like packet delay budget and packet error rate to define a QoS Class Identifier (QCI). Each standardized QCI has associated target values for these parameters, including FLR. For example, a QCI for conversational voice has a very low packet delay budget and a low FLR target to ensure clear, uninterrupted speech. The network uses these QCI profiles to appropriately prioritize traffic, allocate resources, and apply error correction mechanisms. Monitoring FLR allows operators to verify that the network is meeting these guaranteed performance levels, perform root cause analysis for quality degradation, and optimize network configuration for improved service delivery.
Purpose & Motivation
The creation of the Frame Loss Ratio metric was motivated by the transition from circuit-switched to packet-switched networks for real-time communication services. In traditional circuit-switched voice, quality was inherently high and consistent due to dedicated channels. However, packet-switched networks like those based on IP introduce variable delay, jitter, and packet loss due to congestion, routing changes, and transmission errors. To enable commercial deployment of services like VoIP and video telephony over these networks, a standardized, objective measure of data loss was necessary to define, sell, and monitor service quality.
FLR addresses the problem of quantifying service degradation in a way that correlates directly with user perception. For multimedia codecs, losing packets results in gaps, clicks, frozen video frames, or blurry images. By defining FLR, 3GPP provided a common language for equipment vendors, network operators, and service providers to specify performance requirements, conduct interoperability testing, and implement QoS management systems. It solved the limitation of previous approaches that might only measure raw packet loss without considering the application-layer framing or the timing constraints critical for real-time media. FLR forms the basis for Service Level Agreements (SLAs), allowing operators to guarantee a certain level of performance and providing a clear metric for troubleshooting and customer care when quality issues arise.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (3 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-18.
In Release 18, the FLR (Frame Loss Ratio) function was enhanced through the introduction of RTCP-APP signalling for Redundancy Request and Processing Information (PI), which supports speech adaptation for call cases where RTP-based Codec Mode Requests cannot be used. This is specifically required for MTSI clients supporting EVS, and its use mandates the offering of the AVPF profile for speech media streams. Additionally, corrections and IANA registrations were made for related RTCP feedback formats, such as for Viewport.
Explore further
Broader topics and technologies where FLR plays a role.
Defining Specifications
3GPP specifications that define or reference FLR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 26.114 vj10 | IMS Multimedia Telephony Media Handling | Rel-19 |
| TS 44.318 vj00 | Generic Access Network (GAN) Interface Procedures | Rel-19 |