E2E QoS Overall

Architecture
Description
Editor : Houssemeddine Ouerghi [OTN/DRS]

Contributors : Yosra Zarred [OTN/DRS]

TBD

Version : v1.1
Edition Date : November 2016

1 Interne Orange
Content
1. Scope of the document
2. E2E QoS Description
3. QoS Control
4. QoS Application and Transport
5. Technical facts & Open Questions
2 Interne Orange
SCOPE OF THE
DOCUMENT
KEY POINTS & APPLICATION SCENARIOS

3 Interne Orange
Key Points & Application Scenarios

E2E Architecture definition

− BLISS Based recommendation
− Centralized and Dynamic Control (PCRF)
− E2E Transport network coherent QoS application (from Cell Site to PGW/GGSN)
− LTE particular traffic behavior consideration (Buffers dimensioning…)
− IPv4 oriented. No support for IPv6 in this document

Application Scenarios
− Dynamic QoS Control at bearer/PDP context establishment: move from a static model based on
default HSS provisioning to customized QoS per subscriber
− Dynamic QoS Control at bearer/PDP context modification: based on updated PCRF policy (fair
usage, subscription update…), QoS is modified “on the fly”
Taking into consideration mobility context
4 Interne Orange
E2E QOS Description
TARGET ARCHITECTURE

DYNAMIC QOS CONTROL PER SUBSCRIBER

DEPLOYMENT CONSIDERATIONS

5 Interne Orange
Target E2E QoS Architecture
Static default QoS
profiles, to be
overriden by PCRF
Validate and Relay
negociated QoS to PCRF is the only
the RAN Nodes Responsabile of QoS
Negociation and
Attribution

HLR/
S1-MME
HSS

IuPS
S6a

MME PCRF
IuB RNC SGSN S11 Gn Gx

S5

eNB UPE Router P Router PE Router PE PE SGW PGW

NE40E NE40E NE40E Juniper Juniper
S1-U

Transport Edge nodes: Maps negociated

6 Interne Orange QoS attributes to DSCP CoS
Dynamic QoS Control per Subscriber

QoS negotiation and attribution

Based on PCRF policies:
− User classification based on subscription type (either at bearer establishment or in online update)
− User classification based on fair usage policy (Reduced QoS for Heavy users)
Focused on two groups of attributes:
− Scheduling priority (QCI/THP/ARP)
− Maximum bit rate definition (APN-AMBR/UE-AMBR)
− No Guaranteed bit rates technics involved in this architecture
QoS Application
Applied in GGSN/PGW and forwarded to the RAN edge nodes through MME/SGSN
Applied in transport interfaces through mapping to DSCP then to the relevant transport protocol

7 Interne Orange
Dynamic QoS Control per Subscriber
Fair usage use case

Objective Implementation example in 4G

Identify Heavy/Low users and classify them in terms of QoS Volume usage (Gbyte)
priority in network. The objective is to introduce fairness
among users (unless overridden in subscription) in network
resource allocation (Radio resources, scheduling priority)

Principle Heavy User, Low QCI (9)

Periodic usage reporting (daily for example) and covering Usage Upper limit
identified fairness period (Unlimited hours from 23H to 08H
for example) is used to calculated a rank from 1 to 2, 2 is the
heavy user. User is then classified attributed QoS for the next Normal User, Default QCI (8)
period based on the calculated rank
In case of transport interface congestion, and depending on
scheduling weights implemented, normal user could have
little or much more bandwidth available then a Heavy user,
and should be less affected by interface drops.
8 Interne Orange
Dynamic QoS Control per Subscriber
Subscription based differentiation use case

Objective Implementation example in 4G

Offer and monetize QoS priority in the network. This case is in the opposite of the precedent
use case. The objective is to differentiate users based on their subscription (which is
monetized of course), and means not to introduce fairness among them. Allocated Fair Use Volume

Principle
Bronze User, Low QCI (9)
Users could be granted one of three levels of CoS based on their subscription: Bronze, Silver
and Gold users, Silver is the default one. We could configure offers to upgrade CoS with
smaller Fair Use Volume (targeting premium high value users) or to reduce CoS with more
Fair Use Volume (targeting known heavy user profiles)

Combination with Fairness Use case

