QCI

QCI stands for QoS Class Identifier. This is a special indentifier defining the quality of packet
communication provided by LTE. The range of the class is from 1 to 9. Each of this class is
defined as in the following table (TS 23.203).

(3GPP -23.203 Table 6.1.7: Standardized QCI characteristics : Release 8)

Note : GBR stands for Guaranteed Bit Rate

From Rel 12, 4 additional QCIs(65,66,69,70) are defined mainly for Public Safety Group
Communication as shown below.

(3GPP -23.203 Table 6.1.7: Standardized QCI characteristics : Release 12)

The specific QCI value is allocated for each UE and is informed to UE via 'Activate default
EPS bearer context request' message as shown below. (Followings are just a couple of
examples.)

Activate default EPS bearer context request ::= DIVISION

. ...
EPS quality of service
Length: 1
Quality of Service Class Identifier (QCI): QCI 9 (9)

Activate dedicated EPS bearer context request ::= DIVISION

. ...
 EPS quality of service
Length: 5
Quality of Service Class Identifier (QCI): QCI 1 (1)
Maximum bit rate for uplink : 1 kbps
Maximum bit rate for downlink : 1 kbps
Guaranteed bit rate for uplink : 1 kbps
Guaranteed bit rate for downlink : 1 kbps
Packet Packet
Resource Priority Delay Error Loss
QCI Example Services
Type Level Budget Rate
(NOTE 13) (NOTE 2)

100 ms
1
2 (NOTE 1, 10-2 Conversational Voice
(NOTE 3)
NOTE 11)

150 ms
2 Conversational Video (Live
4 (NOTE 1, 10-3
(NOTE 3) Streaming)
NOTE 11)

Real Time Gaming, V2X messages

Electricity distribution – medium
3 50 ms
voltage (e.g. TS 22.261 [51]
(NOTE 3, 3 (NOTE 1, 10-3
clause 7.2.2)
NOTE 14) NOTE 11)
Process automation – monitoring
(e.g. TS 22.261 [51] clause 7.2.2)

300 ms
4 Non-Conversational Video
5 (NOTE 1, 10-6
(NOTE 3) GBR (Buffered Streaming)
NOTE 11)

65
75 ms
(NOTE 3, Mission Critical user plane Push
0.7 (NOTE 7, 10-2
NOTE 9, To Talk voice (e.g., MCPTT)
NOTE 8)
NOTE 12)

66 100 ms
Non-Mission-Critical user plane
(NOTE 3, 2 (NOTE 1, 10-2
Push To Talk voice
NOTE 12) NOTE 10)

67 100 ms
(NOTE 3, 1.5 (NOTE 1, 10-3 Mission Critical Video user plane
NOTE 12) NOTE 10)

75 50 ms
2.5 10-2 V2X messages
(NOTE 14) (NOTE 1)

Non-GBR 100 ms
5
1 (NOTE 1, 10-6 IMS Signalling
(NOTE 3)
NOTE 10)

6 6 300 ms 10-6 Video (Buffered Streaming)

(NOTE 4) (NOTE 1, TCP-based (e.g., www, e-mail,
NOTE 10) chat, ftp, p2p file sharing,
progressive video, etc.)
 100 ms Voice,
7
7 (NOTE 1, 10-3 Video (Live Streaming)
(NOTE 3)
NOTE 10) Interactive Gaming

8
8 Video (Buffered Streaming)
(NOTE 5)
300 ms TCP-based (e.g., www, e-mail,
10-6
(NOTE 1) chat, ftp, p2p file sharing,
9 progressive video, etc.)
9
(NOTE 6)

69
60 ms Mission Critical delay sensitive
(NOTE 3,
0.5 (NOTE 7, 10-6 signalling (e.g., MC-PTT
NOTE 9,
NOTE 8) signalling, MC Video signalling)
NOTE 12)

70 200 ms Mission Critical Data (e.g.

(NOTE 4, 5.5 (NOTE 7, 10-6 example services are the same as
NOTE 12) NOTE 10) QCI 6/8/9)

50 ms
79
6.5 (NOTE 1, 10-2 V2X messages
(NOTE 14)
NOTE 10)

10 ms Low latency eMBB applications

80
6.8 (NOTE 10, 10-6 (TCP/UDP-based);
(NOTE 3)
NOTE 15) Augmented Reality

Diffserv to QCI Mapping-01

draft-henry-tsvwg-diffserv-to-qci-01

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. In this context, it is crucial that quality of service be aligned between
these different environments. However, this is not always the case by default, and
cellular communication networks use a different QoS nomenclature from the
Internet and enterprise networks. This document specifies a set of 3rd Generation
 Partnership Project (3GPP) Quality of Service (QoS) Class Identifiers (QCI) to
