Problem Statement and Gap Analysis of Fine-Grained QoS Assurance for 6G Scenarios

Introduction The evolution from 5G to 6G introduces a new class of applications that require fundamentally different QoS characteristics. Applications such as holographic communications, tactile internet, digital twins, and semantic communications demand per-packet differentiation, deterministic latency bounds, and multi-flow synchronization capabilities that go far beyond the design scope of the current 5G 5QI framework. In this context, 3GPP has already initiated studies on QoS extension mechanisms for 6G scenarios. In [TR23801], Key Issue #5 (KI#5) specifically addresses the 6G QoS framework, using the 5G QoS framework as a baseline to investigate whether and what new functionalities are needed, including support for dynamic QoS requirements, QoS collaboration among the UE, application, and network, and enhanced QoS monitoring mechanisms. Solution variants under KI#5 cover aspects such as QoS flows with dynamic QoS requirements, a collaboration layer between UE/application and UPF via user plane signalling, and differentiated QoS handling for multiplexed media flows. These ongoing efforts indicate that 3GPP is moving from the static, network-centric 5G QoS model toward a more flexible and application-aware 6G QoS framework. Meanwhile, transport networks, including backhaul and core segments, have made significant advances in QoS technologies. Technologies such as FlexE hard slicing, Deterministic Networking (DetNet), Time-Sensitive Networking (TSN), PQ/WFQ scheduling, and SRv6 Traffic Engineering policies can now achieve per-packet scheduling with microsecond-level precision and mathematically provable latency bounds. However, a critical disconnect remains: transport networks possess fine-grained QoS enforcement capabilities, but but lack the service awareness to determine the required treatment level for each packet, flow, or other object in 6G services, which may demand richer QoS requirement information than what current mechanisms can convey. The current 5QI-to-DSCP mapping mechanism compresses rich service requirements into a small set of codepoints, losing critical information needed for per-packet differentiation. Moreover, between the Radio Access Network (RAN) and the transport domain, there is no established mechanism to synchronize richer service attributes. This document aims to:

Analyze the gap between 6G application requirements and the current 5QI QoS framework;
Demonstrate that transport networks already possess sufficient technical capability for fine-grained QoS assurance, but lack the necessary service awareness input from the radio side;
Identify the missing cross-domain information synchronization mechanism;

It is important to clarify that the mechanisms discussed in this document, such as 5QI, DSCP mapping, and existing transport network QoS techniques, are not intended to be replaced. Rather, the gaps identified here reflect enhancements needed when relying solely on these mechanisms without cross-domain information sharing, particularly for emerging 6G use cases.

Abbreviations

6G Scenario Description and Derived QoS Requirements

Representative 6G Scenarios Holographic/Immersive Communications: Real-time holographic telepresence requires simultaneous transmission of multiple volumetric video streams. Each stream contains frames with varying importance (key frames vs. delta frames), and all streams must be synchronized within sub-millisecond jitter bounds. Per-packet latency requirements range from 1 ms to 10 ms depending on the frame type. Tactile Internet: Remote robotic surgery and industrial haptic feedback loops require ultra-low latency (sub-millisecond) with deterministic bounds and zero packet loss. Unlike traditional best-effort traffic, haptic feedback packets carry explicit timing constraints that must be honored by every network element along the path. Digital Twins: Real-time synchronization between physical entities and their digital counterparts generates mixed-criticality traffic. High-priority control commands must be delivered with guaranteed latency, while lower-priority telemetry data can tolerate moderate delays. The network must differentiate packets not just by flow but by individual packet importance within the same flow. Semantic Communications: Next-generation communication systems that transmit meaning rather than raw bits introduce variable-length, semantically compressed packets. The QoS treatment depends not on packet size or flow identity but on semantic importance - a property that cannot be expressed by current 5QI values.

Extra QoS Attributes for 6G From the above scenarios, we derive the following QoS attributes that go beyond current 5QI definitions: The above attributes are not fully covered by the current 5QI framework. 5QI is essentially a scalar index pointing to a set of pre-configured flow-level QoS templates; its design granularity is "one template per QoS flow", rather than "one policy per packet". Although the 5QI value space still has remaining values, expanding the number of standardized 5QI values can only increase the variety of available flow-level templates. It cannot address three fundamental issues: intra-flow differentiation, dynamic QoS adjustment, and QoS dimensions that do not exist in the current templates at all (e.g., semantic importance, inter-packet dependency relationships, and compute-coordination parameters). Therefore, 6G QoS enhancements are considering retaining 5QI as the basic flow-level classification mechanism while introducing supplementary parameters or signaling mechanisms used in parallel with 5QI (such as the QoS Tag approach studied in [TR 23.801]), so as to carry the fine-grained, dynamic, and multi-dimensional service QoS requirements that 5QI templates cannot express.

