Diffserv to QCI Mapping
draft-henry-tsvwg-diffserv-to-qci-03

Abstract

As communication devices become more hybrid, smart devices include more media-rich communication applications, and the boundaries between telecommunication and other applications becomes less clear. Simultaneously, as the end-devices become more mobile, application traffic transits more often between enterprise networks, the Internet, and cellular telecommunication networks, sometimes using simultaneously more than one path and network type. In this context, it is crucial that quality of service be aligned between these different environments. However, this is not always the case by default, and cellular communication networks use a different QoS nomenclature from the Internet and enterprise networks. This document specifies a set of 3rd Generation Partnership Project (3GPP) Quality of Service (QoS) Class Identifiers (QCI) and 5G QoS Identifiers (5QI) to Differentiated Services Code Point (DSCP) mappings, to reconcile the marking recommendations offered by the 3GPP with the recommendations offered by the IETF, so as to maintain a consistent QoS treatment between cellular networks and the Internet. This mapping can be used by enterprises or implementers expecting traffic to flow through both types of network, and wishing to align the QoS treatment applied to one network under their control with the QoS treatment applied to the other network.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 21, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Related Work
• 1.2. Applicability Statement
• 1.3. Document Organization
• 1.4. Requirements language
• 1.5. Terminology Used in this Document
• 2. Service Comparison and Default Interoperation of Diffserv and 3GPP LTE and 5G
• 2.1. Diffserv Domain Boundaries
• 2.2. QCI and Bearer Model in 3GPP
• 2.3. QCI Definition and Logic
• 2.3.1. Conversational
• 2.3.2. Streaming
• 2.3.3. Interactive
• 2.3.4. Background
• 2.4. QCI implementations
• 2.5. 5QI and flow-based QoS Model in 3GPP 5G
• 2.6. GSMA IPX Guidelines Interpretation and Conflicts
• 3. P-GW Device Marking and Mapping Capability Recommendations
• 4. DSCP to QCI or 5QI Mapping Recommendations
• 4.1. Control Traffic
• 4.1.1. Network Control Protocols
• 4.1.2. Operations, Administration, and Maintenance (OAM)
• 4.2. User Traffic
• 4.2.1. Telephony
• 4.2.2. Signaling
• 4.2.3. Multimedia Conferencing
• 4.2.4. Real-Time Interactive
• 4.2.5. Multimedia Streaming
• 4.2.6. Broadcast Video
• 4.2.7. Low-Latency Data
• 4.2.8. High-Throughput Data
• 4.2.9. Standard
• 4.2.10. Low-Priority Data
• 4.3. Summary of Recommendations for DSCP-to-QCI Mapping
• 5. QCI and 5QI to DSCP Mapping Recommendations
• 5.1. QCI, 5QI and Diffserv Logic Reconciliation
• 5.2. Voice [1]
• 5.3. IMS Signaling [5]
• 5.4. Voice-related QCIs and 5QIs [65, 66, 69]
• 5.5. Video QCIs and 5QIs [67, 2, 4, 71, 72, 73, 74, 76]
• 5.6. Live streaming and interactive gaming [7]
• 5.7. Low latency eMBB and AR/VR [80]
• 5.8. V2X messaging [75,3,9]
• 5.9. Automation and Transport [82, 83, 84, 85, 86]
• 5.10. Non-mission-critical data [6,8,9]
• 5.11. Mission-critical data [70]
• 5.12. Summary of Recommendations for QCI or 5QI to DSCP Mapping
• 6. IANA Considerations
• 7. Specific Security Considerations
• 8. Security Recommendations for General QoS
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

3GPP has become the preferred set of standards to define cellular communication principles and protocols. With the augmented capabilities of smartphones, cellular networks increasingly carry non-communication traffic and interconnect with the Internet and Enterprise IP networks. The access networks defined by the 3GPP present several design challenges for ensuring end-to-end quality of service when these networks interconnect with the Internet or to enterprise networks. Some of these challenges relate to the nature of the cellular network itself, being centrally controlled, collision-free and primarily designed around subscription level and associated services, while other challenges relate to the fact that the 3GPP standards are not administered by the same standards body as Internet protocols. While 3GPP has developed tools to enable QoS over cellular networks, little guidance exists on how to maintain consistency of QoS treatment between cellular networks and the Internet, or IP-based Enterprise networks. As such, enterprises and other operators managing traffic flowing through both 3GPP and Internet Protocol links do not always know how to translate 3GPP QoS identifiers into Internet Protocol QoS identifiers and vice versa.The purpose of this document is to provide such guidance.

1.1. Related Work

Several RFCs outline Diffserv QoS recommendations over IP networks, including:

