i

INSTITUT NATIONAL DES TLCOMMUNICATIONS ET DES TECHNOLOGIES DE

LINFORMATION ET DE LA COMMUNICATION ABDELHAFID BOUSSOUF

Gestion de la Qualit de Service dans le

rseau LTE

Par DJENDARA Mohammed El Amine et ZIOUANI Sid Ahmed

Encadr par M. TIENTI Abderrahim

Dpartement des Enseignements en Spcialit, Post-Graduation et Recherche

Mmoire prsent
en vue de lobtention du grade dIngnieur dtat en Tlcommunications et TIC
Option Systme des Tlcommunications

Prsident
M. L. BENSAADA Maitre-Assistant

Examinateurs:
M. A. AZIZOU Maitre-Assistant
M. M. BELKACEM Maitre-Assistant

Promotion: IGE 36
Anne Universitaire : 2015- 2016
Rsum

Rsum
Long Term Evolution a t standardis par le groupe de travail 3GPP afin doffrir
de trs haut dbit pour les services mergeants, ces derniers qui ne cessent de saccrotre
en terme de varit et de magnitude. Pour rpondre aux exigences des utilisateurs sur ces
types de services, les oprateurs et quipementiers du secteur des tlcommunications ont
adopts lapproche du rseau LTE pour la planification et la mise en service de ces
rseaux publics. Le rseau LTE possde de nombreux avantages tels que le trs haut
dbit, un dlai amlior, une efficacit spectrale lev avec un faible cot de dploiement
et une architecture rendue simple par rapport aux autres gnrations 2G et 3G.

Nanmoins, larchitecture du cur de rseau LTE entirement base sur IP oblige

les oprateurs amliorer leur qualit de service, du moment o diffrents types de
service et divers classes dabonns doivent tous tre desservis dans le rseau daccs
radio. La qualit de service varie selon la nature du rseau; en effet, les mcanismes de
priorisation et de classification des trafics, de la gestion et vitement des congestions dans
les files dattente dfinis dans le rseau cur LTE sont celles qui ont t standardises et
adopts par les autorits de rgulation de linternet, eu plus de la mise en place dune
plateforme dite PCC, cette dernire sert lapprovisionnement, la mise en application de
la qualit de service et la taxation des abonns par le rseau EPC. Par contre, les
ressources radiofrquences sont limites est rutilises par loprateur sur lensemble de
son territoire, le sur-approvisionnement nest donc pas une solution; ceci pousse les
chercheurs dans les domaines professionnels et acadmiques dfinir des stratgies
dordonnancement des paquets qui doivent tenir en compte les capacits limits des
cellules en termes de bande passante, lefficacit spectrale prvue par la norme et lquit
entre les diffrents utilisateurs et les diffrents services offerts par un oprateur.

Lobjectif de ce projet est de faire le point sur lapproche adopte par la

norme LTE pour la diffrenciation entre les flux et les paramtres utiliss. Ensuite des
mthodes et mesures de marquage de flux, celles utilises pour la gestion et lvitement
de congestion dans le rseau cur IP ainsi quelques stratgies dordonnancement des
paquets sur linterface radio seront prsentes. Le travail sachve par une tude

ii
comparative sur la performance de trois de ces ordonnanceurs dans le cas dun flux vido,
VoIP et best effort.

Mots-cls : LTE, IP, qualit de service, ordonnanceur de paquet.

Abstrac
t

Abstract
Long Term Evolution was standardized by the 3GPP workgroup to offer a very
throughput for the legacy services (i.e. data) as well as the emerging ones for the end-
user, the latter which do not stop increasing in term of variety and magnitude. To meet
users requirements on these types of services, the operators and equipment
manufacturers of the telecommunications sector adopted the approach of LTE for
planning and commissioning their networks. The LTE network possesses numerous
advantages such as the very high bit rate, an improved latency, a huge spectral efficiency
with a moderate cost of deployment and architecture made simple with regard to the
other generations 2G and 3G.

Nevertheless, the architecture of the core network which is completely based on IP

obliges the operators to improve their quality of service, from the moment when different
types of service and miscellaneous classes of the subscribers must all be served. The
quality of service varies according to the part of LTE network; indeed, the mechanisms
of prioritization and classification of the traffics, the management and the avoidance of
the congestions defined in the core network, are the ones which were standardized and
adopted by the authorities of regulation of the internet. But, the provisioning,
enforcement of the quality of services parameters in the LTE network elements and
charging (based on the category of subscriber and the type of flow) are based on
signaling messages defined by the 3GPP through the PCC domain, which is connected to
the core network. On the other hand, the radio access networks resources are limited
and must be reused by the operator on its whole territory; thus, overprovisioning is not
the right solution; This urges the researchers in the professional and academic domains
to define strategies on packet scheduling which must take into account the limited
capacities allocated to the cells in terms of bandwidth, spectral efficiency, coverage area
planned and fairness between the various users and the various services offered by an
operator.
Abstrac
t The objective of this project is to review the approach of LTE standard for the
differentiation between flows along with the used parameters, then we shall address the
methods and measures of marking of flow, those used for the management and the
avoidance of congestion in the IP core network. After that, we proceed on some strategies
of packet scheduling in the downlink and we shall terminate with a comparative study on
the performance of three packet schedulers in the case of a video streaming, VoIP and
best effort flows.

Keywords: LTE, Quality Of Service, IP, Packet scheduling algorithms, Policy and Charging
Control.
Table des matires
Rsum........................................................................................................................................ii

Abstract.......................................................................................................................................iv

Table des matires.......................................................................................................................vi

Liste des tableaux.......................................................................................................................ix

Liste des figures..........................................................................................................................ix

Liste des sigles............................................................................................................................xi

Ddicaces...................................................................................................................................xv

Remerciement...........................................................................................................................xvi

Introduction gnrale...................................................................................................................1

Chapitre 1 : Architecture du rseau LTE......................................................................................2

1.1 Introduction........................................................................................................................2
1.2 Entit du rseau LTE..........................................................................................................2
1.3 Les interfaces dans le rseau LTE......................................................................................4
1.4 Pile de protocole LTE........................................................................................................5
1.4.1 Pile de protocole dans le plan utilisateur....................................................................5
1.4.2 Pile de protocole dans le plan de contrle..................................................................7
1.5 Flux de trafic dans le rseau LTE......................................................................................9
1.5.1 Flux du trafic dans la voie montante : de lUE vers lInternet...................................9
1.5.2 Flux du trafic utilisateur sur la voie descendante : de lInternet vers lUE..............10
1.6 Les protocoles de couche application S1-AP et notions des tats de lUE:.....................11
1.6.1 Gestion des sessions EPS (Procdures ESM)...........................................................12
Chapitre 2 : La qualit de service dans les rseaux des tlcommunications............................18

2.1 Introduction......................................................................................................................18
2.2 Qualit de service dans les rseaux IP.............................................................................18
2.2.1 Modles de qualit de service...................................................................................18
vi
2.2.2 Les fonctions de qualit de service dans le rseau IP...............................................20

vi
i
 2.3 Qualit de service dans le rseau EPS............................................................................. 25
2.3.1 Les composants dune session EPS..........................................................................25
2.3.2 Les fonctionnalits de la qualit de service dans les plans de contrle et dutilisateur
........................................................................................................................................... 27
2.3.3 Bearer par dfaut et le bearer ddi ........................................................................ 28
2.4 Notions sur le Service Data Flow (SDF) et le bearer EPS..............................................31
2.4.1 Introduction...............................................................................................................31
2.4.2 SDF et bearer EPS....................................................................................................31
2.4.3 Service Data Flow (SDF)..........................................................................................31
2.4.4 Bearer EPS................................................................................................................32
2.4.5 Les paramtres de qualit de service du SDF et du bearer EPS...............................33
Chapitre 3 : Algorithmes dordonnancement des paquets dans le rseau LTE..........................39

3.1 Introduction......................................................................................................................39
3.2 Contraintes lies lallocation des ressources radio....................................................... 40
3.3 Channel sensitive scheduling...........................................................................................41
3.4 Fairness-based algorithms............................................................................................... 44
3.5 Algorithmes ordonnancement multi-classe..................................................................... 45
3.6 Rsum............................................................................................................................ 46
Chapitre 4 : tude comparative sur la performance des ordonnanceurs de paquets PF, MLWDF
et EXP/PF.................................................................................................................................. 47

4.1 Introductions....................................................................................................................47
4.1.1 Choix de loutil.........................................................................................................47
4.2 Prsentation de loutil de simulation : LTE-Sim..............................................................48
4.3 Le scnario.......................................................................................................................49
4.4 Interprtation des rsultats...............................................................................................50
4.4.1 Flux Vido streaming................................................................................................50
4.4.2 Flux VoIP..................................................................................................................53
4.4.3 Flux best effort..........................................................................................................55
4.4.4 Conclusion................................................................................................................57
Conclusion gnrale...................................................................................................................58

vii
Bibliographie................................................................................................................................i

Annexe 1 : Procdures dattachement du terminal au rseau.....................................................iii

Annexe 2 : Etablissement dun bearer ddi...............................................................................v

Annexe 3 : Valeur DSCP avec le type de service recommand.................................................vii

Annexe 4 : Valeur CoS avec la classe de service du flux..........................................................vii

viii
Liste des tableaux
Tableau I. Les caractristiques de chaque bearer EPS (par dfaut et ddi)..........................26
Tableau II. Les classes QCI avec leurs priorits et services ddis selon 3GPP.................30
Tableau III. Le domaine dapplication de chaque paramtre de qualit de service dans le SDF
37
Tableau IV. Domaine de mise en application des paramtres de QoS pour les bearers EPS
38
Tableau V. Valeur DSCP avec les classes de service et traitement PHB.............................vii
Tableau VI. Classe de service et valeur CoS dans la trame Ethernet....................................vii

Liste des figures

Figure 1. Rseau LTE : Architecture gnrale, interfaces et protocoles................................. 5
Figure 2. Piles des protocoles dans le plan utilisateur.............................................................6
Figure 3. Piles des protocoles dans le plan de contrle...........................................................8
Figure 4. Flux du trafic utilisateur dans le sens montant...................................................... 10
Figure 5. Flux de trafic utilisateur dans le sens descendant.................................................. 11
Figure 6. Messages dactivation du bearer par dfaut..........................................................12
Figure 7. Messages dtablissement du bearer ddi............................................................13
Figure 8. Messages de demande dactivation du bearer par lUE........................................14
Figure 9. Messages de modification du bearer initi par le rseau.......................................14
Figure 10. Messages de dsactivation du bearer initi par le rseau..................................15
Figure 11. Message de dsactivation du bearer initi par lutilisateur............................... 16
Figure 12. Messages de demande de connexion au PDN initi par le PDN.......................16
Figure 13. Message de dconnexion du PDN attach.........................................................17
Figure 14. La qualit de service de bout en bout (End-to-End) en LTE............................. 26
Figure 15. Les types de bearer en LTE...............................................................................28

ix
Figure 16. Correspondance entre Flux IP, SDF et bearer EPS pour les applications de lUE
33
Figure 17. Paramtres de qualit de service des connexions entre lUE et chaque APN .. 35

x
Figure 18. La rservation des paramtres de QoS par les lments du rseau LTE............36
Figure 19. La mise en application des paramtres de qualit de service par les lments du
rseau LTE................................................................................................................................. 37
Figure 20. Les paramtres utiliss dans la simulation.........................................................50
Figure 21. Taux de perte des paquets vido en fonction du nombre des utilisateurs..........50
Figure 22. Dlai des paquets vido en fonction du nombre des utilisateurs...................... 51
Figure 23. Dbit moyen par utilisateur en fonction du nombre des utilisateurs.................52
Figure 24. Taux de perte des paquets VoIP en fonction du nombre des utilisateurs...........53
Figure 25. Dlais des paquets VoIP en fonction du nombre des utilisateurs.......................54
Figure 26. Dbit moyen par utilisateur du flux VoIP en fonction du nombre des utilisateurs
54
Figure 27. Taux de perte des paquets de donnes en fonction du nombre des utilisateurs 55
Figure 28. Dlai des paquets de donnes en fonction du nombre des utilisateurs..............56
Figure 29. Dbit du flux de donnes en fonction du nombre des utilisateurs.....................56

x
Liste des sigles
3GPP: 3rd Generation Partnership Project
AF: Assured Forwarding
APN: Access Point Name
AS: Access Stratum
BE: Best Effort
BGP: Border Gateway Protocol
CAR: Committed Access Rate
CBWFQ: Class-Based Weighted Fair Queuing
CDMA: Code Division Multiple Access
CoS: Class of Service
CQ: Custom Queuing
DiffServ: Differentiated Services
DSCP: Differentiated Services Code Point
DPI: Deep Packet Inspection
DRB: Data Radio Bearer
E-UTRAN: Evolved Universal Terrestrial Radio Access Network
EF: Expedited Forwarding
eNB: evolved Node Base station
EPC: Evolved Packet Core
EPS: Evolved Packet System
EXP: Experimental bits
EXP-Rule: Exponential Rule
EXP/PF: Exponential PF
FDD: Frequency Division Duplex
FIFO: First-In First-Out
FLS: Frame Level Scheduler
FTP: File Transfer Protocol
GPF: Generalized PF
xi
GTP: GPRS Tunneling Protocol

xi
i
GTP-C : GPRS Tunneling Protocol in the Control Plane
GTP-U : GPRS Tunneling Protocol in the User Plane
GTS : Generic Traffic Shaping
H-DPI : Heuristic Deep Packet Inspection
HSS : Home Subscriber Server
http : Hypertext Transport Protocol
ICIC: Inter-Cell Interference Coordination
IETF : Internet Engineering Task Force
IMSI : International Mobile Subscriber Identity
IntServ : Integrated Services
IP: Internet Protocol
IPv4: Internet Protocol version 4
IPv6: Internet Protocol version 6
LOG-Rule: Logarithmic Rule
LTE: Long Term Evolution
LTE-A: Long Term Evolution Advanced
M-LWDF: Maximum Largest Weighted Delay First
MAC: Medium Access Control
MME: Mobility Management Entity
MMF: Minimum-Maximum Fairness
MPLS: Multi-Protocol Label Switching
MT: Maximum Throughput
NAS: Non Access Stratum
NFS: Network File System
OCS: Online Charging Subsystem
OFCS: Offline Charging Subsystem
OSPF: Open Shortest Path First
P-GW: Packet Data Network Gateway
PCC: Policy and Charging Control
PCEF: Policy and Charging Enforcement Function
PCRF: Policy and Charging Rules Function

xii
PDCP: Packet Date Convergence Protocol
PDN: Packet Data Network
PDU: Packet Data Unit
PF: Proportional Fairness
PHB: Per-Hop Behavior
PHY: Physical layer
PLMN: Public Land Mobile Network
PQ: Priority Queuing
QoS: Quality of Service
QoE: Quality of Experience
RR: Round Robin
RED: Random Early Detection
RIP: Routing Information Protocol
RLC: Radio Link Control
RRC: Radio Resource Control
RSVP: Resource reSerVation Protocol
RTP: Real-time Transport Protocol
S-GW: Serving Gateway
S1-AP: Application Part in the S1 interface
SDF : Service Data Flow
SIP : Session Initiation Protocol
SMB : Server Message Block
SMTP : Simple Mail Transfer Protocol
SNMP : Simple Network Management Protocol
SON : Self Organizing Network
SPI : Shallow Packet Inspection
SPR : Subscriber Profile Repository
SQL : Structured Query Language
SRB : Signaling Radio Bearer

xiii
STP : Spanning Tree Protocol
TA : Throughput to Average

xiv
TCP : Transmission Control Protocol
TEID (ou TE-ID) : Tunnel Endpoint Identifier
ToS : Type of Service
UE : User Equipment
USIM : Universal Subscriber Identity Module
VLAN : Virtual Local Area Network
VoIP : Voice over IP
VoLTE : Voice over LTE
WFQ : Weighted Fair Queuing
WiMAX : Worldwide Interoperability for Microwave Access
WRED : Weighted Random Early Detection
X2-AP : Application Part in the X2 interface

xiv
Ddicaces

Je ddi ce mmoire :

Mes Parents : qui ont tout fait pour ma russite et de leurs soutiens et pour tous les sacrifices

et leur conseils dans ma vie.

Que dieu vous prserve bonne sant et longue vie

Mes frres: Ghalem, Azize et Adel, qui sont toujours pour moi lexemple de la persvrance.

Et aussi pour leurs soutiens et

encouragements Mes surs et leurs enfants

Mon oncle Sad DJENDARA pour son soutient dans mon parcours universitaire

et bien sr pour tous mes amis que jaime

Je vous souhaite tout le bonheur que vous mritez

DJENDARA Mohammed El Amine

je ddie ce mmoire :

Mes Parents : qui ont tout fait pour ma russite et de leurs soutiens et pour tous les sacrifices

et leurs conseils dans ma vie.

Que dieu vous prserve bonne sant et longue vie

Mes frres et surs : qui sont toujours pour moi lexemple de la persvrance. Et aussi pour

leurs soutiens et encouragements et bien sr pour tous mes amis que jaime

ZIOUANI Sid Ahmed

Remerciement
Avant toute chose, nous tenons remercier Allah qui nous a donn la force et le courage

pour laborer ce modeste travail.

Nous voulons tout dabord remercier vivement notre encadreur Mr.ABDERRAHIM TIENTI

pour nous avoir propos ce projet et pour sa disponibilit et son suivi et ses remarques qui

nous ont permis de ralis ce modeste travail