Problem Statement

Limitations of DSCP-Based QoS Mapping for 6G Services in Transport Networks The 5G QoS model is built around the 5G QoS Identifier (5QI), a scalar value that indexes a set of pre-configured QoS characteristics including resource type (GBR / Non-GBR / Delay-Critical GBR), priority level, packet delay budget, and packet error rate [TS23501]. 5QI values range from 0 to 255. The standardized 5QI values are listed in Table 5.7.4-1 of [TS23501] (currently the ranges 1-10, 65-67, 69-76, 79-80, and 82-90); values 128 to 254 are available for operator-specific use, and the remaining values are reserved. DSCP +----------------+ QER(DSCP) +----------------| wireless core |--------------+ | | network | | | | (5GC) | | | +----------------+ | +--v--+ +--v--+ | gNB | <---------------QoS flow---------------> | UPF | +--*--+ +--*--+ | | | 5G DSCP <--------> TN DSCP <-------> 5G DSCP | | +---------------------------+ | +---------->| IP Transport Network |<-------+ uplink data | (Backhaul) | downlink data +---------------------------+ Figure 1: DSCP mapping between 5G network and IP transport network ]]> However, when 5G QoS requirements are conveyed into the transport network, including the backhaul and core segments, the 5QI information is compressed through a mapping to the Differentiated Services Code Point (DSCP) [RFC2474]. DSCP is a 6-bit field in the IP header, capable of conveying only 64 distinct codepoints. The codepoint space is divided into three pools: a pool of 32 recommended codepoints (Pool 1) assigned by Standards Action, a pool of 16 codepoints (Pool 2) reserved for experimental or local use, and a pool of 16 codepoints (Pool 3) originally specified for experimental use but now utilized for standardized assignments [RFC8436]. In the 5G architecture, for every QoS Flow, the SMF determines the transport-level packet marking value (e.g., the DSCP in the outer IP header) based on the 5QI, the Priority Level (if explicitly signalled), and optionally the ARP priority level, and provides this value to the UPF [TS23501]. This mapping is a many-to-one compression: multiple 5QI values with distinct QoS characteristics may be mapped to the same DSCP codepoint. [RFC8325] makes an analogous observation for the mapping from DSCP to the 3-bit IEEE 802.11 User Priority: "information is lost in the translation from a 6-bit marking to a 3-bit marking" - a principle that applies with even greater force when the rich, multi-dimensional 5QI parameter set is compressed into a single 6-bit value. The 5QI carries information about resource type, priority, delay budget, and error rate, but the DSCP field can only convey a small number of aggregated forwarding treatment classes. Once the mapping is performed, the transport network has no way to recover the original 5QI parameters or to differentiate between flows that share the same DSCP but have different underlying QoS requirements. Meanwhile, transport networks have made significant advances in QoS enforcement technologies. Technologies such as FlexE hard slicing, Deterministic Networking (DetNet), Time-Sensitive Networking (TSN), PQ/WFQ scheduling, and SRv6 Traffic Engineering policies can now achieve per-packet scheduling with microsecond-level precision and mathematically provable latency bounds. These enforcement capabilities are far more granular than what DSCP-based forwarding treatment alone can express. However, a critical disconnect remains: transport networks possess fine-grained QoS enforcement capabilities, but lack the service awareness to determine what level of treatment is required for each packet, flow, or other object in 6G services. This disconnect becomes particularly problematic as 6G scenarios introduce QoS requirements that cannot be adequately conveyed through the DSCP mechanism. The following analysis examines four dimensions in which the DSCP-based mapping falls short.

Granularity Limitation: Codepoint Scarcity Cannot Encode Rich 5QI Characteristics The DSCP field's 6-bit width imposes a hard upper bound of 64 codepoints, and in practice many of these are already assigned or reserved. Even before considering 6G requirements, the mapping of the full set of 5QI values to DSCP involves significant aggregation: distinct 5QI values that differ in packet delay budget, packet error rate, or resource type may be collapsed into a single DSCP codepoint. For 6G services, this aggregation loss becomes unacceptable. XR and holographic applications, for example, require per-packet differentiation within a single QoS flow: I-frames demand extremely high reliability, while P/B frames can tolerate higher loss rates. The 5QI-to-DSCP mapping, being a flow-level and many-to-one operation, cannot convey such intra-flow packet-level distinctions to the transport network. Even 3GPP's introduction of PDU Set concepts in Release 18 [TS23501], defining PDU Set Delay Budget (PSDB) and PDU Set Error Rate (PSER), represents a move toward set-level granularity but remains insufficient for true per-packet differentiation. In [TR23801], Solution variant #5.4 explicitly addresses "applying dynamic QoS per time interval or per packet", and Solution #43 proposes "Finer Packet Filters to enforce QoS Differentiation", indicating that 3GPP itself recognizes the need to move beyond flow-level and DSCP-based granularity. The DSCP mechanism, however, has no capability to carry such finer-grained information into the transport domain.