Silver User, Default QCI (8),
One possible combination could be us follow: Could be downgraded to 9
− Target Known Heavy users from the begin and class them as Bronze users (Low QCI 9)
− Target Premium Users with low traffic profile but with high value and/or high QoS
requirements and class them as Gold (Enhenced QCI 6)
− Class default data user as Silver with QCI8
Gold User, Enhanced QCI (6)
− No movement based on usage is authorized between classes: One user can change its
class only through its subscription
− Fairness algorithm implementation on Silver Users only: Detected Heavy Users from Silver
Users are attributed lower QCI (9) until they go back to a normal usage behavior. However
they should always be tagged as Silver users
9 Interne Orange
Deployment considerations

QoS Marking must be conform to BLISS recommendation (see next slide + annex)
QoS upgrade for mobile traffic from QCI 8/THP 3 (actual deployment) to higher class should take
into account other types of traffic present in the network:
Example: B2B traffic have actually a higher class of service then 3G/4G data traffic. If the non heavy
user upgrade to a higher CoS , B2B traffic with be in a low priority class compared to the Mobile
traffic (or at least a sustainable part of it), which is in violation in BLISS recommendation and actual
Marketing strategy.
Recommendation to limit the QoS differentiation (especially in Fair Usage policies) to:
-Mainly bandwidth control
-CoS differentiation between AF21 at most and BE at least
Recommendation to verify and implement target 8CoS model for all equipment before
generalization of dynamic QoS control for mobile service subject of this document.
− Give more room for QoS differentiation than the actual 4CoS Model (CRT+C1/2/3)
10 Interne Orange
QOS CONTROL
3G/LTE PDP CONTEXT STATIC ESTABLISHMENT (CURRENT)

3G/LTE PDP CONTEXT DYNAMIC ESTABLISHMENT

3G/LTE PDP CONTEXT DYNAMIC MODIFICATION

RAT HANDOVER (MOBILITY USE CASE)

11 Interne Orange
3G PDP Context Static Establishment (Current)
Based on HLR default profile

1- Insert Subscriber Data incl. QoS Profile Subscribed, this is performed at

GPRS Attach Procedure
2- Activate PDP Context Request incl. QoS Requested from the UE, followed
by QoS evaluation in SGSN
3- Create PDP Context Request, followed by admission control and QoS
negotiation in GGSN, and a Create PDP Context Response HLR
4- SGSN re-evaluates the QoS Negotiated, followed by a RAB Assignment
Request incl. QoS Negotiated
5- The RNC maps the QoS attributes, which are received from SGSN, to
RAN-internal QoS profiles, followed by Radio Bearer Setup/Complete
6- RAB Assignment Response
1 Gr
PCRF
7- Activate PDP Context Accept
8- PDP Context (Default Bearer) defined and established with the negotiated
QoS

Gx
3
Iu-C SGSN
4 Gn
2 6
7
Uu Iu-b Iu-U Gi
5
Mobile NodeB RNC GGSN
UE
12 Interne Orange
8
3G PDP Context Dynamic Establishment
Based on Subscription type
1- Insert Subscriber Data incl. QoS Profile Subscribed, this is performed at
GPRS Attach Procedure
2- Activate PDP Context Request incl. QoS Requested from the UE, followed
by QoS evaluation in SGSN
3- Create PDP Context Request, followed by admission control and QoS
negotiation in GGSN, and a Create PDP Context Response
4- GGSN provides PCRF with session information that, together with HLR
subscriber and subscription information, is used by PCRF to evaluate the QoS
that is to be authorized (IMEI-SV and/or
User-Location-Information may be included in the request)
5- GGSN negotiates the QoS received from PCRF and sends a Create PDP
Context Response to SGSN 1 Gr
6- SGSN re-evaluates the QoS Negotiated, followed by a RAB Assignment
PCRF
Request incl. QoS Negotiated
7- The RNC maps the QoS attributes, which are received from SGSN, to
RAN-internal QoS profiles, followed by Radio Bearer Setup/Complete
8- RAB Assignment Response
9- Activate PDP Context Accept 4 Gx
10- PDP Context (Default Bearer) defined and established with the negotiated Iu-C 3
SGSN
6
QoS
2 8 5 Gn
9
Uu Iu-b Iu-U Gi
7
Mobile NodeB RNC GGSN
UE
13 Interne Orange
10
LTE Bearer Dynamic Establishment
Based on Subscription type
1- Attach Request incl. QoS Requested from the UE, followed by QoS
evaluation in MME
2- Update location procedure including Subscriber Data insertion by the HSS
3- Create Session Request, followed by admission control and QoS
negotiation in P-GW, and a Create Session Response
4- Control Credit Request, where P-GW provide PCRF with session
information that, together with subscriber and subscription information, is used HSS
by PCRF to evaluate the QoS that is to be authorized (IMEI-SV and/or
User-Location-Information may be included in the request)
5- Control Credit Answer, with the authorized QoS (QCI, ARP, UE-AMBR)
6- P-GW negotiates the QoS received from PCRF and sends a CreateSession
Response to MME 2 S6a
7- MME re-evaluates the QoS Negotiated, followed by an Attach Accept and
PCRF
an Initial Context Setup Request incl. QoS Negotiated
8- Initial Context Setup Response. Bearer is UP.