[RFC2474] specifies the Diffserv Codepoint Field. This RFC also details Class Selectors, as well as the Default Forwarding (DF) treatment. [RFC2475] defines a Diffserv architecture [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior (PHB) [RFC2597] specifies the Assured Forwarding (AF) PHB. [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) [RFC4594] presents Configuration Guidelines for Diffserv Service Classes [RFC5127] presents the Aggregation of Diffserv Service Classes [RFC5865] specifies a DSCP for Capacity Admitted Traffic [RFC8622] presents the Lower-Effort Per-Hop Behavior (LE-PHB) for Diffserv

Note: [RFC4594] is intended to be viewed as a framework for supporting Diffserv in any network, regardless of the underlying data-link or physical layer protocols. Its principles could apply to IP traffic carried over cellular DataLink and Physical Layer mediums. Additionally, the principles of [RFC4594] apply to any traffic entering the Internet, regardless of its original source location. Thus, [RFC4594] describes different types of traffic expected in IP networks and provides guidance as to what DSCP marking(s) should be associated with each traffic type. As such, this document draws heavily on [RFC4594] , as well as [RFC5127], and [RFC8100].

In turn, the relevant standard for cellular LTE QoS is 3GPP [TS 23.107], which defines more than 1600 General Packet Radio Service (GPRS) QoS profiles across multiple classes and associated attributes. As this quantity is large and source of potential complexity, the 3GPP Technical Specification Group Services and System Aspects, defining the Policy Charging Control Architecture, leverages a subset of QoS profiles used as QoS Class Identifiers (QCI). For 5G communications, [TS 23.501] defines 5G QoS Identifiers. This document draws on these specifications, which are being progressively updated; the current version of which (at the time of writing) are 3GPP [TS 23.203] v16.2.0 and 3GPP [TS 23.501] v16.3.0.

1.2. Applicability Statement

This document is applicable to the use of Differentiated Services that interconnect with 3GPP LTE or 5G cellular networks (referred to as cellular, throughout this document, for simplicity). These guidelines are applicable whether cellular network endpoints are IP-enabled, in which case these guidelines can apply end-to-end, starting from the endpoint operating system, or whether cellular network endpoints are either not IP-enabled, or do not enable QoS, in which case these guidelines apply at the interconnection point between the cellular access network and the Internet or IP network. Such interconnection point can commonly occur at the infrastructure Radio Unit (eNodeB), within the infrastructure core network (CN), or at the edge of the core network toward the Internet or an Enterprise IP network, for example within the Packet Data Network Gateway (P-GW).

1.3. Document Organization

This document is organized as follows:

• Section 2 introduces the QoS logic marking applicable to each domain. We introduce the general logic of Diffserv and the notion of domain boundary. We then examine the 3GPP QoS logic, detailing the concept of bearer, QCI and 5QIs, and showing how QCIs and 5QIs are implemented and used.
• Section 3 provides general recommendations for QoS support at the 3GPP / Diffserv domains boundaries.
• Section 4 proposes a Diffserv to QCI translation scheme, so as to suggest DSCP values that can be directly translated into QCIs or 5QIs values, when traffic moves into a 3GPP domain where QCIs or 5QIs must be used.
• Section 5 proposes a reverse mapping, from QCI to Diffserv. As many QCIs intents do not match existing DSCP values, new DSCP values are proposed wherever needed.
• Section 6 underlines the resulting IANA requirements for this mapping.
• Section 7 and Section 8 examine the security consequences of these new mapping schemes.

1.4. Requirements language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.5. Terminology Used in this Document

Key terminology used in this document includes:

EPS Bearer: a path that user traffic (IP flows) uses between the UE and the PGW.

GGSN: Gateway GPRS Support Node, responsible for the internetworking between the GPRS network and external networks. PGW performs the GGSN functionalities in EPC.

IP BS Manager: Internet Protocol Bearer Service Manager, a function that manages the IP bearer services. Part of this function can include translation of QoS parameters between EPS and external networks.

UE: User Equipment, the end-device.

EPS Session: a PDN connection, comprised of one or more IP flows, that a UE established and maintains to the EPS.

SAE: System Architecture Evolution.

RAN: Radio access network, the radio segment of the LTE network EPS.

EPC: Evolved Packet Core, the core segment of the LTE network EPS.

EPS: Evolved Packet System, the LTE network, comprised of the RANs and EPC.

HSS: Home Subscriber Server, the database that contains user-related and subscriber-related information.

LUS: Live Uplink Streaming, a video flow (often real-time) sent from a source to a sink.

SGW: Serving Gateway, the point of interconnection between the RAN and the EPC.

PGW: Packet Data Network Gateway, point of interconnection between the EPC and external IP networks.

MME: Mobility Management Entity: software function that handles the signaling related to mobility and security for the access network.

PCEF: Policy and Charging Enforcement Function, provides user traffic handling and QoS within the PGW.

PCRF: Policy and Charging Rules Function, a functional entity that provides policy, bandwidth and charging functions for each EPS user.

2. Service Comparison and Default Interoperation of Diffserv and 3GPP LTE and 5G

2.1. Diffserv Domain Boundaries

It is important to recognize that 3GPP standards allow support for principles of [RFC2475]. The user equipment (UE) application function may have no active QoS support, or may support Diffserv or IntServ functions [TS 23.207] v15 5.2.2. When Diffserv is supported, an Internet Protocol Bearer Service Manager (IP BS Manager) function integrated to the UE can translate Diffserv parameters into LTE QoS parameters (e.g. QCI). As such, the UE IP BS Manager function may act as a Diffserv domain boundary (as defined in [RFC2475]) between a Diffserv domain present within the UE networking stack and the LTE Radio Access Network.

Additionally, the P-GW interconnects the UE data plane to the external networks. The P-GW is the element that implements Gateway GPRS (General Packet Radio Service) Support Node (GGSN) functionalities in Evolved Packet Core (EPS) networks. The GGSN includes an IP BS manager function that acts as a Diffserv Edge function, and can translate Diffserv parameters to 3GPP QoS parameters (e.g. QCI or 5G NSA 5QI) and vice versa. In SA 5G, the user plane and control plane are separated, and the P-GW for the user plane (PGW-U) joins the Service Gateway (SGW-U) into the User Plane Function (UPF).

As such, 3GPP standards allow the existence of a Diffserv domain within the UE and outside of the EPS boundaries. The Diffserv domain is not considered within the EPS, where QCIs or 5QIs are used to define and transport QoS parameters.

2.2. QCI and Bearer Model in 3GPP

It is important to note that LTE (4G) and 5G standards are an evolution of UMTS standards (2G, 3G) developed in the 1990s. As such, these standards recognize [RFC2475] (1998), but not [RFC4594] (2006). EPS networks rely on the notion of bearers. A bearer is a conduit between the UE and the P-GW, and LTE supports two types of bearers:

• GBR: Guaranteed Bit Rate bearers. These bearers allocate network resources associated to a GBR value associated to the bearer. These resources stay allocated (reserved) for the duration of the existence of the GBR bearer and the flow it carries.
• Non-GBR bearers: also called default bearers, non-GBR are bearers for which network resources are not permanently allocated during the existence of the bearer and the flow it carries. As such, one or more non-GBR bearer may share the same set of temporal resources.

Each EPS bearer is identified by a name and number, and is associated with specific QoS parameters of various types:

1. QoS Class Identifiers (QCI). A QCI is a scalar associated to a bearer, and is used to define the type of traffic and service expected in the bearer. [TS 23.107] v15 defines 4 basic classes: conversational, streaming, interactive and background. These classes are defined more in details in Section 2.3. Each class includes multiple types of traffic, each associated with sets of attributes, thus permitting the definition of more than 1600 different QoS profiles. [TS 23.203] v16 6.1.7.2 reduces the associated complexity by characterizing traffic based on up to 6 attributes, resulting in 26 types of traffic and their associated expected service requirements through the use of 26 scalars (QCI). Each QCI is defined in the relation to the following six performance characteristics:
2. Resource Type (GBR or Non-GBR).
3. Priority: a scalar used as a tie breaker if two packets compete for a given network resource. A lower value indicates a higher priority.
4. Packet Delay Budget: marks the upper bound for the time that a packet may be delayed between the UE and the PCRF (Policy and Charging Rules Function) or the PCEF function (Policy and Charging Enforcement Function) residing inside the P-GW. PCEF supports offline and online charging while PCRF is real-time. Either component, being in charge of policing and charging, can determine resource reservation actions and policies.
5. Packet Error Loss Rate, defines an upper bound for a rate of non-congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations when needed.
6. Maximum Burst Size (only for some GBR QCIs), defines the amount of data which the Radio Access Network (RAN) is expected to deliver within the part of the Packet Delay Budget allocated to the link between the UE and the radio base station. If more data is transmitted from the application, the Packet Delay Budget may be exceeded.
7. Data rate Averaging Window (only for some GBR QCIs), defines the ‘sliding window’ duration over which the GBR and MBR are calculated.

Although [TS 23.203] v16 6.1.7.2 associates each QCI with up to 6 characteristics, it is clear that these characteristics are constrained by bandwidth allocation, in particular on the radio link that are associated with three commonly used parameters:

1. Maximum Bit Rate (MBR), only valid for GBR bearers, defines the maximum sustained traffic rate that the bearer can support.
2. Guaranteed Bit Rate (GBR), only valid for GBR bearers, defines the minimum traffic rate reserved for the bearer.
3. Aggregate MBR (AMBR), defines the total amount of bit rate available for a group of non-GBR bearers. AMBR is often used to provide differentiated service levels to different types of customers.

2.3. QCI Definition and Logic

[TS 23.107] v15 6.3 defines four possible traffic classes. These four general classes are used as the foundation from which QCI categories are defined in [TS 23.203]. The categorization is made around the notion of sensitivity to delay.

2.3.1. Conversational

The conversational class is intended to carry real-time traffic flows. The expectation of such class is a live conversation between two humans or a group. Examples of such flows include [TS 23.107] v15 6.3.1 telephony speech, but also VoIP and video conferencing. Video conference would be seen as a different class from telephony in the Diffserv model. However, 3GPP positions them in the same general class, as all of them include live conversations. Sensitivity to delay is high because of the real-time nature of the flows. The time relation between the stream entities have to be preserved (to maintain the same experience for all flows and all parties involved in the conversation).

2.3.2. Streaming

The streaming class is intended for flows where the user is watching real time video, or listening to real-time audio (or both). The real-time data flow is always aiming at a live (human) destination. It is important to note that the Streaming class is intended to be both a real-time flow and a one-way transport. Two-way real-time traffic belongs to the conversational class, and non-real-time flows belong to the interactive or the background classes. The delay sensitivity is lower than that of Conversational flows, because it is expected that the receiving end includes a time alignment function (e.g. buffering). As the flow is unidirectional, variations in delay do not conversely affect the user experience as long as the variation is within the alignment function boundaries.

2.3.3. Interactive

The interactive class is intended for flows where a machine or human is requesting data from a remote equipment (e.g. a server). Examples of human interaction with the remote equipment are: web browsing, data base retrieval, server access. Examples of machines interaction with remote equipment are: polling for measurement records and automatic data base enquiries (tele-machines). Delay sensitivity is average, and is based on round trip time (overall time between emission of the request and reception of the response).

2.3.4. Background

The background class applies to flows where the equipment is sending or receiving data files without direct user interaction (e.g. emails, SMS, database transfers etc.) As such, delay sensitivity is low. Background is described as delivery-time insensitive.

Based upon the above principles, [TS 23.203] has defined several QCIs. [TS 23.203] Release 16 6.1.7-A defines 26 QCIs:

Several QCIs cover the same application types. For example, QCIs 6, 8 and 9 all apply to buffered streaming video and web applications. However, LTE context distinguishes several types of customers and environments. As such, QCI 6 can be used for the prioritization of non-real-time data (i.e. most typically TCP-based services/applications) of MPS (multimedia priority services) subscribers, when the network supports MPS. QCI 8 can be used for a dedicated “premium bearer” (e.g. associated with premium content) for any subscriber or subscriber group, while QCI 9 can be used for the default bearer for non-privileged subscribers.

2.4. QCI implementations

[TS 23.203] v16 defines multiple QCIs. However, a UE or a EPS does not need to implement all supported QCIs, even when all matching types of traffic are expected between the UE and the network. In practical implementations, it is common for an EPS to implement one GBR bearer where at least QCI 1 is directed (and optionally other GBR QCIs), and another default bearer where all other traffic to and from the same UE is directed. The QCI associated to that second bearer may depend on the subscriber category. As such, the QCI listed in Section 2.3 are indicative of performance and traffic type classifications, and are not strict in their implementation mandate.

2.5. 5QI and flow-based QoS Model in 3GPP 5G

While 4G LTE QoS is enforced at the EPS bearer level, 5G QoS focuses on the transported flows. A QoS Flow ID (QFI) identifies a given QoS Flow. In the User Plane, the traffic with a given QFI within a PDU session is treated in the same way. The 5G QoS Identifier (5QI) is used in 3GPP to identify a specific QoS forwarding behavior for a 5G QoS Flow (similar to the QCI value for LTE, with the difference that 5QI applies to a flow, carried at some point in a bearer, while QCI applies to a bearer within which certain types of flows are expected). As such, the 5QI defines packet loss rate, packet delay budget etc. In the 5G system, the entity named Session Management Function (SMF) manages the QoS information. The SMF provides QFI information to the Radio Access Network (RAN) for mapping the various QoS flows to access network resources (i.e., data radio bearers). The RAN performs packet marking in the uplink on a per QoS Flow basis, with a marking value determined by the QFI and a treatment matching the asscoiated 5QI. The SMF also instructs the User Plane Function (UPF) for classification, bandwidth enforcement and marking of the user plane traffic in downlink. Such packet marking information includes the QFI and the transport level packet marking value (i.e., the value of the DSCP field in the outer IP header). In [TS 23.501], 3GPP provides the 5G QoS characteristics associated with the 5QIs, and specifies the packet forwarding treatment that a QoS Flow receives end-to-end, from the UE up to the UPF (and back). The characteristics considered are:

• Resource type, i.e., if the flow requires resources to be allocated for Guaranteed Bandwidth Rate (GBR), delay critical GBR, or non-GBR.
• Packet delay budget (PDB), including the PDB consumed in the 5G core network
• Packet Error Rate (PER)
• Averaging window, applicable for GBR and delay-critical GBR
• Maximum data burst volume, applicable for delay-critical GBR only

The following table shows a simplified version from the standardized [TS 23.501] 5QI to QoS characteristics mapping.

+——-+——— +——–+——–+———+———+—————+ | 5QI | Resource | Packet | Packet | Default | Default | Example | | value | Type | delay | error | Max Data| Avg | Services | | | | budget | rate | Burst | Window | | | | | (ms) | | (bytes) | (ms) | | +——-+———-+——–+——–+———+———+—————+ | 1 | | 100 | 10^-2 | N/A | 2000 | Conversational| | | | | | | | voice | +——-+ +——–+——–+———+———+—————+ | 2 | | 150 | 10^-3 | N/A | 2000 | Conversational| | | | | | | | video (live | | | | | | | | streaming) | +——-+ +——–+——–+———+———+—————+ | 3 | | 50 | 10^-3 | N/A | 2000 | Real time | | | | | | | | gaming | +——-+ +——–+——–+———+———+—————+ | 4 | | 300 | 10^-6 | N/A | 2000 | Buffered | | | | | | | | streaming | +——-+ +——–+——–+———+———+—————+ | 65 | | 75 | 10^-2 | N/A | 2000 | Push to talk | | | | | | | | voice (mission| | | | | | | | critical) | +——-+ +——–+——–+———+———+—————+ | 66 | | 100 | 10^-3 | N/A | 2000 | P.t.talk voice| | | | | | | | (non mission | | | | | | | | critical) | +——-+ GBR +——–+——–+———+———+—————+ | 67 | | 100 | 10^-3 | N/A | 2000 | Video (mission| | | | | | | | critical) | +——-+ +——–+——–+———+———+—————+ | 71 | | 150 | 10^-6 | N/A | 2000 | Live uplink | | | | | | | | streaming | +——-+ +——–+——–+———+———+—————+ | 72 | | 300 | 10^-4 | N/A | 2000 | Live uplink | | | | | | | | streaming | +——-+ +——–+——–+———+———+—————+ | 73 | | 300 | 10^-8 | N/A | 2000 | Live uplink | | | | | | | | streaming | +——-+ +——–+——–+———+———+—————+ | 74 | | 500 | 10^-8 | N/A | 2000 | Live uplink | | | | | | | | streaming | +——-+ +——–+——–+———+———+—————+ | 76 | | 500 | 10^-4 | N/A | 2000 | Live uplink | | | | | | | | streaming | +——-+———-+——–+——–+———+———+—————+ | 5 | | 100 | 10^-6 | N/A | N/A | IMS | | | | | | | | signalling | +——-+ +——–+——–+———+———+—————+ | 6 | | 300 | 10^-6 | N/A | N/A | TCP-based | | | | | | | | buffered | | | | | | | | streaming | +——-+ +——–+——–+———+———+—————+ | 7 | | 100 | 10^-3 | N/A | N/A | Voice, video | | | | | | | | (live stream.)| | | | | | | | interactive | | | | | | | | gaming | +——-+ +——–+——–+———+———+—————+ | 8 | Non- | 300 | 10^-6 | N/A | N/A | TCP-based | | | GBR | | | | | buffered | | | | | | | | streaming | +——-+ +——–+——–+———+———+—————+ | 69 | | 60 | 10^-6 | N/A | N/A | Signalling | | | | | | | | (mission | | | | | | | | critical) | +——-+ +——–+——–+———+———+—————+ | 70 | | 200 | 10^-6 | N/A | N/A | Data | | | | | | | | (mission | | | | | | | | critical) | +——-+ +——–+——–+———+———+—————+ | 79 | | 50 | 10^-2 | N/A | N/A | V2X | | | | | | | | messages | +——-+ +——–+——–+———+———+—————+ | 80 | | 10 | 10^-6 | N/A | N/A | Low latency | | | | | | | | eMBB, | | | | | | | | Augmented | | | | | | | | reality | +——-+———-+——–+——–+———+———+—————+ | 82 | | 10 | 10^-4 | 255 | 2000 | Discrete | | | | | | | | automation | +——-+ +——–+——–+———+———+—————+ | 83 | | 10 | 10^-4 | 1354 | 2000 | Discrete | | | | | | | | automation | +——-+ Delay +——–+——–+———+———+—————+ | 84 | Critical | 30 | 10^-5 | 1354 | 2000 | Intelligent | | | GBR | | | | | transport | | | | | | | | systems | +——-+ +——–+——–+———+———+—————+ | 85 | | 5 | 10^-5 | 255 | 2000 | Electricity | | | | | | | | distribution | | | | | | | | H.volt., V2X | +——-+ +——–+——–+———+———+—————+ | 86 | | 5 | 10^-4 | 1354 | 2000 | V2X, collision| | | | | | | | avoidance, | | | | | | | | platooning | +——-+———-+——–+——–+———+———+—————+

Although the focus of 5QI and that of QCI is different, it should be noted that the traffic examples provided by each QCI match the traffic intent for a 5QI with matching number. The 5QI default priority level is a tenfold expression of the QCI priority level (and this document will refer to the QCI priority levels for simplicity) As such, any given QCI or 5QI can be equivalised to the same DSCP value. In turn, an application and its given DSCP value can be expressed either in a QCI or a 5QI (provided that both exist for the assooiated traffic or application).

2.6. GSMA IPX Guidelines Interpretation and Conflicts

3GPP standards do not define or recommend any specific mapping between each QCI or 5QI and Diffserv, and leaves that mapping choice to the operator of the Edge domain boundary (e.g. UE software stack developer, P-GW operator). However, 3GPP defines that “for the IP based backbone, Differentiated Services defined by IETF shall be used” ([TS 23.107] v15 6.4.7).

The GSM Association (GSMA) has published an Inter-Service Provider IP Backbone Guideline reference document [ir.34] that provides technical guidance to participating service providers for connecting IP based networks and services to achieve roaming and inter-working services. The document built upon [RFC3246] and [RFC2597], and upon the initial definition of 4 service classes in [TS 23.107] v15 to recommend a mapping to EF for conversational traffic, to AF41 for Streaming traffic, to AF31, AF21 and AF11 for different traffic in the Interactive class, and to BE for background traffic.

These GSMA Guidelines were developed without reference to existing IETF specifications for various services, referenced in Section 1.1. Additionally, the same recommendations remained while new traffic types under each 3GPP general class were added. As such, the GSMA recommendations yield to several inconsistencies with [RFC4594], including:

• Recommending EF for real-time (conversational) video, for which [RFC4594] recommends AF41.
• Recommending AF31 for DNS traffic, for which [RFC4594] recommends the standard service class (DF)
• Recommending AF31 for all types of signaling traffic, thus losing the ability to differentiate between the various types of signaling flows, as recommended in[RFC4594] section 5.1.
• Recommending AF21 for WAP browsing and WEB browsing, for which [RFC4594] recommends the High Throughput data class
• Recommending AF11 for remote connection protocols, such as telnet or SSH, for which [RFC4594] recommends the OAM class.
• Recommending DF for file transfers, for which [RFC4594] recommends the High Throughput Data class.
• Recommending DF for email exchanges, for which [RFC4594] recommends the High Throughput Data class.
• Recommending DF for MMS exchanged over SMTP, for which [RFC4594] recommends the High Throughput Data class.

The document [ir.34] aso does not provide guidance for QCIs other than 1 to 9, leaving the case of the 12 other QCIs unaddressed.

Thus, document [ir.34] conflicts with the overall Diffserv traffic-conditioning service plan, both in the services specified and the code points specified for them. As such, these two plans cannot be normalized. Rather, as discussed in [RFC2474] Section 2, the two domains (GSMA and other IP networks) are different Differentiated Services Domains separated by a Differentiated Services Boundary. At that boundary, code points from one domain are translated to code points for the other, and maybe to Default (zero) if there is no corresponding service to translate to.

3. P-GW Device Marking and Mapping Capability Recommendations

This document assumes and RECOMMENDS that all P-GWs (as the interconnects between cellular and other IP networks) and all other interconnection points between cellular and other IP networks support the ability to:

• mark DSCP, per Diffserv standards
• mark QCI, per the [TS 23.203] standard, or 5QI, as per the [TS 23.501] standard
• support fully-configurable mappings between DSCP and QCI or 5QI
• process DSCP markings set by cellular endpoint devices

This document further assumes and RECOMMENDS that all cellular endpoint devices (UE) support the ability to:

• mark DSCP, per Diffserv standards
• mark QCI, per the [TS 23.203] standard, OR 5QI, per the [TS 23.501] standard
• support fully-configurable mappings between DSCP (set by applications in software) and QCI or 5QI (set by the operating system and/or the LTE infrastructure)

Having made the assumptions and recommendations above, it bears mentioning that while the mappings presented in this document are RECOMMENDED to replace the current common default practices (as discussed in Section 2.3 and Section 2.4), these mapping recommendations are not expected to fit every last deployment model, and as such MAY be overridden by network administrators, as needed.

4. DSCP to QCI or 5QI Mapping Recommendations

4.1. Control Traffic

4.1.1. Network Control Protocols

The Network Control service class is used for transmitting packets between network devices (e.g., routers) that require control (routing) information to be exchanged between nodes within the administrative domain, as well as across a peering point between different administrative domains.

[RFC4594] Section 3.2 recommends that Network Control Traffic be marked CS6 DSCP. Additionally, as stated in [RFC4594] Section 3.1: “CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols.”

Network Control service is not directly called by any specific QCI or 5QI description, because 3GPP network control does not operate over UE data channels. It should be noted that encapsulated routing protocols for encapsulated or overlay networks (e.g., VPN, Network Virtualization Overlays, etc.) are not Network Control Traffic for any physical network at the cellular space; hence, they SHOULD NOT be marked with CS6 in the first place, and are not expected to be forwarded to the cellular data plane.

However, when such network control traffic is forwarded, it is expected to receive a high priority and level of service. As such, packets marked to CS7 DSCP are RECOMMENDED to be mapped to QCI 82, thus benefiting from a dedicated bearer with low packet error loss rate (10.E-4) and low budget delay (10 ms). Similarly, it is RECOMMENDED to map Network Control Traffic marked CS6 to QCI/5QI 82, thereby admitting it to the Discrete Automation (GBR) category with a relative priority level of 1.9/19.

4.1.2. Operations, Administration, and Maintenance (OAM)

The OAM (Operations, Administration, and Maintenance) service class is recommended for OAM&P (Operations, Administration, and Maintenance and Provisioning). The OAM service class can include network management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog, etc., as well as network services, such as NTP, DNS, DHCP, etc.

[RFC4594] Section 3.3, recommends that OAM traffic be marked CS2 DSCP.

Applications using this service class require a low packet loss but are relatively not sensitive to delay. This service class is configured to provide good packet delivery for intermittent flows. As such, packets marked to CS2 are RECOMMENDED to be mapped to QCI/5QI 9, thus admitting it to the non-GBR Buffered video traffic, with a relative priority of 9/90.

4.2. User Traffic

User traffic is defined as packet flows between different users or subscribers. It is the traffic that is sent to or from end-terminals and that supports a very wide variety of applications and services [RFC4594] Section 4.

Network administrators can categorize their applications according to the type of behavior that they require and MAY choose to support all or a subset of the defined service classes.

4.2.1. Telephony

The Telephony service class is recommended for applications that require real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). This service class SHOULD be used for IP telephony service. The fundamental service offered to traffic in the Telephony service class is minimum jitter, delay, and packet loss service up to a specified upper bound. [RFC4594] Section 4.1 recommends that Telephony traffic be marked EF DSCP.