Timeliness Limitation: Static Codepoint Semantics Cannot Express Dynamic QoS Requirements DSCP is a static marking: once a packet is marked with a particular codepoint, the per-hop behavior it receives is determined by the network's pre-configured PHB associations. The codepoint itself carries no indication that the packet's QoS requirements may change over time. In 6G scenarios, QoS requirements are highly dynamic. In immersive communication, when a user's head rotates and the field of view (FOV) changes, data inside the FOV requires high-priority treatment while data outside the FOV can be degraded - a change that occurs on millisecond timescales. In integrated sensing and communication, the detection of an abnormal event may cause the latency requirement for control commands to drop from 10 ms to 1 ms instantaneously. AI-agent-driven communication allows the terminal-side AI agent to sense local context and dynamically request QoS adjustments. The 5QI-to-DSCP mapping is established at session setup or QoS flow modification and cannot be updated on a per-packet basis without control-plane signaling, which introduces unacceptable latency. Even the dynamic QoS solutions being studied in [TR23801] (e.g., Solution variant #5.4 for dynamic QoS requirements) assume that the RAN and core network can update QoS parameters in real time, yet the transport network, which relies on DSCP, has no corresponding mechanism to receive and act on such updates.

Expression Dimension Limitation: Single Scalar Cannot Carry Multi-Dimensional QoS Semantics The DSCP field is a single scalar value. It cannot express multi-dimensional QoS semantics. Yet 6G services introduce new QoS dimensions that have no representation in the 5G QoS framework at all, let alone in the 6-bit DSCP field. Semantic importance in semantic communication requires the network to differentiate forwarding treatment based on the semantic significance of data packets, a dimension entirely distinct from the existing 5QI parameters. Inter-packet dependency relationships, such as reference relationships in video coding or dependency graphs in distributed AI inference, require the transport network to be aware that the loss of one packet may invalidate a set of dependent packets downstream. Compute-coordination parameters in integrated communication-computing scenarios may require packets to carry deadline or compute-resource requirements for associated computation tasks. Multi-modal stream synchronization requirements in XR demand strict temporal alignment across video, audio, and haptic streams. None of these dimensions can be encoded in a 6-bit scalar. The DSCP mechanism does not merely lack the resolution to distinguish among 6G services. It lacks the dimensionality to represent the QoS information that 6G services require.

Systemic Limitation: QoS Enforcement Capability Exists but Cannot Be Activated The most consequential aspect of this disconnect is that transport networks already possess fine-grained QoS enforcement capabilities that remain underutilized precisely because the DSCP-based mapping cannot activate them. FlexE hard slicing can provide strict bandwidth guarantees and physical isolation. DetNet and TSN can provide deterministic latency bounds and jitter control. SRv6 Traffic Engineering policies can steer flows along paths with specified performance characteristics. These mechanisms operate at much finer granularity than DSCP-based per-hop behavior. They can enforce per-flow, per-class, or even per-packet scheduling decisions with microsecond precision. However, to invoke these mechanisms for a specific 6G service, the transport network needs to know the service's QoS requirements in sufficient detail to select the appropriate enforcement policy. The DSCP codepoint, carrying at most 6 bits of aggregated information, is insufficient to drive this selection process. The transport network therefore has the capability to deliver fine-grained QoS, but lacks the service-aware input required to configure and invoke those capabilities. This is not a limitation of transport QoS technology. It is a limitation of the information interface between the radio/core domain and the transport domain.

Summary In summary, the problem is not that DSCP is intrinsically incapable of conveying any QoS information, nor is it that 5QI is inadequate as a QoS specification framework. The problem is that the 5QI-to-DSCP mapping constitutes an information bottleneck: it compresses a multi-dimensional, dynamically adjustable, and fine-grained QoS specification into a 6-bit scalar with static semantics. For 5G services with relatively uniform QoS requirements, this compression may be tolerable. For 6G services, which require per-packet differentiation, dynamic QoS adjustment, multi-dimensional QoS semantics, and activation of transport-layer fine-grained enforcement mechanisms, the compression is fundamentally lossy in ways that cannot be compensated by simply expanding the codepoint space or adding more standardized 5QI values. A 6G QoS framework that continues to rely on DSCP as the sole carrier of QoS information into the transport network will systematically underutilize the transport network's enforcement capabilities and fail to deliver the end-to-end QoS assurance that 6G applications demand.