Differentiated Services Code Point (DSCP) mappings, to reconcile the marking
recommendations offered by the 3GPP with the recommendations offered by the
IETF, so as to maintain a consistent QoS treatment between cellular networks and
the Internet.

Status of This Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force

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

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

This Internet-Draft will expire on October 15, 2019.

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

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

Table of Contents

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

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

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

Note: [RFC4594] is intended to be viewed as a framework for supporting Diffserv

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

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

1.2. Applicability Statement

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

1.3. Document Organization

This document is organized as follows:

 Section 2 introduces the QoS logic marking applicable to each domain. We

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

1.4. Requirements language

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

1.5. Terminology Used in this Document

 Key terminology used in this document includes:

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

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

IP BS Manager: Internet Protocol Bearer Service Manager, a function that

manages the IP bearer services. Part of this function can include translation of QoS
parameters between EPS and external networks.

UE: User Equipment, the end-device.

EPS Session: a PDN connection, comprised of one or more IP flows, that a UE

established and maintains to the EPS.

SAE: System Architecture Evolution.

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

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

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

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

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

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

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

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

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

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

2. Service Comparison and Default Interoperation of

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

Additionally, the P-GW interconnects the UE data plane to the external networks.
The P-GW is the element that implements Gateway GPRS (General Packet Radio
Service) Support Node (GGSN) functionalities in Evolved Packet Core (EPS)
networks. The GGSN includes an IP BS manager function that acts as a Diffserv
Edge function, and can translate Diffserv parameters to LTE QoS parameters (e.g.
QCI) and vice versa.

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

2.2. QCI and Bearer Model in 3GPP

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

 GBR: Guaranteed Bit Rate bearers. These bearers allocate network

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

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

1. QoS Class Identifiers (QCI). A QCI is a scalar associated to a

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

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

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

2.3. QCI Definition and Logic

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

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

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

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

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

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

QCI Resource Priority Packet Packet Example Services

Type Level Delay Error
Budget Loss
1 GBR 2 100 ms 10.E-2 Conversational Voice
2 GBR 4 150 ms 10.E-3 Conversational Video (Live
QCI Resource Priority Packet Packet Example Services
Type Level Delay Error
Budget Loss
Streaming)
3 GBR 3 50 ms 10.E-3 Real Time Gaming, V2X messages,
Electricity distribution (medium
voltage) Process automation
(monitoring)
4 GBR 5 300 ms 10.E-6 Non-Conversational Video (Buffered
Streaming)
65 GBR 0.7 75 ms 10.E-2 Mission Critical user plane Push To
Talk voice (e.g., MCPTT)
66 GBR 2 100 ms 10.E-2 Non-Mission-Critical user plane Push
To Talk voice
67 GBR 1.5 100 ms 10.E-3 Mission Critical Video user plane
75 GBR 2.5 50 ms 10.E-2 V2X messages
71 GBR 5.6 150 ms 10.E-6 "Live" Uplink Streaming
72 GBR 5.6 300 ms 10.E-4 "Live" Uplink Streaming
73 GBR 5.6 300 ms 10.E-8 "Live" Uplink Streaming
74 GBR 5.6 500 ms 10.E-8 "Live" Uplink Streaming
76 GBR 5.6 500 ms 10.E-4 "Live" Uplink Streaming
5 Non-GBR 1 100 ms 10.E-6 IMS Signalling
6 Non-GBR 6 300 ms 10.E-6 Video (Buffered Streaming) TCP-
based (e.g. www, email, chat, ftp,
p2p file sharing, progressive video)
7 Non-GBR 7 100 ms 10.E-3 Voice, Video (live streaming),
interactive gaming
8 Non-GBR 8 300 ms 10.E-6 Video (buffered streaming) TCP-
based (e.g. www, email, chat, ftp,
p2p file sharing, progressive video)
9 Non-GBR 9 300 ms 10.E-6 Same as 8
69 Non-GBR 0.5 60 ms 10.E-6 Mission Critical delay sensitive
signalling (e.g., MC-PTT signalling,
MC Video signalling)
70 Non-GBR 5.5 200 ms 10.E-6 Mission Critical Data (e.g. example
services are the same as QCI 6/8/9)
79 Non-GBR 6.5 50 ms 10.E-2 V2X messages
80 Non-GBR 6.8 10 ms 10.E-2 Low latency eMMB applications
(TCP/UDP-based); augmented reality
82 GBR 1.9 10 ms 10.E-6 Discrete automation (small packets)
83 GBR 2.2 10 ms 10.E-4 Discrete automation (large packets)
QCI Resource Priority Packet Packet Example Services
Type Level Delay Error
Budget Loss
84 GBR 2.4 30 ms 10.E-5 Intelligent Transport Systems
85 GBR 2.1 5 ms 10.E-5 Electricity Distribution - High Voltage

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

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. GSMA IPX Guidelines Interpretation and Conflicts

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