7
1 4 Gx 5
3
S1-MME MME
6S11

LTE-Uu S1-U SGi

Mobile eNB EPG

UE S/P-GW
14 Interne Orange
8
3G PDP Context Dynamic modification 9- The RNC maps the QoS attributes, which are
received from SGSN, to RAN-internal QoS profiles,
followed by Radio Bearer Setup/Complete
1- Ongoing PDP Context (Default Bearer) with negotiated QoS 10- RAB Assignment Response
2- Subscription modification: A subscriber connects to a self-service portal 11- Modify PDP Context Request/Accept
and upgrades its subscription in order to receive better QoS, this results in an 12- Update PDP Context Response followed by
update of the subscriber group in PCRF admission control and negotiation of the QoS in GGSN
13- The PDP Context (Default Bearer) is upgraded
Fairusage exhaustion: GGSN reports consumed quota to PCRF when the /downgraded with regards to better/worst QoS
granted quota in GGSN is exhausted, The aggregated usage passes a defined (depending on use case)
threshold, which triggers PCRF to re-evaluate the QoS Authorized HLR

3- PCRF re-evaluates the QoS to be authorized followed by a RAR-message

to GGSN with the new QoS Authorized
4- Update PDP Context Request, incl. the new QoS Authorized Gr
5- SGSN re-evaluates the QoS Negotiated, followed by a release of the PCRF 2
existing RAB using the RAB Assignment Request
6- Radio Bearer Release
7- RAB Assignment Response
8- SGSN requests a set-up of the new RAB using the RAB Assignment
Request incl. QoS Negotiated 3 Gx
Iu-C5 SGSN 4
Gn
7 12
11 8
10
Uu Iu-b Iu-U Gi
6
Mobile NodeB 9 RNC GGSN
UE
1

15 Interne Orange 13
LTE Bearer Dynamic modification 6- The eNodeB forwards the NAS message Modify EPS
Bearer Context Request to the UE.
7- The UE confirms the modification of the bearer with a
1- Ongoing Default Bearer with authorized QoS NAS response message
2- Subscription modification: A subscriber connects to a self-service portal 8- eNodeB confirms to the MME with E-RAB Modify
and upgrades its subscription in order to receive better QoS, this results in an Response message.
update of the subscriber group in PCRF 9- MME confirms the update of APN-AMBR by sending
Fairusage exhaustion: GGSN reports consumed quota to PCRF when the Update Bearer Response towards the EPG
granted quota in GGSN is exhausted, The aggregated usage passes a defined 10- The Default Bearer is upgraded /downgraded with
threshold, which triggers PCRF to re-evaluate the QoS Authorized regards to better/worst QoS (depending on use case)
3- PCRF re-evaluates the QoS Authorized, followed by a CCA message to HSS
EPG with the downgraded Bearer QoS and APN-AMBR
4- Update Bearer Request, incl. the new Bearer QoS and APN-AMBR
Authorized
5- MME re-calculates the UE-AMBR and provides it to the eNodeB together 2 S6a
with the updated Bearer QoS by E-RAB Modify Request message. A NAS PCRF 2
message Modify EPS Bearer Context Request is also included by the MME,
containing the updated APN-AMBR and QCI.
8
7
3 Gx
5 9
S1-MME MME
4 S11
6