Transport Network QoS Capabilities Unlike traditional Differentiated Services Code Point (DSCP) mechanisms, modern Transport network transport networks have evolved to support a variety of fine-grained Quality of Service (QoS) assurance technologies. Rather than relying on statistical multiplexing across a shared set of eight DSCP queues per port, these technologies employ mechanisms such as hard-isolation channels, resource-reserved partitions, explicit path steering, and slice identifier mapping. These mechanisms enable end-to-end transport capabilities with dedicated bandwidth, bounded latency, and controlled jitter across Layer 1.5, Layer 2, and Layer 3. The following subsections detail the specific capabilities of these technologies.

FlexE/MTN Hard Slicing (L1.5) FlexE/MTN Hard Slicing: FlexE [OIF-FLEXE] introduces a Shim layer between the Ethernet MAC and PHY, dividing the physical interface bandwidth into N x 5 Gbps timeslots to achieve interface-level hard isolation. On this basis, MTN [G8310] adds an MTN Section segment layer and an MTN Path channel layer, supporting 64B/66B block-level timeslot cross-connection, end-to-end OAM, and protection switching, thereby forming a networkable hard-sliced channel.

Granularity of QoS Guarantee: FlexE provides coarse-grained N x 5 Gbps timeslots. MTN offers end-to-end hard-sliced channel transport at the path layer, while its finer sub-timeslot division at the Mbps level is handled by fine-granularity slicing (fgMTN/FGU), described in Section 4.2.2.
QoS Guarantee Mechanism: Based on 64B/66B code block timeslot partitioning at the Physical Coding Sublayer (PCS) and a TDM switching fabric, traffic bypasses the MAC/IP packet forwarding path, achieving dedicated bandwidth, deterministic low latency, and hard pipe isolation. The MTN path layer further provides connectivity check, performance monitoring, and 1+1 protection capabilities.
QoS Improvement over DSCP:
- FlexE/MTN upgrades traditional DSCP queue-based statistical multiplexing to physical-layer hard slicing isolation, allowing high-priority services to occupy dedicated bandwidth channels that are largely unaffected by BE/ToC burst traffic.
- MTN further provides end-to-end channelized transport and carrier-grade protection, making it suitable for services with strict isolation and protection requirements, such as enterprise private lines and power production control.

Fine-Grained Slicing (L1.5) Fine-Grained Slicing: Based on 64B/66B code block flows, coarse-grained MTN/FlexE slicing channels are further divided into fixed sub-time-slots at the Mbps level [G8312-20]. This provides end-to-end hard-isolation transport with dedicated bandwidth, deterministic low latency, and microsecond-level jitter.

QoS Granularity: N x 10 Mbps (based on the FGU base frame, providing 10 Mbps granularity hard-slicing channels).
QoS Assurance Mechanism: Building upon coarse-grained FlexE/MTN hard slicing, sub-time-slot cross-connection is introduced. This provides TDM-level hard-isolation channels for low-bandwidth services, such as sub-gigabit enterprise/government dedicated lines and 5G slice transport. The allocated bandwidth is strictly dedicated and cannot be preempted by other slices.
QoS Improvements over DSCP:
- It extends user-level hard slicing for Business-to-Business (2B) services over coarse-grained MTN pipes, achieving Mbps-level dedicated bandwidth. This fills the capability gap between 5 Gbps coarse-grained FlexE and IP queue statistical multiplexing, providing an SDH-like deterministic experience with guaranteed low packet loss and microsecond-level jitter.
- Link-level slicing capacity is increased from dozens of coarse-grained channels to thousands (K-level) of fine-grained channels, supporting finer multi-tenant isolation and differentiated QoS transport.

Channelized Sub-interfaces (L2) Channelized Sub-interfaces: Multiple logical sub-interfaces are partitioned on a physical port, with each sub-interface bound to independent bandwidth, queuing, and scheduling resources, thereby achieving interface-level resource-reserved slicing.

QoS Granularity: Sub-interface level. The bandwidth granularity is typically at the Mbps level, depending on the underlying link capacity and Hierarchical QoS (HQoS) configuration.
QoS Assurance Mechanism: Through the partitioning of multiple sub-interfaces on a physical port, independent bandwidth and scheduling queues are reserved for each sub-interface, achieving resource-reserved (semi-hard) isolation. This mechanism is applicable to link scenarios lacking FlexE/MTN hard-slicing capabilities, providing coarse-grained slicing transport.
QoS Improvements over DSCP:
- It compensates for the slicing capability gap in non-FlexE/MTN links, enabling coarse-grained slicing transport across all scenarios (including traditional Ethernet and non-FlexE optical ports).
- It expands the shared eight DSCP queues on a traditional port into independent queue sets for each sub-interface. This increases the total available queue resources and bandwidth utilization on the port, preventing resource contention among different services within the same queue set.