Nous adressons nos remerciements tous les enseignants qui ont accept de rpondre nos

questions et pour leurs conseils, leurs contribution pendant la phase de notre recherche

Nous tenons tout particulirement remercier nos familles, nos trs chers parents, qui ont

toujours t prsent pour nous.

Nos remerciements sadressent galement nos amis et nos collgues pour leur soutien et leur

encouragement.

Nous adressons nos sincres remerciements ceux qui ont contribu l'laboration de notre

mmoire.

DJENDARA Mohammed El Amine

ZIOUANI Sid Ahmed
 1
Introduction gnrale

Introduction gnrale
La qualit de service en tlcommunication peut tre vue comme tant la performance
globale du rseau, particulirement la performance observe par les utilisateurs de ce rseau.
Afin de quantifier la mesure de la qualit de service, plusieurs aspects lis au rseau
sont considrs, tels que : le taux derreur, dbit applicatif (bit rate), dbit thorique
(throughput), dlai de transmission, la disponibilit, la gigue ...Etc.
Cette qualit de service peut tre attribue une certaine communication soit de faon
statique par un ensemble de valeurs affectes aux attributs, ou dynamiquement selon la
performance actuelle du rseau. Gnralement, un trafic de donnes ou de voix est associ
une classe de service standardise (Ex. Conversationnelle ou Streaming) o les attributs de
qualit de service sont prdfinis, le rseau na que les configurer automatiquement.
La qualit de service est obtenue soit par la rservation des ressources (bande passante,
mmoire en processeur dans les nuds intermdiaires du rseau), par gestion de priorit de
traitement dans les files dattente ou par dautres techniques implmentes dans les nuds du
rseau.
Afin que le rseau sengage fournir cette qualit de service et de la respecter, un
engagement ou contrat de service (Service Level Agreement ou SLA) sera pass entre
lutilisateur (prcisment lapplication utilisatrice) et le rseau. Dune part, le rseau sengage
garantir la qualit dexprience (QoE), et dautre part, lapplication utilisatrice sengage
respecter les paramtres dfinis dans le profil dabonnement. Ce contrat peut tre soit conclu
de manire statique travers une configuration manuelle ou dynamiquement par une
ngociation en temps-rel entre lapplication utilisatrice et le rseau.
De point de vue utilisateur, la qualit de service est lie au dbit offert son
application, dlai de transmission de bout-en-bout, la gigue, le taux derreur de transmission
des donnesEtc. Lutilisateur sera satisfait par le service sil est toujours disponible quel que
soit ltat du rseau et quil soit dlivr avec une certaine qualit recherche et ngocie dans
le contrat de service avec loprateur.

Du point de vue rseau, ce dernier sera proccup par la matrise de lattribution de ces
ressources ses utilisateurs en fonction des critres et politiques de lutilisation du rseau.
Loprateur doit tre en mesure de contrler cette affectation parmi les utilisateurs, et
ventuellement de facturer les consommations des usagers suivant sa politique de taxation. Le
rseau est aussi charg de prioriser les utilisateurs en fonction de type dapplication, heure du
jour, groupe dabonns. Enfin, le rseau sengage respecter cette classification et de la
protger contre toute tentative de violation. [1]

1
Chapitre 1 : Architecture du rseau LTE

Chapitre 1 : Architecture du rseau LTE

1.1 Introduction

Le rseau LTE aussi appel EPS (Evolved Packet System) est un rseau IP de bout-en-
bout, lEPS est divis en deux parties : une partie qui soccupe des technologies relatives
laccs au rseau par voie radio (E-UTRAN) et une autre partie qui traite les technologies
relatives au cur du rseau (EPC). Une connectivit IP de bout-en-bout veut dire que tous
trafics (flux) provenant du terminal mobile et destiner un serveur applicatif distant (se
trouvant linternet par exemple) est transport par le protocole IP par le rseau de loprateur
EPS.

1.2 Entit du rseau LTE

User Equipment (UE) : cest le terminal mobile de labonn, il est muni dune carte
USIM qui stocke lidentit unique au monde de labonn qui est lIMSI et dune cl
secrte Ki qui ne doit jamais quitter le terminal et le HSS, cette cl est utilise pendant
la phase de lauthentification de lutilisateur en gnrant le vecteur dauthentification
qui servira ensuite de gnrer lensemble des cls pour chiffrer les donnes utilisateur
changes entre le terminal et leNB et de chiffrer et protger (par contrle dintgrit)
les messages de contrle changs entre le terminal et leNB (via linterface Uu) et
entre le terminal et le MME (via NAS). LUE connecte au rseau LTE de loprateur
via linterface radio Uu.
eNB: eNB fournit laccs radio aux utilisateurs qui se trouvent dans sa zone de
couverture, leNB soccupe de la gestion des ressources radio tels que : lallocation et
lordonnancement des ressources radio, le contrle dadmission sur la voie radio, la
gestion et le contrle des bearers radio et la coordination avec les cellules voisines
pour amliorer la couverture et la rception des UEs qui se trouvent aux bords de la
cellule travers lICIC.
Mobility Management Entity (MME) : Le MME communique avec le HSS pour
authentifier lutilisateur ainsi de tlcharger son profil dabonnement, il effectue les
fonctions relatives la gestion de la mobilit des usagers et la gestion de leurs sessions
en utilisant la signalisation NAS. Les fonctions principales du MME sont
o Signalisation NAS.
o Authentification des utilisateurs (dans le cas des abonns locaux et ceux en
situation ditinrance) en dialoguant avec le HSS via linterface S6a.

2
Chapitre 1 : Architecture du rseau LTE
o Gestion de la mobilit par les messages : de paging, mise jour de la zone de
suivi et le transfert intercellulaire.

3
 o Gestion des bearers EPS.
Serving Gateway (S-GW) : Il sert relayer les paquets IP entre le P-GW et leNB pour
un utilisateur donn utilisant un flux donn via des tunnels de donnes GTP. Il
intervient pendant la phase de transfert intercellulaire entre eNB ou inter-technologies
daccs 3GPP afin dtablir les tunnels de donnes et de contrle pour relayer les
paquets de la station de base source la station de base cible.
PDN Gateway (P-GW) : Les principales fonctions assures par cet quipement sont :
o Attribution dune adresse IPv4/IPv6 lUE attach lAPN selon le type de
PDN demand par lUE.
o Routage et acheminement des paquets IPv4/IPv6 sur les voies : montante et
descendante.
o Assure le transfert intercellulaire et le relayage des donnes utilisateur dans le
cas de son itinrance du rseau 3GPP (LTE/LTE-A) vers un rseau non-3GPP
(CDMA2000, WiMAX).
o Tarification des donnes utilisateurs selon le type dabonnement, type de
service, heure du jour etc.
o Inspection et filtrage des paquets IP selon la politique de loprateur (Deep
Packet Inspection DPI, Shallow Packet Inspection SPI, Heuristic Deep Packet
Inspection H-DPI).
Home Subscriber Server (HSS) : Cest la base de donnes o les profils dabonnements
de chaque utilisateur y sont stocks, il fournit les vecteurs dauthentification ainsi que
le profil de labonnement au MME.
Policy and Charging Rules Function (PCRF) :Cest lentit qui se charge de la
tarification des donnes utilisateur et la fourniture des rgles (dite rgle PCC) relatives
au paramtres de qualit de service et la mthode de taxation appliquer la fonction
PCEF (Policy and Charging Enforcement Function) qui est gnralement implmente
dans le P-GW.
Subscriber Profile Repository (SPR) : Les profils de souscription des abonnes sont
stocks dans cette entit, elle interagit avec le PCRF pour fournir le profil de labonn,
le PCRF cre une rgle PCC par rapport labonn et transmet cette rgle au PCEF
pour lexcuter.
Online Charging System (OCS) : Il comptabilise le crdit consomm par lutilisateur
en temps-rel selon le volume de donnes, lvnement et/ou lheure du jour.
Offline Charging System (OFCS) : Il fournit les informations de tarification CDR au P-
GW (en passant par le PCRF) pour comptabiliser le volume et le type de service exploits par
lutilisateur durant la priode du contrat, lors de lchance du contrat le P-GW transmet les
paquets CDR lOFCS pour calculer le montant exacte et de gnrer la facture mensuelle
labonn post-pay.
1.3 Les interfaces dans le rseau LTE
LTE-Uu : Cest linterface pour les plans : de contrle et utilisateur entre lUE et
leNB. La signalisation sur LTE-Uu est assure par la couche RRC et reprsente par le
bearer radio SRB (Signaling Radio Bearer). La connexion dans le plan utilisateur est
transporte par les canaux logiques reprsente par le bearer radio de donnes DRB
(Data Radio Bearer).
X2 : Deux eNBs sont relies logiquement via cette interface, elle est utilise dans le
plan de contrle lors du handover X2 et pour les fonctions relatives au SON (Self
Organizing Network) grce au protocole de couche applicatif X2-AP. Dans le plan
utilisateur cest le protocole applicatif GTP-U qui est utilis pour acheminer les
donnes et dtablir les bearers par utilisateur et par type de service demand.
S1-U : Cest linterface dans le plan utilisateur entre leNB et le S-GW, il sert
acheminer les donnes de lutilisateur travers les tunnels GTP crs (grce au
protocole GTP-U) dans leNB et S-GW.
S1-MME : LeNB est reli au MME par linterface S1-MME, seul les messages de
contrle sont changs dans cette interface.
S11 : Cest linterface dans le plan de contrle entre le MME et le S-GW. Elle sert
crer les tunnels GTP pour lutilisateur entre le S-GW et le P-GW et entre le S-GW et
leNB lors de lattachement initial de lUE par exemple.
S5 : Cette interface relie logiquement le S-GW et le P-GW du mme oprateur pour les
plans utilisateur et de contrle. Cette interface transporte les messages de contrle pour
la cration, modification et suppression des bearers par utilisateur. Cependant, dans le
cas o le S-GW et le P-GW se trouvent dans deux PLMNs diffrents, ces nuds sont
connects via linterface S8.
S6a : Cest linterface entre le HSS et le MME, elle sert transmettre les messages de
contrle, par exemple, le transfert du profil de labonn et les vecteurs
dauthentification du HSS au MME.
Sp : Le SPR est reli au PCRF via cette interface, tous les messages changs entre ces
deux entits sont bass sur le protocole applicatif DIAMETER.
Gx : Elle sert relier le PCRF au P-GW pour changer les rgle PCC excuter (par le
PCEF) pour un utilisateur donn (ou par flux) ainsi que les paramtres de qualit de
service ngocis auprs du PCRF.
Gy : Cest linterface entre le P-GW et lOCS pour la taxation des abonns prpays.
Gz : Le P-GW est reli lOFCS pour la taxation des abonns post-pays.
SGi : Le P-GW est connect avec le rseau PDN externe pour transporter les paquets
IP vers et depuis le rseau EPC, cette interface est base sur le protocole IP pour
lacheminement des donnes utilisateurs.
 La figure suivante illustre larchitecture globale du rseau LTE avec toutes les entits
prcdemment mentionnes, en citant le protocole applicatif utilis pour la communication
entre deux nuds connects via une interface donne.

Figure 1. Rseau LTE : Architecture gnrale, interfaces et protocoles

1.4 Pile de protocole LTE

1.4.1 Pile de protocole dans le plan utilisateur

A. LTE-Uu

Packet Data Convergence Protocol (PDCP) : Il se charge du transport efficace des

paquets IP travers la liaison radio en ralisant : la compression dentte, le
chiffrement et le contrle dintgrit des messages AS (Access Stratum entre leNB et
lUE), ordonne les paquets IP avant de les dlivrer la couche application ainsi que la
retransmission des paquets en cas derreur ou dexpiration du minuteur associ au PDU
courant.
Radio Link Control (RLC) : Du ct de lmetteur, RLC se charge de dlivrer les PDU
la couche MAC. Lors de la formation du PDU, la couche RLC effectue la
concatnation et la segmentation des SDU reu de la couche PDCP. Du ct du
rcepteur, RLC se charge de rassembler et de rordonner les PDUs reus afin de
construire les PDU-PDCP. Le protocole RLC fonctionne selon un des trois modes
suivants : mode transparent (Transparent Mode TM), mode acquitt (Acknowledged
Mode AM) ou le mode non-acquitt (Unacknowledged Mode UM).
 Medium Access Control (MAC) : La couche MAC est lintermdiaire entre la couche
RLC et la couche PHY, elle se connecte avec la couche PHY via les canaux de
transport et via les canaux logiques avec la couche RLC. Pour cela, lune des
principales fonctions de MAC est le multiplexage et le dmultiplexage entre les canaux
logiques et les canaux de transport. La couche MAC supporte la qualit de service en
faisant une priorisation entre les donnes issues des canaux logiques et dtablir
lordonnancement appropri. Lordonnanceur implment dans leNB alloue de faon
dynamique les ressources radio entre les diffrents UEs et sassure que chaque bearer
radio associ lUE soit allou la qualit de service ngocie.

B. Interfaces S1-U/S5/X2

GPRS Tunneling Protocol version 2 User Plane (GTP-U): Ce protocole sert

acheminer les paquets IP travers les interfaces S1-U, S5 et X2 (dans le cas de
transfert intercellulaire inter-eNB) ces paquets sont marqus (en plus de ladresse IP
source/destination) par les identifiant du tunnel GTP (Tunnel End-point Identifier ou
TE-ID) de chaque entit du mme canal de communication.
La figure suivante rsume la pile des protocoles utiliss entre les diffrents lments du
rseau LTE dans la communication dans le plan utilisateur :

Figure 2. Piles des protocoles dans le plan utilisateur

1.4.2 Pile de protocole dans le plan de contrle

A. LTE-Uu

Non-Access Stratum (NAS) : Cette couche protocolaire effectue les fonctions relatives
la gestion de la mobilit (grce au protocole EPS Mobility Management ou EMM)
et la gestion des bearers radio (grce au protocole EPS Session Management ESM).
Radio Resource Control (RRC) : Cette couche se charge de transfrer la signalisation
NAS, ainsi que les fonctions de gestion des ressources radio. Ces principales fonctions
sont :
o Diffusion des informations systme.
o Etablir, reconfigurer et librer les connexions RRC sur la voie radio entre
leNB et lUE.
o Etablissement, modification et la libration des bearers radio.

B. X2

Application Part in the X2 interface (X2AP): Cette couche prend en charge la mobilit
des UEs entre les cellules LTE voisines ainsi que les fonctions de SON. Dans le cas de
la mobilit, X2AP sassure de transfrer le contexte de lUE, le relayage des donnes
utilisateur entre leNB source et leNB cible. Dans le cas de SON, les eNBs changent
les informations sur la charge du trafic dans chaque eNB, les mises jour sur la
configuration de leNB et la coordination entre les eNBs pour ajuster les paramtres de
mobilit.

C. S1-MME

Application Part in the S1 interface (S1-AP): La gestion de linterface S1, le transport

des messages de signalisation NAS et la gestion du contexte de lUE sont les fonctions
assures par cette couche. Le MME communique avec le S-GW pour tablir le(s)
bearer(s) EPC et la modification ou la libration du contexte de lUE.

D. Interfaces S11/S5/S10

GPRS Tunneling Protocol version 2 Control Plane (GTPv2-C) : Ce protocole se

charge dchanger les informations de contrle pour la cration, modification et la
suppression des tunnels GTP entre chaque extrmit du canal. Il cre les tunnels afin
dacheminer les donnes utilisateur lors du transfert intercellulaire titre dexemple.
E. S6a

DIAMETER : Se protocole est utilis pour divers applications ; dans cette interface, il
sert changer les donnes de souscription ainsi que les informations ncessaires pour
lauthentification de lutilisateur entre le HSS et le MME.

F. Gx

DIAMETER: Il est utilis pour dlivrer les rgles PCC appliquer au PCEF (P-GW)
depuis le PCRF.

G. Gy

DIAMETER : Le P-GW interagit avec lOCS pour changer les informations de

contrle du crdit (Credit Control ou CC) pour taxer les abonns prpays.

H. Gz

GTP : Le protocole GTP effectue le transfert des CDR entre le P-GW et lOFCS pour
collecter les informations de taxation des abonns post-pays.

La figure suivant reprsente la pile protocolaire entre les diffrents lments du rseau
LTE impliqus durant les communications dans le plan de contrle :

Figure 3. Piles des protocoles dans le plan de contrle

 1.5 Flux de trafic dans le rseau LTE