LTE-Uu S1-U SGi

Mobile eNB EPG

UE S/P-GW
1

16 Interne Orange 10
RAT Handover (Mobility use case)

Click to expand Call Flow or see attached file : “Mobility Call flow.docx”

17 Interne Orange
QOS APPLICATION AND
TRANSPORT
DSCP MARKING AND CONVERSION TABLE

GENERIC TRANSPORT INTERFACE QOS CONFIGURATION

QOS TRANSPORT MECHANISMS

QUEUE DIMENSIONING IN LTE

18 Interne Orange
DSCP Marking and conversion table
See BLISS recommendation in annex

19 Interne Orange
Generic transport interface QoS configuration

Auto-generated or forwarded
Control Plan: ISIS, BGP, LDP…
CPU

CS7: FC-7 FC-7 FC-7 FC-7 FC-7: CS7

CS6: FC-6 FC-5 FC-6 FC-5 FC-5 FC-6: CS6

CoS Reclassification, drop, ….

EF: FC-5 FC-5 FC-6 FC-6 FC-5: EF

Ingress I/F

Egress I/F
SPQ

AF41: FC-4 FC-4 FC-4 FC-4 40% FC-4: AF41

Strict
Priority
AF31: FC-3 FC-3 FC-3 FC-3 30% Queue FC-3: AF31

WRED Profile
WFQ
AF21: FC-2 FC-2 FC-2 FC-2 15% FC-2: AF21
Weighted
AF11: FC-1 FC-1 FC-1 FC-1 10% Fair Queue FC-1: AF11

5%
BE: FC-0 FC-0 FC-0 FC-0 FC-0: BE

Classification Policing Ingress Queuing Congestion Egress Queuing Scheduling Shaper Egress marking
Based on Avoidance (DSCP Example)
DSCP/EXP/802.1p Mechanisms
(DSCP Example) (WRED…)
20 Interne Orange
Ingress QoS Mecanisms Egress QoS Mecanisms
QoS Transport Mechanisms
GPRS services, Abis over TDM, A over IP
Upstream: Upstream:
1.Map QoS from DSCP/ 1.Map QoS from DSCP/
Upstream: 802.1p to MPLS EXP if next 802.1p to MPLS EXP if next
1.Map QoS negociated priority to hop is another PE or to hop is another PE or to
DSCP and 802.1p DSCP/802.1p if SGSN DSCP/802.1p if GGSN
2.Rate Limiting Upstream: 2.Queue Scheduling 2.Queue Scheduling
3.Queue Scheduling Upstream & Downstream Upstream & Downstream 1.Transmit on TDM channel Downstream: Downstream:
4.TDM encapsulation 1.Map QoS priority from EXP to 1.Map QoS priority from EXP to Downstream: 1.Map From MPLS EXP if 1.Map From MPLS EXP if
Downstream: EXP and 802.1p EXP 1.Map 802.1p(5) and DSCP(5) to last hop is another PE or last hop is another PE or
1.Map QoS priority from 802.1p/ 2.Queue scheduling 2.Queue scheduling MPLS EXP from DSCP/802.1p if SGSN from DSCP/802.1p if GGSN
DSCP to a negocitaed GPRS QoS 2.Queue Scheduling to DSCP/802.1p to DSCP/802.1p
2.Rate Limiting 2.Policing 2.Policing
3.Policing 3.Queue Scheduling 3.Queue Scheduling
4.Radio Scheduling

