Internet DRAFT - draft-henry-tsvwg-diffserv-to-qci
draft-henry-tsvwg-diffserv-to-qci
Network Working Group J. Henry
Internet-Draft T. Szigeti
Intended status: Informational Cisco
Expires: October 15, 2020 L. Contreras
Telefonica
April 13, 2020
Diffserv to QCI Mapping
draft-henry-tsvwg-diffserv-to-qci-04
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
Henry, et al. Expires October 15, 2020 [Page 1]
Internet-Draft DIFFSERV-QCI April 2020
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, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
1.4. Requirements language . . . . . . . . . . . . . . . . . . 6
1.5. Terminology Used in this Document . . . . . . . . . . . . 6
2. Service Comparison and Default Interoperation of Diffserv and
3GPP LTE and 5G . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 7
2.2. QCI and Bearer Model in 3GPP . . . . . . . . . . . . . . 8
2.3. QCI Definition and Logic . . . . . . . . . . . . . . . . 9
2.3.1. Conversational . . . . . . . . . . . . . . . . . . . 9
2.3.2. Streaming . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Interactive . . . . . . . . . . . . . . . . . . . . . 10
2.3.4. Background . . . . . . . . . . . . . . . . . . . . . 10
2.4. QCI implementations . . . . . . . . . . . . . . . . . . . 13
2.5. 5QI and flow-based QoS Model in 3GPP 5G . . . . . . . . . 13
2.6. GSMA IPX Guidelines Interpretation and Conflicts . . . . 17
3. P-GW Device Marking and Mapping Capability Recommendations . 18
4. DSCP to QCI or 5QI Mapping Recommendations . . . . . . . . . 19
4.1. Control Traffic . . . . . . . . . . . . . . . . . . . . . 19
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 19
4.1.2. Operations, Administration, and Maintenance (OAM) . . 20
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 21
Henry, et al. Expires October 15, 2020 [Page 2]
Internet-Draft DIFFSERV-QCI April 2020
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 22
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 22
4.2.5. Multimedia Streaming . . . . . . . . . . . . . . . . 23
4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 23
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 24
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 25
4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 25
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 26
4.3. Summary of Recommendations for DSCP-to-QCI Mapping . . . 26
5. QCI and 5QI to DSCP Mapping Recommendations . . . . . . . . . 28
5.1. QCI, 5QI and Diffserv Logic Reconciliation . . . . . . . 28
5.2. Voice [1] . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3. IMS Signaling [5] . . . . . . . . . . . . . . . . . . . . 31
5.4. Voice-related QCIs and 5QIs [65, 66, 69] . . . . . . . . 31
5.5. Video QCIs and 5QIs [67, 2, 4, 71, 72, 73, 74, 76] . . . 32
5.6. Live streaming and interactive gaming [7] . . . . . . . . 34
5.7. Low latency eMBB and AR/VR [80] . . . . . . . . . . . . . 34
5.8. V2X messaging [75,3,9] . . . . . . . . . . . . . . . . . 35
5.9. Automation and Transport [82, 83, 84, 85, 86] . . . . . . 35
5.10. Non-mission-critical data [6,8,9] . . . . . . . . . . . . 36
5.11. Mission-critical data [70] . . . . . . . . . . . . . . . 37
5.12. Summary of Recommendations for QCI or 5QI to DSCP Mapping 37
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
7. Specific Security Considerations . . . . . . . . . . . . . . 40
8. Security Recommendations for General QoS . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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
Henry, et al. Expires October 15, 2020 [Page 3]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 4]
Internet-Draft DIFFSERV-QCI April 2020
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:
o 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.
o Section 3 provides general recommendations for QoS support at the
3GPP / Diffserv domains boundaries.
o 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.
o 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.
o Section 6 underlines the resulting IANA requirements for this
mapping.
o Section 7 and Section 8 examine the security consequences of these
new mapping schemes.
Henry, et al. Expires October 15, 2020 [Page 5]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 6]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 7]
Internet-Draft DIFFSERV-QCI April 2020
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:
o 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.
o 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.
Henry, et al. Expires October 15, 2020 [Page 8]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 9]
Internet-Draft DIFFSERV-QCI April 2020
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:
+----+----------+----------+--------+--------+----------------------+
| QC | Resource | Priority | Packet | Packet | Example Services |
| I | Type | Level | Delay | Error | |
| | | | Budget | Loss | |
Henry, et al. Expires October 15, 2020 [Page 10]
Internet-Draft DIFFSERV-QCI April 2020
+----+----------+----------+--------+--------+----------------------+
| 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 |
Henry, et al. Expires October 15, 2020 [Page 11]
Internet-Draft DIFFSERV-QCI April 2020
| | | | | | |
| 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 |
| | | | | | |
Henry, et al. Expires October 15, 2020 [Page 12]
Internet-Draft DIFFSERV-QCI April 2020
| 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.
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
Henry, et al. Expires October 15, 2020 [Page 13]
Internet-Draft DIFFSERV-QCI April 2020
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:
o Resource type, i.e., if the flow requires resources to be
allocated for Guaranteed Bandwidth Rate (GBR), delay critical GBR
(DCGBR), or non-GBR.
o Default priority level
o Packet delay budget (PDB), including the PDB consumed in the 5G
core network
o Packet Error Rate (PER)
o Averaging window (in milliseconds), applicable for GBR and delay-
critical GBR
o Default maximum data burst volume (in bytes), applicable for
delay-critical GBR only
The following table shows a simplified version from the standardized
[TS 23.501] 5QI to QoS characteristics mapping.
+----+-------+-------+------+-------+-------+-------+---------------+
| 5Q | Resou | Prior | Pack | Packe | Defau | Defau | Example |
| I | rce | ity | et D | t | lt | lt | Services |
| | Type | Level | elay | Error | Max | Avg W | |
| | | | Budg | Rate | Burst | indow | |
| | | | et | | | | |
+----+-------+-------+------+-------+-------+-------+---------------+
| 1 | GBR | 20 | 100 | 10.E- | N/A | 2000 | Conversationa |
| | | | ms | 2 | | | l voice |
| | | | | | | | |
| 2 | GBR | 40 | 150 | 10.E- | N/A | 2000 | Conversationa |
| | | | ms | 3 | | | l video (live |
| | | | | | | | streaming) |
| | | | | | | | |
| 3 | GBR | 30 | 50 | 10.E- | N/A | 2000 | Real time |
| | | | ms | 3 | | | gaming, V2X |
| | | | | | | | messages, |
| | | | | | | | medium |
| | | | | | | | voltage |
| | | | | | | | electricity |
Henry, et al. Expires October 15, 2020 [Page 14]
Internet-Draft DIFFSERV-QCI April 2020
| | | | | | | | dist. |
| | | | | | | | |
| 4 | GBR | 50 | 300 | 10.E- | N/A | 2000 | non-conversat |
| | | | ms | 6 | | | ional video |
| | | | | | | | (buffered |
| | | | | | | | streaming) |
| | | | | | | | |
| 65 | GBR | 7 | 75 | 10.E- | N/A | 2000 | Mission |
| | | | ms | 2 | | | critical user |
| | | | | | | | plane push- |
| | | | | | | | to-talk voice |
| | | | | | | | (e.g. MCPTT) |
| | | | | | | | |
| 66 | GBR | 20 | 100 | 10.E- | N/A | 2000 | Non-mission |
| | | | ms | 3 | | | critical user |
| | | | | | | | plane push- |
| | | | | | | | to-talk voice |
| | | | | | | | |
| 67 | GBR | 15 | 100 | 10.E- | N/A | 2000 | Mission |
| | | | ms | 3 | | | critical user |
| | | | | | | | plane video |
| | | | | | | | |
| 71 | GBR | 56 | 150 | 10.E- | N/A | 2000 | "Live" uplink |
| | | | ms | 6 | | | streaming |
| | | | | | | | |
| 72 | GBR | 56 | 300 | 10.E- | N/A | 2000 | "Live" uplink |
| | | | ms | 4 | | | streaming |
| | | | | | | | |
| 73 | GBR | 56 | 300 | 10.E- | N/A | 2000 | "Live" uplink |
| | | | ms | 8 | | | streaming |
| | | | | | | | |
| 74 | GBR | 56 | 500 | 10.E- | N/A | 2000 | "Live" uplink |
| | | | ms | 8 | | | streaming |
| | | | | | | | |
| 76 | GBR | 56 | 500 | 10.E- | N/A | 2000 | "Live" uplink |
| | | | ms | 4 | | | streaming |
| | | | | | | | |
| 5 | non- | 10 | 100 | 10.E- | N/A | N/A | IMS signaling |
| | GBR | | ms | 6 | | | |
| | | | | | | | |
| 6 | non- | 60 | 300 | 10.E- | N/A | N/A | Video |
| | GBR | | ms | 6 | | | (Buffered |
| | | | | | | | Streaming) |
| | | | | | | | TCP-based |
| | | | | | | | (e.g. www, |
| | | | | | | | email, chat, |
| | | | | | | | etc.) |
| | | | | | | | |
Henry, et al. Expires October 15, 2020 [Page 15]
Internet-Draft DIFFSERV-QCI April 2020
| 7 | non- | 70 | 100 | 10.E- | N/A | N/A | Voice, Video |
| | GBR | | ms | 3 | | | (live |
| | | | | | | | streaming), |
| | | | | | | | interactive |
| | | | | | | | gaming |
| | | | | | | | |
| 8 | non- | 80 | 300 | 10.E- | N/A | N/A | Video |
| | GBR | | ms | 6 | | | (Buffered |
| | | | | | | | Streaming) |
| | | | | | | | TCP-based |
| | | | | | | | (e.g. www, |
| | | | | | | | email, chat, |
| | | | | | | | etc.) |
| | | | | | | | |
| 9 | non- | 90 | 300 | 10.E- | N/A | N/A | Same as 8 |
| | GBR | | ms | 6 | | | |
| | | | | | | | |
| 69 | non- | 5 | 60 | 10.E- | N/A | N/A | Mission |
| | GBR | | ms | 6 | | | Critical |
| | | | | | | | delay |
| | | | | | | | sensitive |
| | | | | | | | signalling |
| | | | | | | | (e.g., MC- |
| | | | | | | | PMC) |
| | | | | | | | |
| 70 | non- | 55 | 200 | 10.E- | N/A | N/A | Mission |
| | GBR | | ms | 6 | | | critical data |
| | | | | | | | (e.g. same |
| | | | | | | | examples as |
| | | | | | | | QCI/5QI 6,7,8 |
| | | | | | | | |
| 79 | non- | 65 | 50 | 10.E- | N/A | N/A | V2X messages |
| | GBR | | ms | 2 | | | |
| | | | | | | | |
| 80 | non- | 68 | 10 | 10.E- | N/A | N/A | Low latency |
| | GBR | | ms | 6 | | | eMMB |
| | | | | | | | applications |
| | | | | | | | (TCP/UDP- |
| | | | | | | | based); |
| | | | | | | | augmented |
| | | | | | | | reality |
| | | | | | | | |
| 82 | DCGBR | 19 | 10 | 10.E- | 255 B | 2000 | Discrete |
| | | | ms | 4 | | ms | automation |
| | | | | | | | |
| 83 | DCGBR | 22 | 10 | 10.E- | 1354 | 2000 | Discrete |
| | | | ms | 4 | B | ms | automation |
| | | | | | | | |
Henry, et al. Expires October 15, 2020 [Page 16]
Internet-Draft DIFFSERV-QCI April 2020
| 84 | DCGBR | 24 | 30 | 10.E- | 1354 | 2000 | Intelligent |
| | | | ms | 5 | B | ms | Transport |
| | | | | | | | Systems |
| | | | | | | | |
| 85 | DCGBR | 21 | 5 ms | 10.E- | 255 B | 2000 | Electricity |
| | | | | 5 | | ms | distribution, |
| | | | | | | | High voltage, |
| | | | | | | | V2X |
| | | | | | | | |
| 86 | DCGBR | 18 | 5 ms | 10.E- | 1354 | 2000 | V2X, |
| | | | | 4 | B | ms | collision |
| | | | | | | | avoidance, |
| | | | | | | | platooning, |
| | | | | | | | self driving |
+----+-------+-------+------+-------+-------+-------+---------------+
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
Henry, et al. Expires October 15, 2020 [Page 17]
Internet-Draft DIFFSERV-QCI April 2020
types under each 3GPP general class were added. As such, the GSMA
recommendations yield to several inconsistencies with [RFC4594],
including:
o Recommending EF for real-time (conversational) video, for which
[RFC4594] recommends AF41.
o Recommending AF31 for DNS traffic, for which [RFC4594] recommends
the standard service class (DF)
o 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.
o Recommending AF21 for WAP browsing and WEB browsing, for which
[RFC4594] recommends the High Throughput data class
o Recommending AF11 for remote connection protocols, such as telnet
or SSH, for which [RFC4594] recommends the OAM class.
o Recommending DF for file transfers, for which [RFC4594] recommends
the High Throughput Data class.
o Recommending DF for email exchanges, for which [RFC4594]
recommends the High Throughput Data class.
o 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:
Henry, et al. Expires October 15, 2020 [Page 18]
Internet-Draft DIFFSERV-QCI April 2020
o mark DSCP, per Diffserv standards
o mark QCI, per the [TS 23.203] standard, or 5QI, as per the [TS
23.501] standard
o support fully-configurable mappings between DSCP and QCI or 5QI
o process DSCP markings set by cellular endpoint devices
This document further assumes and RECOMMENDS that all cellular
endpoint devices (UE) support the ability to:
o mark DSCP, per Diffserv standards
o mark QCI, per the [TS 23.203] standard, OR 5QI, per the [TS
23.501] standard
o 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
Henry, et al. Expires October 15, 2020 [Page 19]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 20]
Internet-Draft DIFFSERV-QCI April 2020
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
Henry, et al. Expires October 15, 2020 [Page 21]
Internet-Draft DIFFSERV-QCI April 2020
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
Henry, et al. Expires October 15, 2020 [Page 22]
Internet-Draft DIFFSERV-QCI April 2020
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,
Henry, et al. Expires October 15, 2020 [Page 23]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 24]
Internet-Draft DIFFSERV-QCI April 2020
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]
Henry, et al. Expires October 15, 2020 [Page 25]
Internet-Draft DIFFSERV-QCI April 2020
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:
Henry, et al. Expires October 15, 2020 [Page 26]
Internet-Draft DIFFSERV-QCI April 2020
+------+--------------------+---------------+-----------------------+
| DSCP | Recommended | Resource Type | Priority Level |
| | QCI/5QI | | (QCI/5QI) |
+------+--------------------+---------------+-----------------------+
| CS7 | 82 | GBR | 1.9 / 19 |
| | | | |
| CS6 | 82 | GBR | 1.9 / 19 |
| | | | |
| EF | 1 | GBR | 2 / 20 |
| | | | |
| CS5 | 4 | GBR | 5 / 50 |
| | | | |
| AF43 | 7 | non-GBR | 7 / 70 |
| | | | |
| AF42 | 4 | GBR | 5 / 50 |
| | | | |
| AF41 | 2 | GBR | 4 / 40 |
| | | | |
| CS4 | 80 3 | non-BGR GBR | 6.8 / 68, 3 / 30 |
| | | | |
| AF33 | 8 | non-GBR | 8 / 80 |
| | | | |
| AF32 | 6 | non-GBR | 6 / 60 |
| | | | |
| AF31 | 4 | GBR | 5 / 50 |
| | | | |
| CS3 | 85 | GBR | 2.1 / 21 |
| | | | |
| AF23 | 8 | Non-GBR | 8 / 80 |
| | | | |
| AF22 | 6 | Non-GBR | 6 / 60 |
| | | | |
| AF21 | 70 | Non-GBR | 5.5 / 55 |
| | | | |
| CS2 | 9 | Non-GBR | 9 / 90 |
| | | | |
| AF13 | 9 | Non-GBR | 9 / 90 |
| | | | |
| AF12 | 8 | Non-GBR | 8 / 80 |
| | | | |
| AF11 | 6 | Non-GBR | 6 / 60 |
| | | | |
| CS0 | 9 | Non-GBR | 9 / 90 |
| | | | |
| CS1 | 9 | Non-GBR | 6.8 / 68 |
| | | | |
| LE | 9 | Non-GBR | 6.8 / 68 |
+------+--------------------+---------------+-----------------------+
Henry, et al. Expires October 15, 2020 [Page 27]
Internet-Draft DIFFSERV-QCI April 2020
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
Henry, et al. Expires October 15, 2020 [Page 28]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 29]
Internet-Draft DIFFSERV-QCI April 2020
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]
Henry, et al. Expires October 15, 2020 [Page 30]
Internet-Draft DIFFSERV-QCI April 2020
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:
o QCI/5QI 65 is GBR, mission critical PTT voice, priority 0.7/7
o QCI/5QI 66 is GBR, non-mission critical PTT voice, priority 2/20
o 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
Henry, et al. Expires October 15, 2020 [Page 31]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 32]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 33]
Internet-Draft DIFFSERV-QCI April 2020
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.
Henry, et al. Expires October 15, 2020 [Page 34]
Internet-Draft DIFFSERV-QCI April 2020
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
Henry, et al. Expires October 15, 2020 [Page 35]
Internet-Draft DIFFSERV-QCI April 2020
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
Henry, et al. Expires October 15, 2020 [Page 36]
Internet-Draft DIFFSERV-QCI April 2020
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:
+--------+----------+----------+----------------------+-------------+
| QCI/5Q | Resource | Priority | Example Services | Recommended |
| I | Type | Level | | DSCP (PHB) |
+--------+----------+----------+----------------------+-------------+
| 1 | GBR | 2 | Conversational Voice | 44 (VA) |
| | | | | |
| 2 | GBR | 4 | Conversational Video | 35 (N.A.) |
| | | | (Live Streaming) | |
| | | | | |
Henry, et al. Expires October 15, 2020 [Page 37]
Internet-Draft DIFFSERV-QCI April 2020
| 3 | GBR | 3 | Real Time Gaming, | 19 (N.A.) |
| | | | V2X messages, | |
| | | | Electricity | |
| | | | distribution (medium | |
| | | | voltage) Process | |
| | | | automation | |
| | | | (monitoring) | |
| | | | | |
| 4 | GBR | 5 | Non-Conversational | 37 (N.A.) |
| | | | Video (Buffered | |
| | | | Streaming) | |
| | | | | |
| 65 | GBR | 0.7 | Mission Critical | 42 (N.A.) |
| | | | user plane Push To | |
| | | | Talk voice (e.g., | |
| | | | MCPTT) | |
| | | | | |
| 66 | GBR | 2 | Non-Mission-Critical | 43 (N.A.) |
| | | | user plane Push To | |
| | | | Talk voice | |
| | | | | |
| 67 | GBR | 1.5 | Mission Critical | 33 (N.A.) |
| | | | Video user plane | |
| | | | | |
| 75 | GBR | 2.5 | V2X messages | 17 (N.A.) |
| | | | | |
| 71 | GBR | 5.6 | Live uplink | 35 (N.A.) |
| | | | streaming | |
| | | | | |
| 72 | GBR | 5.6 | Live uplink | 35 (N.A.) |
| | | | streaming | |
| | | | | |
| 73 | GBR | 5.6 | Live uplink | 35 (N.A.) |
| | | | streaming | |
| | | | | |
| 74 | GBR | 5.6 | Live uplink | 35 (N.A.) |
| | | | streaming | |
| | | | | |
| 76 | GBR | 5.6 | Live uplink | 35 (N.A.) |
| | | | streaming | |
| | | | | |
| 82 | GBR | 1.9 | Discrete automation | 25 (N.A.) |
| | | | (small packets) | |
| | | | | |
| 83 | GBR | 2.2 | Discrete automation | 27 (N.A.) |
| | | | (large packets) | |
| | | | | |
| 84 | GBR | 2.4 | Intelligent | 31 (N.A.) |
Henry, et al. Expires October 15, 2020 [Page 38]
Internet-Draft DIFFSERV-QCI April 2020
| | | | Transport Systems | |
| | | | | |
| 85 | GBR | 2.1 | Electricity | 23 (N.A.) |
| | | | Distribution - High | |
| | | | Voltage | |
| | | | | |
| 86 | GBR | 1.8 | Intelligent | 29 (N.A.) |
| | | | Transport Systems | |
| | | | | |
| 5 | Non-GBR | 1 | IMS Signalling | 40 (CS5) |
| | | | | |
| 6 | Non-GBR | 6 | Video (Buffered | 10 (AF11) |
| | | | Streaming) TCP-based | |
| | | | (e.g. www, email, | |
| | | | chat, ftp, p2p file | |
| | | | sharing, progressive | |
| | | | video) | |
| | | | | |
| 7 | Non-GBR | 7 | Voice, Video (live | 38 (AF43) |
| | | | streaming), | |
| | | | interactive gaming | |
| | | | | |
| 8 | Non-GBR | 8 | Video (buffered | 12 (AF12) |
| | | | streaming) TCP-based | |
| | | | (e.g. www, email, | |
| | | | chat, ftp, p2p file | |
| | | | sharing, progressive | |
| | | | video) | |
| | | | | |
| 9 | Non-GBR | 9 | Same as 8 | 14 (AF13) |
| | | | | |
| 69 | Non-GBR | 0.5 | Mission Critical | 41 (N.A.) |
| | | | delay sensitive | |
| | | | signalling (e.g., | |
| | | | MC-PTT signalling, | |
| | | | MC Video signalling) | |
| | | | | |
| 70 | Non-GBR | 5.5 | Mission Critical | 20 (AF22) |
| | | | Data (e.g. example | |
| | | | services are the | |
| | | | same as QCI 6/8/9) | |
| | | | | |
| 79 | Non-GBR | 6.5 | V2X messages | 21 (N.A.) |
| | | | | |
| 80 | Non-GBR | 6.8 | Low latency eMMB | 32 (CS4) |
| | | | applications | |
| | | | (TCP/UDP-based); | |
| | | | augmented reality | |
Henry, et al. Expires October 15, 2020 [Page 39]
Internet-Draft DIFFSERV-QCI April 2020
+--------+----------+----------+----------------------+-------------+
6. IANA Considerations
This document has no IANA actions. Although this document suggests
the use of codepoints in the Pool 1 of the codespace defined in
[RFC2474], no exclusive attribution is requested. The recommended
utilisation of seven codepoints in Pool 2 and six codepoints in pool
3 is also intended as a recommendation for experimental or Local Use,
as defined in [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:
o 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,
Henry, et al. Expires October 15, 2020 [Page 40]
Internet-Draft DIFFSERV-QCI April 2020
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.
o 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
[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,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>.
[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,
<https://www.rfc-editor.org/info/rfc3246>.
[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,
<https://www.rfc-editor.org/info/rfc5865>.
Henry, et al. Expires October 15, 2020 [Page 41]
Internet-Draft DIFFSERV-QCI April 2020
9.2. Informative References
[ir.34] 3gpp, "guidelines for ipx provider networks - gsma",
August 2018, <https://www.gsma.com/newsroom/wp-content/
uploads//ir.34-v14.0-3.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003,
<https://www.rfc-editor.org/info/rfc3662>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <https://www.rfc-editor.org/info/rfc5127>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <https://www.rfc-editor.org/info/rfc8100>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[TS23.107]
3gpp, "quality of service (qos) concept and architecture
v15.0", June 2018, <www.3gpp.org/dynareport/23107.htm>.
Henry, et al. Expires October 15, 2020 [Page 42]
Internet-Draft DIFFSERV-QCI April 2020
[TS23.203]
3gpp, "policy and charging control architecture v16.0",
December 2019, <www.3gpp.org/dynareport/23203.htm>.
[TS23.207]
3gpp, "end-to-end quality of service (qos) concept and
architecture v15.0", June 2018, <www.3gpp.org/
dynareport/23207.htm>.
[TS23.501]
3gpp, "system architecture for the 5G System (5GS) v15.0",
December 2019, <www.3gpp.org/dynareport/23501.htm>.
[TS26.939]
3gpp, "guidelines on the framework for live uplink
streaming (FLUS) v15.0", September 2019, <www.3gpp.org/
dynareport/26939.htm>.
Authors' Addresses
Jerome Henry
Cisco
Email: jerhenry@cisco.com
Tim Szigeti
Cisco
Email: szigeti@cisco.com
Luis Miguel Contreras Murillo
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Henry, et al. Expires October 15, 2020 [Page 43]