3GPP [TS 23.203] describes two QCIs adapted to Voice traffic: QCI 1 (GBR) and QCI 7 (non-GBR). The same logic is found in [TS 23.501] for the same 5QIs. However, Telephony traffic as intended in [RFC4594] supposes resource allocation control. Telephony SHOULD be configured to receive guaranteed forwarding resources so that all packets are forwarded quickly. The Telephony service class SHOULD be configured to use Priority Queuing system. QCI 7 does not match these conditions. As such, packets marked to EF are RECOMMENDED to be mapped to QCI/5QI 1, thus admitting it to the GBR Conversational Voice category, with a relative priority of 2/20.

4.2.2. Signaling

The Signaling service class is recommended for delay-sensitive client-server (e.g., traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between 1) IP phone and soft-switch, 2) soft-client and soft-switch, and 3) media gateway and soft-switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. [RFC4594] Section 4.2 recommends that Signaling traffic be marked CS5 DSCP.

While Signaling is recommended to receive a superior level of service relative to the default class (e.g., relative to QCI 7), it does not require the highest level of service (i.e., GBR and very high priority). As such, it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to QCI/5QI 4, thereby admitting it to the GBR Non-conversational video category, with a relative priority level of 5/50.

Note: Signaling traffic for native Voice dialer applications should be exchanged over a control channel, and is not expected to be forwarded in the data-plane. However, Signaling for non-native (OTT) applications may be carried in the data-plane. In this case, Signaling traffic is control-plane traffic from the perspective of the voice/video telephony overlay-infrastructure. As such, Signaling should be treated with preferential servicing versus other data-plane flows.