Mobile BTS CSG MASG UPE Router P Router PE Router MASG BSC PE SGSN PE GGSN
UE NE40E NE40E NE40E Juniper Juniper
Downstream
1.Queue Scheduling
Upstream: Upstream: Upstream: Upstream: Upstream & Downstream
1.Map DSCP (5) and 802.1p 1.Map QoS from inner 1.Map Outer MPLS EXP to 1.Map negocitaed GPRS QoS to 1.Map negocitaed GPRS QoS to
Downstream
(5) to MPLS EXP 802.1p to outer MPLS EXP 802.1p 802.1p/DSCP 802.1p/DSCP
1.Map negocitaed GPRS QoS to
2.Queue Scheduling 2.Queue Scheduling 2.Queue Scheduling 2.Rate Limiting 2.Rate Limiting
802.1p/DSCP
Downstream: Downstream: Downstream: 3.Policing 3.Policing
2.Rate Limiting
1.Transmit on TDM, no 1.Map Outer MPLS EXP to 1.Map QoS from inner 4.Queue Scheduling 4.Queue Scheduling
3.Policing
mapping 802.1p 802.1p to outer MPLS EXP Downstream:
4.Queue Scheduling
2.Queue Scheduling 2.Policing 2.Policing 1.Map QoS negociated priority to
3.Queue Scheduling 3.Queue Scheduling DSCP and 802.1p
2.Rate Limiting
3.Queue Scheduling
VPLS 4.TDM encapsulation

IP services over TDM encapsulation

21 Interne Orange
QoS Transport Mechanisms
GPRS services, Abis over IP, A over IP
Upstream:
Upstream: 1.Map negocitaed GPRS QoS to
1.Map QoS negociated priority to 802.1p/DSCP Downstream
DSCP and 802.1p 2.Rate Limiting 1.Queue Scheduling
2.Rate Limiting 3.Policing
3.Queue Scheduling 4.Queue Scheduling Downstream
Upstream & Downstream
Downstream: Downstream: 1.Map negocitaed GPRS QoS to
1.Map negocitaed GPRS QoS to
1.Map QoS priority from 802.1p/ 1.Map QoS negociated priority to 802.1p/DSCP
Upstream & Downstream 802.1p/DSCP
DSCP to a negocitaed GPRS QoS DSCP and 802.1p 2.Rate Limiting
1.Map QoS priority from EXP to 2.Rate Limiting
2.Rate Limiting 2.Rate Limiting 3.Policing
EXP 3.Policing
3.Policing 3.Queue Scheduling 4.Queue Scheduling
2.Queue scheduling 4.Queue Scheduling
4.Radio Scheduling

Mobile BTS UPE Router P Router PE Router BSC PE SGSN PE GGSN

UE NE40E NE40E NE40E Juniper Juniper

Upstream: Upstream: Upstream: Upstream:

1.Map QoS from DSCP/ 1.Map MPLS EXP to DSCP/ 1.Map QoS from DSCP/ 1.Map QoS from DSCP/
802.1p to MPLS EXP 802.1p 802.1p to MPLS EXP if next 802.1p to MPLS EXP if next
2.Queue Scheduling 2.Queue Scheduling hop is another PE or to hop is another PE or to
Downstream: Downstream: DSCP/802.1p if SGSN DSCP/802.1p if GGSN
1.Map MPLS EXP to DSCP/ 1.Map QoS from DSCP/ 2.Queue Scheduling 2.Queue Scheduling
802.1p 802.1p to MPLS EXP Downstream: Downstream:
2.Policing 2.Policing 1.Map From MPLS EXP if 1.Map From MPLS EXP if
3.Queue Scheduling 3.Queue Scheduling last hop is another PE or last hop is another PE or
from DSCP/802.1p if SGSN from DSCP/802.1p if GGSN
to DSCP/802.1p to DSCP/802.1p
Flat IP L3VPN 2.Policing 2.Policing
3.Queue Scheduling 3.Queue Scheduling

22 Interne Orange IP services over A over IP encapsulation

QoS Transport Mechanisms
3G, IuB/IuPS over IP
Upstream:
1.Map the QoS attributes, which
are received from SGSN, to RAN- Upstream:
Upstream: internal QoS profiles QoS Then to 1.Map QoS from MPLS EXP
1.Map QoS negociated RAN 802.1p/DSCP to DSCP/802.1p
internal QoS Profiles to DSCP and 2.Rate Limiting 2.Queue Scheduling
802.1p 3.Policing Downstream:
2.Rate Limiting 4.Queue Scheduling 1.DSCP/802.1p to MPLS
3.Queue Scheduling Downstream: EXP
Downstream: 1.Map the QoS attributes, which 2.Policing
Upstream & Downstream
1.Map QoS priority from 802.1p/ are received from SGSN, to RAN- 3.Queue Scheduling
1.Map QoS priority from EXP to
DSCP to a negocitaed GPRS QoS internal QoS profiles QoS Then to
EXP
2.Rate Limiting 802.1p/DSCP
2.Queue scheduling
3.Policing 2.Rate Limiting
4.Radio Scheduling 3.Queue Scheduling