SRv6 Policy / NRP (L3) SRv6 Policy and Network Resource Partition (NRP): Based on IPv6 Segment Routing [RFC8986], explicit path control with SLA constraints is achieved [RFC9256], and through NRP [RFC9543], the bandwidth and queue resources of physical links are divided into independent partitions. SRv6 TE Policy is responsible for mapping service flows to customized paths that meet delay, packet loss, and bandwidth constraints; NRP is responsible for implementing queue and bandwidth resource isolation on the outbound interfaces at each hop along the path. Together, they form an L3 bearer architecture combining "path selection + per-hop resource guarantee."

QoS Granularity: Traffic steering is performed based on traffic groups identified by Color + Forward Class, with granularity covering VPN, user, and application-level flows. NRP-level resource partitions can be further mapped to different NRPs according to users or service flows. The data-plane NRP Selector ID is typically 13 bits, while the control-plane NRP ID is 32 bits.
QoS Assurance Mechanism: At the control plane, candidate paths of SR Policies are associated with NRPs via BGP SR Policy, PCEP, or IGP extensions. At the data plane, two implementation approaches exist: first, using the End.NRP SID to bind each SID in the segment list to a specific NRP, when a packet arrives at that SID, it is forwarded according to the associated queue resources; second, the packet carries an NRP Selector ID, and the outbound interface maps this identifier to an independent HQoS queue and reserved bandwidth under an L3 sub-interface. Candidate paths within a policy can be selected based on constraints such as NRP, Flex-Algo, delay, and bandwidth.
QoS Improvements over DSCP:
- Instead of relying on eight shared DSCP queues on a port, independent queues and bandwidth are reserved for different NRPs, achieving reservation-based (semi-hard) isolation.
- Supports cross-domain deployment, where different users, VPNs, or application flows can be mapped to different NRPs, enabling end-to-end user-level KPI assurance.
- Can work in coordination with FlexE/MTN hard slicing, FGU fine-granularity slicing, or channelized sub-interfaces, forming a hierarchical QoS architecture of "NRP service-level partitioning + underlying hard slice resource isolation".

SRv6 Source Address Fine-Grained Slicing (L3) SRv6 Source Address Fine-Grained Slicing (L3): A Slice ID is carried in the source address (or HBH extension header) of an IPv6 packet, enabling forwarding devices to identify the slice instance to which the packet belongs on a per-hop basis and map it to the corresponding network slice channel and independent queue resources. This mechanism does not define a new resource isolation method but rather provides a data-plane identification means for NRP/slice resources without requiring additional packet headers, reducing forwarding processing overhead.

QoS Granularity: Slice-instance level, with bandwidth granularity depending on the underlying bearer channel (e.g., 1 Mbps level), capable of covering individual users, single service flows, or single applications.
QoS Assurance Mechanism: The Slice ID is carried in the lower-order bits (e.g., the lower 28 bits) of the SRv6 source address or in the HBH extension header. The device maps packets to pre-provisioned network slice channels or Flex-channels on the interface based on the Slice ID, with each slice channel having independent queues and reserved bandwidth. The Slice ID is typically associated with an SRv6 TE Policy: the Policy determines the path, while the Slice ID identifies on the data plane which slice resources should be used for that path. It can be combined with ePBR or Flowspec for refined traffic steering.
QoS Improvements over DSCP:
- Independent slice channels are allocated for each user or service on top of traditional port queues, achieving bandwidth reservation and latency guarantees without requiring hardware parsing of additional extension headers, thus minimizing impact on forwarding performance.
- Bandwidth granularity is flexible, ranging from Mbps to 10 Gbps as needed, covering scenarios from small-bandwidth enterprise private lines to large-bandwidth dedicated lines.
- Existing network equipment can be smoothly upgraded to support this feature as long as it supports H-QoS, SRv6, and sufficient queue resources, without requiring modifications to the underlying physical links.

Service Awareness Asymmetry and the Cross-Domain QoS Consistency Gap The previous sections have established two facts: (1) transport networks possess powerful fine-grained QoS enforcement capabilities, such as FlexE hard slicing, FGU, and SRv6 Traffic Engineering policies; and (2) the current 5QI-to-DSCP mapping compresses rich service QoS requirements into a small set of codepoints, resulting in significant information loss. This section addresses a third, equally fundamental issue: the asymmetry in service awareness between the radio access domain and the transport domain. The radio access domain can obtain detailed service information through interactions with the UE, application servers, and core network functions, whereas the transport domain receives only a coarse DSCP marking and has no means to actively perceive the QoS requirements of the service flows it carries. This asymmetry creates a cross-domain QoS consistency gap: fine-grained QoS assurance in the radio domain degrades into coarse-grained QoS treatment in the transport domain, and end-to-end QoS assurance for 6G services is substantially undermined.