La figure 4 montre le flux dans le plan utilisateur dun usager LTE qui tente daccder
linternet via le rseau, la figure 5 montre le cas dun flux destination de lUE depuis
linternet.
Les paquets IP sont achemins travers le tunnel GTP sur les interfaces S1-U et S5.
Ces tunnels sont tablis par bearer lorsque lutilisateur est attach au rseau LTE. Plus quun
bearer EPS est tabli dans chacune de ces deux interfaces (S1-U et S5). Donc, afin didentifier
un bearer de faon unique, lidentifiant de tunnel (TEID) est attribu dans chaque extrmit.
En gnral, un tunnel GTP est identifi par les couples adresses IP (source et destination) et
numros de port UDP (source et destination), chaque nud attribue cet identifiant et le nud
voisin doit lutiliser afin de se communiquer. Ces identifiants de tunnels sont chang via les
protocoles dapplication du plan de contrle de chaque interface (par exemple le protocole S1-
AP dans linterface S1).
Lorsque le tunnel GTP est tabli dans linterface S1-U, le S-GW attribue un TEID pour
le trafic sur la voie montante (UL S1-TEID dans la figure 4) et leNB attribue un TEID pour le
trafic sur la voie descendante (DL S1-TEID dans la figure 5). Les valeurs des TEIDs dans le
tunnel S1 GTP sont changes entre leNB et le S-GW en utilisant le S1-AP et les messages
GTP-C. Paralllement, lorsquun tunnel GTP est tabli sur linterface S5, le P-GW attribue le
TEID pour le trafic dans la voie montante (UL S5-TEID) et le P-GW rserve un autre TEID
pour le trafic sur la voie descendante (DL S5-TEID), les identifiants du tunnel S5 GTP sont
changs entre le S-GW et le P-GW via le protocole GTP-C.
Lorsquun paquet de lutilisateur est dlivr travers le tunnel GTP aux interfaces S1-
U et S5, leNB, S-GW et le P-GW routent ce paquet en lencapsulant par la valeur de
lidentifiant TEID attribu par lentit GTP rceptrice. Dans la voie montante, le S-GW
construit une relation un--un entre le TEID du tunnel S1 GTP (UL S1-TEID) et celui du
tunnel S5 GTP (UL S5- TEID) pour terminer le tunnel S1 et de router le trafic de lutilisateur
vers le tunnel S5. De la mme manire, dans la voie descendante, le S-GW construit une
relation un--un entre lidentifiant du tunnel S5 (DL S5-TEID) et celui du tunnel S1 (DL S1-
TEID) afin de terminer le tunnel S5 et dacheminer le trafic vers le tunnel S1 destination de
leNB.

1.5.1 Flux du trafic dans la voie montante : de lUE vers lInternet

1. LUE transmet son paquet IP vers leNB travers linterface radio LTE-Uu.
2. LeNB encapsule le paquet IP avec lentte du tunnel GTP et achemine le paquet IP
rsultant vers le S-GW. Pour cela, leNB choisit un identifiant TEID (ici UL S1-TEID),
ladresse IP de destination (ici S-GW IP address) et ladresse IP source (ici eNB IP
address) pour construire lentte du tunnel S1 GTP.
3. Aprs avoir reu le paquet IP, le S-GW enlve lentte du tunnel S1 GTP, et encapsule
le paquet IP avec lentte du tunnel S5 GTP. Ici, le S-GW choisit son tour
lidentifiant
 du tunnel S5 utiliser (ici UL S5-TEID), ladresse IP de destination (ici P-GW IP
address) et ladresse IP source (ici S-GW IP address) pour raliser lentte du tunnel
S5 GTP.
4. Aprs avoir reu le paquet IP, le P-GW enlve lentte du tunnel S5 GTP et achemine
le paquet au rseau externe (ici lInternet) travers le routage des paquets IP.

Figure 4. Flux du trafic utilisateur dans le sens montant

1.5.2 Flux du trafic utilisateur sur la voie descendante : de lInternet vers lUE
1. Le P-GW reoit le paquet IP destin lUE depuis le rseau externe (ici lInternet).
2. Le P-GW encapsule ce paquet IP avec lentte du tunnel S5 GTP, cette entte contient
lidentifiant TEID (ici DL S5-TEID), ladresse IP de destination (ici S-GW IP address)
et ladresse IP source (ici P-GW IP address). Le paquet IP rsultant sera rout vers le
S- GW correspondant.
3. Aprs la rception du paquet IP par le S-GW, ce dernier enlve lentte du tunnel S5
GTP, et encapsule avec lentte S1 GTP en ajoutant lidentifiant du tunnel (ici DL S1-
TEID), ladresse IP destination (ici eNB IP address) et ladresse IP source (ici S-GW
IP address) pour former lentte S1 GTP.
4. Aprs la rception du paquet par leNB, cette dernire enlve lentte du tunnel S1
GTP du paquet IP de lutilisateur, et transfre ce dernier travers le bearer radio de
donnes (DRB) sur la liaison radio LTE-Uu. [2]
 Figure 5. Flux de trafic utilisateur dans le sens descendant

1.6 Les protocoles de couche application S1-AP et notions des tats de

lUE:
Le MME est lentit du plan de contrle qui implmente les procdures relatives la
gestion des connexions radio des UE et la gestion des sessions utilisateurs avec le rseau EPS ;
en plus, cette entit fournit les procdures pour la mobilit des UE dans le rseau daccs, la
gestion des services de la connexion des couche suprieurs et la scurit des messages
changs entre lUE et le MME (NAS).

Ces procdures permettent aux entits du rseau telles que le S-GW et le HSS de savoir ltat
actuel du terminal en termes de connexion et de session ; en effet, le terminal peut avoir deux
tats EMM :
EMM-deregistered : dans cet tat le MME na aucune information sur la localisation
de lUE dans le rseau, cet tat correspond un terminal dtach du rseau (mis hors-
tension) ou allum mais mis en mode avion.
EMM-registered : ds que le terminal sattache au rseau, le MME mis ce terminal
dans cette tat ; dsormais, le MME a une information sur la localisation de lUE qui
peut soit exacte ou la cellule prs (localisation selon la zone de suivi auquel le
terminal se trouve). Le terminal reste dans cette tat jusqu son dtachement du
rseau, lUE peut communiquer avec le rseau pour excuter dautres procdures.

Pour faire cette communication il faut tablir une connexion de signalisation avec le MME.
Cela dpond si la signalisation existe entre UE et MME, lUE est considr soit en mode :
 ECM-idle : o la connexion radio est libre mais le terminal reste toujours attach au
rseau, aucune procdure EPS ne peut tre lance si la connexion radio nest pas tabli
et maintenue entre lUE et leNB et que le contexte pour cette UE existe sur linterface
S1-MME entre leNB et le MME, ce dernier possde linformation imprcise sur la
localisation de lUE, lUE dclenche la procdure de mise jour de la zone de suivi
que dans le cas ditinrance entre deux zones de suivi diffrentes (la procdure de
transfert intercellulaire nest pas applique dans cet tat ECM).
ECM-connected : le terminal reste dans cet tat tant que la connexion radio reste
maintenue, le MME a une information prcise sur la localisation de lUE, le passage
de lUE dans une autre cellule implique le dclenchement du processus de transfert
intercellulaire.

Enfin, les procdures ESM sont utilises uniquement par le MME et lUE pour
ltablissement, la modification et la libration du contexte et des bearers EPS dans le plan
utilisateur.

1.6.1 Gestion des sessions EPS (Procdures ESM)

Ces procdures sont utilises pour lactivation, modification, et dsactivation des

bearer EPS dans le plan utilisateur, ces bearers de donnes seront utiliss pour transmettre les
donnes entre UE et le rseau IP. Ces procdures sont :

Activation du bearer par dfaut EPS.

Activation du bearer ddi EPS.
Modification du bearer EPS.
Dsactivation du bearer EPS.
La connexion au PDN.

La dconnexion de lUE avec le PDN.

A. Activation du bearer par dfaut

Figure 6. Messages dactivation du bearer par dfaut

 La figure ci-dessus dcrit les changes protocolaires entre lUE et le MME pour
lactivation du bearer par dfaut.
La procdure dactivation de ce bearer est initialise par le MME entre lUE et le P-
GW. Le bearer par dfaut est utilis pour tout trafic qui ne ncessite pas un niveau de qualit
de service autre que celui du best effort. Le bearer par dfaut noffre pas une limite infrieure
sur le dbit sur ces applications (vhicules), les ressources radio alloues ses flux ne lui sont
pas exclusifs dans leNB, le bearer par dfaut (contrairement au bearer ddi) est tablit sans
faire le contrle dadmission radio.
Le MME initialise la procdure dactivation du bearer par dfaut comme une rponse
au message de demande de connexion PDN connectivity request. Le MME envoie vers lUE le
message NAS activate default EPS bearer context request qui est inclus dans lacquittement du
message dattachement NAS Attach Accept.
Si lUE accepte la demande dactivation du bearer par dfaut, il rpond par le message
NAS activate default EPS bearer context accept qui est lui-mme inclus dans le message NAS
attach complete.
Un chec de la procdure dattachement provoque lchec de la procdure de
lactivation du bearer par dfaut. Dans le cas o lUE naccepte pas la rponse de demande
dactivation du bearer, il rpond par le message NAS activate default EPS bearer context
reject qui contient la cause de ce rejet.

B. Activation du bearer ddi

La procdure dactivation du bearer ddi est utilise pour tablir le bearer ddi qui
requiert un niveau de qualit de service spcifique entre UE et le PDN.
Le bearer ddi est utilis pour vhiculer le flux IP qui est ncessite un traitement
spcial lors de son acheminement. La procdure dactivation du EPS bearer ddi est
initialise par le rseau, mais elle peut tre demande par lUE par la procdure de
modification du bearer.

C. Activation du bearer ddi par initie par le rseau

Figure 7. Messages dtablissement du bearer ddi

 La figure ci-dessus reprsente le chronogramme qui illustre les changes entre lUE et
le rseau pour lactivation du bearer ddi.
Le MME envoie le message NAS activate dedicated EPS bearer context request vers
lUE. Ce message contient lidentit du bearer attribuer (EBI), les paramtres de qualit de
service allous au bearer et lidentit du bearer par dfaut avec lequel le bearer ddi
partagera son adresse IP. Si lUE accepte la demande du MME, il rpond avec le message NAS
Activate dedicated EPS bearer context accept. En cas dchec lUE rpond avec le message
NAS Activate dedicated EPS bearer context reject, ce message contient la cause de ce rejet.

C. Activation du bearer ddi initi par lUE

Figure 8. Messages de demande dactivation du bearer par lUE

La figure ci-dessus montre le droulement des changes de signalisation pour la phase

dtablissement du bearer ddi initie par lUE.
LUE peut demander ltablissement dun nouveau bearer qui regroupe un ensemble de
trafic marqu par un ensemble commun des paramtres de qualit de service. LUE envoie le
message NAS Bearer resource modification request vers le MME. Ce message contient
lidentit du bearer par dfaut, cette identit indique le PDN dans lequel le bearer ddi doit
tre tabli. La qualit de service requise et aussi inclue, indiquant la classe de service et les
ressources qui doivent tre alloues.
Si MME accepte la demande, il dclenche la procdure dactivation du bearer ddi
pour rserver les ressources ce bearer, si le MME naccepte pas cette demande il envoie le
message bearer resource modification reject dont la cause de ce rejet est mentionne.

D. Modification du bearer

Figure 9. Messages de modification du bearer initi par le rseau

 La figure ci-dessus reprsente les changes de signalisation impliqus dans la
procdure de modification du bearer.
La procdure de modification du bearer est utilise pour modifier les paramtres de
qualit de service associs au TFT du bearer, lUE peut demander au rseau de dmarrer cette
procdure en envoyant dune demande de modification des ressources, cette dernire contient
lidentit du bearer.
Le MME mit le message NAS Modify EPS bearer context request destination de
lUE, ce message contient lidentifiant du bearer et les informations concernant les paramtres
de qualit de service (du TFT) modifis. Si lUE accepte cette demande, il rpond par un
acquittement positif NAS Modify EPS bearer context accept, sinon lacquittement ngatif est
envoy par le message NAS Modify EPS bearer context reject qui contient une variable dite
cause value qui indique la raison du rejet.

E. Dsactivation du bearer

Cette procdure est utilise pour librer les ressources alloues ce bearer,
lchance de cette procdure, les sessions qui appartenaient ce bearer seront tous termines.
Cette procdure peut tre lance par le rseau cause de longue priode dinactivit radio du
terminal ou par une demande explicite de part de lUE.
E.1 Libration du bearer initie par le rseau

Figure 10. Messages de dsactivation du bearer initi par le rseau

La figure ci-dessus montre les changes de signalisation afin de librer les ressources
alloue un bearer.
Lorsque lUE est en mode ECM-connected et que ce dernier est inactif du point de vue
rseau pendant un certain temps, le MME envoie une demande de libration du bearer radio
dans le message NAS deactivate EPS bearer context request et lenvoie vers lUE. Ce message
contient lidentit du bearer ddi librer. Aprs que lUE reoit ce message, ce dernier
enlve
tous les ressources alloues au bearer et envoie par la suite le message NAS Deactivate EPS
bearer context accept vers le MME.
LorsquUE est en mode ECM-idle, le MME peut effectuer la libration du contexte
associ son bearer localement (sans changes de signalisation), ltat du bearer est
synchronis dans le prochain passage vers ltat ECM-connected (par exemple dans la
procdure de la mise jour de la zone de suivi TAU). Lorsque tous les bearers qui
appartiennent au UE sont librs, le MME met lUE dans ltat EMM-deregistered.
E.2 Dsactivation du bearer initi par lUE

La figure suivante montre les messages de signalisation changs entre lUE et le

rseau pour la libration du bearer.

Figure 11. Message de dsactivation du bearer initi par lutilisateur

LUE peut demander la dsactivation du bearer par lenvoie du message NAS Bearer
resource Modification request vers le MME. Ce message contient lidentit du bearer et celle
du bearer par dfaut. Lors de la rception de ce message par le MME, ce dernier si cette
demande peut tre effectue, et sil est possible le MME dmarre la procdure de dsactivation
du bearer. Si le MME nest pas capable daccepter cette demande, il envoie le message NAS
bearer resource modification reject vers UE qui contient la cause du rejet.

F. Connexion de lUE au PDN

Figure 12. Messages de demande de connexion au PDN initi par le PDN

 La figure ci-dessus illustre les messages relatifs la connexion de lUE au PDN et
lallocation de ladresse IP.
Lors de la phase dtablissement du bearer par dfaut, le message de connexion au
PDN NAS PDN Connectivity Request qui peut tre inclut dans le message dattachement NAS
Attach Request. Dans ce message, lUE inclut les informations concernant le type de
connectivit dsir (IPv4 ou IPv6), pour que la requte dallocation dadresse IP soit redirige
vers le bon serveur DHCP (DHCPv4 ou DHCPv6), ce dernier attribue une adresse aprs la
procdure dactivation du bearer par dfaut. Le message NAS PDN connectivity request peut
indiquer aussi les informations sur nom du point daccs (APN) et le PDN connecter avec,
ceci est vrai pour le cas dtablissement dun autre bearer (au plus du premier bearer par
dfaut). Si le MME accepte cette demande, il dmarre la procdure dtablissement du
contexte. Dans le cas de refus, le message NAS PDN connectivity reject est envoy au MME
contenant la cause du rejet.

G. Procdure de dconnexion de lUE

Figure 13. Message de dconnexion du PDN attach

La figure ci-dessus reprsente les changes entre lUE et le rseau pour sa dconnexion.

Tous les bearers (que ce soit ddi ou par dfaut) seront librs la fin de cette
procdure. LUE initialise cette procdure en envoyant le message NAS PDN disconnection
request vers le MME. Ce message contient lidentifiant du bearer par dfaut. Si MME accepte
cette demande, il met le message NAS PDN disconnection request, il initialise la procdure de
dsactivation du bearer sino il envoie un message NAS PDN disconnection reject vers UE
avec la cause de ce rejet. [3]
Chapitre 2 : La qualit de service dans les rseaux des tlcommunications

Chapitre 2 : La qualit de service dans les rseaux des

tlcommunications

2.1 Introduction
Aujourdhui, on remarque une vritable explosion de la consommation des donnes,
due laugmentation du nombre des utilisateurs mobile qui appartiennent diffrentes
catgories ; autres que le terminal mobile, diffrents types de priphriques terminaux peuvent
tre utiliss afin de se connecter au rseau et daccder une varit de service au plus de la
voix tlphonique (tels que : navigation sur le web, streaming vido, visiophonie, tlphonie
sur IP, etc) et avec lmergences des applications mobiles, laccs ces services est rendu
plus faciles, mais cette diversit de service nest pas sans consquence sur les rseaux des
oprateurs qui doivent fournir un niveau dassurance lors de la dlivrance de ces services ses
clients en un intervalle de temps satisfaisant, tout en tenant compte de la raret des ressources
radio frquentielles et la capacit limite de ces liens de transmission. La diffrenciation entre
les groupes dabonns (selon le forfait) et les types de services proposs, permet loprateur
dutiliser de manire efficace ses ressources mme en cas de congestion. Mais, quels sont les
approches et mcanismes adopts par le rseau cur LTE qui permettent la gestion de qualit
de service et de rpondre aux attentes des utilisateurs ? Telle est la question que nous allons
rpondre dans le cadre de ce chapitre.

2.2 Qualit de service dans les rseaux IP

2.2.1 Modles de qualit de service

A Le modle Best-Effort

Il est considr comme le modle le plus simple implmenter, dans ce modle une
application peut envoyer des paquets sans aucune limitation, elle ne requiert aucune
permission de la part du rseau pour dmarrer sa session. Du ct du rseau, la dlivrance des
paquets est faite selon la capacit des liens actuels et ltat des files dattente de ces
quipements intermdiaires impliqus dans la session actuelle, cette dlivrance est faite sans
aucune contrainte pose sur le dlai et la fiabilit. Cest le modle par dfaut utilis par
lInternet et il est applicable par la plupart des applications rseau non-temps rel tels que FTP
et E-mail, le modle de gestion des files dattente initialement propos repose sur FIFO (First-
In First-Out).
B. Le modle IntServ