Mobile NodeB UPE Router P Router PE Router RNC PE PE GGSN

UE NE40E NE40E NE40E Juniper Juniper

Upstream: Upstream: Upstream

1.Map QoS from DSCP/ 1.Map MPLS EXP to DSCP/ 1.Queue Scheduling
802.1p to MPLS EXP 802.1p Upstream:
2.Queue Scheduling 2.Queue Scheduling 1.Map QoS from DSCP/ Downstream
Downstream: Downstream: 802.1p to MPLS EXP 1.Map negocitaed UMTS QoS to
1.Map MPLS EXP to DSCP/ 1.Map QoS from DSCP/ 2.Queue Scheduling 802.1p/DSCP
802.1p 802.1p to MPLS EXP Downstream: 2.Rate Limiting
2.Policing 2.Policing 1.Map From MPLS EXP to 3.Policing
3.Queue Scheduling 3.Queue Scheduling DSCP/802.1p 4.Queue Scheduling
2.Policing
3.Queue Scheduling
Flat IP L3VPN

23 Interne Orange
IuPS over IP
QoS Transport Mechanisms
LTE
Upstream:
1.Map negociated QCI to DSCP and Upstream: Upstream
802.1p 1.Map QoS from BGP Label 1.Queue Scheduling
2.Rate Limiting to MPLS EXP
3.Queue Scheduling 2.Policing Downstream
Downstream: 3.Queue Scheduling 1.Map negocitaed QCI to 802.1p/
1.Map QoS priority negociated QCI Upstream & Downstream Downstream: DSCP
to DSCP 1.Map QoS priority from EXP to 1.Map From MPLS EXP to 2.Rate Limiting
2.Rate Limiting EXP BGP label 3.Policing
3.Policing 2.Queue scheduling 2.Queue Scheduling 4.Queue Scheduling
4.Radio Scheduling

Mobile eNB UPE Router P Router PE Router PE PE PGW

UE NE40E NE40E NE40E Juniper Juniper

Upstream: Upstream:
Upstream:
1.Map QoS from DSCP/ 1.Map MPLS EXP to BGP
1.Map QoS from MPLS EXP
802.1p to MPLS EXP Label
to DSCP/802.1p
2.Queue Scheduling 2.Queue Scheduling
2.Queue Scheduling
Downstream: Downstream:
Downstream:
1.Map MPLS EXP to DSCP/ 1.Map QoS from BGP Label
1.DSCP/802.1p to MPLS
802.1p to MPLS EXP
EXP
2.Policing 2.Policing
2.Queue Scheduling
3.Queue Scheduling 3.Queue Scheduling

Flat IP L3VPN

24 Interne Orange
S1-U over IP encapsulation
Queue dimensioning in LTE (1/2)
transmission rate
1Ge Exemple

Traffic sent at interface rate in bursty fashion.

Adaptation needed at QoS setting to improve QoE Mean rate
Tuning consist in some equipments time

− Tuning buffer size to not drop traffic in queue 1S

− Implement traffic shaping to protect some network segment but with a drawback to increase latency.
− Rate limit . This could impact TCP peak traffic as some traffic is drop (potential marketing impact)
Calculation is complex and depend on equipment behavior. Tuning during lab test is recommended. We assume that:

Authorized data volume in

Ethernet rate Measurement
Mobile Ethernet Access kBytes in the measurement
in Mbit/s window
window

200M Access burst 1G (*) 2400 200 96 ms

(*) In a window of 96 ms, a volume data at most of 2400 kBytes could be sent at a rate of 1 Gbit/s maximum, equivalent to a
contiguous period of time of 19,2 ms
25 Interne Orange
Queue dimensioning in LTE (2/2)
Downlink & Uplink:
-Buffer size must be superior to 2MBytes
in all involved interfaces and for for all
involved CoS queues (from AF41 to AF11
and BE)
-Special attention must paid to low rate
interface (<1Gbps), in UPE routers and
MW links

eNB

UPE Router P Router PE Router PE PE PGW

NE40E NE40E NE40E Juniper Juniper