Service Awareness in the Radio Access Domain In the 5G system, the access and core network domain, comprising the UE, RAN, and core network functions such as SMF, PCF, and NEF, has access to rich service-level information. The SMF receives QoS requirements from the PCF based on policy decisions, subscription information, and application-provided requirements. The PCF may obtain application-specific QoS requirements from the Application Function (AF) via the NEF, or directly from the AF when trusted. The UE can signal its own QoS preferences or context information through NAS signaling or application-layer interactions. For 6G, this service awareness is expected to become even richer: the UE-side AI agent may sense local context (traffic type, sensor input, user experience KPIs) and dynamically request QoS adjustments; the network may interact with application servers to obtain semantic importance, dependency relationships, or compute-coordination parameters. As a result, the radio access domain can construct a detailed, multi-dimensional, and dynamically adjustable QoS profile for each service flow or even each packet. It can then enforce this profile through 5QI, QoS flow parameters, PDU Set handling, and other radio-level mechanisms.

Passive QoS Reception in the Transport Domain In contrast, the transport domain is largely passive with respect to service QoS information. It does not interact with the UE, the application server, or the core network's policy functions. Instead, it relies on the DSCP marking carried in the IP header of each packet. This marking is determined by the UPF based on the 5QI-to-DSCP mapping, as described in Section 4.1. The transport network has no independent means to discover the service type, the application's QoS requirements, the semantic importance of the data, the dependency relationships among packets, or the dynamic changes in QoS needs. It can only apply pre-configured Per-Hop Behaviors (PHBs) associated with the received DSCP codepoint. Even when the transport network is equipped with advanced QoS enforcement mechanisms such as DetNet or TSN, it cannot activate them in a service-specific manner because it lacks the necessary service-aware input. The transport domain is therefore not a participant in the end-to-end QoS negotiation; it is merely a passive executor of a coarse-grained marking.

The Cross-Domain QoS Consistency Gap The asymmetry described above creates a cross-domain QoS consistency gap. On the radio side, the network may have determined that a particular video frame is an I-frame requiring PER <= 10^-6, or that a control command for a tactile application requires a 1 ms latency bound. However, when the packet enters the transport domain, this rich information is reduced to a single DSCP codepoint. The transport network may treat this packet with the same PHB as many other packets that share the same DSCP but have entirely different QoS requirements. The fine-grained QoS assurance policy configured in the radio domain is thus not consistently reflected in the transport domain. The end-to-end QoS path becomes a concatenation of a fine-grained radio segment and a coarse-grained transport segment, with no mechanism to ensure that the transport segment can deliver the treatment that the radio segment assumes. This is not a failure of transport QoS technology; it is a failure of cross-domain information exchange.

Impact on End-to-End QoS Assurance for 6G Services For 6G services, the impact of this gap is severe. Holographic communications, tactile internet, digital twins, and semantic communications require per-packet differentiation, deterministic latency bounds, and multi-flow synchronization across the entire end-to-end path. If the transport domain cannot receive and act upon the rich QoS requirements that the radio domain has negotiated, then the end-to-end QoS assurance is fundamentally compromised. For example, a holographic frame's I-frame may be marked with a high-priority DSCP, but the transport network may not know that it requires redundancy protection or that its loss would invalidate an entire GOP. A tactile control packet may be marked with a low-latency DSCP, but the transport network may not know that its deadline is 1 ms and may route it through a path that cannot meet that bound. A semantic communication packet may carry high semantic importance, but the transport network has no field in which to receive that information. In all these cases, the transport network's powerful enforcement capabilities remain underutilized, and the end-to-end QoS assurance degrades to the level of the weakest link - the coarse-grained DSCP-based transport treatment.

Summary In summary, the radio access domain and the transport domain operate with fundamentally different levels of service awareness. The radio domain can interact with UEs, application servers, and core network functions to obtain rich, dynamic, and multi-dimensional QoS requirements. The transport domain, however, receives only a DSCP marking and has no mechanism to actively perceive the QoS needs of the flows it carries. This asymmetry creates a cross-domain QoS consistency gap: fine-grained radio QoS assurance is not consistently translated into transport QoS treatment, and end-to-end QoS assurance for 6G services is substantially degraded. Bridging this gap requires a cross-domain information exchange mechanism that allows the transport network to become aware of the service QoS requirements that the radio domain has already negotiated, so that the transport network's fine-grained enforcement capabilities can be properly activated and aligned with the radio domain's QoS policies.