IntServ est un modle qui prend en considration lexigence des applications sur la
qualit de service. Dans ce modle, lapplication devra envoyer une requte contenant le type
de service utiliser au rseau avant de dmarrer la session. La requte est faite par change
des messages RSVP (Resource reSerVation Protocol). Avec RSVP, lapplication devra signaler
ces besoins en qualit de service avec tous les quipements intermdiaires impliqus dans la
communication de bout-en-bout.
Lapplication exprime ses paramtres tels que le dbit et la bande passante, une fois
que le rseau reoit cette demande, il vrifie la conformit entre les ressources demandes et
celles disponibles afin de dcider si lapplication sera alloue par ces ressources ou pas. En cas
de disponibilit des ressources, le rseau maintient ltat de chaque flux (identifi par le couple
adresses IP, les ports sources et destination ainsi que le protocole de couche application) et
effectue les fonctions de : classification du trafic, la mise en file dattente (queuing) et la
politique dordonnancement approprie. Une fois que lapplication reoit un acquittement
positif de la part du rseau, elle commencera mettre ses paquets, et le rseau veille ce que
ses besoins en qualit de service pralablement ngocis seront respects pendant toute la
dure de la session.
Deux types de services sont offerts par ce modle :

Garantie de service : O la bande passante alloue est respecte ainsi que le

dlai est limit.
Contrle de la charge : O certaines applications dotes dun faible dlai et une
haute priorit seront maintenues en cas de congestion dans la file dattente de
lquipement intermdiaire.

C. Modle DiffServ

Contrairement au modle IntServ, DiffServ ne requiert pas une signalisation de bout-

en- bout entre lapplication et le rseau afin que ce dernier lui rserve des ressources avant
dentamer la transmission des paquets. Au lieu, la priorisation des paquets est base sur la
valeur du champ DSCP dans lentte du paquet IP.
Dans le rseau DiffServ, chaque quipement intermdiaire effectue lacheminement du
paquet indpendamment de son voisin, ce comportement est appel en littrature PHB (Per-
Hop Behavior). Un paquet IP peut appartenir lune des classes PHB suivantes :
Expedited Forwarding (EF) : Cette classe est gnralement associe aux flux
faible latence et faible variation de dlai (gigue), ces services requirent un
dbit constant et un acheminement rapide depuis la file dattente (fast
forwarding).
 Assured Forwarding (AF) : Dans ce cas, la bande passante du flux est fixe ds
le dbut de la session, en cas dinfraction, le trafic sera affect lune des
quatre classes AF o chacune delle est configure par la probabilit de perte du
paquet dans la file et un volume spcifique de donnes utiliser. IETF suggre
limplmentation de quatre files dattente ddies pour chaque classe AF note
AF1x, AF2x, AF3x et AF4x respectivement, pour chaque classe trois valeurs de
probabilit de perte sont attribues. Donc, au total un paquet peut tre affect
lune des 12 sous-classes AF possibles.
Best Effort (BE) : Cette classe est applicable pour les services lastiques
insensibles au dlai, gigue et perte de paquet tels que les flux de classe de
service background.
Lavantage de DiffServ est sa simplicit de configuration et quil ne requiert aucun
change protocolaire entre les quipements intermdiaires pour la rservation des ressources.
LIETF a recommand des valeurs standards de DSCP pour chaque classe de service PHB ;
chaque quipementier peut adapter ces valeurs selon le type de flux achemin, cependant, les
rseaux doprateurs souffrent de problme dinteroprabilit, car la correspondance des
champs DSCP dun quipement un autre doit tre respecte pour garantir la qualit de
service du flux.

2.2.2 Les fonctions de qualit de service dans le rseau IP

Dans le domaine IP, la qualit de service est assure en faisant appel aux fonctions
suivantes :
Marquage et classification du trafic : Selon les caractristiques du flux entrant, ce
dernier est associ une classe de service approprie. Ces deux fonctions sont
appliques port dentre de lquipement intermdiaire.
Gestion de congestion : Cette fonction fournit les mesures ncessaires afin dviter la
concurrence des applications sur les ressources disponibles en cas de congestion. La
gestion de congestion consiste mettre en mmoire tampon les paquets en attente,
avant dexcuter lalgorithme dordonnancement pour arranger la squence
dacheminement des paquets. Cette fonction est applique sur le port de sortie de
lquipement intermdiaire.
vitement de congestion : Cette fonction consiste surveiller ltat dutilisation des
ressources du rseau, elle sapplique sur le port de sortie de lquipement. En cas de
congestion dans la file dattente, les paquets seront supprims de manire active.
Trafic policing : Lquipement intermdiaire surveille de manire active un flux
particulier arrivant dans son port dentre, et veille ce que les paramtres lis ce
flux ne soient pas viols. En cas de violation de ces paramtres par ce flux, des
restrictions
 et des pnalits lui seront imposs afin de prvenir lusage agressif sur les ressources du
rseau et de protger certains flux sensibles et hautement prioriss.
Trafic shaping : Cette fonction consiste adapter de manire proactive, le volume du
flux sortant par rapport aux ressources disponibles sur le lien de communication avec
le prochain saut (voisin), ceci permet de supprimer les paquets en cas de congestion.
Cette fonction est applique par chaque quipement intermdiaire sur son port de
sortie.
La classification du trafic et le marquage sont les fondations pour fournir des services
diffrencis, la gestion des flux et ressources du rseau sont assurs par les autres fonctions
cites ci-dessus.

A. Classification et marquage des flux

Cette fonction permet de correspondre un flux avec une priorit dordonnancement et

classe de service particulire. Ce marquage de flux peut tre fait en tenant en compte la valeur
du champ DSCP du paquet IP, le champ CoS dans la trame Ethernet mais aussi en fonction de
linterface dentre. Gnralement, une classe de flux est dfinie par le quintuple suivant :
adresse IP source et destination, numro de port source et destination et le protocole de couche
application utilis. Il arrive souvent que le marquage de flux seffectuera par rapport au
segment du rseau impliqu dans la procdure dacheminement des paquets.
Lquipement intermdiaire pourra r adopter la mme classification utilise par son
voisin ou de dfinir sa propre politique de marquage des paquets indpendamment, afin de les
correspondre ses propres critres.

A.1 Entte IPv4

Depuis dcembre 1998, lIETF a publi le document RFC 2474 intitul Definition of
the Differentiated Services field (DS field) in the IPv4 and IPv6 headers, depuis, le champ ToS
(Type of Service) qui stend sur 3 bits (8 valeurs possibles) a t redfini sous le champ DSCP
qui a 8 bits de longueur (donc 64 classes de services peuvent tre dfinis au maximum), les
trois bits les plus gauche sont utiliss pour assurer la rtrocompatibilit avec la spcification
IP Precedence utilise dans le champ ToS, de nos jours, peu de rseaux adoptent cette
configuration. Les deux bits les plus droite sont utiliss pour le contrle du flux et pour
ajuster la taille du paquet IP envoyer, ce deux bits sont appels ECN (Explicit Congestion
Notification).
Lannexe 3 reprsente les diffrentes classes de service dfini pour la spcification IP
Precedence, lantcdent du DSCP.
 A.2 Entte IPv6

En IPv6, le marquage du flux IPv6 est fait grce au champ TC (Traffic Class) qui est
similaire au champ ToS. Dans le paquet IPv6, 20 octets de label sont rservs pour usages
futurs.
A.3 Qualit de service dans la trame Ethernet

Au niveau de la trame Ethernet, le champ TAG qui stend sur 4 octets est utilis pour
diffrencier entre les types de flux transports, cette classification pourra tre faite par
lidentifiant du VLAN tiquet et la priorit de la trame encode sur 3 bits. Lannexe 4
reprsente les classes de services associs pour une trame Ethernet donne.

B. Gestion de congestion

La gestion de congestion assure la gestion du trafic entrant dans lquipement

intermdiaire, cette fonction utilise les technologies de gestion de file dattente dans les cas de
congestion, ces technologies consistent crer les files dattente, classifier les paquets,
attribuer chaque file dattente sa propre classe de service avant dordonnancer les flux
entrants. Une interface qui nest pas surcharge, envoie les paquets entrants ds que ces
derniers sont reus. Lorsque le rythme de rception des paquets devient plus grand par rapport
au rythme de lmission sur linterface, la congestion devient alors invitable dans le cas
dabsence des mesures de prvention.
La gestion de congestion permet la classification des paquets entrant sur le port de
llment rseau, laffectation des paquets leurs files dattente respectives et de dclencher le
processus dordonnancement dans chaque file dattente selon leurs priorits.

C. vitement de congestion

Ce mcanisme permet une surveillance active des ressources rseau tels que ltat des
files dattente et la mmoire tampon, et supprime les paquets afin de prvenir la surcharge de
ces ressources.
C.1 Tail Drop

La politique traditionnelle de suppression des paquets est le tail drop. Lorsque la

longueur maximale de la file est atteinte, tous les paquets suivants seront supprims.
Linconvnient de cette technique est quelle peut engendrer le problme de global TCP
synchronization. Ce problme consiste la suppression des paquets issus de connexions TCP
diffrentes, les processus TCP dclenchent le mcanisme dvitement de congestion et
commencent rduire le rythme denvoi des paquets, et progressivement, le rythme denvoi
des paquets augmentera pour atteindre le seuil. Cela causera une oscillation sur le dbit de ces
paquets entre les valeurs minimales et seuil (de congestion).
 C.2 RED et WRED

Afin de parer au problme de global TCP synchronization, Random Early Detection et

Weighted Random Early Detection sont utiliss.
Lalgorithme RED ou WRED fixe des seuils minimal et maximal pour chaque file, et
traite les paquets entrants dans une file de la manire suivante :
Lorsque la longueur de la file est plus courte par rapport au seuil minimal, aucun
paquet ne sera supprim.
Lorsque la longueur atteint le seuil maximal, tous les paquets suivants seront supprims.

Si la longueur de la file se situe entre les deux seuils, la suppression des paquets est
faite de faon alatoire ; plus la longueur de la file est grande, plus la probabilit de perte des
paquets est aussi grande. Cependant le seuil maximal de probabilit de perte des paquets ne
devra jamais tre dpass.
Contrairement au RED, WRED calcule la longueur moyenne de la file, cette valeur est
ensuite compare avec les deux seuils prcdemment cits afin de dterminer la probabilit de
suppression des paquets. La longueur moyenne est calcule selon la formule suivante :

+1 = (1 2) + 2 1

O : +1 est la nouvelle longueur moyenne,

est la longueur moyenne actuelle de la file,

1estlalongueurmoyenneprcdentedelafile,n est un paramtre configurable.

Le WRED prend en considration la priorit du flux grce au champ DSCP, ToS ou
autre pour dterminer la priorit des paquets en terme de probabilit de suppression ; donc, les
paquets dont la valeur IP Precedence est faible, auront une forte probabilit dtre supprims.
Si tous les paquets ont une mme probabilit de suppression, lalgorithme WRED fonctionnera
de la mme faon que le RED.

D. Traffic Policing

Traffic Policing permet de limiter le dbit allou une session donne, si les paquets
dune certaine connexion excdent cette spcification, cette fonction consiste supprimer les
paquets suivants ou de dgrader leurs valeurs DSCP (ou IP Precedence selon la configuration).
 D.1 Committed Access Rate (CAR)

Pour le fournisseur daccs, il est primordial de limiter le dbit ascendant de ces

clients, cela permet de contrler efficacement la performance de son rseau. Le CAR utilise la
technique du seau jeton (Token Bucket en anglais).
Le CAR classifie les paquets en se basant sur les critres de classe de flux, type de
service
Etc. Les paquets qui correspondent ses critres sont envoys directement au seau jeton.
Le seau jetons est un outil de contrle du trafic, le systme rserve des jetons selon le dbit
fix par rapport ce flux. Le nombre de jeton indique le dbit du trafic que le rseau peut
accommoder.
Si le seau possde assez de jetons pour les paquets envoyer, alors ils seront
achemins et simultanment, les jetons utiliss seront supprims. Si le seau ne possde pas
assez de jeton pour le flux, ces paquets seront supprims. Les paquets de ce flux peuvent tre
rmis une fois que les jetons lui seront rservs dans le seau.
Ainsi, en limitant le dbit du trafic selon le dbit actuel du seau, le contrle du trafic est
implment. En pratique, le CAR peut tre utilis pour changer le marquage du trafic selon la
configuration du rseau, cela permet dviter la suppression du paquet au dtriment de sa
latence. Mais dans le cas de congestion dans la file dattente, le rseau ne garantit pas que ce
paquet soit achemin.

E. Traffic Shaping

Traffic Shaping consiste limiter le dbit du trafic sortant de lquipement

intermdiaire afin de lisser le dbit dmission du flux par le rseau. Cette fonction est
implmente dans les buffers et les seaux jetons. Lorsque le dbit des paquets est trs grand
pour tre support par le port de sortie, ces paquets seront buffriss, ensuite ils seront mis
selon la capacit actuelle du seau jetons.
E.1 Generic Traffic Shaping (GTS)

GTS permet dajuster pro activement le dbit du trafic sortant, en pratique, il est utilis
pour adapter le dbit des flux sortants selon la capacit actuelle du lien. Similaire au CAR, le
GTS utilise le seau jetons pour le contrle du flux, mais la diffrence est que les paquets
supprims par le CAR sont buffriss par le GTS. Donc, le GTS permet de diminuer le volume
des paquets perdus en cas de congestion.
Le mode oprateur du GTS pour chaque flux est le suivant :

Vrifie la conformit du paquet selon les critres configurs dans lquipement

intermdiaire : tout paquet qui ne correspond pas ses critres sera directement
achemin vers le port de sortie, dans le cas contraire, le paquet est envoy au seau
jetons pour tre trait et des jetons y seront rservs selon le dbit appropri au trafic.
 Si le seau possde assez de jetons, le paquet sera achemin, et en mme temps, les
jetons utiliss seront supprims depuis le seau. Si le seau ne possde pas assez de
jetons, le GTS met ce paquet dans la file dattente GTS. Le paquet sera achemin
depuis la file selon les critres du rseau une fois ce paquet entr dans cette file.
Si la longueur de la file atteint sa limite suprieure, les paquets suivants seront
directement supprims.
GTS arrte lenvoi des paquets si les jetons contenus dans le seau ne sont pas
suffisants, ou aucun paquet ne figure dans sa file dattente (file GTS).

F. Line Rate

Line Rate permet de spcifier le dbit maximum dmission des paquets sur une
interface donne, ce mcanisme utilise le seau jetons pour le contrle du trafic.
Lorsquil y a assez de jetons, les paquets seront directement achemins. Lorsquil n y a
pas assez de jetons et pour grer la congestion, les paquets seront mis dans des files dattentes
o chacune delles correspond une qualit de service particulire.
Alors que les paquets seront mis en file dattente standard en GTS, Line Rate met le
flux en se basant sur son type de service dans sa file dattente quivalente (conforme sa
qualit de service). [4]

2.3 Qualit de service dans le rseau EPS

Lorsquun UE excute plusieurs applications en mme temps, chaque application

requiert un niveau de qualit de service spcifique, par exemple lUE peut faire une session
VoIP et en mme temps quune recherche sur le web ou un tlchargement est en cours
dexcution. La VoIP ncessite une qualit de service importante en terme de latence et de
gigue (variation sur le dlai de transmission) par aux applications de web browsing titre
dexemple, dans le but daccommoder plusieurs types de service la fois, diffrents bearers
sont dfini dans la norme, chaque bearer est associ un niveau de qualit de service.

2.3.1 Les composants dune session EPS

Une connexion IP tablit de bout-en-bout entre lUE et le PDN est appele session EPS
(ou PDN Connection), chaque session EPS est reprsente par une adresse IP et un nom de
domaine APN. Plusieurs bearers peuvent tre tablis pour une session EPS, la politique de
qualit de service (ou QoS Policy) applique pour chaque bearer est obtenue par le PCRF.
En gnrale deux types de bearers existent, leurs buts est de fournir la connectivit de
lUE associ une politique de qualit de service dfinit par loprateur. Le tableau suivant
montre quelques caractristiques non-communes pour ces deux bearers, ces caractristiques
seront ensuite abordes dans les sections Bearer par dfaut et bearer ddi et Notions sur
le Service Data Flow (SDF) et le bearer EPS du prsent chapitre.

Type de bearer Par dfaut Ddi

Traffic Flow Template (TFT) Une pour lensemble des Une par chaque bearer
flux transports par ce tablit
bearer
Quantit Un par session EPS Zro ou plusieurs
Type de ressource Non-GBR GBR ou non-GBR
Requit pour ltat EMM-registered Oui Non

Tableau I. Les caractristiques de chaque bearer EPS (par dfaut et ddi)

La figure suivante montre lensemble des bearers requis pour ltablissement dune
session EPS.

Figure 14. La qualit de service de bout en bout (End-to-End) en LTE

A. Bearer daccs radio E-UTRAN

LE-RAB est utilis pour le transport des paquets utilisateur de la voie radio jusquau
rseau cur, il est dfinit comme tant la concatnation du bearer S1 et le bearer radio des
donnes DRB ; lidentifiant E-RAB ID est utilis par leNB et le MME pour fournir lidentit
de lutilisateur au rseau EPC, cet identifiant a la mme valeur que celle attribue au EPS
Bearer ID (identifiant du bearer EPS). Les entits du rseau responsable de la gestion de ce
bearer sont leNB et le MME.
 Data radio bearer : Ce bearer accommode les paquets du bearer E-RAB entre lUE et
leNB sur linterface LTE-Uu.
S1 Bearer : Il vhicule les paquets transport dans le bearer E-RAB entre leNB et le
S- GW.

B. Bearer S5/S8

Ce bearer est utilis pour transporter les paquets du bearer EPS entre le S-GW et le P-
GW.