eNB
Downlink:
-Shaping per eNB and per cell site to
Minimum between Cell site Radio
Capacity and transmission capacity
(Example: Microwave, port rate...)
-Shape per VLAN in case of multi hop
MW, shape per port in case of single hop
26 Interne Orange tranmission (transmission of single MW)
TECHNICAL FACTS &
OPEN QUESTIONS

27 Interne Orange
Open questions

How to define the volume usage limit to consider a user as “Heavy”?

− 1st method: calculation could be based on 3G/4G traffic repartition to define one limit
− 2nd method: define indendant limits for 3G and 4G,first one hit enable user tag as heavy.

What usage cycle to consider?

− Busy hours, 23H-08H…?

What is the impact of GBR use case introduction?

28 Interne Orange
Annex 1
Bliss recommendation (extract)

In order to avoid micro-loop issue and protect Network Control priority traffic, the following recommendations are based on the following
rules:
− One-hop network control and routing protocols should not be in the same queue with any packet which can loop. We also made a
distinction with the self-generated network control and routing protocols disregarding if it is one-hop or multi-hop. Indeed, a self-generated
packet could not loop on the router that emits this packet,
− Conversational services (including the signaling) traffic must be treated as strict priority and associated to high priority queue in order to
avoid jitter and delay,
− CoS definition depends on QoS constraints: Performance (jitter, delay, loss) and Availability,
− The target CoS model is based on 8 CoS model and CoS merging is proposed to design a 7, 6, 5and 4 CoS models.
− All recommendations must be take into account as a whole and not individually.
− These recommendations will be then expanded during the elaboration of High Level Design (HLD) taking into account the specificities of
equipment’s, network, traffic and services:
o QoS parameters tuning (e.g. queue limit, buffer sizing …) must take into account the hardware capacity of the line card,
o Both ingress and egress side of the router must be configured. Indeed, when backpressure20 is activate, the drops on “ingress side” of
the fabric should concern low priority packets. That’s why it’s also important not to forget to create some ingress core CoS policies, that
will apply on equipment ports.
Otherwise the BCP CoS recommendations will not be met with unexpected drops, losses … of packets.

29 Interne Orange
Annex 1
Bliss recommendation (extract)
Recommendation #1: Design and enforce a DiffServ-based policy only when necessary i.e. whenever technical or economical contexts justify
traffic prioritization. Besides, it is recommended in the following case:
o in the presence of high peak rates (> 2% of the link capacity), so as to guarantee appropriate QoS to all services at high economically
sustainable loads
o in the presence of undesirable, constantly growing traffic (e.g. P2P), so as to avoid too frequent network upgrades.
o in order to preserve high priority traffic in case of failure
Recommendation #2: Only one DiffServ domain should be defined from the Home gateway (or Customer Premise Equipment) to the Service
Platform including any border router of the Orange network. Besides, following recommendations apply to this DiffServ domain.
Recommendation #3: Marking (or remarking) should be performed as close as possible to the source and in trusted equipment. Any border
router of the Orange DiffServ domain shall be in charge of remarking packets.
Recommendation #4: Un-trusted traffic should be remarked and considered as Best effort traffic.
Recommendation #5: DSCP marking and PHB consistency issues must be addressed within the Orange networks (fixed en mobile) for the sake
of consistency.
Recommendation #6: It is recommended to classify each traffic flow into one of the 4,5,6,7 or 8 Classes of Services (CoS) model.
The classes are named as follow: FC-n where FC stands for Forwarding Class and n is the index of the class. In 8 CoS model, n is equal to the
EXP, dot1p or IP precedence value with 0 < n < 7. In other CoS models, some FC classes are merged and n corresponds to the FC classes of
the 8 CoS model. For example, FC-21 corresponds to the concatenation of FC-1 into the FC-2 class. Note that in case of concatenation, the
Class behaviour corresponds to the first number. In FC-463, the behaviour corresponds to the FC-4 class. Classes are listed from the highest
priority class to the lowest. Classes FC-7, FC-5, FC-6, FC-4 and FC-3 are considered as priority traffic compared to other classes FC-2, FC-1
and FC-0.
30 Interne Orange
Annex 1
Bliss recommendation (extract)
Recommendation #7: The following rules apply to the different classes and CoS model:
o The FC-7 class is dedicated to self-generated Network Control and Routing protocols (e.g. IS-IS, BFD, LDP, BGP … traffic). The FC-7 class
MUST NEVER be used for traffic in transit. CS7 tag should be used, but CS6 is also acceptable.
o The FC-5 Real Time class is dedicated to applications that require very low delay, very low jitter and very low packet loss for relatively
constant rate traffic sources.
o The FC-6 class is dedicated to multi-hop Network Control and Routing protocols in transit that can loop (e.g. transit BGP, T-LDP … traffic).
In any case, this class MUST NEVER be used for self-generated Network Control and Routing protocols. CS6 tag should be used, but CS7
is also acceptable.
o The FC-4 class is dedicated to critical flows that require less jitter constraints but need low delay and very low loss probability. Traffic
classified in this FC-4 class should receive a minimum bandwidth guarantee. Typical usage corresponds to Video streaming.
o The FC-3 class is dedicated to critical data flows that require less jitter and very low loss probability constraints but accommodate to large
delay. Traffic classified in this FC-3 class should receive a minimum bandwidth guarantee. Typical usage corresponds to Critical Data.
o The FC-2 class corresponds to flows that require low jitter, delay and loss probability. Traffic classified in this FC-2 class should receive a
minimum bandwidth guarantee.
o The FC-1 class corresponds to flow that require no particular constraints but should receive a minimum bandwidth guarantee.
o The FC-0 class is dedicated to Best effort traffic and provides no QoS guarantee.
o The FC-57 is similar to the FC-5, but include the FC-7 class in the 5 CoS model.
o The FC-43 class is similar to the FC-4 class, but including the FC-3 class in the 6 CoS model.
o The FC-463 class is similar to the FC-4 class, but including the FC-6 and FC-3 classes in the 6, 5 and 4 CoS models.
o The FC-21 class is similar to the FC-2 class, but including the FC-1 class in the 7, 6, 5 and 4 CoS models. These different CoS correspond
to different hardware queues in the equipment and several DSCP values are mapped in each CoS. Some DSCP values are already
associated to different services and there are DSCP values still available for future use. Within one CoS, there is no prioritization between
traffic associated with different DSCP values (unless RED or WRED is implemented). It is worth mentioning that this table is likely to evolve
31 inInterne
the future
Orangein order to deal with new affiliate and service requirements. Yet this shall be conducted from a group-wise perspective for the
sake of consistency.
Annex 1
Bliss recommendation (extract)

Recommendation #8: 8 CoS model is the target for the Orange networks.
Recommendation #9: It is recommended to dimension the network and Class of Service so that, no packet loss occurs in classes associated
to Priority Traffic group in case of a single network failure. This dimensioning must take into account the capacity and limitation of the
equipment’s as well as the backpressure mechanism.
Recommendation #10: The FC-7, FC-5 and possibly the FC-6 classes should be treated as strict priority. In addition, the load of these classes
should be controlled via rate limitation mechanisms. Rate limit should be carefully defined taking into account the expected load in FC-7, FC-5
and FC-6 during certain failure conditions.
Recommendation #11: Operational entities will choose the right CoS model depending on their needs, QoS constraints, network segment and
devices capabilities.
Recommendation #12: New BCP QoS model might be adapted to take into account current or possible equipment limitations and network
migration scenarios. For instance:
o If equipment support only one strict priority queue, the 4 CoS model must be applied.
o For equipment which not implicitly prioritizes Network Control traffic, 4 CoS MUST NOT be used to avoid micro-loop issue.
o For equipment that could not tag differently Network Control traffic in transit (e.g. BGP) from one-hop traffic (e.g. IS-IS), it might be
possible to use the FC-7 with CS6 tag or CS7 tag. The next equipment in the data path MUST remark CS7 transit packets to CS6 and
forward them into FC-6 class.

32 Interne Orange
References

BCP IP MPLS backbone v3.2 2015

LTE Transport HLD v2.3bis
FMC HLD for 2G and 3G services v 3.2
End-2-End Quality of Service E2E QoS Use Cases, Ericsson presentation
OTN End To End Quality Of Service Design Rev A, Ericsson Solution Design

33 Interne Orange