Gap Analysis This section aims to systematically analyze the key gaps in achieving fine-grained QoS assurance for 6G. It elaborates on three core issues: the limitations of existing QoS marking mechanisms, the underutilization of transport network capabilities, and the absence of cross-domain coordination mechanisms.

Gap 1: Existing DSCP Mechanism Cannot Match 6G's Rich QoS Parameters

Current State Currently, the transfer of QoS information from the 5G core network to the transport network heavily relies on the Differentiated Services Code Point (DSCP). The 5G QoS Identifier (5QI) defines flow-level QoS templates on the radio side, but when entering the transport network, it is compressed and mapped into a 6-bit DSCP field with a maximum of 64 codepoints. This mapping is a lossy compression, reducing multi-dimensional, dynamic QoS requirements into a small number of fixed forwarding behavior classes.

Key Gap

Insufficient Granularity: DSCP is an aggregate, flow-level marker that cannot express the per-packet differentiation required by 6G applications. For example, key frames (I-frames) versus non-key frames (P/B-frames) in holographic communications, or packets with varying semantic importance in semantic communications, require vastly different treatment within the network. DSCP cannot carry this information.
Missing Dimensions: DSCP is inherently a scalar value and cannot carry the multi-dimensional QoS semantics introduced by 6G scenarios. Critical attributes such as "remaining latency budget", "inter-flow synchronization requirements", "burst profile", and "semantic importance" cannot be expressed through a single 6-bit codepoint.
Static Nature vs. Dynamic Requirements: DSCP markings are static; once assigned, the corresponding Per-Hop Behavior (PHB) is fixed. However, the QoS requirements of 6G applications are highly dynamic. For instance, control commands in the Tactile Internet may need to change their latency requirements from 10 ms to 1 ms instantaneously. The DSCP mechanism cannot support such real-time, per-packet QoS adjustments.

Consequence Due to the information bottleneck created by the DSCP mechanism, the transport network can only perform coarse-grained, flow-level or aggregate-level scheduling. It cannot distinguish the priority of individual packets within the same QoS flow, nor can it perceive or understand the unique multi-dimensional QoS constraints of 6G applications. This directly prevents the system from meeting the stringent spatio-temporal consistency requirements of 6G scenarios (such as holographic multi-view synchronization and tactile feedback loops), fundamentally limiting the realization of end-to-end fine-grained QoS.

Gap 2: Wired Transport Network Lacks Service Awareness, Leading to Underutilization of Powerful QoS Capabilities

Current State Modern transport networks (including backhaul and core segments) possess extremely powerful QoS assurance technologies, such as FlexE hard slicing, Deterministic Networking (DetNet), Priority Queuing/Weighted Fair Queuing (PQ/WFQ) scheduling, and SRv6 Traffic Engineering policies. These technologies can achieve per-packet scheduling with microsecond or even nanosecond precision and provide mathematically provable bounds on latency and jitter.

Key Gap

Disconnect Between Capability and Awareness: Despite possessing these powerful execution capabilities, the transport network lacks awareness of the services it carries. Routers and switches make forwarding decisions based only on coarse-grained markers like DSCP in the packet header, without knowing what specific service a packet belongs to, its real-time constraints, or the level of assurance it requires.
Limited Information Input: Currently, DSCP is the sole channel for the transport network to receive service information. This 6-bit field is grossly insufficient to drive the complex internal QoS engines of modern transport devices. For example, even if a device supports DetNet, it needs to know the precise latency budget of a flow to reserve resources accordingly, which is information that DSCP cannot provide.
Limitations of Telemetry: While telemetry mechanisms like In-situ Operations, Administration, and Maintenance (IOAM) [RFC9197] can provide network state visibility, their data export and processing introduce latency, making them unsuitable for scenarios requiring real-time, per-packet responses.

Consequence The transport network possesses powerful tools but lacks the intelligence to deploy them effectively. Its capabilities for sophisticated scheduling, isolation, and deterministic delivery remain dormant because they lack the precise service-awareness input needed for activation. This means that the advanced transport infrastructure deployed by operators is severely underutilized when facing complex 6G services, often defaulting back to coarse, DSCP-based service models. The solution lies in providing the transport network with a "brain" capable of perceiving service needs, rather than relying solely on the "mute" marker of DSCP.

Gap 3: Missing Cross-Domain Information Synchronization Mechanism Leads to Failure of Radio-Wireline QoS Coordination

Current State In the current 5G architecture, the information exchange between the Radio Access Network (RAN) and the transport network is extremely limited. It is characterized by a unidirectional, lossy 5QI-to-DSCP mapping from the RAN to the transport domain. There is no standardized, real-time, bidirectional information channel between the two domains to exchange richer service attributes and network status.

Key Gap