2.3.2 Les fonctionnalits de la qualit de service dans les plans de contrle

et dutilisateur

A. Plan de contrle

Contrle dadmission : Elle permet au rseau de prendre les dcisions concernant

ltablissement dune nouvelle session en se basant sur les ressources actuelles
utilises.
Contrle du profil dabonnement : Le rseau vrifie si lutilisateur a le droit
dutiliser le service demand avec le niveau de qualit de service attribu.
Gestion des services : Cest la coordination entre les fonctions dans le plan de contrle
durant la phase de modification et de suppression des bearers EPS.
Fonction de traduction : Elle couvre les diffrents protocoles utiliss pour
linterfonctionnement entre le rseau EPC et le rseau externe en ce qui concerne le
maintien du niveau de qualit de service pour les flux achemins.

B. Plan dutilisateur

Fonction de traduction (mapping) : Elle fournit chaque flux le marquage spcifique

requis pour attribuer le niveau de qualit de service attendu. Par exemple: le marquage
du DSCP dans le P-GW.
Fonction de classification : Elle consiste lassignation des flux de donnes dans leur
bearer appropri, cette classification est faite selon la qualit de service
correspondante.
Gestion des ressources : cette fonction distribue les ressources disponibles entre tous
les services qui partagent les mmes ressources du rseau en se basant sur la priorit de
chaque utilisateur, parmi les mcanismes de gestion des ressources en trouve :
lordonnancement des paquets, gestion de la bande passante, et contrle de puissance
dans la voie radio.
 Traffic Shaping : Elle sert lisser le dbit du flux de donnes entrant sur lien avec la
capacit actuelle de ce dernier. [5]
2.3.3 Bearer par dfaut et le bearer ddi

Pour une bonne gestion de la qualit de service dans le rseau LTE, deux type de
bearer sont dfini Bearer ddi and Default bearer. Default bearer est tabli lors de
lattachement du UE tandis que le bearer ddi est tabli lorsque le rseau doit fournir une
QoS spcifique comme VoLTE.
La figure suivante montre les deux types de bearer dfini dans la norme avec leurs
paramtres appropris :

Figure 15. Les types de bearer en LTE

A. Bearer par dfaut

Lorsque lUE initialise la connexion avec le rseau LTE pour la premire fois, le rseau
lui attribue un bearer par dfaut dont les paramtres correspondent au profil dabonnement
(tlcharg par le MME depuis le HSS) se bearer sera maintenu jusqu la dconnexion de
lUE vis--vis le rseau. Le bearer par dfaut ne supporte aucun dbit garanti, il fournit les
services en mode best effort, chaque bearer a une adresse IP ; lUE peut avoir un deuxime
bearer par dfaut dans le cas dune demande de connexion un deuxime APN. Dans ce cas,
une deuxime adresse IP sera alloue par la passerelle de cet APN. Les QCI 5 jusqu 9
correspondent ce bearer.

B. Bearer ddi

Cest un autre bearer trs important pour un traitement dun service spcifique comme
VoLTE, vido. Il ne require pas une adresse IP additionnelle parce quil partage ladresse IP
qui a t alloue pour le bearer par dfaut. Les flux accommods dans ce bearer peuvent avoir
un dbit garanti (GBR). Pour offrir le traitement spcifique ces flux, chaque bearer ddi
contient les paramtres dfinit dans le TFT Template, le bearer ddi peut tre class comme
tant :
 Guaranteed Bit Rate Bearer (GBR Bearer):Ce bearer reprsente le minimum
de dbit garanti allou pour des applications temps-rel tels que : la VoLTE.
Chaque bearer est associ avec une valeur GBR prdtermine. Si le trafic
transport est gale cette valeur, donc il ny aura pas de congestion qui peut
entrainer une perte des paquets. Le bearer GBR est tabli la demande parce
quil bloque toutes les ressources de transmission pour lui tre rserves durant
la procdure de contrle dadmission.
Non-Guaranteed Bit Rate Bearer (Non-GBR Bearer):Ce bearer ne garantit
aucun dbit binaire, il est principalement utilis pour les applications non-temps
rel comme la navigation web et le transfert des fichiers. Les services
achemins par ce bearer sont souvent en risque davoir une congestion qui peut
entrainer la suppression de leurs paquets. Ltablissement de ce bearer ne
bloque pas les ressources dune transmission spcifique. Le bearer non-GBR
peut tre associ au bearer ddi ou le bearer par dfaut.

C. Paramtres de qualit de service

Un bearer EPS est dfini par quatre paramtres o leurs valeurs dpondent de la nature
du service demand, de la priorit de labonn qui est lie son profil et de ltat actuel des
ressources de loprateur, ces paramtres sont :
QoS Class Indicator (QCI)
Allocation and Retention Priority (ARP)
Guaranteed Bit Rate (GBR) rserv pour les services temps-rels.
Maximum Bit Rate (MBR) rserv pour les services temps-rels.
C.1 Quality of Service Class Indicator (QCI)

Le QCI indique le traitement spcial appliquer sur un trafic ou un paquet IP qui est
mis sur un bearer spcifique. Ce traitement peut inclure la priorit dordonnancement, le seuil
dadmission Etc.
3GPP recommande pour chaque classe QCI lensemble des valeurs suivantes :
 QCI Resource Priority Packet Packet Loss Example Services
Type Level Delay Rate
Budget
1 2 100 ms Conversational Voice
102
2 4 150 ms Conversational Video (Live Streaming)
103
3 GBR 3 50 ms Real Time Gaming
103
4 5 300 ms 106
Non-Conversational Video (Buffered
Streaming)
5 1 100 ms IMS Signaling
106
6 6 300 ms Video (Buffered Streaming)
106
Non- TCP-based (e.g., www, e-mail, chat, ftp,
p2p file sharing, progressive video, etc.)
GBR
7 7 100 ms 103
Voice,Video (Live Streaming)
Interactive Gaming
8 8 Video (Buffered Streaming)
TCP-based (e.g., www, e-mail, chat, ftp, p2p
9 9 300 ms 10
file sharing, progressive video, etc.)
6
Tableau II. Les classes QCI avec leurs priorits et services ddis selon 3GPP

C.2 Allocation and Retention Priority (ARP)

ARP indique si un bearer (tabli ou modifi) peut tre accept ou rejet par loprateur
dans le cas dune congestion dans ces liens de transmission. Il est utilis par leNB pour
supprimer les paquets qui ont une faible ARP pour le but de librer la capacit du rseau et
dallger sa charge. Ce paramtre peut tre un paramtre important lors du handover lorsque
UE dplac vers une cellule congestionne.
C.3 Maximum Bit Rate (MBR)

MBR est spcifi pour les bearers de type GBR et il est applicable juste dans les
services temps rel. Il spcifie le dbit binaire maximum dans un bearer pour lequel le trafic
ne peut par le dpass.
C.4 Guaranteed Bit Rate (GBR)

Le GBR est principalement dfini pour le GBR bearer, il spcifie il le dbit binaire qui
doit le rseau garantir pour un bearer particulier. Dans la release 8 du 3GPP le MBR doit tre
gale au GBR c d que le dbit garantie cest aussi le dbit maximum garantie qui est permet
par le rseau.
3GPP a ajout un paramtre avec les 4 autre paramtres qui est Aggregate Maximum
Bit Rate (AMBR) et qui est appliqu seulement sur un groupe des bearers non GBR. AMBR
permet aux oprateurs de limit la somme total de dbit binaire consommer par un seul
utilisateur. Ce paramtre est appliquer dans les deux sens UL et DL. [6]

2.4 Notions sur le Service Data Flow (SDF) et le bearer EPS

2.4.1 Introduction

Un system LTE est un systme qui est capable de fournir des services avec des QoS
diffrentes pour tous les types dutilisateurs (Gold, Silver, Bronze) et pour le type de service
demand (Internet, VoIP, etc) afin dutiliser les ressources du rseaux dune faon
performante et dassurer une QoE pour ces diffrents utilisateurs.
Pour cette raison, LTE classifie les flux IP utilisateurs dans des SDF diffrents, chaque
SDF est Contrl par des rgles de QoS.

2.4.2 SDF et bearer EPS

Un SDF reprsente un groupe de flux IP associ au service utilis par lutilisateur. Le

bearer EPS reprsente les flux IP des SDF qui ont la mme classe de QoS.

Les flux IP qui arrivent au P-GW sont filtrs grce aux Packet Filters associs dans des
TFT pour les bearers EPS et par le SDF Templates pour les SDF, ces Packet Filters sont
prconfigurs par les oprateurs selon leurs politiques (ex : Marketing).
Les flux IP qui sont caractriss par le mme service et qui correspondent aux Packet
Filters dun SDF Template particulier, ce SDF Template (qui correspond aux Packet Filters
dun TFT donn) est mapp au bearer EPS correspondant. Les SDF qui ont la mme classe de
QoS sont regroups dans un seul bearer EPS ; si les SDF ont des classes de QoS diffrentes,
ils seront regroups dans des bearers EPS diffrents.

2.4.3 Service Data Flow (SDF)

Cest lensemble des flux IP qui sont classifis selon le type de service utilis. Les
diffrents SDF ont des niveaux de qualit de service diffrents qui sont appliques par les
procdures PCC.
 Les flux IP qui sont destination de lUE sont classifis dans des SDF suivant leur type
de service par lutilisation de SDF Template, ensuite des politiques de QoS (priorit, bande
passante, etc.) seront appliques ces SDF ; enfin, chaque SDF est mapp par le P-GW vers le
bearer EPS qui satisfera les conditions de QoS avant de transmettre ces flux vers lUE.

2.4.4 Bearer EPS

Il existe deux types de bearer EPS : bearer par dfaut et bearer ddi. Lors de
lattachement de lUE au rseau, le bearer par dfaut est tabli et suivi par lallocation
dadresse IP pour la connexion de lUE au PDN, lorsque lUE veut des services qui demandent
une QoS importante et que ces services ne sont pas supports par le bearer par dfaut (ex :
VoLTE), un bearer ddi sera tabli la demande avec une QoS diffrente celle du bearer
existant (bearer par dfaut), un UE peut se connecter plusieurs PDN qui ont obligatoirement
un bearer par dfaut et zro ou plusieurs bearers ddis.
Un bearer par dfaut est tabli par APN. Lors de lattachement de lUE au rseau, le
rseau a besoin des informations pour tablir ce bearer tels que : la QoS de lUE et le nom de
domaine de lAPN. Ces informations sont stockes dans le HSS (dans le profil dabonnement
de lUE), donc le MME tlcharge ces informations (default APN, QoS profile Etc.) pour
slectionner le P-GW (passerelle) et dactiver le bearer par dfaut avec lAPN qui correspond
sur la base de ces informations reues.

La figure16 montre les SDF et bearer EPS tablis entre lUE et le rseau EPC. Lorsque
les flux IP sont dlivrs vers UE (DL) travers EPS, les flux IP qui arrivent au P-GW travers
le PDN sont filtrs par les SDF Templates. Les flux 1, 2, 3 sont filtrs aux SDF 1, 2 et 3
respectivement, et les flux 4, 5 vers SDF 4. Plusieurs politiques de QoS sont appliques
chaque SDF, ensuite les SDF sont mapps avec le bearer EPS par classification en utilisant
TFT. Les SDF 1 et 2 sont mapps avec le bearer par dfaut et les SDF 3 et 4 avec le bearer
ddi, larrive des flux IP dans lUE, ces derniers seront destins vers leurs applications
respectives.
 Figure 16. Correspondance entre Flux IP, SDF et bearer EPS pour les
applications de lUE

2.4.5 Les paramtres de qualit de service du SDF et du bearer EPS

La qualit de service est dfinie au niveau du flux(ou SDF QoS parameters) et au

niveau bearer (ou EPS bearer QoS parameters). Le niveau de service (Service Level) et niveau
bearer (Bearer Level) sont aussi appels SDF Level et SDF Aggregate Level. Un SDF
Aggregate Level reprsente un groupe de SDF qui ont la mme valeur du QCI, ARP et
appartenant une session EPS donne.
SDF QoS parameters : QCI, ARP, GBR, MBR.
EPS bearer QoS parameters : QCI, ARP, GBR, MBR, APN-AMBR et UE-
AMBR.

A. Paramtres de qualit de service du SDF

QCI et ARP sont appliqus sur tous les SDF. QCI est une valeur entre 1 et 9 qui
indique neuf classes de qualit de service diffrentes, o chacune est dfini par les paramtres
suivants pour chaque paquet IP : le dbit (GBR, non-GBR ou MBR), Packet Delay budget
(entre 50 ms et 300 ms) et Packet Loss Rate (10-2 ~ 10-6).
Si le trafic rseau nest pas congestionn, le trafic utilisateur dun SDF peut tre
vhicul au plus avec un dbit maximum spcifi (MBR). Cependant le GBR est le dbit
garanti dun SDF ; donc, dans le cas o le trafic rseau est congestionn le trafic utilisateur
sera vhicul au moins avec un dbit garanti (GBR).
 Il existe deux types de SDF :

GBR SDF QoS parameters : QCI, ARP, GBR (en UL et DL) et MBR (en UL
et DL) constituent ces paramtres.
Non-GBR SDF QoS parameters : Dont les paramtres sont QCI, ARP et
MBR (en UL et DL).

B. Paramtres de qualit de service du bearer EPS

Similaire au SDF, QCI et ARP sont aussi appliqus dans tous les bearers EPS. Un
bearer EPS peut tre classifi comme GBR ou non-GBR, tout dpend du QCI choisi.
Autre que QCI et ARP, Le bearer EPS est dfini par les paramtres : MBR, GBR et
AMBR qui indique le dbit maximum, le dbit minimum et la somme des dbits non-garanti
(non-GBR) pour tous les bearers dun UE respectivement.
Il existe deux types dAMBR :

APN-AMBR : la bande passante maximale qui peut tre partage entre tous les
bearers non-GBR dans un PDN donn.
UE-AMBR : la bande passante maximale qui peut tre partage entre tous les
bearers dans lUE.
Un UE peut se connecter avec plus dun PDN (chaque PDN possde son APN-
AMBR), donc la somme des APN-AMBR de tous les PDN ne doit pas dpasser lUE-AMBR.
GBR bearer QoS parameters : Il est dfinit par les paramtres suivant : QCI,
ARP, GBR (en UL et DL) et MBR (en UL et DL).
Non-GBR bearer QoS parameters : Dont les paramtres sont : QCI, ARP,
APN-AMBR (en UL et DL) et UE-AMBR (en UL et DL).
La figure suivante montre deux connexions dUE vers deux APN, o pour chaque APN
est dfini par des paramtres de qualit de service dans ces bearers EPS et dans les SDF.
 Figure 17. Paramtres de qualit de service des connexions entre lUE et chaque
APN

Dans cette figure, lUE est connect deux PDN, il possde deux adresses IP
attribues par les P-GW 1 et P-GW 2 respectivement. Pour chaque PDN, il existe un bearer
par dfaut et deux bearers ddis. Les flux IP sont filtrs grce aux SDF Templates
configures dans chaque P-GW. Il y a deux groupes de SDF (1 5) appliqus aux flux IP
arrivants au P-GW 1 et P-GW 2 respectivement. Pour ces SDF, les ressources rseau sont
alloues et les paquets arrivants sont traits suivant les rgles de QoS dfinies dans le P-GW ;
aprs ce traitement, les SDF sont mapps dans le bearer EPS correspondant en se basant sur
les paramtres QCI et ARP. Prenant le cas du PDN 1, les SDF 1 et 2 sont mapps dans un
bearer par dfaut non-GBR et les SDF 3 et 4 dans un bearer ddi non-GBR qui sont tablis
pour le mme UE. La correspondance entre le SDF avec le bearer EPS est dfinie dans le
TFT.
Le paramtre APN-AMBR dfinit le seuil maximal de la somme des dbits pour tous
les bearers non-GBR dun UE tablis dans le mme APN, et tous les bearers non-GBR
associs un UE, verront leur somme maximale des dbits contrle par le paramtre UE-
AMBR.
 C. Approvisionnement et la mise en vigueur de QoS

Figure 18. La rservation des paramtres de QoS par les lments du rseau
LTE

C.1 Approvisionnement de la qualit de service

La figure ci-dessus indique les entits du rseau impliques dans la phase de

rservation des ressources relatives une qualit de service, demande par le rseau lui-mme
ou linitiative de lusager.

Approvisionnement de la qualit de service dans le SDF

Tous les paramtres de QoS qui correspondent un SDF particulier sont provisionns
par le PCRF.

Approvisionnement de la qualit de service dans le bearer EPS

Les paramtres de la qualit de service dun bearer par dfaut sont provisionns par le
HSS, ils sont stocks avec les donnes de souscription de labonn LTE. Lors de la phase
dtablissement du bearer par dfaut, le MME tlcharge le profil de qualit service depuis le
HSS, et lenvoie vers les entits EPS appropries. Ces paramtres de QoS peuvent tre
modifis lautorisation du PCRF.
UE-AMBR qui est contrl par eNB est fourni par le HSS, mais il peut tre modifi par
le MME, ce dernier remplace lUE-AMBR existant par la somme des dbits autoriss par tous
les APN connects avec lUE, afin de ne pas dpasser la valeur fournie par le HSS (souscrite
dans le profil).
 Les paramtres de QoS dun bearer ddi sont approvisionns par le PCRF. Il
dtermine ces paramtres en se basant sur les informations de souscription envoyes par le
SPR lorsque ce bearer est activ.
C.2 Mise en vigueur de la qualit de service