The GSM Association (GSMA) has published an Inter-Service Provider IP Backbone

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

These GSMA Guidelines were developed without reference to existing IETF

specifications for various services, referenced in Section 1.1. Additionally, the
same recommendations remained while new traffic types under each 3GPP general
class were added. As such, the GSMA recommendations yield to several
inconsistencies with [RFC4594], including:
  Recommending EF for real-time (conversational) video, for
which [RFC4594] recommends AF41.
 Recommending AF31 for DNS traffic, for which [RFC4594] recommends the
standard service class (DF)
 Recommending AF31 for all types of signaling traffic, thus losing the ability
to differentiate between the various types of signaling flows, as
recommended in[RFC4594] section 5.1.
 Recommending AF21 for WAP browsing and WEB browsing, for
which [RFC4594] recommends the High Throughput data class
 Recommending AF11 for remote connection protocols, such as telnet or
SSH, for which [RFC4594] recommends the OAM class.
 Recommending DF for file transfers, for which [RFC4594] recommends the
High Throughput Data class.
 Recommending DF for email exchanges, for which [RFC4594] recommends
the High Throughput Data class.
 Recommending DF for MMS exchanged over SMTP, for
which [RFC4594] recommends the High Throughput Data class.

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

Thus, document [IR.34] conflicts with the overall Diffserv traffic-conditioning

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

