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

4.1.1. 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.¶

4.1.2. 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.¶

4.1.3. 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.¶

4.1.4. 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.¶

4.1.5. 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.¶

4.2.1. 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.¶

4.2.2. 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.¶

4.2.3. 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.¶

4.2.4. 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".¶

4.2.5. 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.¶

4.3.1. 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.¶

4.3.2. 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.¶

4.3.3. 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.¶

4.3.4. 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.¶

4.3.5. 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.¶

5.1.1. 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.¶

5.1.2. 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.¶

5.1.3. 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.¶

5.2.1. 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.¶

5.2.2. 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.¶

5.2.3. 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.¶

5.3.1. 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.¶

5.3.2. 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.¶

5.3.3. 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.¶