Les rgles de QoS sont appliques lors de la dtection des trafics utilisateur (flux IP,
SDFs, bearer EPS).

Figure 19. La mise en application des paramtres de qualit de service par les
lments du rseau LTE

Cette figure montre o sont fixs et appliqus les paramtres de QoS par SDF et par
bearer EPS. Les paramtres de QoS qui se trouvent dans le S-GW sont les mmes contenus
dans le P-GW, seuls les QCI sont reprsents dans cette figure.

Mise en vigueur de la qualit de service dans le SDF

Les paramtres de QoS contenus dans le SDF sont appliqus par le P-GW. Les flux IP
qui arrivent au P-GW sont filtrs par les SDF Templates.

Paramtres de QoS dans le SDF Mise en application

QCI Appliqu tous les SDF par le P-GW.
ARP Appliqu par le P-GW tous les SDF.
MBR Appliqu tous les SDF par le P-GW.
GBR Appliqu par le P-GW uniquement aux GBR
SDF.

Tableau III. Le domaine dapplication de chaque paramtre de qualit de service dans le SDF
Mise en vigueur de la qualit de service dans le bearer EPS

Les paramtres de QoS pour les bearers EPS sont appliqus dans les entits du rseau
EPS suivantes : UE, eNB, S-GW et P-GW.
APN-AMBR est appliqu pour tous les bearers de type non-GBR (actifs dans
un PDN) par les entits qui se trouvent aux extrmits du tunnel rserv (ici
lUE et P-GW). Ce paramtre est applicable uniquement dans le sens ascendant
(vers leNB), ct P-GW, ce paramtre est pris en considration dans les deux
sens de la communication.
UE-AMBR est appliqu par leNB pour tous les bearers non-GBR actifs dun
UE donn.
LUE et leNB prennent en considration le MBR (dbit maximum), ce dernier est
appliqu juste pour les bearers de type GBR et uniquement pour le trafic ascendant, il est
applicable seulement pour le trafic descendant par le S-GW et P-GW. [7]
Paramtres de QoS dans le bearer Mise en application
EPS
QCI Appliqu tous les bearers par toutes les entits du
rseau.
ARP Appliqu tous les bearers par toutes les entits du
rseau lexception de lUE.
MBR Appliqu seulement aux bearers de type GBR :
Sens montant : par lUE et leNB.
Sens descendant : par le S-GW et le P-GW.
GBR Appliqu seulement aux bearers de type GBR par
toutes les entits du rseau lexception de lUE.
APN-AMBR Appliqu seulement aux bearers de type non-GBR :
Sens montant : par lUE et leNB.
Sens descendant : le P-GW.
UE-AMBR Appliqu seulement aux bearers de type non-GBR par
leNB.

Tableau IV. Domaine de mise en application des paramtres de QoS pour les bearers EPS
Chapitre 3 : Algorithmes dordonnancement des paquets dans le rseau LTE

Chapitre 3 : Algorithmes dordonnancement des paquets

dans le rseau LTE

3.1 Introduction

Lordonnancement est lune des principales fonctions utilises dans le rseau LTE, car
elle est charge de distribuer les ressources disponibles entre les utilisateurs actifs afin de
satisfaire leurs exigences en qualit de service. Dans le rseau LTE, les ordonnanceurs des
paquets pour la transmission (sur les voies montante et descendante) sont implments dans
leNB; cet lment joue un rle fondamental : il vise maximiser lefficacit spectrale
travers une allocation effective des ressources qui rduit ou rend ngligeable limpact de
fluctuation instantane sur la qualit du canal de transmission radio. Actuellement, les services
multimdia en temps-rel tels que la vido et la VoIP sont devenus trs populaires et trs
utiliss parmi les utilisateurs dans les rseaux mobiles rcents. LTE fournit une qualit de
service pour les services multimdia avec une connectivit rapide et une prise en charge dans
le cas dune forte mobilit des usagers entre les cellules LTE voisines. Cependant, les
spcifications du groupe 3GPP ninclut aucune politique dordonnancement pour supporter les
applications lastiques et non- lastiques, limplmentation de ces ordonnanceurs est laisse
sous la responsabilit des quipementiers tlcoms.
Seule lallocation dynamique des ressources est implmente en LTE, ceci permet de
maximiser lutilisation des ressources offertes par le rseau et de fournir lquit (fairness en
anglais) entre les utilisateurs. Lordonnanceur est une fonction qui rside dans la couche MAC
de leNB, cette couche est aussi responsable des procdures daccs alatoire et les requtes
dordonnancement inities par lUE pour la transmission sur la voie montante.
Lordonnanceur des paquets peut tre segment en deux entits spares :

Time Domain Packet Scheduler (TDPS) : Cest lordonnanceur des paquets

dans le domaine temporel, cet ordonnanceur choisit un groupe des UEs pour
partager les ressources radio pendant la priode du temps TTI (Transmission
Time Interval) qui dure 1 ms qui reprsente deux blocs de ressources RBs
conscutifs.
Frequency Domain Packet Scheduler (FDPS) : Lordonnanceur des paquets
dans le domaine frquentiel dtermine la taille du bloc de transport allouer et
le schma de codage MCS par rapport aux conditions instantanes du canal
radio par UE.
La stratgie dordonnancement dans nimporte quel rseau sans-fil peut tre classe
selon deux approches :
 Channel independent scheduling : Cette approche se base sur lhypothse que le
canal de transmission est invariant dans le temps et sans imperfection. On peut
citer quelques algorithmes qui remplissent ce critre tels que : First-in-First-out
(FIFO), Round Robin (RR), Weighted Fair Queuing (WFQ), Largest Weighted
Delay First (LWDF) Etc.
Channel dependent scheduling : Avec laide des rapports sur la qualit du canal
radio CQI (Channel Quality Indicator) transmis par lUE et destin leNB,
lordonnanceur est en mesure destimer la qualit du canal radio peru par
chaque UE, on peut citer quelques algorithmes qui adoptent cette approche :
Proportional Fairness (PF), Modified-Largest Weighted Delay First (M-LWDF),
Exponential Proportional Fairness (EXP/PF), Logarithmic Rule (LOG rule)
Etc.
En LTE, seuls les ordonnanceurs qui prennent en considration ltat actuel du canal
radio (perceptible chez lUE) sont recommands par les organismes de normalisation.

3.2 Contraintes lies lallocation des ressources radio

Dlai de transmission : Un dlai dacheminement dlimit pour un paquet est

essentiel pour maintenir la qualit de service approprie.
Condition du canal : cause des variations sur la distance entre la station de
base et les utilisateurs, ainsi que dautres facteurs tels que : propagation multi
trajet et lvanouissement du signal par effet de masque (shadow fading), la
condition du canal radio pour chaque utilisateur souffre de fluctuations
invitables.
Type de service : De faon gnrale, il existe deux types de services en LTE :
temps rel (Real Time) et non-temps rel (Non-Real Time). La priorit
dordonnancement du paquet devra tre faite par rapport au type de service
auquel il appartient le flux.
Complexit : Elle quantifie le temps ncessaire pour quun algorithme
sexcute. Ds lors que lallocation des ressources en LTE est faite dans chaque
intervalle de temps TTI qui vaut 1 ms. Ainsi, lalgorithme choisi doit fournir un
rsultat avec un temps bien infrieur celui du TTI. Un algorithme
dordonnancement avec une faible complexit est requis pour effectuer cette
allocation.
tat de la mmoire tampon (buffer status) : Il fournit les informations sur le
volume de paquet en attendant dtre servi dans la file dattente. Ce paramtre
est troitement li au dbit associ lapplication utilise, une application dont
 le dbit est grand, a une file dattente plus longue que celle avec un dbit
infrieur.

Fairness (quit) : Dans un groupe de flux htrogne, fairness est dfini

comme tant le volume exact de ressource associ un flux en fonction de ses
caractristiques : taille, type de service, qualit du canal etc.
Dans le contexte de notre tude, fairness est considre comme une question de savoir
si les utilisateurs ou les flux ont reu les ressources quils mritent.
Deux types de fairness sont dfinis dans le domaine dallocation des ressources :

Partial fairness : Cest la mesure faite dans un groupe o les flux

appartiennent au mme type, par exemple : fairness parmi les flux
VoIP. Malgr que les flux appartiennent la mme classe, ils ne
possdent pas la mme condition du canal radio, cet gard, on peut
dire que ces flux sont partiellement htrognes.
Total fairness : Cest la mesure faite dans un groupe o les flux sont
htrognes, par exemple : VoIP, Video et Best-effort. Dans ce cas,
les utilisateurs ne possdent pas le mme dbit ni la mme condition
du canal radio. [8]

3.3 Channel sensitive scheduling

A. Maximum Throughput

Cet algorithme offre un dbit maximum global au rseau en allouant chaque RB aux
UEs qui prouvent une meilleure qualit du canal radio. Cela veut dire, un UE qui possde une
trs bonne qualit du canal sera toujours programm par lordonnanceur pour la transmission
(montante et/ou descendante), lordonnanceur choisit lutilisateur i pour la transmission du
kme bloc de ressource par la formule suivante : [9]

= arg max( ( )); 1 [10]

O :
est le dbit attendu pour lutilisateur i linstant t dans le kme bloc de

ressource( )et N le nombre des utilisateurs dans la cellule.

Linconvnient de cet ordonnanceur est quil est non-quitable lors de lallocation des
ressources pour les utilisateurs qui se trouvent aux bords de la cellule. [9]
B. Proportional Fairness

Cet algorithme offre un compromis entre lefficacit spectrale et lquit entre les
utilisateurs. Lordonnanceur choisit lutilisateur i parmi N candidats selon la formule suivante :
()
= arg max ( ) ; 1 [11]

(1)

O : est le dbit moyen dans lintervalle de temps t-1, la valeur du
dnominateur sera rduit pour les utilisateurs ayant une mauvaise condition du canal radio, ce
qui rend la mtrique maximale, donc ces utilisateurs auront malgr tout toutes leurs ressources
demandes. [9]
Le dbit moyen de lutilisateur dans lintervalle de temps t est calcul par la formule
suivante :
1
( )
1)
1

( ) = (1 + ( ) [12]

O : T est lintervalle de temps de transmission TTI gale 1 ms. ( ) est le dbit

atteint par lutilisateur i linstant t.

C. Generalized Proportional Fairness (GPF)

Cet ordonnanceur est une amlioration de lordonnanceur PF avec lintroduction de

deux nouveaux paramtres et , ces derniers reprsentent les facteurs de pondration

respectivement pour le dbit binaire atteint pour lutilisateur
i ( ( )) et le dbit binaire atteint
lintervalle de temps t-1( 1) [9], la formule mathmatique employe par cet
ordonnanceur est la suivante :


= max ( [ ()] ) [13]

[( 1)]

D. Throughput to Average

Cet algorithme est considr comme une approche intermdiaire entre lordonnanceur
MT et PF, la priorit m de lutilisateur i pour le kme bloc de ressource est dtermine par la
formule suivante : [9]

()) ; 1 [14]