4.2.3. Multimedia Conferencing

The Multimedia Conferencing service class is recommended for applications that require real-time service for rate-adaptive traffic. [RFC4594] Section 4.3 recommends Multimedia Conferencing traffic be marked AF4x (that is, AF41, AF42, and AF43, according to the rules defined in [RFC2475]. The Diffserv model allows for three values to allow for different relative priorities of flows of the same nature.

The primary media type typically carried within the Multimedia Conferencing service class marked AF41 is video intended to be a component of a real-time exchange; as such, it is RECOMMENDED to map AF41 into the Conversational Video (Live Streaming) category, with a GBR. Specifically, it is RECOMMENDED to map AF41 to QCI/5QI 2, thereby admitting AF41 into the GBR Conversational Video, with a relative priority of 4/40.

AF42 is typically reserved for video intended to be a component of real-time exchange, but which criticality is less than traffic carried with a marking of AF41. As such, it is RECOMMENDED to map AF42 into the Conversational Video (Live Streaming) category, with a GBR, but a lower priority than QCI/5QI 2. Specifically, it is RECOMMENDED to map AF42 to QCI/5QI 4, thereby admitting AF42 into the GBR Conversational Video, with a relative priority of 5/50.

Traffic marked AF43 is typically used for real-time video exchange of lower criticality. As such, it is RECOMMENDED to map AF43 into the Conversational Video (Live Streaming) category, but without a GBR. Specifically, it is RECOMMENDED to map AF43 to QCI/5QI 7, thereby admitting AF437 into the non-GBR Voice, Video and Interactive gaming, with a relative priority of 7/70.

4.2.4. Real-Time Interactive

The Real-Time Interactive service class is recommended for applications that require low loss and jitter and very low delay for variable-rate inelastic traffic sources. Such applications may include inelastic video-conferencing applications, but may also include gaming applications (as pointed out in [RFC4594] Sections 2.1 through 2.3 and Section 4.4. [RFC4594] Section 4.4 recommends Real-Time Interactive traffic be marked CS4 DSCP.

The primary media type typically carried within the Real-Time Interactive service class is video; as such, it is RECOMMENDED to map this class into a low latency Category. Specifically, it is RECOMMENDED to map CS4 to QCI 80, thereby admitting Real-Time Interactive traffic into the non-GBR category Low Latency eMBB (enhanced Mobile Broadband) applications with a relative priority of 6.8. In cases where GBR is required, for example because a single bearer is allocated for all non-GBR traffic, using a GBR equivalent is also acceptable. In this case, it is RECOMMENDED to map CS4 to QCI/5QI 3, thereby admitting Real-Time Interactive traffic into the GBR category Real-time gaming, with a relative priority of 3/30.

4.2.5. Multimedia Streaming

The Multimedia Streaming service class is recommended for applications that require near-real-time packet forwarding of variable-rate elastic traffic sources. Typically, these flows are unidirectional. [RFC4594] Section 4.5 recommends Multimedia Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33, according to the rules defined in [RFC2475].

The primary media type typically carried within the Multimedia Streaming service class is video; as such, it is RECOMMENDED to map this class into a Video Category. Specifically, it is RECOMMENDED to map AF31 to QCI/5QI 4, thereby admitting AF31 into the GBR Non Conversational Video category, with a relative priority of 5/50.

Flows marked with AF32 are expected to be of the same nature as flows marked with AF32, but with a lower criticality. As such, these flows may not require a dedicated bearer with GBR. Therefore, it is RECOMMENDED to map AF32 to QCI/5QI 6, thereby admitting AF32 traffic into the non-GBR category Video (Buffered Streaming) with a relative priority of 6/60.

Flows marked with AF33 are expected to be of the same nature as flows marked with AF31 and AF32, but with the lowest criticality. As such, it is RECOMMENDED to map AF33 to QCI/5QI 8, thereby admitting AF33 traffic into the non-GBR category Video (Buffered Streaming) with a relative priority of 8/80.

4.2.6. Broadcast Video

The Broadcast Video service class is recommended for applications that require near-real-time packet forwarding with very low packet loss of constant rate and variable-rate inelastic traffic sources. Typically, these flows are unidirectional. [RFC4594] Section 4.6 recommends Broadcast Video traffic be marked CS3 DSCP.

As directly implied by the name, the primary media type typically carried within the Broadcast Video service class is video; as such, it is RECOMMENDED to map this class into a Video Category. Specifically, it is RECOMMENDED to map CS3 to QCI/5QI 4, thereby admitting Multimedia Streaming into the GBR Non Conversational Video category, with a relative priority of 5/50. In cases where GBR availability is constrained, using a non-GBR equivalent is also acceptable. In this case, it is RECOMMENDED to map CS3 to QCI/5QI 6, thereby admitting Real-Time Interactive traffic into the non-GBR category Video with a relative priority of 6/60.

4.2.7. Low-Latency Data

The Low-Latency Data service class is recommended for elastic and time-sensitive data applications, often of a transactional nature, where a user is waiting for a response via the network in order to continue with a task at hand. As such, these flows are considered foreground traffic, with delays or drops to such traffic directly impacting user productivity. [RFC4594] Section 4.7 recommends Low-Latency Data be marked AF2x (that is, AF21, AF22, and AF23, according to the rules defined in [RFC2475].

The primary media type typically carried within the Low-Latency Data service class is data; as such, it is RECOMMENDED to map this class into a data Category. Specifically, it is RECOMMENDED to map AF21 to QCI/5QI 70, thereby admitting AF21 into the non-GBR Mission Critical Data category, with a relative priority of 5.5/55.

Flows marked with AF22 are expected to be of the same nature as flows marked with AF21, but with a lower criticality. Therefore, it is RECOMMENDED to map AF22 to QCI/5QI 6, thereby admitting AF22 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 6/60.

Flows marked with AF23 are expected to be of the same nature as flows marked with AF21 and AF22, but with the lowest criticality. As such, it is RECOMMENDED to map AF23 to QCI/5QI 8, thereby admitting AF23 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 8/80.

It should be noted that a consequence of such classification is that AF22 is mapped to the same QCI and 5QI as CS3, and AF23 is mapped to the same QCI and 5QI as AF33. However, this overlap is unavoidable, as some QCIs and 5QIs express intents that are expressed in the Diffserv domain through distinct marking values, grouped in the 3GPP domain under the same general category.

4.2.8. High-Throughput Data

The High-Throughput Data service class is recommended for elastic applications that require timely packet forwarding of variable-rate traffic sources and, more specifically, is configured to provide efficient, yet constrained (when necessary) throughput for TCP longer-lived flows. These flows are typically not user interactive.

According to [RFC4594] Section 4.8 it can be assumed that this class will consume any available bandwidth and that packets traversing congested links may experience higher queuing delays or packet loss. It is also assumed that this traffic is elastic and responds dynamically to packet loss. [RFC4594] Section 4.8 recommends High-Throughput Data be marked AF1x (that is, AF11, AF12, and AF13, according to the rules defined in [RFC2475].

The primary media type typically carried within the High-Throughput Data service class is data; as such, it is RECOMMENDED to map this class into a data Category. Specifically, it is RECOMMENDED to map AF11 to QCI/5QI 6, thereby admitting AF11 into the non-GBR Video and TCP-based traffic category, with a relative priority of 6/60.

Flows marked with AF12 are expected to be of the same nature as flows marked with AF11, but with a lower criticality. Therefore, it is RECOMMENDED to map AF12 to QCI/5QI 8, thereby admitting AF12 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 8/80.

Flows marked with AF13 are expected to be of the same nature as flows marked with AF11 and AF12, but with the lowest criticality. As such, it is RECOMMENDED to map AF13 to QCI/5QI 9, thereby admitting AF13 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 9/90.

It should be noted that a consequence of such classification is that AF11 is mapped to the same QCI as CS3 and AF22, AF12 is mapped to the same QCI and 5QI as Af33 and AF23, and AF13 is mapped to the same QCI and 5QI as CS2. However, this overlap is unavoidable, as some QCIs and 5QIs express intents that are expressed in the Diffserv domain through distinct marking values, grouped in the 3GPP domain under the same general category.

4.2.9. Standard

The Standard service class is recommended for traffic that has not been classified into one of the other supported forwarding service classes in the Diffserv network domain. This service class provides the Internet’s “best-effort” forwarding behavior. [RFC4594] Section 4.9 states that the “Standard service class MUST use the Default Forwarding (DF) PHB”.

The Standard service class loosely corresponds to the default non-GBR bearer practice in 3GPP. Therefore, it is RECOMMENDED to map Standard service class traffic marked DF DSCP to QCI/5QI 9, thereby admitting it to the low priority Video and TCP-based traffic category, with a relative priority of 9/90.

4.2.10. Low-Priority Data

The Low-Priority Data service class serves applications that the user is willing to accept without service assurances. This service class is specified in [RFC3662] and [RFC8622]. [RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP. [RFC8622] updates these recommendations and suggests the LE (000001) marking. As such, this document aligns with this recommendation and notes that CS1 marking has become ambiguous.

The Low-Priority Data service class does not have equivalent in the 3GPP domain, where all service is controlled and allocated differentially. As such, there is no clear QCI or 5QI that could be labelled low priority below the best effort category. As such, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP and LE DSCP to QCI/5QI 9, thereby admitting it to the low priority Video and TCP-based traffic category, with a relative priority of 9/90.

4.3. Summary of Recommendations for DSCP-to-QCI Mapping

The table below summarizes the [RFC4594] DSCP marking recommendations mapped to 3GPP:

5. QCI and 5QI to DSCP Mapping Recommendations

Traffic travelling from the 3GPP domain toward the Internet or the enterprise domain may already display DSCP marking, if the UE is capable of marking DSCP along with, or without, upstream QCI bearer or 5QI marking, as detailed in Section 2.1.

When Diffserv marking is present in the flows originating from the UE and transiting through the CN (Core Network), and if Diffserv marking are not altered or removed on the path toward the Diffserv domain, then the network can be considered as end-to-end Diffserv compliant. In this case, it is RECOMMENDED that the entity providing the translation from 3GPP to Diffserv ignores the QCI or 5QI value and simply forwards unchanged the Diffserv values expressed by the UE in its various flows.

This general recommendation is not expected to fit every last deployment model, and as such Diffserv marking MAY be overridden by network administrators, as needed, before the flows are forwarded to the Internet, the enterprise network or the Diffserv domain in general. Additionally, within a given Diffserv domain, it is generally NOT RECOMMENDED to pass through DSCP markings from unauthenticated, unidentified or unauthorized devices, as these are typically considered untrusted sources, as detailed in Section 7. Such risk is limited within the 3GPP domain where no upstream traffic is admitted without prior authentication of the UE. However, this risk exists when UE traffic is forwarded to an enterprise domain to which the UE does not belong.

In cases where the UE is unable to apply Diffserv marking, or if these markings are modified or removed within the 3GPP domain, such that these markings may not represent the intent expressed by the UE, and in cases where the QCI is available to represent the flow intent, the recommendations in this section apply. These recommendations MAY apply to the boundary between the 3GPP and the Diffserv model, and MAY also apply to the Diffserv domain, when a given applicaiton traffic flows through both the 3GPP and the Diffserv domains (e.g. multiple paths) and when the enteprise administrator wishes to ensure that the same QoS intent is applied for both paths.

5.1. QCI, 5QI and Diffserv Logic Reconciliation

The QCIs and 5QIs are defined as relative priorities for traffic flows which are described by combinations of 6 or more parameters, as expressed in Section 2.2. As such, QCIs and 5QIs also represent flows in terms of multi-dimensional needs, not just in terms of relative priorities. This multi-dimensional logic is different from the Diffserv logic, where each traffic class is represented as a combination of needs relative to delay, jitter and loss. This characterization around three parameters allows for the construction of a fairly hierarchical traffic categorization infrastructure, where traffic with high sensitivity to delay and jitter also typically has high sensitivity to loss.

By contrast, the 3GPP QCI and 5QI structure presents multiple points where dimensions cross one another with different or opposing vectors. For example, IMS signaling (QCI or 5QI 5) is defined with very high priority (1/10), low loss tolerance (10-6), but is non-GBR and belongs to the signaling category. By contrast, Conversational voice (QCI or 5QI 1) has lower priority (2/20) than IMS signaling, higher loss tolerance (10-2), yet benefits from a GBR. Fitting both QCIs or 5QIs 5 and 1 in a hierarchical model is challenging.

At the same time, QCIs and 5QIs represent needs that can apply to different applications of various criticality but sending flows of the same nature. For example, QCIs or 5QIs 6, 8 and 9 all include voice traffic, video traffic, but also email or FTP. What distinguish these QCIs/5QIs is the criticality of the associated traffic. Diffserv does not envisions voice and FTP as possibly belonging to the same class. As the same time, QCIs or 5QIs 2 and 9 include real-time voice traffic. Diffserv does not allow a type of traffic with stated sensitivity to loss, delay and jitter to be split into categories at both end of the priority spectrum.

As such, it is not expected that QCIs and 5QIs can be mapped to the Diffserv model strictly and hierarchically. Instead, a better approach is to observe the various QCI and 5QI categories, and analyze their intent. This process allows for the grouping of several QCIs or 5QIs into hierarchical groups, that can then be translated into ensembles coherent with the Diffserv logic. This approach, in turn, allows for incorporation of new QCIs and 5QIs as the 3GPP model continues to evolve.

It should be noted, however, that such approach results in partial incompatibility. Some QCIs or 5QIs represent an intent that is simply not present in the Diffserv model. In that case, attempting to artificially stitch the QCI/5QI to an existing Diffserv traffic class and marking would be dangerous. QCI or 5QI traffic forwarded to the Diffserv domain would be mixed with Diffserv traffic that would represent a very different intent.

As such, the result of this classification is that some QCIs and 5QIs call for new Diffserv traffic classes and markings. This consequence is preferable to mixing traffic of different natures into the same pre-existing category.

Each QCI is represented with 6 parameters and each 5QI with 7 parameters, including an Example Services value. This parameter is representative of the QCI or 5QI intent. Although [TS 23.203] and [TS 23.501] summarize each QCI or 5QI intent, these standards contain only summaries of more complex classifications expressed in other 3GPP standards. It is often necessary to refer to these other standards to obtain a more complete description of each QCI/5QI and the multiple type of flows that each QCI or 5QI represents.

For the purpose of this document, the QCI or 5QI intent is the primary classification driver, along with the priority level. The secondary elements, such as priority, delay budget and loss tolerance allow for better refinement of the relative classifications of the QCIs and 5QIs. The resource types (GBR, DElay-critical GBR, non-GBR) provide additional visibility into the intent.

Although 26 QCIs are listed in [TS 23.203] and 27 5QIs in [TS 23.501], representing two (GBR, non-GBR) or three resource types (GBR, non-GBR, Delay-Critical GBR) respectively, 21 and 22 priority values, 9 delay budget values, and 7 loss tolerance values, examining the intent in fact surfaces 9 traffic families:

1. Voice QCI/5QI [1] (dialer / conversational voice) is its own group
2. Voice signaling [5] (IMS) is its own group
3. Voice related (other voice applications, including PTT) [65, 66, 69]
4. Video (conversational or not, mission critical or not) [67, 2, 4, 71, 72, 73, 74, 76]
5. Live streaming / interactive gaming is its own group [7]
6. Low latency eMBB, AR/VR is its own group [80]
7. V2X messaging [75, 3, 9]
8. Automation and Transport [82, 83, 84, 85, 86]
9. Non-mission-critical data [6, 8, 9]
10. Mission-critical data is its own group [70]

5.2. Voice [1]

Several QCIs or 5QIs are intended to carry voice traffic. However, QCI/5QI 1 stands apart from the others. Its category is Conversational Voice, but this QCI/5QI is intended to represent the VoLTE voice bearer, for dialer and emergency services. QCI/5QI 1 uses a GBR, and has a priority level of 2/20. Its packet delay budget is 100 ms (from UE to P-GW) with a packet error loss of at most 10.E-2. As the GBR is allocated by the infrastructure, QCI/5QI 1 is both admitted and allocated dedicated resources. As such, QCI/5QI 1 maps in intent and function to [RFC5865], Admitted Voice, and is RECOMMENDED for mapping to DSCP 44.

5.3. IMS Signaling [5]

QCI/5QI 5 is intended for Signaling. This category does not represent signaling for VoLTE, as such signaling is not conducted over the UE data channels. Instead, QCI/5QI 5 is intended for IMS services. IP Multimedia System (IMS) is a framework for delivering multimedia services over IP networks. These services include real-time and video applications, and their signaling is recommended to be carried, whenever possible, using IETF protocols such as SIP. Being of signaling nature, QCI/5QI 5 is non-GBR. However, being critical to enabling IMS real-time applications, QCI/5QI 5 has a high priority of 1/10. Its packet delay budget is 100 ms, but packet error loss rate very low, at less than 10.E-6. Overall, QCI/5QI 5 maps rather well to the intent of [RFC4594] signaling for real time applications, and as such is RECOMMENDED to map to [RFC4594] Signaling, CS5.

5.4. Voice-related QCIs and 5QIs [65, 66, 69]

Several QCIs/5QIs display the commonality of targeting voice (non-VoLTE) traffic:

• QCI/5QI 65 is GBR, mission critical PTT voice, priority 0.7/7
• QCI/5QI 66 is GBR, non-mission critical PTT voice, priority 2/20
• QCI/5QI 69 is non-GBR, mission-critical PTT signaling, priority 0.5/5

These QCIs/5QIs are Voice in nature, and naturally fit into a proximity marking model with DSCP 46 and 44.

Additionally, lower priority marks higher precedence intent in QCI and 5QI. However, there is no model in [RFC4594] that distinguishes 3 classes of voice traffic. Therefore, new markings are unavoidable. As such, there is a need to group these markings in the Voice category (101 xxx), and to order 69, 65 and 66 with different markings to reflect their different priority levels.

Among these three QCIs/5QIs, 69 is non-GBR, intended for mission-critical PTT signaling, with the highest priority of the three, at 0.5/5. 69 is intended for signaling, but is latency sensitive, with a low 60 ms delay budget and a low 10.E-6 loss tolerance. Being of Signaling nature for real time applications, QCI/5QI 69 has proximity of intent with CS5 (Voice signaling, 40), but this marking is already used by QCI/5QI 5. Therefore, it is RECOMMENDED to map QCI/5QI 69 to a new DSCP marking, 41.

Similarly, QCI/5QI 66 is GBR and targeted for non-mission critical PTT voice, with a priority level of 2/20. 66 is Voice in nature, and GBR. However, 66 is intended for non-mission-critical traffic, and has a lower priority than mission-critical Voice, a higher tolerance for delay (100 ms vs 75). As such, 66 cannot fit within [RFC4594] model mapping real-time voice to the class EF (DSCP 46). Here again, a new marking is needed. As such, this QCI/5QI fits in intent and proximity closest to Admitted Voice, but is non-GBR, and therefore non-admitted, guiding a new suggested DSCp marking of 43.

Then, QCI/5QI 65 is GBR, intended for mission critical PTT voice, with a relative low priority index of 0.7/7. QCI/5QI 65 receives GBR and is intended for mission critical traffic. Its priority is higher (0.7 vs 2) than QCI/5QI 66, but a lower priority (0.7/7 vs 0.5/5) than QCI/5QI 69. Additionally, 65 cannot be represented by DSCP 44 (used by QCI/5QI 1), or DSCP 46 (used by non-GBR voice). As such, QCI/5QI 65 fits between QCIs/5QIs 69 66, with a new suggested DSCP marking of 42.

5.5. Video QCIs and 5QIs [67, 2, 4, 71, 72, 73, 74, 76]

Although six different QCIs and 5QIs have example services that include some form of video traffic, eight QCIs and 5QIs are video in nature, 67, 2, 4, 71, 72, 73, 74, and 76.

All eight QCIs/5QIs represent video streams and fit naturally in the AF4x category. However, these QCIs/5QIs do not match [RFC4594] intent for multimedia conferencing, in that they are all admitted (being associated to a GBR). They also do not match the category described by [RFC5865] for capacity-admitted traffic. Therefore, there is not a clear possible mapping for any of these QCIs and 5QIs to an existing AF4x category. In order to avoid mixing admitted and non-admitted video in the same class, it is necessary to associate these QCIs/5QIs to new Diffserv classes.

In particular, QCI/5QI 67 is GBR, intended for mission-critical video user plane. This QCI/5QI is video in nature, and matches traffic that is rate-adaptive, and real time. 67 priority is high (1.5/15), with a tolerant delay budget (100ms) and rather low loss tolerance (10.E-3). 67 is GBR.

As such, it is RECOMMENDED to map QCI/5QI 67 against the DSCP value closest to AF4x video with lowest discard eligibility (AF41), namely DSCP 33.

Similarly, QCI/5QI 2 is intended for conversational video (live streaming). 2 is also video in nature and associated to a GBR, however its priority is lower than 67 (4/40 vs 1.5/15). Additionally, its delay budget is also larger (150 ms vs 100 ms). Its packet error loss is also 10.E-3. As such, 2 fits well within a video queue, with a larger drop probability than 67. Therefore, it is RECOMMENDED to map QCI/5QI 2 to the video category with a Diffserv marking of 35.

QCIs/5QIs 71, 72, 73, 74 and 76 are intended for “Live” Uplink Streaming (LUS) services, where an end-user with a radio connection (for example a reporter or a drone) streams live video feed into the network or to a second party ([TS 26.939]). This traffic is GBR. However, [TS 26.939] defines LUS and also differentiates GBR from MBR and TBR. At the time of the admission, the infrastructure can offer a Guaranteed Bit Rate, which should match the bare minimum rate expected by the application (and its codec). Because of the burstiness nature of video, the Maximum Bit Rate (MBR) available to the trannsmission should be much higher than the GBR. In fact, the Target Bit Rate (TBR), which is the prefered service operation point for that application, is likely close to the MBR. Thus, the application will receive a treatment between the GBR and the TBR. This allocated bit rate will directly translate in video quality changes, where an available bit rate close to the GBR will result in a lower Mean Opinion Score than a bit rate close to the TBR. As the application detects the contraints on the available bit rate, it may adapt by changing its codec and compression scheme accordingly. Flows with higher compression will have higher delay tolerance and budget (as a single packet burst represents a larger segment of the video flow) but lower loss tolerance (as each lost packet represents a larger segment of the video flow). As such, 71, 72, 73, 74 and 76 express intents similar to QCI/5QI 2, with additional constraints on the directionality of the flow (upstream only) and the bit rate applied by the infrastructure. These constraints are orthogonal to the intent of the flow. As such, it is RECOMMENDED to map QCIs/5QIs 71, 72, 73, 74 and 76 to the same DSCP value as QCI/5QI 2, and thus to the video category with a Diffserv marking of 35.

QCI/5QI 4 is intended for non-conversational video (buffered streaming), with a priority of 5/50. 4 is also video in nature. Although it is buffered, it is admitted, being associated to a GBR. QCI/5QI 4 as a lower priority than QCIs/5QIs 67 and 2, and a larger delay budget (300 ms vs 150/100). However, its packet loss tolerance is low (10.E-6). This combination makes it eligible for a video category, but with a higher drop probability than 67 and 2. Therefore, it is RECOMMENDED to map QCI/5QI 4 to DSCP 37.

5.6. Live streaming and interactive gaming [7]

QCI/5QI 7 is non-GBR and intended for live streaming voice or video interactive gaming. Its priority is 7/70. It is the only QCI/5QI targeting this particular traffic mix. In the Diffserv model, voice and video are different categories, and are also different from interactive gaming (real time interactive). In the 3GPP model, live streaming video and mission-critical video are defined in other queues with high priority (e.g. QCI or 5QI 2 for video Live streaming, with a priority of 2/20, or QCI/5QI 67 for mission-critical video, with a priority of 1.5/15). By comparison, QCI/5QI 7 priority is relatively low (7/70), with a 100 ms budget delay and a comparatively rather high loss tolerance (10.E-3).

As such, 7 fits well with bursty (e.g. video) and possibly rate adaptive flows, with possible drop probability. It is also non-admitted (non-GBR), and as such, fits close to [RFC4594] intent for multimedia conferencing, with high discard eligibility. Therefore, it is RECOMMENDED to map QCI/5QI 7 to the existing Diffserv category AF43.

5.7. Low latency eMBB and AR/VR [80]

QCI/5QI 80 is intended for low latency eMBB (enhanced Mobile Broadband) applications, such as Augmented Reality of Virtual Reality (AR/VR). 80 priority is 6.8/68, with a low packet delay budget of 10 ms, and a packet error loss rate of at most 10.E-6. 80 is non-GBR, yet intended for real time applications. Traffic in the AR/VR category typically does not react dynamically to losses, requires bandwidth and a low and predictable delay.

As such, QCI/5QI 80 matches closely the specifications for CS4. Therefore, it is RECOMMENDED to map QCI/5QI 80 to the existing category CS4.

5.8. V2X messaging [75,3,9]

Three QCIs/5QIs are intended specifically to carry Vehicle to Anything (V2X) traffic, 75, 3, and 79. All 3 QCIs/5QIs are data in nature, and fit naturally into the AF2x category. However, two of these (75 and 3) are admitted (GBR), and therefore do not fit in the current Diffserv model. 79 is non-admitted, but matches none of the AF2X categories in [RFC4594].

In particular, QCI/5QI 75 is GBR, with a rather high priority (2.5/25), a low delay budget (50 ms), but tolerance to losses (10E-2). Being low latency data in nature, 75 fits well in the AF2X category. However, being admitted, it fits none of the existing markings. Being the highest traffic (in priority) in this low latency data family, 75 is recommended to be mapped to a new category, as close as possible to the AF2X class, and with a low drop probability. As such, it is RECOMMENDED to map QCI/5QI 75 to DSCP 17.

Similarly, QCI/5QI 3 is intended for V2X messages, but can also be used for Real time gaming, or Utility traffic (medium voltage distribution) or process automation monitoring. QCI/5QI 3 priority is 3/30. 3 is data in nature, but GBR. Its delay budget is low (50 ms), but with some tolerance to loss (10E-3).

QCI/5QI 3 is of the same type as QCI/5QI 75, but with a lower priority. Therefore, 3 should be mapped to a category close to the category to which 75 is mapped, but with a higher drop probability. As such, it is RECOMMENDED to map QCI/5QI 3 to DSCP 19.

Additionally, QCI/5QI 79 is also intended for V2X messages. 79 is similar in nature to 75 and 3, but is non-critical (non-GBR). Its priority is also lower (6.5/65). Its budget delay is similar to that of 75 and 3 (50 ms), and its packet error loss rate is similar to that of 75 (10.E-2).

79 partially matches AF2X, but is not elastic, and therefore cannot fit exactly in [RFC4594] model. As such, it is recommended to a mapping similar to QCI/5QIs 75 and 3, with a higher drop probability. Therefore, it is RECOMMENDED to map QCI/5QI 79 to DSCP 21.

5.9. Automation and Transport [82, 83, 84, 85, 86]

QCI/5QI 84 is intended for intelligent transport systems. As such, its intent is close to the V2X messaging category. QCI 84 is also admitted (GBR in [TS 23.203] and Delay-Critical GBR in [TS 23.501]). However, 84 is intended for traffic with a smaller packet delay budget (30 ms vs 50 ms for QCI/5QI 75) and a smaller packet error loss maximum rate (10.E-6 vs 10.E-2 for QCI/5QI 75). As such, 84 should be mapped against a category above that of 75 or 3. Being admitted, 84 does not map easily into an existing category. As such, it is RECOMMENDED to map QCI/5QI 84 to DSCP category 31.

5QI 86 is also intended for intelligent transport systems, and fits in the same general category as 84. 86 is also admitted (Delay-Critical GBR), with a higher priority (18) than 84 but similar burst rate (1354 bytes). 5QI 86 therefore fits into a category close to that of 84. As such, it is RECOMMENDED to map 5QI 86 to DSCP captegory 29.

QCI/5QI 85 is intended for electricity distribution (high voltage) communication. As such, it is close in intent to QCI/5QI 3. 85 is also GBR. However, 85 priority is lower than that of QCI/5QI 3 (2.1/21 vs 3/30). 85 has also a very low packet delay budget (5 ms vs 50 ms for QCI/5QI 3) and low packet error loss rate (10.E-6 vs 10.E-3 for QCI/5QI 3). As such, 84 should be mapped to a category higher than that of QCI/5QI 3,with a very low drop probability. As such, it is RECOMMENDED to map QCI/5QI 85 to DSCP category 23.

QCIs/5QIs 82 and 83 are both intended for discrete automation control traffic. 82 represents traffic with a higher priority (1.9/19) than traffic matched to 83 (priority 2.2/22). 82 also expects smaller data bursts (255 bytes) than 83 (1358 bytes). However, both QCIs are admitted (GBR), with the same low packet delay budget (10 ms) and packet error loss maximum rate (10.E-4).

As such, 82 and 83 fit in the same general category, with a higher drop probability assigned to 83. They also fit the general intent category of automation traffic types, with a priority higher than that of other M2M traffic types (e.g. V2X messages). As such, they fit well into the AF3X category. However, being both admitted (GBR), they do not easily map to any existing AF3X category, and require new categories.

As such, it is RECOMMENDED to map QCI/5QI 82 to DSCP category 25. Similarly, it is RECOMMENDED to map QCI/5QI 83 to DSCP category 79.

5.10. Non-mission-critical data [6,8,9]

QCIs/5QIs 6, 8 and 8 are intended for non-GBR, Video or TCP data traffic. All 3 QCIs/5QIs are data in nature, non-mission critical, relative low priority and therefore fit naturally into the AF1x category. The inclusion in these QCIs/5QIs’ intent of buffered video is an imperfect fit for AF1X. However, the intent of these QCIs/5QIs is to match buffered, and non-mission critical traffic. As such, they match the intent of AF1X, even if the Diffserv model would not associate buffered video to non-mission critical, buffered and low priority traffic.

The intent of all three QCIs/5QIs is similar. The difference lies in their priority and criticality.

QCI/5QI 6 has priority 6/60, a packet delay budget of 300 ms, and a packet error loss rate of at most 10.E-6. QCI/5QI 8 has a priority 8/80, a packet delay budget of 300 ms, and a packet error loss rate of at most 10.E-6. QCI/5QI 9 has priority 9/90, and also a packet delay budget of 300 ms and a packet error loss rate of at most 10.E-6. As these three QCIs/5QIs represent the same intent and are only different in their priority level, using discard eligibility to differentiate them is logical. As such, it is RECOMMENDED to map QCI/5QI 6 to category AF11. Similarly, it is RECOMMENDED to map QCI/5QI 8 to AF12. And logically, it is RECOMMENDED to map QCI/5QI 9 to AF13.

5.11. Mission-critical data [70]

QCI/5QI 70 is non-GBR, intended for mission critical data, with a priority of 5.5/55, a packet delay budget of 200 ms and a packet error loss rate tolerance of at most 10.E-6. The traffic types intended for 70 are the same as for QCIs/5QIs 6,8,9 categories, namely buffered streaming video and TCP-based traffic, such as www, email, chat, FTP, P2P and other file sharing applications. However, 70 is specifically intended for applications that are mission critical. For this reason, 70 priority is higher than 6, 8 or 9 priorities (5.5/55 vs 6/60, 8/80 and 9/90 respectively). Therefore, 70 fits well in the AF2x family, while 6,8,9 are in AF1x. As 70 displays intermediate differentiated treatment, if also fits well with an intermediate discard eligibility. As such, it is RECOMMENDED to map QCI/5QI 70 to DSCP 20 (AF22).

5.12. Summary of Recommendations for QCI or 5QI to DSCP Mapping

The table below summarizes the 3GPP QCI and 5QI to [RFC4594] DSCP marking recommendations:

6. IANA Considerations

This document allocates fourteen codepoints (17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 41, 42 and 43), further detailed in Section 5, in Pool 1 of the code space defined by [RFC2474].

7. Specific Security Considerations

The recommendations in this document concern widely deployed wired and wireless network functionality, and, for that reason, do not present additional security concerns that do not already exist in these networks.

8. Security Recommendations for General QoS

It may be possible for a wired or wireless device (which could be either a host or a network device) to mark packets (or map packet markings) in a manner that interferes with or degrades existing QoS policies. Such marking or mapping may be done intentionally or unintentionally by developers and/or users and/or administrators of such devices.

To illustrate: A gaming application designed to run on a smartphone may request that all its packets be marked DSCP EF. Although the 3GPP infrastructure may only allocate a non-GBR default QCI (e.g. QCI 9) for this traffic, the translation point into the Internet domain may consider the DSCP marking instead of the allocated QCI, and forward this traffic with a marking of EF. This traffic may then interfere with QoS policies intended to provide priority services for business voice applications.

To mitigate such scenarios, it is RECOMMENDED to implement general QoS security measures, including:

• Setting a traffic conditioning policy reflective of business objectives and policy, such that traffic from authorized users and/or applications and/or endpoints will be accepted by the network; otherwise, packet markings will be “bleached” (i.e., re-marked to DSCP DF). Additionally, Section 5 made it clear that it is generally NOT RECOMMENDED to pass through DSCP markings from unauthorized, unidentified and/or unauthenticated devices, as these are typically considered untrusted sources. This is especially relevant for Internet of Things (IoT) deployments, where tens of billions of devices with little or no security capabilities are being connected to LTE and IP networks, leaving them vulnerable to be utilized as agents for DDoS attacks. These attacks can be amplified with preferential QoS treatments, should the packet markings of such devices be trusted.
• Policing EF marked packet flows, as detailed in [RFC2474] Section 7 and [RFC3246] Section 3.

Finally, it should be noted that the recommendations put forward in this document are not intended to address all attack vectors leveraging QoS marking abuse. Mechanisms that may further help mitigate security risks of both wired and wireless networks deploying QoS include strong device- and/or user-authentication, access-control, rate-limiting, control-plane policing, encryption, and other techniques; however, the implementation recommendations for such mechanisms are beyond the scope of this document to address in detail. Suffice it to say that the security of the devices and networks implementing QoS, including QoS mapping between wired and wireless networks, merits consideration in actual deployments.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses