| Network Working Group | J. Henry |
| Internet-Draft | T. Szigeti |
| Expires: October 15, 2019 | Cisco |
| April 13, 2019 |
Diffserv to QCI Mapping-01
draft-henry-tsvwg-diffserv-to-qci-01
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. 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) 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 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 October 15, 2019.
Copyright (c) 2019 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.
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 enabled 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. The purpose of this document is to provide such guidance.
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
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. As such, 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 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). This document draws on this specification, which is being progressively updated; the current version of which (at the time of writing) is 3GPP [TS 23.203] v16.0.
This document is applicable to the use of Differentiated Services that interconnect with 3GPP 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).
This document is organized as follows:
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.
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.
It is important to recognize that LTE 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] v16 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 LTE QoS parameters (e.g. QCI) and vice versa.
As such, LTE 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 are used to define and transport QoS parameters.
It is important to note that LTE standards (4G, 5G) 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:
Each EPS bearer is identified by a name and number, and is associated with specific QoS parameters of various types:
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:
[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.
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).
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.
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).
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:
| QCI | Resource Type | Priority Level | Packet Delay Budget | Packet Error Loss | Example Services |
|---|---|---|---|---|---|
| 1 | GBR | 2 | 100 ms | 10.E-2 | Conversational Voice |
| 2 | GBR | 4 | 150 ms | 10.E-3 | Conversational Video (Live Streaming) |
| 3 | GBR | 3 | 50 ms | 10.E-3 | Real Time Gaming, V2X messages, Electricity distribution (medium voltage) Process automation (monitoring) |
| 4 | GBR | 5 | 300 ms | 10.E-6 | Non-Conversational Video (Buffered Streaming) |
| 65 | GBR | 0.7 | 75 ms | 10.E-2 | Mission Critical user plane Push To Talk voice (e.g., MCPTT) |
| 66 | GBR | 2 | 100 ms | 10.E-2 | Non-Mission-Critical user plane Push To Talk voice |
| 67 | GBR | 1.5 | 100 ms | 10.E-3 | Mission Critical Video user plane |
| 75 | GBR | 2.5 | 50 ms | 10.E-2 | V2X messages |
| 71 | GBR | 5.6 | 150 ms | 10.E-6 | "Live" Uplink Streaming |
| 72 | GBR | 5.6 | 300 ms | 10.E-4 | "Live" Uplink Streaming |
| 73 | GBR | 5.6 | 300 ms | 10.E-8 | "Live" Uplink Streaming |
| 74 | GBR | 5.6 | 500 ms | 10.E-8 | "Live" Uplink Streaming |
| 76 | GBR | 5.6 | 500 ms | 10.E-4 | "Live" Uplink Streaming |
| 5 | Non-GBR | 1 | 100 ms | 10.E-6 | IMS Signalling |
| 6 | Non-GBR | 6 | 300 ms | 10.E-6 | Video (Buffered Streaming) TCP-based (e.g. www, email, chat, ftp, p2p file sharing, progressive video) |
| 7 | Non-GBR | 7 | 100 ms | 10.E-3 | Voice, Video (live streaming), interactive gaming |
| 8 | Non-GBR | 8 | 300 ms | 10.E-6 | Video (buffered streaming) TCP-based (e.g. www, email, chat, ftp, p2p file sharing, progressive video) |
| 9 | Non-GBR | 9 | 300 ms | 10.E-6 | Same as 8 |
| 69 | Non-GBR | 0.5 | 60 ms | 10.E-6 | Mission Critical delay sensitive signalling (e.g., MC-PTT signalling, MC Video signalling) |
| 70 | Non-GBR | 5.5 | 200 ms | 10.E-6 | Mission Critical Data (e.g. example services are the same as QCI 6/8/9) |
| 79 | Non-GBR | 6.5 | 50 ms | 10.E-2 | V2X messages |
| 80 | Non-GBR | 6.8 | 10 ms | 10.E-2 | Low latency eMMB applications (TCP/UDP-based); augmented reality |
| 82 | GBR | 1.9 | 10 ms | 10.E-6 | Discrete automation (small packets) |
| 83 | GBR | 2.2 | 10 ms | 10.E-4 | Discrete automation (large packets) |
| 84 | GBR | 2.4 | 30 ms | 10.E-5 | Intelligent Transport Systems |
| 85 | GBR | 2.1 | 5 ms | 10.E-5 | Electricity Distribution - High Voltage |
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.
[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.
3GPP standards do not define or recommend any specific mapping between each QCI 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:
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.
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:
This document further assumes and RECOMMENDS that all cellular endpoint devices (UE) support the ability to:
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.
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 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 82, thereby admitting it to the Discrete Automation (GBR) category with a relative priority level of 1.9.
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 9, thus admitting it to the non-GBR Buffered video traffic, with a relative priority of 9.
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.
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). 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 1, thus admitting it to the GBR Conversational Voice category, with a relative priority of 2.
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 (i.e., 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 4, thereby admitting it to the GBR Non-conversational video category, with a relative priority level of 5.
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.
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 2, thereby admitting AF41 into the GBR Conversational Video, with a relative priority of 4.
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 2. Specifically, it is RECOMMENDED to map AF42 to QCI 4, thereby admitting AF42 into the GBR Conversational Video, with a relative priority of 5.
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 7, thereby admitting AF437 into the non-GBR Voice, Video and Interactive gaming, with a relative priority of 7.
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 3, thereby admitting Real-Time Interactive traffic into the GBR category Real-time gaming, with a relative priority of 3.
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 4, thereby admitting AF31 into the GBR Non Conversational Video category, with a relative priority of 5.
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 6, thereby admitting AF32 traffic into the non-GBR category Video (Buffered Streaming) with a relative priority of 6.
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 8, thereby admitting AF33 traffic into the non-GBR category Video (Buffered Streaming) with a relative priority of 8.
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 4, thereby admitting Multimedia Streaming into the GBR Non Conversational Video category, with a relative priority of 5. 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 6, thereby admitting Real-Time Interactive traffic into the non-GBR category Video with a relative priority of 6.
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 70, thereby admitting AF21 into the non-GBR Mission Critical Data category, with a relative priority of 5.5.
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 6, thereby admitting AF22 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 6.
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 8, thereby admitting AF23 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 8.
It should be noted that a consequence of such classification is that AF22 is mapped to the same QCI as CS3, and AF23 is mapped to the same QCI as AF33. However, this overlap is unavoidable, as some QCIs express intents that are expressed in the Diffserv domain through distinct marking values, grouped in the 3GPP domain under the same general category.
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 6, thereby admitting AF11 into the non-GBR Video and TCP-based traffic category, with a relative priority of 6.
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 8, thereby admitting AF12 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 8.
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 9, thereby admitting AF13 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 9.
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 as Af33 and AF23, and AF13 is mapped to the same QCI as CS2. However, this overlap is unavoidable, as some QCIs express intents that are expressed in the Diffserv domain through distinct marking values, grouped in the 3GPP domain under the same general category.
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 "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 9, thereby admitting it to the low priority Video and TCP-based traffic category, with a relative priority of 9.
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 [LE-PHB]. [RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP.
Note: This marking recommendation may change in the future, as [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic.
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 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 to QCI 9, thereby admitting it to the low priority Video and TCP-based traffic category, with a relative priority of 9.
The table below summarizes the [RFC4594] DSCP marking recommendations mapped to 3GPP:
| DSCP | Recommended QCI | Resource Type | Priority Level |
|---|---|---|---|
| CS7 | 82 | GBR | 1.9 |
| CS6 | 82 | GBR | 1.9 |
| EF | 1 | GBR | 2 |
| CS5 | 4 | GBR | 5 |
| AF43 | 7 | non-GBR | 7 |
| AF42 | 4 | GBR | 5 |
| AF41 | 2 | GBR | 4 |
| CS4 | 80 3 | non-BGR GBR | 6.8 3 |
| AF33 | 8 | non-GBR | 8 |
| AF32 | 6 | non-GBR | 6 |
| AF31 | 4 | GBR | 5 |
| CS3 | 85 | GBR | 2.1 |
| AF23 | 8 | Non-GBR | 8 |
| AF22 | 6 | Non-GBR | 6 |
| AF21 | 70 | Non-GBR | 5.5 |
| CS2 | 9 | Non-GBR | 9 |
| AF13 | 9 | Non-GBR | 9 |
| AF12 | 8 | Non-GBR | 8 |
| AF11 | 6 | Non-GBR | 6 |
| CS0 | 9 | Non-GBR | 9 |
| CS1 | 9 | Non-GBR | 6.8 |
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 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 QCI to Diffserv ignores the QCI 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.
The QCIs 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 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 structure presents multiple points where dimensions cross one another with different or opposing vectors. For example, IMS signaling (QCI 5) is defined with very high priority (1), low loss tolerance (10-6), but is non-GBR and belongs to the signaling category. By contrast, Conversational voice (QCI 1) has lower priority (2) than IMS signaling, higher loss tolerance (10-2), yet benefits from a GBR. Fitting both QCIs 5 and 1 in a hierarchical model is challenging.
At the same time, QCIs represents needs that can apply to different applications of various criticality but sending flows of the same nature. For example, QCIs 6, 8 and 9 all include voice traffic, video traffic, but also email or FTP. What distinguish these QCIs 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, QCI 2 and QCI 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 can be mapped to the Diffserv model strictly and hierarchically. Instead, a better approach is to observe the various QCI categories, and analyze their intent. This process allows for the grouping of several QCIs 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 as the 3GPP model continues to evolve.
It should be noted, however, that such approach results in partial incompatibility. Some QCIs represent an intent that is simply not present in the Diffserv model. In that case, attempting to artificially stitch the QCI to an existing Diffserv traffic class and marking would be dangerous. QCI 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 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, including an Example Services value. This parameter is representative of the QCI intent. Although [TS 23.203] summarizes each QCI intent, this standard is only a summary of more complex classification expressed in other 3GPP standards. It is often necessary to refer to these other standards to obtain a more complex description of each QCI and the multiple type of flows that each QCI represents.
For the purpose of this document, the QCI 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. The resource types (GBR, non-GBR) provide additional visibility into the intent.
Although 26 QCIs are listed in [TS 23.203], representing two bearer types (GBR, non-GBR), 21 priority values, 9 delay budget values, and 7 loss tolerance values, examining the intent surfaces 9 traffic families:
Several QCIs are intended to carry voice traffic. However, QCI 1 stands apart from the others. Its category is Conversational Voice, but this QCI is intended to represent the VoLTE voice bearer, for dialer and emergency services. QCI 1 uses a GBR, and has a priority level of 2. 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 1 is both admitted and allocated dedicated resources. As such, QCI 1 maps in intent and function to [RFC5865], Admitted Voice, and is RECOMMENDED for mapping to DSCP 44.
QCI 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 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 5 is non-GBR. However, being critical to enabling IMS real-time applications, QCI has a high priority of 1. Its packet delay budget is 100 ms, but packet error loss rate very low, at less than 10.E-6. Overall, QCI 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.
Several QCIs display the commonality of targeting voice (non-VoLTE) traffic:
These QCI 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. 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, 69 is non-GBR, intended for mission-critical PTT signaling, with the highest priority of the three, at 0.5. QCI 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 69 has proximity of intent with CS5 (Voice signaling, 40), but this marking is already used by QCI 5. Therefore, it is RECOMMENDED to map QCI 69 to a new DSCP marking, 41.
Similarly, QCI 66 is GBR and targeted for non-mission critical PTT voice, with a priority level of 2. QCI 66 is Voice in nature, and GBR. However, QCI 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, QCI 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 fits in intent and proximity closest to Admitted Voice, but is non-GBR, and therefore non-admitted, guiding a new suggested marking of 43.
Then, QCI 65 is GBR, intended for mission critical PTT voice, with a relative low priority index of 0.7. QCI 65 receives GBR and is intended for mission critical traffic. Its priority is higher (0.7 vs 2) than QCI 66, but a lower priority (0.7 vs 0.5) than QCI 69. Additionally, QCI 65 cannot be represented by DSCP 44 (used by QCI 1), or DSCP 46 (use by non-GBR voice). As such, QCI 65 fits between QCI 69 and QCI 66, with a new suggested marking of 42.
Although six different QCIs have example services that include some form of video traffic, eight QCIs are video in nature, QCIs 67, 2, 4, 71, 72, 73, 74, and 76.
All eight QCIs represent video streams and fit naturally in the AF4x category. However, these QCIs 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 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 to new Diffserv classes.
In particular, QCI 67 is GBR, intended for mission-critical video user plane. This QCI is video in nature, and matches traffic that is rate-adaptive, and real time. QCI 67 priority is high (1.5), with a tolerant delay budget (100ms) and rather low loss tolerance (10.E-3). QCI 67 is GBR.
As such, its RECOMMENDED to map QCI 67 against the DSCP value closest to AF4x video with lowest discard eligibility (AF41), namely category 33.
Similarly, QCI 2 is intended for conversational video (live streaming). This QCI 2 is also video in nature and associated to a GBR, however its priority is lower than QCI 67 (4 vs 1.5). Additionally, its delay budget is also larger (150 ms vs 100 ms). Its packet error loss is also 10.E-3. As such, QCI 2 fits well within a video queue, with a larger drop probability than QCI 67. Therefore, it is RECOMMENDED to map QCI 2 to the video category with a Diffserv marking of 35.
QCI 4 is intended for non-conversational video (buffered streaming), with a priority of 5. This QCI is also video in nature. Although it is buffered, it is admitted, being associated to a GBR. QCI 4 as a lower priority than QCI 67 and QCI 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 QCI 67 and 2. Therefore, it is RECOMMENDED to map QCI 4 to DSCP 37.
QCIs 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.239] 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).
QCI 7 is non-GBR and intended for live streaming voice or video interactive gaming. Its priority is 7. It is the only QCI 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 2 for video Live streaming, with a priority of 2, or QCI 67 for mission-critical video, with a priority of 1.5). By comparison, QCI 7 priority is relatively low (7), with a 100 ms budget delay and a comparatively rather high loss tolerance (10.E-3).
As such, QCI 7 first 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 7 to the existing Diffserv category AF43.
QCI 80 is intended for low latency eMBB (enhanced Mobile Broadband) applications, such as Augmented Reality of Virtual Reality (AR/VR). This QCI priority is 6.8,with a low packet delay budget of 10 ms, and a packet error loss rate of at most 10.E-6.
QCI 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 80 matches closely the specifications for CS4. Therefore, it is RECOMMENDED to map QCI 80 to the existing category CS4.
Three QCIs are intended specifically to carry Vehicle to Anything (V2X) traffic, QCIs 75, 3, and 79. All 3 QCIs are data in nature, and fit naturally into the AF2x category. However, two of these QCIs (75 and 3) are admitted (GBR), and therefore do not fit in the current Diffserv model. QCI 79 is non-admitted, but matches none of the AF2X categories in [RFC4594].
In particular, QCI 75 is GBR, with a rather high priority (2.5), a low delay budget (50 ms), but tolerance to losses (10E-2). Being low latency data in nature, QCI 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, QCI 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 75 to DSCP 17.
Similarly, QCI 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 3 priority is 3. QCI 3 is data in nature, but GBR. Its delay budget is low (50 ms), but with some tolerance to loss (10E-3).
QCI 3 is of the same type as QCI 75, but with a lower priority. Therefore, QCI 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 3 to DSCP 19.
Additionally, QCI 79 is also intended for V2X messages. QCI 79 similar in nature to QCIs 75 and 3, but is non-critical (non-GBR). Its priority is also lower (6.5). Its budget delay is similar to that of QCIs 75 and 3 (50 ms), and its packet error loss rate is similar to that of QCI 75 (10.E-2).
QCI 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 75 and 3, with a higher drop probability. Therefore, it is RECOMMENDED to map QCI 79 to DSCP 21.
QCI 84 is intended for intelligent transport systems. As such, its intent is close to the V2X messaging category. QCI 84 is also admitted (GBR). However, QCI 84 is intended for traffic with a smaller packet delay budget (30 ms vs 50 ms for QCI 75) and a smaller packet error loss maximum rate (10.E-6 vs 10.E-2 for QCI 75).As such, QCI 84 should be mapped against a category above that of QCIs 75 or QCI 3. Being admitted, QCI 84 does not map easily into an existing category. As such, it is RECOMMENDED to map QCI 84 to category 31.
QCI 85 is intended for electricity distribution (high voltage) communication. As such, it is close in intent to QCI 3. QCI 85 is also GBR. However, QCI 85 priority is lower than that of QCI 3 (2.1 vs 3). QCI 85 has also a very low packet delay budget (5 ms vs 50 ms for QCI 3) and low packet error loss rate (10.E-6 vs 10.E-3 for QCI 3). As such, QCI 84 should be mapped to a category higher than that of QCI 3,with a very low drop probability. As such, it is RECOMMENDED to map QCI 85 to category 25.
QCIs 82 and 83 are both intended for discrete automation control traffic. QCI 82 represents traffic with a higher priority (1.9) than traffic matched to QCI 83 (priority 2.2). QCI 82 also expects smaller data bursts (255 bytes) than QCI 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, QCIs 82 and 83 fit in the same general category, with a higher drop probability assigned to QCI 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 82 to category 27. Similarly, it is RECOMMENDED to map QCI 83 to category 29.
QCIs 6, 8 and 8 are intended for non-GBR, Video or TCP data traffic. All 3 QCIs are data in nature, non-mission critical, relative low priority and therefore fit naturally into the AF1x category. The inclusion in these QCIs' intent of buffered video is an imperfect fit for AF1X. However, the intent of these QCIs 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 is similar. The difference lies in their priority and criticality.
QCI 6 has priority 6, a packet delay budget of 300 ms, and a packet error loss rate of at most 10.E-6. QCI 8 has a priority 8, a packet delay budget of 300 ms, and a packet error loss rate of at most 10.E-6. QCI 9 has priority 9, 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 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 6 to category AF11. Similarly, it is RECOMMENDED to map QCI 8 to AF12. And logically, it is RECOMMENDED to map QCI 9 to AF13.
QCI 70 is non-GBR, intended for mission critical data, with a priority of 5.5, 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 QCI 70 are the same as for QCIs 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, QCI 70 is specifically intended for applications that are mission critical. For this reason, QCI 70 priority is higher than QCIs 6, 8 or 9 priorities (5.5 vs 6, 8 and 9 respectively). Therefore, QCI 70 fits well in the AF2x family, while 6,8,9 are in AF1x. As QCI 70 displays intermediate differentiated treatment, if also fits well with an intermediate discard eligibility. As such, it is RECOMMENDED to map QCI 70 to DSCP 20 (AF22).
The table below summarizes the 3GPP QCI to [RFC4594] DSCP marking recommendations:
| QCI | Resource Type | Priority Level | Example Services | Recommended DSCP (PHB) |
|---|---|---|---|---|
| 1 | GBR | 2 | Conversational Voice | 44 (VA) |
| 2 | GBR | 4 | Conversational Video (Live Streaming) | 35 (N.A.) |
| 3 | GBR | 3 | Real Time Gaming, V2X messages, Electricity distribution (medium voltage) Process automation (monitoring) | 19 (N.A.) |
| 4 | GBR | 5 | Non-Conversational Video (Buffered Streaming) | 37 (N.A.) |
| 65 | GBR | 0.7 | Mission Critical user plane Push To Talk voice (e.g., MCPTT) | 42 (N.A.) |
| 66 | GBR | 2 | Non-Mission-Critical user plane Push To Talk voice | 43 (N.A.) |
| 67 | GBR | 1.5 | Mission Critical Video user plane | 33 (N.A.) |
| 75 | GBR | 2.5 | V2X messages | 17 (N.A.) |
| 82 | GBR | 1.9 | Discrete automation (small packets) | 27 (N.A.) |
| 83 | GBR | 2.2 | Discrete automation (large packets) | 29 (N.A.) |
| 84 | GBR | 2.4 | Intelligent Transport Systems | 31 (N.A.) |
| 85 | GBR | 2.1 | Electricity Distribution - High Voltage | 25 (N.A.) |
| 5 | Non-GBR | 1 | IMS Signalling | 40 (CS5) |
| 6 | Non-GBR | 6 | Video (Buffered Streaming) TCP-based (e.g. www, email, chat, ftp, p2p file sharing, progressive video) | 10 (AF11) |
| 7 | Non-GBR | 7 | Voice, Video (live streaming), interactive gaming | 38 (AF43) |
| 8 | Non-GBR | 8 | Video (buffered streaming) TCP-based (e.g. www, email, chat, ftp, p2p file sharing, progressive video) | 12 (AF12) |
| 9 | Non-GBR | 9 | Same as 8 | 14 (AF13) |
| 69 | Non-GBR | 0.5 | Mission Critical delay sensitive signalling (e.g., MC-PTT signalling, MC Video signalling) | 41 (N.A.) |
| 70 | Non-GBR | 5.5 | Mission Critical Data (e.g. example services are the same as QCI 6/8/9) | 20 (AF22) |
| 79 | Non-GBR | 6.5 | V2X messages | 21 (N.A.) |
| 80 | Non-GBR | 6.8 | Low latency eMMB applications (TCP/UDP-based); augmented reality | 32 (CS4) |
This document allocates thirteen codepoints (17, 19, 21, 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].
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.
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:
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.
| [RFC2474] | Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998. |
| [RFC2597] | Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999. |
| [RFC3246] | Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002. |
| [RFC5865] | Baker, F., Polk, J. and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010. |