= max (

()
 O : ( ) est le dbit moyen long terme pour lutilisateur i linstant t.

Daprs la formule, plus le dbit global long terme est grand pour lUE i moins sera sa
priorit attribue par leNB pour le kme bloc de ressource. [9]
E. Modified-Largest Weighted Delay First

Dans cet algorithme, les flux temps-rel et non-temps-rel ne sont traits de la mme
manire, cet ordonnanceur prend en considration la longueur en bits du paquet de lutilisateur
i le dlai dacheminement du paquet Di et un poids i du paquet dans la file dattente au plus

des paramtres ( ) et ( 1) . Lordonnanceur choisit lutilisateur i pour la transmission

dans lintervalle de temps t avec la formule suivante : [9]

()

= ) ; 1 [15]
(1)
max (

Daprs la formule suivante, il est clair que lquit entre les utilisateurs dpend de la
condition du canal radio, le processus darrive des paquets et la qualit de service requise
pour les flux figurants dans la file dattente. [9]

F. Exponential Proportional Fairness (EXP/PF)

Cet algorithme a t dfini pour supporter les flux multimdia temps-rel pour les
systmes TDM (Time Division Multiplex) tel que lUMTS, il garantit un dlai sur les services
en temps-rel ainsi quun dbit maximal de la cellule avec un certain niveau dquit. La
mtrique de priorit est calcule selon la formule suivante : [9]
(
() ; 1 [16]
= max
)

1+
(1)

( )

O :
=1
=

Et le nombre de flux en temps-rel actifs, est le poids associ chaque flux

appartenant un flux de service donn, est la longueur en bit du paquet figurant dans la file

dattente. () est le dbit attendu pour lutilisateur i linstant t pour le kme bloc de

ressource,

( 1) est le dbit moyen jusqu linstant prcdent (t-1) lmission du paquet courant,
cette proprit
(
(
1)) permet lordonnanceur de prendre en charge les flux non-temps rels. [9]

G. Exponential Rule (EXP-Rule)

 Lordonnanceur exponentiel est considr comme une amlioration de lordonnanceur
EXP/PF, il utilise au plus des paramtres utiliss dans EXP/PF : lefficacit spectrale de
lutilisateur i est lun des paramtres doptimisation qui sont fixs par rapport au besoin du
rseau. [9]

1
+()


= arg ( ) ; 1 , [17]
max

( )

O : est lefficacit spectrale de lutilisateur i pour le kme bloc de ressource. ,

et sont les paramtres doptimisation de lordonnanceur par rapport aux contraintes du rseau.

Il est noter que lordonnanceur EXP-Rule prend en considration le dlai pris par un
paquet dun utilisateur et de le normaliser par rapport au dlai global expriment par les UEs
de la cellule. Lavantage de cet ordonnanceur est quil sappuie sur ltat du rseau (ici la
cellule LTE) avant daborder le processus dordonnancement. [9]

H. Logarithmic Rule (Log-Rule):

Cet algorithme se base sur les mmes paramtres utiliss dans lordonnanceur EXP-
Rule, cependant, la mtrique dordonnanceur est calcule partir du logarithme du dlai
dacheminement du flux de lutilisateur i. La formule utilise est la suivante : [9]

= arg max( log( + ) ) ; 1 [18]

Lquit et le dbit optimal de la cellule LTE sont obtenus en choisissant les bons
paramtres doptimisation ai, bi et c. [9]

3.4 Fairness-based algorithms

A. Round Robin (RR)

Lordonnanceur alloue la mme quantit des ressources pour tous les UEs. RR vise
fournir un partage cot gal du temps de transmission du paquet pour chaque utilisateur.
Cependant, la performance en terme de dbit est dgrade de faon significative tant donn
que lordonnanceur ne sappuie pas sur les mesures de SINR (Signal to Interference and Noise
Ration faite par les UEs dans la liaison descendante) pour dterminer le nombre de bits
transmettre dans le bloc de transport.
Pour de nombreuses raisons, lordonnanceur RR ne peut tre dcrit comme un
ordonnanceur quitable :
 Les utilisateurs ne peuvent avoir la mme position vis--vis la station de base,
donc la qualit du canal radio pour chaque utilisateur ne peut tre gale; ce qui
signifie que tous les utilisateurs nont pas le mme dbit garanti.
 Les services demands par les utilisateurs ne sont pas de mme nature (VoIP,
SMS, http etc.). Chaque type de service a sa propre qualit de service
respecter tel que le dbit et la taille des paquets transmettre.

Lordonnanceur RR nest pas efficace pour les services non-lastiques, du moment que
LTE se focalise sur la garantie de la qualit de service pour les services non-lastiques
mergeants (tel que D2D, Video Streaming ...etc.).

B. Max-Min Fair (MMF)

La distribution des ressources par cet ordonnanceur est faite de faon itrative entre les
UEs afin daugmenter le dbit global attribu chaque utilisateur de manire progressive et
quitable. Lorsque le dbit demand est allou un utilisateur, lalgorithme arrte dattribuer
les ressources pour cet utilisateur et commence allouer les ressources au prochain utilisateur
jusqu satisfaire leur besoin en dbit. Lalgorithme ne sarrte pas tant que les utilisateurs
naient pas atteint leur dbit voulu et que les ressources ne soient pas puises.
Linconvnient de cet algorithme est la rduction de lefficacit du systme, en effet les
utilisateurs qui ont de bonnes conditions de canal radio seront toujours pnaliss. Dune part,
tous les utilisateurs auront au dbut le mme dbit allou pour la communication, ceci prsente
un grand avantage pour les UEs qui ncessitent un faible dbit, ces derniers seront toujours
satisfaits du service. Dautre part, les UEs qui requirent du haut dbit ne seront pas toujours
satisfaits sur le service fourni, gnralement leur dbit allou nest pas suffisant pour profiter
du niveau de qualit de service pralablement ngoci. [8]

3.5 Algorithmes ordonnancement multi-classe

Cette classe dordonnanceur prend en considration les classes des flux mis en file
dattente afin dexcuter la politique dordonnancement approprie chaque classe. Le type de
flux (que ce soit temps rel ou non-temps rel) est un paramtre fondamental pour ce type
dalgorithmes. Avant de prendre la dcision sur lallocation des ressources, le type de service
doit tre inspect avant dallouer les blocs de ressources appropris pour lmission. En
revanche, malgr la priorisation des flux temps-rels, les flux lastiques ne seront pas ngligs
et supprims de la file dattente en cas dencombrement. [9]

A. Frame Level Scheduler (FLS)

Le FLS est un ordonnanceur qui prend en considration la qualit de service, il est

principalement utilis pour les communications en temps-rel dans les rseaux LTE. Son
schma dordonnancement est divis en deux niveaux, ces derniers interagissent entre eux
pour permettre lallocation dynamique des blocs de ressources aux UEs. Dans le niveau
suprieur,
un algorithme moins complexe bas sur une boucle de contrle linaire et discrte dans le
temps; ce niveau spcifie le nombre de bits contenu dans le paquet transmettre par la source
(ici lUE qui utilise une application temps rel) dans la trame LTE. Dans le niveau infrieur,
les ressources radio sont attribues aux UEs en utilisant la stratgie dordonnancement PF en
tenant en compte de la bande passante requise par lordonnanceur FLS. Cette modlisation en
deux niveaux permet dobtenir un compromis entre le dbit offert par le systme et lquit.
Pour lordonnanceur PF le volume des donnes () pour du ime flux dans la kme trame LTE
est
calcul selon la formule suivante :
() = () () [18]

Dans la formule prcdente, le volume de donnes transmettre est la convolution

dans le temps discret (*) entre le niveau de la file dattente ()et la rponse impulsionnelle du
filtre linaire utilis note(). [19]

3.6 Rsum

Dans ce chapitre, on a prsent quelques candidats potentiels pour lallocation des

ressources radio sur la voie descendante dans le rseau daccs E-UTRAN.
Le paramtre le plus sensible tenir en compte lors de la conception des algorithmes
dordonnancement est la complexit, en effet, leNB doit allouer les ressources radio et de
transmettre les donnes utilisateur pendant la dure de la trame LTE qui vaut 1 ms; le rsultat
fourni par le(s) algorithme(s) potentiel(s) devra tre dtermin pendant une dure infrieure ou
gale la dure de la trame.
Lalgorithme dordonnancement choisi doit aussi tenir en compte de la variation du
canal radio dans le temps, cet gard le bilan de la liaison doit tre pris en considration sur la
voie descendante pour tous les UEs (par estimation du CQI partir du SINR) qui sont
desservis par la cellule. Cela ne permet pas de fournir lquit gnrale (general fairness) qui
sera difficile atteindre avec lhtrognit des services (temps rel et non-temps rel)
proposs par loprateur.
Lobjectif de lordonnancement est de garantir la qualit de service perue par les
applications utilisatrices en termes de dbit garanti et de latence limites, et datteindre le dbit
optimal offert par la cellule LTE qui est dtermin pendant la phase de dimensionnement.
Chapitre 4 : Etude comparative sur la performance des ordonnanceurs de paquets PF,
MLWDF et EXP/PF

Chapitre 4 : tude comparative sur la performance des

ordonnanceurs de paquets PF, MLWDF et EXP/PF

4.1 Introductions

Dans cette partie on va tudier la performance des diffrents algorithmes

dordonnancement : PF, MLWDF et EXPPF.
Premirement nous allons prsenter les outils de simulation les plus utiliss et leurs
caractristiques et par la suite on dtermine les scnarios quon va simuler, et la fin on
observe et on analyse les rsultats trouvs.

4.1.1 Choix de loutil

Pour simuler les diffrents rseaux que ce soit filaire ou sans-fil, il existe plusieurs
outils de simulations, mais chaque simulateur a ses avantages et ses inconvnients par rapport
aux autres simulateurs. Dans notre cas, les simulateurs qui nous permet de tester, danalyser et
dvaluer les algorithmes d'ordonnancement qui sont utiliss dans le rseau LTE sont OPNET,
OMNET ++, Network Simulator et LTE-Sim; donc on va dfinir chacun et dterminer le
simulateur quon va travailler avec.

A. OPNET

Optimized Network Engineering Toolset un outil de simulation trs utilis et trs

performant, il est caractris par la possibilit de simuler nimporte quel type de rseaux, et le
grand nombre de modles et de protocoles supports, le langage de dveloppement cest le C+
+, mais linconvnient majeur cest que il nest pas gratuit et mme les versions Acadmiques
sont limites.

B. OMNET++

OMNET++ est un simulateur rseau qui peut travailler sur une plateforme Windows ou
sur Linux, il peut simuler plusieurs types de rseaux sans-fil et filaire, il a aussi un diteur
graphique NED qui permet de crer et de visualiser les topologies, son avantage cest quil est
open Source, et il a un module SimuLTE qui supporte la technologie LTE, le langage de
dveloppement cest le C++, il est un peu lent pour les grandes simulations.
C. Network Simulation NS

Un simulateur rseau trs utilis, il fonctionne sur Windows et Linux, il permet de

simuler plusieurs types de rseau. La version 3 supporte un module pour LTE mais il nest pas
riche en algorithme dordonnancement, ce simulateur est aussi open-source et il est destin
pour les recherches acadmiques.

D. LTE-Sim

LTE-Sim est un simulateur rseau open-source qui est dvelopp sous Linux, il est
utilis pour simuler des diffrents vnements en LTE, son avantage est quil possde une
bibliothque trs riche (scnario prdfini, protocole, quipements, algorithmes
dordonnancements, etc...). Il est trs modulaire, son inconvnient est quil ne contient pas un
diteur graphique pour interprter les rsultats.
Pour notre simulation, nous avons choisi dutiliser le simulateur LTE-Sim
premirement par ce quil est ddi au rseau LTE et deuximement pour sa flexibilit et sa
richesse en algorithmes dordonnancements qui est le but de notre simulation et bien sr par ce
quil est open source.

4.2 Prsentation de loutil de simulation : LTE-Sim

LTE-Sim est un outil de simulation open source qui permet la simulation des
vnements discrets avec environnement multicellulaire, simulation raliste des applications et
limplmentation complte de la pile de protocole LTE. LTE-Sim est crit en C++ avec
approche oriente-objets, quatre grandes classes sont dfinies en LTE-Sim :
Simulator : cette classe contient les mthodes qui permettent lexcution,
lordonnancement et larrt des vnements qui composent la simulation.
Frame Manager : cette classe dfinit la structure de la trame LTE adopter.
Network Manager : contient les mthodes qui assurent la cration des lments
du rseau LTE (UE, eNB, Femtocell etc.), la gestion de la bande de
frquence et la mobilit des utilisateurs.
Flow Manager : cette classe gnre et prend en charge les applications telles
que : VoIP et vido.
Chaque lment du rseau est cr et instanci dans la simulation par une classe ddie
(classe UE, classe eNB et classe MME) toute la pile protocolaire est implmente entre ces
nuds de la couche physique la couche application. Durant la phase dexcution de la
simulation, les lments du rseau peuvent tre la source ou la destination dun flux, un flux
est
accommod en utilisant les adresses IP source et destination, les numros de port de transport
source et destination.
Lallocation des ressources ainsi que la gestion de qualit de service dans la voie radio
sont assures par les ordonnanceurs des paquets qui sont localiss leNB, LTE-Sim supporte
les algorithmes dordonnancement trs rpandus tels que : PF, M-LWDF, EXP/PF, FLS et
LOG-Rule. Quatre types de flux ont t dvelopps et peuvent tre simuls :
Trace-based : cette classe simule le flux vido temps-rel (streaming direct).
VoIP : cette classe gnre pendant la simulation des flux voix en format G.729.
Constant Bit-Rate : cette classe gnre des paquets avec un dbit constant, en
particulier, la taille et lintervalle du temps denvoi de ces paquets sont
paramtrs dans le constructeur de cette classe.
Infinite Buffer : cette classe simule une source qui a toujours des donnes
transmettre, elle simule en particulier les applications de tlchargement qui
tolrent sur le dlai mais rigoureuses sur le taux de perte des paquets.
Le modle de transmission des paquets et celui de la propagation sont implments
dans le module Channel, ce dernier propose les scnarios suivant : path loss, penetration loss,
shadowing et fast fading dans le cas de propagation multi-trajet.
Toutes les fonctionnalits cites sont regroupes pour offrir la flexibilit et la
modularit lors de la dfinition du rseau LTE et les scnarios tester. [20]

4.3 Le scnario

Le scnario de notre simulation considre un environnement urbain avec une cellule en

tenant en compte des diffrentes interfrences qui peuvent exister, avec des cellules macro
dont la couverture est de 1 km, en tenant en compte du modle de propagation avec perte ainsi
que la prsence dinterfrence intercellulaire au sein dun eNB. Les utilisateurs utilisent un
seul flux (13 des utilisateurs gnrent le flux VoIP, 13 des utilisateurs pour le flux vido et
1 pour les
3
flux de classe interactive). Le nombre dutilisateurs varie de 5 40, ces utilisateurs se dplacent
avec une vitesse de 3 km/h (pour la premire partie de la simulation) puis avec une vitesse de
120 km/h (pour la deuxime partie de la simulation).
Pour des soucis de prcision, chaque simulation est rpte cinq fois afin den tirer le
rsultat moyen, les critres de comparaison entre les diffrents ordonnanceurs sont : le dbit, le
dlai et le taux de perte des paquets dans le systme daccs simul.
Les rsultats seront reprsents sous forme de graphes (labscisse tant le nombre
dutilisateur) laide du logiciel open source Gnuplot.
 Lensemble des paramtres utiliss dans la simulation sont rsums dans le tableau
suivant :
Paramtre Valeur
Nombre de cellule dans leNB 1
Largeur de bande 10 MHz
Structure de la trame LTE FDD
Rayon de couverture cellulaire 1 km
Vitesse des utilisateurs 3 km/h, 120 km/h
Dure dune simulation 100 sec
Dlai maximal tolr dans la simulation 100 msec
Dbit du flux vido 242 kbit/sec
Figure 20. Les paramtres utiliss dans la simulation

4.4 Interprtation des rsultats

4.4.1 Flux Vido streaming

A. Taux de perte des paquets (packet loss ratio)

Sachant que le taux de perte des paquets vido streaming est limit 0.1 % dans la
norme LTE. La figure suivante montre le taux de perte des paquets induit en utilisant chaque
ordonnanceur dans le cas du flux vido pour les vitesses de 3 et 120 km/h.

Figure 21. Taux de perte des paquets vido en fonction du nombre des
utilisateurs
 On remarque que le taux de perte des paquets augmente avec laugmentation du
nombre des utilisateurs, ceci est valable pour tous les ordonnanceurs de paquet.
une vitesse de 3 km/h: pour le cas de lordonnanceur PF : on constate quil est
autant performant que les autres ordonnanceurs (M-LWDF et EXP/PF) pour cinq utilisateurs,
sa performance va tre dgrade lorsquon augmente le nombre des utilisateurs jusqu un
taux de perte suprieur 90% partir de 35 utilisateurs.
Pour le cas du M-LWDF et EXP/PF : daprs les rsultats obtenus, on remarque que
ces deux ordonnanceurs ont presque les mme taux de perte, ils dmarrent avec un taux de
perte acceptable (infrieur 10 % jusquau douzime utilisateur) et ils atteignent un taux
infrieur 70 % pour 40 utilisateurs.
une vitesse de 120 km/h : la performance des ordonnanceurs EXP/PF et M-LWDF
se dgrade par rapport 3 km/h, mais leurs performances restent meilleures par rapport celle
de PF; o plus de 50 % des paquets vido sont perdus pour un nombre dutilisateurs suprieur
10.

B. Dlai

Les figures suivantes reprsentent le dlai du paquet vido en fonction du nombre des
usagers pour les trois ordonnanceurs avec des vitesses de 3 km/h et 120 km/h respectivement.

Figure 22. Dlai des paquets vido en fonction du nombre des utilisateurs

une vitesse de 3 km/h : Sachant que le dlai recommand dans la norme est de 150 msec
pour le flux vido. On remarque que le dlai est maintenu au-dessous de 100 msec pour les
ordonnanceurs EXP/PF et M-LWDF, par contre le dlai est trop grand pour le cas de
lordonnanceur PF (il dpasse les 100 msec partir du dixime utilisateur).

une vitesse de 120 km/h : Le dlai recommand de la vido reste toujours respect
(avec une lgre diffrence par rapport une vitesse de 3 km/h) lorsque les algorithmes
EXP/PF et M-LWDF sont utiliss. Par contre, lordonnanceur PF fournit un dlai trop grand
est non acceptable sur ce flux.

C. Dbit (Throughput)

Les figures suivantes reprsentent la variation du dbit moyen par utilisateur en

fonction du nombre des utilisateurs circulants des vitesses de 3 et 120 km/h.

Figure 23. Dbit moyen par utilisateur en fonction du nombre des utilisateurs

une vitesse de 3 km/h : Sachant que le dbit allou cette application est de 242 kbit/sec
dans la simulation. On remarque que les trois ordonnanceurs offrent un dbit acceptable;
partir du dixime utilisateur, la performance de lordonnanceur PF commence se dgrader.
Par contre, les autres ordonnanceurs maintiennent toujours un dbit largement satisfaisant pour
cette application.
une vitesse de 120 km/h : En dpit dune trs haute mobilit des usagers, les
ordonnanceurs EXP/PF et M-LWDF offrent un dbit qui satisfait le flux vido, lordonnanceur
PF ne permet de garantir un dbit minimum pour accommoder ce flux.
D. Conclusion sur le flux vido

Les ordonnanceurs EXP/PF et M-LWDF rpondent aux besoins de flux vido en

termes de dbit et de latence mme en cas dune trs haute mobilit, avec un petit avantage du
M- LWDF. Lordonnanceur PF nest pas convenable ce type de flux o les dlais et la
garantie du dbit sont des contraintes majeures.

4.4.2 Flux VoIP

A. Taux de perte des paquets (packet loss ratio)

Les figures suivantes reprsentent la variation du taux de perte des paquets VoIP en
fonction du nombre des usagers des vitesses de 3 et 120 km/h.

Figure 24. Taux de perte des paquets VoIP en fonction du nombre des
utilisateurs

une vitesse de 3 km/h : Le taux de perte recommand par la norme est de 1 %, ce

rapport est maintenu par lensemble des ordonnanceurs quel que soit le nombre des usagers
avec une meilleure performance observe dans lordonnanceur PF.
une vitesse de 120 km/h : le taux de perte des paquets VoIP est maintenu au-
dessous de 1 % pour les ordonnanceurs EXP/PF et PF pour un nombre dutilisateurs infrieur
25, la performance sera dgrade ds que ce nombre sera trs important.

B. Dlai

Les figures suivantes montrent la variation du dlai par rapport au nombre des usagers
pour des vitesses de 3 et 120 km/h respectivement.
 Figure 25. Dlais des paquets VoIP en fonction du nombre des utilisateurs

une vitesse de 3 km/h : Sachant que le dlai dacheminement du flux VoIP prvu
dans la norme est de 100 msec. Les trois ordonnanceurs engendrent un dlai acceptable sur le
flux VoIP, la performance est meilleure pour les ordonnanceurs EXP/PF et PF.
une vitesse de 120 km/h: Malgr que le dlai reste conforme la recommandation,
la performance de lordonnanceur PF se dgrade considrablement lorsque le nombre des
usagers est suprieur 35.

C. Dbit (Throughput)

Les figures suivantes reprsentent les variations du dbit en fonction du nombre des
utilisateurs pour des vitesses de 3 et 120 km/h.

Figure 26. Dbit moyen par utilisateur du flux VoIP en fonction du nombre des
utilisateurs
 Pour les deux cas de figures, le dbit applicatif moyen des utilisateurs est proportionnel
au nombre des usagers, cette remarque est valable pour les trois types dordonnanceur simuls,
lordonnanceur EXP/PF offre le meilleur dbit par rapport aux M-LWDF et PF une vitesse
de 120 km/h des usagers.

D. Conclusion sur le flux VoIP

Dans ce cas, on remarque que lalgorithme le plus conforme au flux VoIP en terme de
dlai et de taux de perte des paquets est lordonnanceur EXP/PF suivi par lordonnanceur PF
et M-LWDF.

4.4.3 Flux best effort

A. Taux de perte des paquets

La figure suivante reprsente la variation du taux de perte des paquets de donnes en

fonction du nombre des utilisateurs des vitesses de 3 et 120 km/h.

Figure 27. Taux de perte des paquets de donnes en fonction du nombre des
utilisateurs

On constate que le taux de perte des paquets pour le flux best effort nest pas maintenu
au-dessous de 0.001 % (spcifi dans la norme) quel que soit le nombre des utilisateurs. Le
taux de perte des paquets est trs grand pour une vitesse de 120 km/h (qui atteint 50 % pour
cinq utilisateurs). Nanmoins, le taux de perte des paquets best effort diminue avec
laugmentation du nombre des utilisateurs, ceci est d laugmentation du nombre des
utilisateurs accompagns par une augmentation du temps dattente de ces flux en mmoire
avant dtre traits par les ordonnanceurs, sachant que la dure de mise en attente des paquets
est prise en considration par les ordonnanceurs EXP/PF et M-LWDF.
B. Dlai

Les figures suivantes reprsentent la variation du dlai en fonction du nombre des

utilisateurs qui se dplacent des vitesses de 3 et de 120 km/h.

Figure 28. Dlai des paquets de donnes en fonction du nombre des utilisateurs

On constate daprs les rsultats obtenus que le dlai dacheminement est le mme
pour tous les ordonnanceurs, ce dlai est maintenu mme en cas des usagers mobiles.

C. Dbit (Throughput)

Les figures suivantes montrent la variation du dlai en fonction du nombre des

utilisateurs avec des vitesses de 3 et 120 km/h.

Figure 29. Dbit du flux de donnes en fonction du nombre des utilisateurs

On remarque que le dbit moyen par utilisateur de flux best effort dcroit avec
laugmentation de la vitesse et du nombre des usagers dans la cellule, ce dbit reste
relativement constant pour un nombre dutilisateur suprieur 20, en constate aussi que
lordonnanceur EXP/PF fournit le meilleur dbit aux utilisateurs dans les deux cas de figures
(3 et 120 km/h).
D. Conclusion sur le flux best effort

Lordonnanceur EXP/PF fournit les meilleurs rsultats en termes de dbit et de taux de

perte des paquets par rapport lordonnanceur M-LWDF et PF sur les flux lastiques.

4.4.4 Conclusion

Aprs ltude ralise sur la performance des diffrents types dordonnanceur, on a

constat que leurs performances dpondent des facteurs de mobilit des usagers ainsi que la
nature des services excuts. En effet, lordonnanceur PF nest pas destin aux applications
temps-rel (ici la VoIP et la vido) par ce quil ne rpond pas leurs exigences en termes de
dlai, dbit garanti et le taux de perte tolrables; le faite que ces paramtres sont tous pris en
considration par lordonnanceur EXP/PF (dans le calcul de priorit), ce dernier est
convenable la fois pour les flux temps-rel (prcisment la VoIP) et au flux best effort.
Si la charge du rseau pour les flux non temps-rel est grande par rapport aux autres
flux, il est recommand dutiliser lordonnanceur PF du faite de sa robustesse pour les usagers
mobiles. Par contre, si la charge des flux temps-rel augmente dans leNB; le PF nest pas une
solution dordonnancement, le M-LWDF et EXP/PF sont les stratgies dordonnancement qui
sont destines ces types de service.
 58
Conclusion gnrale

Conclusion gnrale
Les oprateurs mobiles cherchent toujours satisfaire et rpondre aux besoins de leurs clients
en terme de dbit, des diffrents services proposs, de la couverture,Etc. Ces besoins
obligent les oprateurs de rendre leurs rseaux trs performant et trs puissant pour garantir
une meilleure exprience aux utilisateurs.
Les technologies prcdentes telles que GSM, UMTS et HSPA ont connues un trs bon succs
ses dernires annes, mais elles sont limites en termes de dbits face aux applications et les
services qui ncessitent des dbits trs levs.
La technologie LTE a t standardise par 3GPP, elle se base sur une architecture tout IP qui
permet de fournir et de garantir le haut dbit pour les utilisateurs avec une meilleure gestion de
qualit de service entre les diffrents types de service et les diffrentes catgories des
utilisateurs.
Dans notre travail, on a prsent larchitecture LTE avec ses diffrents lments ainsi que la
dfinition de la qualit de service sur le domaine coeur IP et sur le domaine LTE (rseau
daccs) avec tous les paramtres qui agissent sur la diffrenciation entre les flux IP.
Dans la partie de notre simulation, on a focalis notre travail sur ltude et lvaluation des
performances des diffrents algorithmes dordonnancement (PF, MLWDF, EXPPF) proposs
pour la technologie LTE.
Daprs les rsultats obtenus la fin de la simulation, on a constat que le choix
dordonnanceur le plus conforme dpend du type de trafic attendu, la charge du rseau
(nombre dutilisateur estim) et la couverture.
Pour les ordonnanceurs quon a tudi, on a conclu que le PF est optimal lorsque la majorit
du trafic est non temps-rel, ce quil nest pas convenable pour la vido et VoIP. Et pour
MLWDF et EXPPF, on constate que ces ordonnanceurs sont les plus fiables pour les flux de
type vido et VoIP avec une lgre diffrence entre eux.
En revanche il existe dautres ordonnanceurs plus fiable, qui rpondent au besoin de la qualit
de service comme Frame Level Scheduler qui est utilis principalement pour les flux en
temps- rel.

58
Chapitre 4 : Etude comparative sur la performance des ordonnanceurs de paquets PF,
MLWDF et EXP/PF

Finalement, Les politiques d'ordonnancement nont pas t normalises. C'est du savoir-faire

de l'oprateur et de lquipementier. Le partage des ressources ne peut pas tre fait
quitablement en temps car sinon, les mobiles en bordure de cellule auraient un trs mauvais
dbit. Le partage quitable en dbit nest pas satisfaisant aussi; car les mobiles proches de
l'antenne auraient un trs mauvais dbit, align sur celui des mobiles en bordure de cellule. Les
oprateurs doivent mettre en place une politique intermdiaire, de faon assurer un dbit
individuel minimal tous, tout en essayant de maximiser le dbit global dans la cellule.
Par ailleurs, la politique dordonnancement va aussi dpendre de la qualit de service de
chaque classe de flux, mieux vaut que la politique dordonnancement soit ractive en offrant
une quit partielle entre les utilisateurs.

59
Bibliographie
[1] Incerti, D., IP Qualit de Service, Universit Paul Sabatier, Toulouse.

[2] NMC Consulting Group, LTE Network Architecture: Basic, 10 Juillet 2013.

[3] Romney, M., LTE and the Evolution to 4G Wireless, Agilent Technologies, 2009, p 133

[4] Hangzhou H3C Technologies Co. LTD, QoS Technology White Paper, 2008.

[5] Radisys Corporation Credential, End-to-End QoS in LTE, 12 Juillet 2012.

[6] Amandeep N, A Survey on Quality of Service in LTE Networks, International Journal

Science and Research (IJSR), 2015.

[7] NMC Consulting Group, LTE QoS: SDF & EPS Bearer QoS, 11 Septembre 2013.

[8] Itturalde Ruiz, G.M., Performances des Rseaux LTE, Universit de Toulouse, 2 Octobre
2012.

[9] Fouziya Sulthana S., Nakkeeran R., Study of Downlink Algorithms in LTE Networks,
Journal of Networks, Vol 9, No 12, December 2014.

[10] 3GPP, Tech. Specific. Group Radio Access Network-Requirements for Evolved UTRA (E-
UTRA) and Evolved UTRAN (E-UTRAN), 3GPP TS 25. 913.

[11] International Telecommunication Union (ITU), overall network operation, telephone

service, service operation and human factors, ITU-T recommendation E. 800 Annex B, Aout
2008.

[12] 3E. Dahlman, S. Parkvall, J. Skold and P. Beming, 3GEvolution HSPA and LTE for
mobile Broadband.Academic Press, 2008.

[13] Amit Kumar, Jyotsna Sengupta, Yun-fei Liu, 3GPP LTE: The Future of Mobile
Broadband Wireless Personal Communication, vol. 62, pp. 671-686, 2012.

i
[14] 3GPP, Tech. Specific. Group Services and System Aspects Policy and charging control
architecture (Release 9), 3GPP TS 23. 203.

i
[15] 3GPP, Tech. Specific. Group Radio Access Network Physical Channel and Modulation
(Release 8), 3GPP TS36. 211.

[16] N. Kolehmainen, J. Puttonen, P. Kela, T. Ristaniemi, T.Henttonen, and M. Moisio,

Channel Quality Indication Reporting Schemes for UTRAN Long Term Evolution
Downlink, in Proceedings of IEEE Vehicular Technology Conference, VTC-Spring, Marina
Bay, Singapore, vol. 1, pp. 2522 2526, May 2008.

[17] 3GPP, Tech. Specific. Group Radio Access Network Evolved Universal Terrestrial
Radio Access (E-UTRA) and Evolved Terrestrial Radio Access Network (EUTRAN); Medium
Access Control (MAC) protocol specification (Release 9), 3GPP TS 36. 321.

[18]Afroz, F., Barua, S. and Sandrasegaran, K. (2014), Performance Analysis of FLS, EXP,
LOG andM-LWDF Packet Scheduling Algorithms in Downlink 3GPP LTE System,
International Journal of Wireless & Mobile Networks (IJWMN), Vol. 6(5), PP. 77-91.

[19] Afroz F., Heidery R., Shehab M., Sandrasegaran K., Shompa S.S., Comparative analysis
of downlink packet scheduling algorithms in 3GPP LTE Networks, International Journal of
Wireless & Mobile Networks (IJWMN) Vol 7, No 5, October 2015.

[20] Subramanian R., Ghosal P., Barua S., Xing S., Cong S., Al Karim H., Sandrasegaran K.,
Survey of LTE Downlink Schedulers algorithms in open access simulation tools NS-3 and
LTE- Sim, International Journal of Wireless & Mobile Networks (IJWMN) Vol 7, No 2, April
2015.

ii
Annex
e

Annexe 1 : Procdures dattachement du terminal au rseau

La procdure dattachement de lUE consiste lauthentification mutuelle de lUE et du
rseau, lchance de cette procdure, un contexte est tabli pour lUE dans lentit
MME. Aprs la slection du S-GW par le MME un bearer par dfaut est tabli et maintenu
de bout- en-bout (c'est--dire de lUE vers P-GW) suivi par lallocation de ladresse IP.
Les tapes de cette procdure :
1- UE tablit la connexion RRC avec leNB, cette demande est envoye dans le message
RRC Connection Setup.
2- UE envoie une demande dattachement au rseau en parallle avec la demande de
connectivit IP par les messages Attach Request et PDN Connectivity Request mis dans
le message RRC Connectivity Request, leNB tablit une connexion logique S1 avec le
MME pour cet UE.
3- Si le rseau nest pas capable pour identifier lUE avec lidentit mentionne dans le
message dattachement (qui est le TMSI), le MME dmarre la procdure
dauthentification et lactivation de la scurit (aprs le choix du mode de scurit) et
du contrle dintgrit pour les messages de contrle.
4- Le MME informe le HHS avec la localisation de lUE en envoyant le message Update
Location Request encapsul par le protocole DIAMETER, ce message sert aussi comme
une demande implicite du profil dabonnement de cet UE stock dans le HSS.
5- Le HHS met jour sa base de donnes avec la nouvelle localisation dUE et envoie le
profil dabonn vers le MME dans le message DIAMETER Update Location
Acknowledge.
6- Le MME choisit le S-GW appropri et envoie ce dernier une demande
dtablissement du bearer par dfaut pour lUE sur les interfaces S1 et S5, cette
demande est envoye dans le message Create Session Request encapsul dans le
protocole eGTP-C.
7- Le S-GW choisit un identifiant local du tunnel (TEID) pour linterface S5 et rpercute
la demande du MME (message eGTP-C Create Session Request) au P-GW pour crer
le bearer par dfaut. Le P-GW choisit son tour son TEID et envoie le message eGTP-
C Create Session Response qui contient les identits du TEID du tunnel S5 et ladresse
IP alloue ce terminal ; cet instant, le bearer S5 est cr et maintenu entre le S-GW
et le P-GW.
8- Ds la rception du message, le S-GW envoie lacquittement au MME via le message
eGTP-C Create Session Response.
9- Le MME tablit le bearer entre leNB et le S-GW, en envoyant le message S1-AP
Initial Context Setup Request vers eNB pour crer le contexte de cette UE, ce message
contient les contextes de scurit et du bearer (Bearer Context et Security Context).
10- Aprs la rception du message S1-AP Initial Context Setup, leNB procde
lactivation du contexte de scurit avec lUE en envoyant le message NAS Security
Mode Command.
11- UE tablit les paramtres de scurit (utiliss pour le chiffrement et le contrle
dintgrit) en envoyant le message NAS Security Mode Complete vers eNB.
Maintenant tous les messages changs entre UE et eNB sur linterface radio sont
protgs par chiffrement et intgrit.
12- eNB reconfigure les ressources de lUE par lenvoi dun message RRC Connection
Request vers UE. Dans ce message leNB passe le message NAS Activate Default EPS
Bearer Context Request vers lUE.
13- UE met jour les paramtres de connexion radio par le message RRC Connection
Reconfiguration, ce message est acquitt par leNB via le message RRC Connection
Reconfiguration Complete.
14- A cet instant, leNB envoie son acquittement du message dtablissement du contexte
au MME via S1-AP Initial Context Setup Response.
15- MME demande au S-GW dtablir le bearer S1 avec leNB en envoyant le message
eGTP-C Modify Bearer Request en indiquant lidentifiant du tunnel choisi par leNB.
16- Aprs la rception de ce message par le S-GW, ce dernier rpond au MME par le
message eGTP-C Modify Bearer Response en indiquant son tour le TEID choisi.
17- Le MME maintenant envoie lUE le message dacquittement celui de la demande
dattachement via NAS Attach Accept suivi dune demande dtablissement du bearer
radio dans le message Activate Default Bearer Context Request.
18- Le MME alloue le GUTI du terminal et lenvoie dans le message dacquittement NAS
Attach Accept, lUE envoie le message NAS Attach Complete comme une rponse
positive au MME. Enfin, lUE envoie lacquittement de ltablissement du bearer par
dfaut par le message NAS ESM Activate default EPS Bearer Context Accept.
Annexe 2 : Etablissement dun bearer ddi :
Aprs la russite de la procdure dattachement, lUE peut demander des services du rseau en
utilisant la procdure Service Request. Un exemple lorsque lUE demande des ressources au
rseau pour initialiser une session des donnes, lUE peut utiliser la procdure NAS Service
Request.
Le droulement de la procdure est le suivant :
1. UE tablit la connexion radio par le messageRRC Connection Setup avec leNB
2. UE envoie le message NAS Service Request vers MME et demande les ressources pour
un bearer ddi en ajoutant le message Bearer Resource Allocation Request dans le
message RRC Connection Setup. LeNB tablit la connextion logique S1 avec le MME
pour lUE.
3. UE peut initialiser les procdures optionnelles didentification et dauthentification via
le message NAS Security Mode.
4. MME initialise la procdure de modification des tunnels associs du bearer ddi avec
le S-GW/P-GW par le message eGTP-C Modify Bearer Request envoy vers S-GW.
5. Aprs la rception de ce message, le S-GW prpare les ressources ncessaires (choix
du TEID) et rpercute le message vers le P-GW.
6. P-GW active les ressources requises pour lactivation du bearer par dfaut et acquitte
par le message eGTP-C Modify Bearer Response vers le S-GW, ce dernier rpercute le
message vers le MME.
7. MME dmarre la procdure de rservation des ressources du bearer ddi par lenvoi
du message eGTP-C Bearer Resource Command vers le S-GW.
8. S-GW rserve les ressources ncessaires ce bearer et rpercute le message vers le P-
GW.
9. P-GW alloue les ressources ncessaires au bearer ddi (TFT Templates) et rpond au
S-GW par une demande de cration du bearer eGTP-C Create Bearer Request.
10. S-GW acquitte au P-GW par le message eGTP-C Create Bearer Response, ensuite un
acquittement de la demande (cration du bearer ddi) du MME est envoy via le
message eGTP-C Modify Bearer Response.
11. MME envoie un message leNB pour lallocation des ressources ncessaires au
bearer S1 (entre S-GW et eNB) via le message E-RAB Setup Request vers eNB, en
plus du message NAS Activate Dedicated EPS Bearer Context Request vers UE pour la
demande dactivation du bearer ddi lUE.
12. eNB alloue les ressources radio par le message RRC Connection Reconfiguration
Request vers UE, ce message inclut le message dactivation du bearer ddi.
13. UE tablit le bearer radio DRB et rpond leNB par le message RRC Connection
Reconfiguration Complete.
14. eNB rpond au MME par un acquittement E-RAB Setup Response.
15. UE envoie maintenant le message NAS Activate Dedicated EPS Bearer Context Accept
vers MME travers leNB, qui sert comme acquittement positif la demande
dactivation du bearer ddi.
16. MME envoie un acquittement au S-GW par le message eGTP-C Create Bearer
Response pour complter lactivation du bearer ddi, le S-GW passe ce message vers
P-GW ; cette instant, le bearer ddi est tabli de bout-en-bout entre lUE et le P-
GW.
Annexe 3 : Valeur DSCP avec le type de service
recommand
Type de service DSCP PHB Valeur DSCP
Routage IP CS6 (110000) 48
Conversationnel Voix EF(101110) 46
Conversationnel Vido AF41(100010) 34
Signalisation Vido AF31(011010) 26
Interactif (haute priorit) AF2x(010xx0) 18, 20, 22
Interactif (moyenne priorit) AF1x(001xx0) 10, 12, 14
Streaming Vido CS4(000100) 4
Signalisation Voix CS3(000011) 3
Gestion du rseau CS2(000010) 2
Scavenger CS1(000001) 1
Best Effort 0 0
Tableau V. Valeur DSCP avec les classes de service et traitement PHB

Annexe 4 : Valeur CoS avec la classe de service du flux

Type de service Utilit Valeur CoS Exemple dapplications
Network Control Les flux critiques qui 7 BGP, SNMP
demandent un faible taux de
perte des paquets.
Internet control Les flux sensibles au dlai 6 STP, OSPF et RIP
dacheminement et
ncessitent un faible taux de
perte des paquets.
Voice Le trafic voix qui requiert 5 SIP
une latence infrieure 10
ms.
Video Trafic vido qui ncessite un 4 RTP
dlai infrieur 100 ms.
Critical Les applications qui 3 NFS, SMB
applications requirent un dbit
minimum garanti.
Excellent Effort Les trafics qui ont une 2 SQL
priorit haute par rapport
aux services best-effort,
telles que les requtes aux
bases de donnes
Best Effort Classe de service par dfaut, 1 http
convenable pour les flux qui
nexigent aucun traitement
prfrentiel.
Background Applicable aux flux qui sont 0 FTP, SMTP
admis par le rseau, et qui ne
doivent pas impacter les
autres applications critiques.
Tableau VI. Classe de service et valeur CoS dans la trame Ethernet