Missing Information from Radio to Wireline: The radio side (via UE, AF, PCF, etc.) can acquire extremely rich service information, such as per-packet importance, remaining latency budget, and inter-flow synchronization requirements. However, these crucial QoS parameters cannot be synchronized to the transport network, leaving the transport domain unaware of the fine-grained QoS policies already negotiated by the radio side.
Missing Feedback from Wireline to Radio: Information about the transport network's congestion state, path quality variations, and queuing delays cannot be fed back to the radio side. This prevents the radio side from perceiving the actual conditions of the transport network, thereby hindering joint cross-domain optimization (e.g., the radio side adjusting its scheduling strategy when the transport link degrades).
Lack of Unified QoS Parameter Matching Mechanism: The radio domain and the wireline domain operate with different QoS models and parameter systems (e.g., 5QI vs. DSCP). There is no unified mechanism to define, map, and interpret these cross-domain QoS parameters, leading to semantic loss and ambiguity during information transfer.

Consequence The radio domain and the wireline domain operate as isolated "information silos", functioning independently without forming an effective closed-loop optimization. Even if both domains are individually capable of providing fine-grained QoS, the end-to-end QoS assurance chain is broken at this interface due to a lack of coordination. The result is that the meticulously designed fine-grained QoS policies on the radio side are stripped down upon entering the transport network, degrading back to coarse-grained best-effort service. Ultimately, the end-to-end, full-link fine-grained QoS assurance demanded by 6G applications cannot be achieved.

Gap Summary The following table summarizes the three core gaps identified in this section:

Conclusion This document has identified three interrelated gaps that prevent fine-grained QoS assurance from spanning the RAN-to-transport path in 6G networks:

The 5QI-to-DSCP mapping constitutes an information bottleneck. The 6-bit DSCP codepoint space cannot convey the fine-grained, dynamic, and multi-dimensional QoS attributes required by 6G services, leaving transport networks unable to activate their existing fine-grained enforcement capabilities.
Transport networks possess rich QoS technologies (FlexE slicing, DetNet, TSN, SRv6 TE, etc.) but lack service awareness; they cannot receive richer service-level QoS requirements from the RAN/core domain, rendering these capabilities largely underutilized.
No cross-domain information synchronization mechanism exists between the radio and transport domains, preventing end-to-end QoS policy coordination and leaving both domains to operate with incomplete information.

These three gaps share a common root cause: the absence of a service-aware information interface between the RAN/core domain and the transport domain. DSCP, designed for a simpler networking era, is fundamentally inadequate as the sole bridge for 6G's multi-dimensional QoS requirements. Transport networks already have the technical capability; what is missing is the service awareness to activate it in a coordinated, end-to-end manner. We recommend the following standardization directions:

define a Service-Aware QoS information model to complement 5QI with fine-grained service attributes, preferably within 3GPP SA2 in coordination with IETF TEAS;
develop a radio-to-transport QoS information exchange protocol supporting both proactive and reactive modes;
define cross-domain QoS parameter mapping between 3GPP and transport parameter spaces;
establish testbed validation to quantitatively demonstrate the benefits.

We encourage the relevant IETF (TEAS, FANTEL, SPRING, DetNet) and 3GPP (SA2, SA6) working groups to consider these gaps as input to their standardization activities.

Security Considerations This document analyzes gaps and does not specify a protocol or mechanism, so it introduces no new security vulnerabilities. Work that addresses the gaps identified here will need to consider at least the following. Conveying richer service QoS information from the radio/core domain into the transport network exposes information about applications, and indirectly about users, that the transport network does not receive today. Any such information should be limited to what the transport network needs to select a treatment and should remain within the operator's trust domain or be governed by inter-operator agreement. A richer QoS interface between domains is also a target for abuse: forged or inflated QoS requests could be used to obtain transport resources without entitlement or to deny them to others, and transport-to-radio feedback could reveal transport topology and load. Cross-domain QoS signaling will therefore need authentication, integrity protection, and admission control, and the transport network must remain in control of the resources it commits.

Acknowledgements TBA.

IANA Considerations TBA.

Informative References . [G8312-20] ITU-T, "Overview of fine grain metro transport network", Recommendation ITU-T G.8312.20, 2023, . [IEEE8021Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", IEEE Std 802.1Q- 2022, 2022, . [OIF-FLEXE] OIF, "Flex Ethernet 2.2 Implementation Agreement", OIF- FLEXE-02.2, September 2021, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 2018, . [RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry", RFC 8436, DOI 10.17487/RFC8436, August 2018, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [TR23801] 3GPP, "Study on Architecture for 6G System; Stage 2", 3GPP TR 23.801-01, work in progress, 2026, . [TS23501] 3GPP, "System architecture for the 5G System (5GS); Stage 2", 3GPP TS 23.501, 2026, . ]]>