3. P-GW Device Marking and Mapping Capability

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

 mark DSCP, per Diffserv standards

 mark QCI, per the [TS 23.203] standard
 support fully-configurable mappings between DSCP and QCI
 process DSCP markings set by cellular endpoint devices

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

 mark DSCP, per Diffserv standards

 mark QCI, per the [TS 23.203] standard
 support fully-configurable mappings between DSCP (set by applications in
software) and QCI (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 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 description,
because 3GPP network control does not operate over UE data channels. It should
be noted that encapsulated routing protocols for encapsulated or overlay networks
(e.g., VPN, Network Virtualization Overlays, etc.) are not Network Control Traffic
for any physical network at the cellular space; hence, they SHOULD NOT be
marked with CS6 in the first place, and are not expected to be forwarded to the
cellular data plane.

However, when such network control traffic is forwarded, it is expected to receive

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

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 9, thus admitting it to the non-GBR Buffered video traffic, with a
relative priority of 9.

4.2. User Traffic

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

Network administrators can categorize their applications according to the type of

behavior that they require and MAY choose to support all or a subset of the
defined service classes.

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

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

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 (i.e., relative to QCI 7), it does not require the highest level of
service (i.e., GBR and very high priority). As such, it is RECOMMENDED to map
 Signaling traffic marked CS5 DSCP to QCI 4, thereby admitting it to the GBR Non-
conversational video category, with a relative priority level of 5.

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

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 2, thereby admitting AF41 into the GBR Conversational Video,
with a relative priority of 4.

AF42 is typically reserved for video intended to be a component of real-time

exchange, but which criticality is less than traffic carried with a marking of AF41.
As such, it is RECOMMENDED to map AF42 into the Conversational Video (Live
Streaming) category, with a GBR, but a lower priority than QCI 2. Specifically, it is
RECOMMENDED to map AF42 to QCI 4, thereby admitting AF42 into the GBR
Conversational Video, with a relative priority of 5.

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

4.2.4. Real-Time Interactive

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

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

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 4, thereby
admitting AF31 into the GBR Non Conversational Video category, with a relative
priority of 5.

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

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

4.2.6. Broadcast Video

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

As directly implied by the name, the primary media type typically carried within
the Broadcast Video service class is video; as such, it is RECOMMENDED to map
this class into a Video Category. Specifically, it is RECOMMENDED to map CS3 to
QCI 4, thereby admitting Multimedia Streaming into the GBR Non Conversational
Video category, with a relative priority of 5. In cases where GBR availability is
constrained, using a non-GBR equivalent is also acceptable. In this case, it is
RECOMMENDED to map CS3 to QCI 6, thereby admitting Real-Time Interactive
traffic into the non-GBR category Video with a relative priority of 6.
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 70, thereby admitting AF21
into the non-GBR Mission Critical Data category, with a relative priority of 5.5.

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

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

It should be noted that a consequence of such classification is that AF22 is

mapped to the same QCI as CS3, and AF23 is mapped to the same QCI as AF33.
However, this overlap is unavoidable, as some QCIs express intents that are
expressed in the Diffserv domain through distinct marking values, grouped in the
3GPP domain under the same general category.

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 6, thereby admitting AF11
 into the non-GBR Video and TCP-based traffic category, with a relative priority of
6.

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

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

It should be noted that a consequence of such classification is that AF11 is

mapped to the same QCI as CS3 and AF22, AF12 is mapped to the same QCI as
Af33 and AF23, and AF13 is mapped to the same QCI as CS2. However, this
overlap is unavoidable, as some QCIs express intents that are expressed in the
Diffserv domain through distinct marking values, grouped in the 3GPP domain
under the same general category.

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 "best-effort" forwarding
behavior. [RFC4594] Section 4.9 states that the "Standard service class MUST use
the Default Forwarding (DF) PHB".

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

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
[LE-PHB]. [RFC3662] and [RFC4594] both recommend Low-Priority Data be
marked CS1 DSCP.

Note: This marking recommendation may change in the future, as [LE-PHB]

defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an
additional DSCP for this traffic.

The Low-Priority Data service class does not have equivalent in the 3GPP domain,
where all service is controlled and allocated differentially. As such, there is no
clear QCI that could be labelled low priority below the best effort category. As
such, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to
QCI 9, thereby admitting it to the low priority Video and TCP-based traffic
category, with a relative priority of 9.
4.3. Summary of Recommendations for DSCP-to-QCI
Mapping
The table below summarizes the [RFC4594] DSCP marking recommendations
mapped to 3GPP:

DSCP Recommended QCI Resource Type Priority Level

CS7 82 GBR 1.9
CS6 82 GBR 1.9
EF 1 GBR 2
CS5 4 GBR 5
AF43 7 non-GBR 7
AF42 4 GBR 5
AF41 2 GBR 4
CS4 80 3 non-BGR GBR 6.8 3
AF33 8 non-GBR 8
AF32 6 non-GBR 6
AF31 4 GBR 5
CS3 85 GBR 2.1
AF23 8 Non-GBR 8
AF22 6 Non-GBR 6
AF21 70 Non-GBR 5.5
CS2 9 Non-GBR 9
AF13 9 Non-GBR 9
AF12 8 Non-GBR 8
AF11 6 Non-GBR 6
CS0 9 Non-GBR 9
CS1 9 Non-GBR 6.8

5. QCI-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 marking, as detailed in Section 2.1.

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

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

In cases where the UE is unable to apply Diffserv marking, or if these markings

are modified or removed within the 3GPP domain, such that these markings may
not represent the intent expressed by the UE, and in cases where the QCI is
available to represent the flow intent, the recommendations in this section apply.

5.1. QCI and Diffserv Logic Reconciliation

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

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

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

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

It should be noted, however, that such approach results in partial incompatibility.

Some QCIs represent an intent that is simply not present in the Diffserv model. In
that case, attempting to artificially stitch the QCI to an existing Diffserv traffic
class and marking would be dangerous. QCI traffic forwarded to the Diffserv
domain would be mixed with Diffserv traffic that would represent a very different
intent.

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

Each QCI is represented with 6 parameters, including an Example Services value.

This parameter is representative of the QCI intent. Although [TS 23.203]
summarizes each QCI intent, this standard is only a summary of more complex
classification expressed in other 3GPP standards. It is often necessary to refer to
these other standards to obtain a more complex description of each QCI and the
multiple type of flows that each QCI represents.

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

Although 26 QCIs are listed in [TS 23.203], representing two bearer types (GBR,
non-GBR), 21 priority values, 9 delay budget values, and 7 loss tolerance values,
examining the intent surfaces 9 traffic families:

1. Voice QCI [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]
9. Non-mission-critical data [6, 8, 9]
10. Mission-critical data is its own group [70]

5.2. Voice QCI [1]

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

5.3. IMS Signaling [5]

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

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

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

 QCI 65 is GBR, mission critical PTT voice, priority 0.7

 QCI 66 is GBR, non-mission critical PTT voice, priority 2
 QCI 69 is non-GBR, mission-critical PTT signaling, priority 0.5

These QCI are Voice in nature, and naturally fit into a proximity marking model
with DSCP 46 and 44.

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

Among these three QCIs, 69 is non-GBR, intended for mission-critical PTT

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

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

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

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

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

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

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

As such, its RECOMMENDED to map QCI 67 against the DSCP value closest to
AF4x video with lowest discard eligibility (AF41), namely category 33.

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

QCI 4 is intended for non-conversational video (buffered streaming), with a

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

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

5.6. Live streaming and interactive gaming [7]

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

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

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

QCI 80 is intended for low latency eMBB (enhanced Mobile Broadband)
applications, such as Augmented Reality of Virtual Reality (AR/VR). This QCI
priority is 6.8,with a low packet delay budget of 10 ms, and a packet error loss
rate of at most 10.E-6.

QCI 80 is non-GBR, yet intended for real time applications. Traffic in the AR/VR
category typically does not react dynamically to losses, requires bandwidth and a
low and predictable delay.

As such, QCI 80 matches closely the specifications for CS4. Therefore, it is

RECOMMENDED to map QCI 80 to the existing category CS4.

5.8. V2X messaging [75,3,9]

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

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

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

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

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

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

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

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

QCI 85 is intended for electricity distribution (high voltage) communication. As

such, it is close in intent to QCI 3. QCI 85 is also GBR. However, QCI 85 priority is
lower than that of QCI 3 (2.1 vs 3). QCI 85 has also a very low packet delay
budget (5 ms vs 50 ms for QCI 3) and low packet error loss rate (10.E-6 vs 10.E-3
for QCI 3). As such, QCI 84 should be mapped to a category higher than that of
QCI 3,with a very low drop probability. As such, it is RECOMMENDED to map QCI
85 to category 25.
 QCIs 82 and 83 are both intended for discrete automation control traffic. QCI 82
represents traffic with a higher priority (1.9) than traffic matched to QCI 83
(priority 2.2). QCI 82 also expects smaller data bursts (255 bytes) than QCI 83
(1358 bytes). However, both QCIs are admitted (GBR), with the same low packet
delay budget (10 ms) and packet error loss maximum rate (10.E-4).

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

As such, it is RECOMMENDED to map QCI 82 to category 27. Similarly, it is

RECOMMENDED to map QCI 83 to category 29.

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

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

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

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

5.11. Mission-critical data [70]

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

QCI Resource Priority Example Services Recommended

Type Level DSCP (PHB)
1 GBR 2 Conversational Voice 44 (VA)
2 GBR 4 Conversational Video (Live Streaming) 35 (N.A.)
3 GBR 3 Real Time Gaming, V2X messages, 19 (N.A.)
Electricity distribution (medium voltage)
Process automation (monitoring)
4 GBR 5 Non-Conversational Video (Buffered 37 (N.A.)
Streaming)
65 GBR 0.7 Mission Critical user plane Push To Talk 42 (N.A.)
voice (e.g., MCPTT)
66 GBR 2 Non-Mission-Critical user plane Push To 43 (N.A.)
Talk voice
67 GBR 1.5 Mission Critical Video user plane 33 (N.A.)
75 GBR 2.5 V2X messages 17 (N.A.)
82 GBR 1.9 Discrete automation (small packets) 27 (N.A.)
83 GBR 2.2 Discrete automation (large packets) 29 (N.A.)
84 GBR 2.4 Intelligent Transport Systems 31 (N.A.)
85 GBR 2.1 Electricity Distribution - High Voltage 25 (N.A.)
5 Non-GBR 1 IMS Signalling 40 (CS5)
6 Non-GBR 6 Video (Buffered Streaming) TCP-based 10 (AF11)
(e.g. www, email, chat, ftp, p2p file
sharing, progressive video)
7 Non-GBR 7 Voice, Video (live streaming), 38 (AF43)
interactive gaming
8 Non-GBR 8 Video (buffered streaming) TCP-based 12 (AF12)
(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 delay sensitive signalling 41 (N.A.)
(e.g., MC-PTT signalling, MC Video
signalling)
70 Non-GBR 5.5 Mission Critical Data (e.g. example 20 (AF22)
services are the same as QCI 6/8/9)
QCI Resource Priority Example Services Recommended
Type Level DSCP (PHB)
79 Non-GBR 6.5 V2X messages 21 (N.A.)
80 Non-GBR 6.8 Low latency eMMB applications 32 (CS4)
(TCP/UDP-based); augmented reality

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

7. Specific Security Considerations

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

8. Security Recommendations for General QoS

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

To illustrate: A gaming application designed to run on a smartphone may request

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

To mitigate such scenarios, it is RECOMMENDED to implement general QoS

security measures, including:

 Setting a traffic conditioning policy reflective of business objectives and

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

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