N° d’ordre: 04/TCO/IRS Année Universitaire: 2013-2014

UNIVERSITE D'ANTANANARIVO
------------------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-------------------------------
DEPARTEMENT TELECOMMUNICATIONS

MEMOIRE DE FIN D'ETUDES

en vue de l'obtention
du DIPLOME d’INGENIEUR
Grade : Master
Mention : Télécommunication
Parcours : Ingénierie des Réseaux et Systèmes
Domaine : Science de l’Ingénieur

par : ANDRIAMIFIDY Nalijaona Irina

INFLUENCE DU SCHEDULING SUR LA QUALITE

DE SERVICE DANS LES RESEAUX LTE
Soutenu le mardi 24 mars 2015 devant la Commission d'Examen composée de :

Président :
M. RATSIMBAZAFY Andriamanga
Examinateurs :
M. RAVONIMANANTSOA Ndaohialy Manda-Vy
Mme RAMAFIARISONA Malalatiana
M. ANDRIAMANALINA Ando

Directeur de mémoire : M. RAKOTOMALALA Mamy Alain

« Je l’ai rempli de l’Esprit de Dieu, de
sagesse, d’intelligence, et de savoir
pour toutes sortes d’ouvrages »

Exode 31:3

« Ary efa nofenoiko

fanahin’Andriamanitra izy, dia
fahendrena sy fahiratan-tsaina
sy fahalalana ny amin’ny tao-zavatra
samy hafa »

Eksodosy 31:3
 REMERCIEMENTS

Je ne saurai jamais remercier assez le grand Dieu de remplir ma vie de sa grâce abondante, sans Lui
ce mémoire de fin d’études n’aurait jamais été.

Au terme de ces cinq années d’études, il m’est particulièrement agréable de remercier les
nombreuses personnes qui ont, à des titres divers, participé à l’élaboration du présent travail.

Je remercie, le Directeur de l’Ecole Supérieure Polytechnique d’Antananarivo, Monsieur

ANDRIANARY Philippe, Professeur Titulaire, pour son accueil chaleureux au sein de
l’établissement.

Je tiens à exprimer mes profondes et sincères reconnaissances à Monsieur RAKOTOMALALA

Mamy Alain, Maître de Conférences et Chef de Département au sein du Département
Télécommunication, pour m’avoir encadré et qui n’a cessé de me prodiguer de précieux conseils.

Mes remerciements vont aussi à Monsieur RATSIMBAZAFY Andriamanga, Maître de

Conférences, qui nous a fait l’honneur de présider les membres du Jury de ce mémoire.
Je témoigne toute ma reconnaissance aux autres membres du jury qui ont voulu examiner ce travail:
 Monsieur RAVONIMANANTSOA Ndaohialy Manda-vy, Maître de Conférences
 Madame RAMAFIARISONA Malalatiana, Maître de Conférences
 Monsieur ANDRIAMANALINA Ando, Maître de Conférences

J'adresse également mes remerciements à tous les Enseignants de l’Ecole Supérieure Polytechnique
d’Antananarivo en particulier ceux du département Télécommunications.

J'exprime ma gratitude à ma famille pour son immense soutien et son encouragement permanent.
Enfin, je ne saurai oublier toutes les personnes qui m’ont aidé de près ou de loin dans l’élaboration
du présent mémoire.

i
 TABLE DES MATIERES

REMERCIEMENTS ...................................................................................................................................... i
TABLE DES MATIERES ............................................................................................................................ ii
NOTATIONS ET ABREVIATIONS ........................................................................................................ viii
INTRODUCTION ......................................................................................................................................... 1
CHAPITRE 1 THEORIE ET SYSTEMES DES FILES D’ATTENTE ................................................... 3
1.1 Introduction ......................................................................................................................................... 3

1.2 Concept de la théorie des files d’attente............................................................................................ 3

1.2.1 Origine des attentes....................................................................................................................... 4

1.2.2 Objectif de l’analyse des files d’attente ........................................................................................ 4

1.2.3 Les caractéristiques des systèmes de files d’attente ..................................................................... 5

1.2.3.1 La population.......................................................................................................................... 6

1.2.3.2 Le nombre de serveurs ........................................................................................................... 6

1.2.3.3 Les tendances quant à l’arrivée et au service ......................................................................... 7

1.2.3.4 L’ordre de traitement des clients ............................................................................................ 9

1.3 File d’attente à priorités strictes avec préemption ......................................................................... 10

1.3.1 Description du problème............................................................................................................. 11

1.3.2 Formalisation mathématique ..................................................................................................... 11

1.3.2.1 File d’attente avec impatience .............................................................................................. 11

1.3.2.2 Variables de performance ..................................................................................................... 12

1.3.3 Règles de priorité ........................................................................................................................ 13

1.3.4 Cas d’une file à une classe de clients ......................................................................................... 13

1.3.4.1 File / /1 + ................................................................................................................. 13

1.3.4.2 File / /1 + .................................................................................................................. 15

1.3.4.3 Encadrement de la probabilité de perte d’un client .............................................................. 16

1.3.5 Cas d’une file à deux classes de clients...................................................................................... 17

1.3.5.1 Cas particulier ...................................................................................................................... 17

1.3.5.2 Cas avec priorité stricte et avec préemption ......................................................................... 18

1.3.5.3 Mesures de performances ..................................................................................................... 21

ii
 1.4 Conclusion ......................................................................................................................................... 22

CHAPITRE 2 ARCHITECTURE LTE/EPC ........................................................................................... 23

2.1 Introduction ....................................................................................................................................... 23

Notions de plan usager et de plan de contrôle .................................................................................... 23

2.2 Présentation générale de l’architecture .......................................................................................... 24

2.3 Le réseau cœur .................................................................................................................................. 26

2.3.1 La Serving Gateway (S-GW) ...................................................................................................... 26

2.3.2 Le Mobility Management Entity (MME) ................................................................................... 27

2.3.3 La Packet Data Network Gateway (P-GW ou PDN-GW).......................................................... 27

2.3.4 Le Home Subscriber Server (HSS) ............................................................................................ 27

2.3.5 Le Policy Control and charging Rules Function (PCRF)......................................................... 28

2.4 Le réseau d’accès............................................................................................................................... 28

2.5 L’architecture protocolaire .............................................................................................................. 29

2.5.1 Le plan usager............................................................................................................................. 29

2.5.2 Le plan de contrôle ..................................................................................................................... 29

2.6 Le bearer EPS ................................................................................................................................... 30

2.6.1 Bearer avec débit garanti............................................................................................................ 31

2.6.2 Bearer sans débit garanti............................................................................................................ 31

2.7 Les interfaces terrestres du LTE ..................................................................................................... 31

2.7.1 Structure protocolaire des interfaces S1 et X2........................................................................... 32

2.7.2 L’interface S1.............................................................................................................................. 33

2.7.2.1 Le plan usager (S1-U) .......................................................................................................... 33

2.7.2.2 Le plan de contôle (S1-MME).............................................................................................. 35

2.7.3 L’interface X2 ............................................................................................................................. 37

2.7.3.1 Le plan usager (X2-U).......................................................................................................... 37

2.7.3.2 Le plan de contrôle (X2-C) .................................................................................................. 38

2.8 L’interface radio ............................................................................................................................... 39

Plan usager et plan de contrôle ........................................................................................................... 39

iii
 2.9 Conclusion ......................................................................................................................................... 41

CHAPITRE 3 QUALITE DE SERVICE EN LTE/EPC.......................................................................... 42

3.1 Introduction ....................................................................................................................................... 42

3.2 La notion de bearer ........................................................................................................................... 42

3.2.2 Le bearer EPS ............................................................................................................................. 44

3.2.3 Bearer par défaut et bearer dédié ............................................................................................... 46

3.2.3.1 Le bearer par défaut (connectivité générique) ...................................................................... 46

3.2.3.2 Le bearer dédié (besoin de QoS spécifique) ......................................................................... 48

3.3 Les paramètres de QoS ..................................................................................................................... 51

3.3.1 Le QoS Class Identifier (QCI) .................................................................................................... 52

3.3.2 L’Allocation and Retention Priority (ARP) ............................................................................... 55

Principe ............................................................................................................................................ 55

3.3.3 Les paramètres de débit .............................................................................................................. 56

3.3.3.1 Le Guaranteed Bit Rate (GBR) ............................................................................................ 56

3.3.3.2 Le Maximal Bit Rate (MBR)................................................................................................ 56

3.3.3.3 Les débits agrégés (UE-AMBR et APN-AMBR) ................................................................ 57

3.4 Politique de gestion de la QoS .......................................................................................................... 57

3.4.1 L’AF ou Application Function................................................................................................... 60

3.4.2 SPR ou Subscription Profile Repository .................................................................................... 60

3.4.3 PCRF ou Policy Charging Rules Function ............................................................................... 61

3.4.4 PCEF ou Policy Charging Enforcement Function ................................................................... 61

3.4.5 TDF ou Traffic Detection Function .......................................................................................... 62

3.4.6 OCS ou Online Charging System............................................................................................... 63

3.5 Conclusion ......................................................................................................................................... 63

CHAPITRE 4 FONCTION D’ORDONNANCEMENT DANS L’eNodeB ............................................ 64

4.1 Introduction ....................................................................................................................................... 64

4.2 Architecture de QoS dans les réseaux 3GPP LTE ......................................................................... 64

4.3 Fonction de gestion de la QoS et traitement au sein des nœuds.................................................... 65

iv
 4.4 Considération du scheduling au sein de l’eNodeB ......................................................................... 69

4.5 Formulation mathématique du problème d’allocation de ressources radio ................................ 73

4.6 Algorithmes d’ordonnancement ...................................................................................................... 75

4.6.1 Les algorithmes opportunistes .................................................................................................... 75

4.6.1.1 Proportional Fair (PF) .......................................................................................................... 76

4.6.1.2 Exponential Proportional Fair (EXPPF)............................................................................... 76

4.6.2 Les algorithmes équitables ......................................................................................................... 76

4.6.2.1 Round Robin (RR) ............................................................................................................... 76

4.6.2.2 Max-Min Fair (MMF) .......................................................................................................... 77

4.6.3 Algorithmes considérant les délais ............................................................................................. 77

Modified Largest Weighted Delay First (MLWDF) ........................................................................ 77

4.6.4 Algorithmes optimisant le débit .................................................................................................. 77

4.6.5 Les algorithmes multi-classes..................................................................................................... 78

4.7 Application des paramètres de QoS dans le réseau ....................................................................... 78

4.8 Conclusion ......................................................................................................................................... 80

CHAPITRE 5 EVALUATION DE L’INFLUENCE DU SCHEDULING SUR LA QOS PAR

SIMULATION............................................................................................................................................. 81
5.1 Introduction ....................................................................................................................................... 81

5.2 Modèles d’évaluation des QoS ......................................................................................................... 81

5.2.1 Key Performance Indicator (KPI) .............................................................................................. 82

5.2.2 Paramètres de performance de QoS à base du Service Level Agreement (SLA)...................... 82

5.2.2.1 Le débit de transmission ou throughput ............................................................................... 82

5.2.2.2 Le délai de transmission ou delay ........................................................................................ 82

5.2.2.3 La variation du délai de transit ou jitter ............................................................................... 83

5.2.2.4 Le taux de perte des paquets ou packet loss ......................................................................... 84

5.3 Evaluation des performances par simulation ................................................................................. 84

5.3.1 Présentation du simulateur ........................................................................................................ 84

5.3.2 Critères d’évaluation................................................................................................................... 85

v
 5.3.3 Scénario et paramètres de simulation ........................................................................................ 86

5.3.3.1 Scénario de simulation ......................................................................................................... 86

5.3.3.2 Paramètres de simulation...................................................................................................... 87

5.4 Aspect et principe de simulation ...................................................................................................... 88

5.4.1 Fonctionnement de l’algorithme PPM ...................................................................................... 88

5.4.1.1 Phase 1 : Ordonnancement initial des PRB .......................................................................... 89

5.4.1.2 Phase 2 : Gestion des files d’attente et prédiction des délais des paquets ............................ 89

5.4.1.3 Phase 3 : Processus cut-in .................................................................................................... 93

5.5 Interprétation des résultats .............................................................................................................. 93

5.5.1 Comparaison des algorithmes .................................................................................................... 93

5.5.1.1 Le trafic Best Effort ou BE................................................................................................... 94

5.5.1.2 Le trafic Vidéo ..................................................................................................................... 97

5.5.1.3 Le trafic VoIP ..................................................................................................................... 101

5.5.2 Comparaison des services ......................................................................................................... 105

5.5.2.1 Délai end-to-end ................................................................................................................. 105

5.5.2.2 Gigue des trafics ................................................................................................................. 106

5.5.2.3 Taux de perte de paquets .................................................................................................... 107

5.5.2.4 Débit de transmission perçu par l’utilisateur ...................................................................... 108

5.6 Conclusion ....................................................................................................................................... 109

CONCLUSION GENERALE .................................................................................................................. 110

ANNEXES .................................................................................................................................................. 111
ANNEXE 1 LES PRINCIPAUX KPI EN LTE/EPC ........................................................................ 111

A1.1. Les KPI d’accessibilité en EPC ............................................................................................... 111

A1.2. Les KPI de mobilité en EPC.................................................................................................... 111

A1.3. Les KPI d’utilisation en EPC .................................................................................................. 112

A1.4. Les KPI d’accessibilité en LTE ............................................................................................... 113

A1.5. Les KPI de maintien en LTE .................................................................................................. 113

A1.6. Les KPI d’intégrité en LTE .................................................................................................... 113

vi
 A1.7. Les KPI de disponibilité en LTE ............................................................................................ 113

A1.8. Les KPI de mobilité en LTE.................................................................................................... 113

ANNEXE 2 : MODELES DE TRAFIC EN LTE ............................................................................... 114

A2.1. Modélisation et caractérisation du trafic voix sur IP (VoIP ................................................ 114

A2.2. Modélisation et caractérisation du trafic vidéo ..................................................................... 116

A2.3. Modélisation et caractérisation du trafic web ....................................................................... 117

A2.4. Modèle de trafic File Transfert Protocol (FTP) .................................................................... 118

BIBLIOGRAPHIE .................................................................................................................................... 119

FICHE DE RENSEIGNEMENTS ........................................................................................................... 123
RESUME .................................................................................................................................................... 124
ABSTRACT ............................................................................................................................................... 124

vii
NOTATIONS ET ABREVIATIONS

1. Minuscules latines

( ) Densité de probabilité de ( )

ℎ Numéro du dernier paquet identifié comme sera en retard dans la queue

virtuelle de la file k
Taux de perte estimé pour les paquets entrants dans la file k et sa queue
virtuelle
Numéro du premier paquet identifié comme sera en retard dans la queue
virtuelle de la file k
Nombre estimé de nouvelle arrivée de paquets dans la queue virtuelle de la file
k pendant l’intervalle de temps pour la transmission des paquets dans la file k
, Temps d’arrivée estimé du nième paquet de la queue virtuelle dans la file k

, Temps de réception estimé du nième paquet de la queue virtuelle dans la file k

( ) Densité du temps d'attente d'un client de la classe

ℎ Numéro du dernier paquet identifié comme sera en retard dans la file k

Indice des classes des clients

Numéro du premier paquet identifié comme sera en retard dans la file k

Nombre de paquets dans la file k

Probabilité associée à l'état

ième
Durée de service requise par le client

, Temps d’arrivée de l’ième paquet dans la file k

viii
 Temps d’observation pour voir quel paquet dans la file k ne peut arriver à
destination avant le PDB
Temps de propagation dans la couche physique du paquet i

, Temps de réception de l’ième paquet de la file k

2. Majuscules latines

( ) Fonction de répartition de la période entre le moment où le serveur commence à

servir le 1er client parmi les clients de la classe 1 et le moment où aucun client
de la classe 1 n'est plus présent dans le système.

( ) Fonction de répartition du temps de complétion de service d'un client de la

classe
Ordre d’arrivée des clients

Loi constante (déterministe);

, Retard du paquet i dans la file k

ième
Délai de patience associé au client après son arrivée.

, Intervalle de temps estimé pendant laquelle le nième paquet dans la queue

virtuelle de la file k sera ordonnancé pour être transmis
, Débit prévu si le PRB y est alloué à l’UE x

Débit moyen des paquets de l’UE x dans la file k

Loi Erlang-

( ) Fonction de répartition de la charge du travail apportée par la classe

ix
 Loi générale

Loi générale indépendante

Loi hyper exponentielle d'ordre

( ) Fonction de répartition du premier saut dû de la phase active

Nombre de client moyen dans le système (file+serveur)

Nombre de client moyen dans la file de classe

Taux de perte estimé pour la file k

Loi exponentielle (processus de Markov)

Nombre de transmission successive de paquets dans la file k avant le temps

d’observation en cours et après le dernier paquet supprimé
Nombre de clients entrés dans le système jusqu'à l’instant

, Probabilité qu'un client de la classe soit admis en service

, Intervalle de temps pendant laquelle l’ième paquet dans la file k sera ordonnancé
pour être transmis
( ) Fonction de répartition du temps de service

( ) Fonction de répartition du temps de service complémentaire

Temps nécessaire pour transmettre tous les paquets dans la file k

Intervalle de temps de transmission : 1 TTI = 10 ms

x
 Seuil pour le taux de perte de paquets dans la file k

Instant où quitte la file d’attente

ième
Instant d'arrivée du client

Temps d’inter-arrivée entre le client et le client − 1.

Temps d’attente moyen

,
Temps d'attente moyen des clients de la classe qui abandonnent la file

, Temps d'attente moyen des clients de la classe qui restent dans la file

, Temps d’attente moyen des clients de la classe qui rejoignent le serveur

,
Temps d'attente moyen de tous les clients de la classe

ième
Temps d’attente proposé au client avant la fin de son service.

Processus Markovien multidimensionnel

Version stationnaire de

Temps passé dans le système à l'instant par le client en service à cet instant

3. Minuscules grecques

Taux d’attente des clients de la classe

Taux d’arrivée des clients de la classe

Probabilité de perte d'un client de la classe

ième
Probabilité de perte du client

xi
 Taux de service

Probabilité de perte d'un client à l'état stationnaire

Charge du système

4. Majuscules grecques

∆ Temps d’inter-arrivée moyen pour les paquets dans la file k

∆ Temps d’inter-réception moyen pour les paquets dans la file k

ième
Temps de séjour du client dans le système (file+serveur)
ième
Temps d’attente effectif du client dans la file

ℱ Un tribu défini sur Ω

ℒ Transformée de Laplace de la fonction

Ω Univers de l’espace de probabilité d’une file d’attente

Probabilité définie sur ℱ

5. Abréviations

2G 2ème Génération des réseaux mobiles

3G 3ème Génération des réseaux mobiles

3GPP 3rd Generation Partnership Project

3GPP2 3rd Generation Partnership Project 2

4G 4ème Génération des réseaux mobiles

AAA Authentication Authorization Accounting

ADC Application Detection and Control

ADSL Asymmetric Digital Subscriber Line

AF Application Function

AGW Access Gateway

AMR-NB Adaptive Multi-Rate Narrowband

AMR-WB Adaptive Multi-Rate Wideband

xii
APN Access Point Name

APN-AMBR Access Point Name-Agregated Maximum Bit Rate

ARP Allocation and Retention Priority

AS Access Stratum

ASN-GW Access Service Network GateWay

ATM Asynchronous Transfer Mode

BBERF Bearer Binding and Event Reporting Function

BE Best Effort

CBWFQ Class Based Weighted Fair Queuing

CPU Central Processing Unit

CQI Channel Quality Indicator

CS Circuit Switched

DCCH Dedicated Control CHannel

DEPS Dernier Entré, Premier Servi

DL DownLink

DNS Domain Name Server

DRB Data Radio Bearer

DSCP Differentiated Service Code Point marking

DTCH Dedicated Traffic CHannel

ECGI E-UTRAN Cell Global Identifier

EMM EPS Mobility Management

eNB evolved NodeB

EPC Evolved Packet Core

EPS Evolved Packet System

E-RAB E-UTRAN Radio Access Bearer

ESM EPS Session Management

E-UTRAN Evolved UMTS Terrestrial Radio Acces Network

xiii
EXPPF Exponential Proportional Fair

FDD Frequency Division Duplex

FIFO First In First Out

GBR Guaranteed Bit Rate

GERAN GSM EDGE Radio Access Network

GPRS General Packet Radio Service

GTP-C GPRS Tunneling Protocol – Control plane

GTP-U GPRS Tunneling Protocol – User plane

HARQ Hybrid Automatic Repeat reQuest

HSS Home Subscriber Server

HTML HyperText Markup Language

HTTP HyperText Tranfer Protocol

IHM Interface Homme-Machine

IMS IP Multimedia Subsystem

IP Internet Protocol

IP-CAN IP Connectivity Access Network

IPsec Internet Protocol Security

ISDN Identifier Subscriber Domain Number

KPI Key Performance Indicator

LCG Logical Channel Groups

LIFO Last In First Out

LTE Long Term Evolution

MAC Medium Access Control

MBR Maximal Bit Rate

MCS Modulation and Coding Scheme

MLWDF Modified Largest Weighted Delay First

MME Mobility Management Entity

xiv
MMS Multimedia Message Services

MSISDN Mobile Station ISDN Number

NAS Non Access Stratum

N-GBR Non-Guaranteed Bit Rate

NRT Non Real-Time

O&M Operation and Maintenance

OCS Online Charging System

OFCS Offline Charging System

OFDM Orthogonal Frequency Division Multiplexing

OS Operating System

OSI Open Systems Interconnection

OTT Over The Top

PA Phase Active

PASTA Poisson Arrivals See Time Averages

PBR Prioritized Bit Rate

PCC Policy Control and Charging

PCEF Policy and Charging Enforcement Function

PCRF Policy Control and charging Rules Function

PDB Packet Delay Budget

PDCCH Physical Downlink Control CHannel

PDCP Packet Data Convergence Protocol

PDN Packet Data Network

PDSCH Physical Downlink Shared CHannel

PDU Packet Data Unit

PEPS Premier Entré, Premier Servi

PF Proportional Fair

P-GW PDN Gateway

xv
PHY Physique

PI Phase Inactive

PELR Packet Error Loss Rate

PPM Packet Prediction Mechanism

PRB Physical Resource Block

PUSCH Physical Uplink Shared CHannel

QCI QoS Class Identifier

QoS Quality of Service

RAN Radio Access Network

RAT Radio Access Technology

RLC Radio Link Control

RNC Radio Network Controller

RRC Radio Resource Control

RRM Radio Resource Management

RT Real-Time

RTP Real-Time Transport Protocol

RTSP Real Time Streaming Protocol

S1-AP S1 - Application Protocol

S1-C S1 – Control plane

S1-U S1 – User plane

SAE System Architecture Evolution

SCTP Stream Control Transmission Protocol

SDP Session Description Protocol

SGSN Serving GPRS Support Node

S-GW Serving Gateway

SIP Session Initiation Protocol

SLA Service Level Agreement

xvi
SMS Short Message Services

SPI Security Parameter Index

SPT Shortest Processing Time

SRB Signaling Radio Bearer

SRS Sounding Reference Signal

SRVCC Single Radio Voice Call Continuity

S-TMSI SAE-Temporary Mobile Subscriber Identity

TAI Tracking Area Identity

TCP Transmission Control Protocol

TEID Tunneling End IDentifiers

TFT Traffic Flow Template

TTI Transmission Time Interval

UDP User Datagram Protocol

UE User Equipment

UE-AMBR User Equipment- Agregated Maximum Bit Rate

UL UpLink

UMTS Universal Mobile Telecommunications System

USIM Universal Subscriber Identity Module

UTRAN Universal Terrestrial Radio Access Network

VoD Video on Demand

VoIP Voix sur IP

VoLTE Voice over LTE

VPLMN Visited Public Land Mobile Network

X2-AP X2 – Application Protocol

X2-C X2 – Control plane

X2-U X2 – User plane

xvii
 INTRODUCTION

Les réseaux UMTS (Universal Mobile Terrestrial Standard) et son évolution HSPA (High Speed
Packet Access) ont rencontré un succès commercial en lien avec le développement de nouveaux
usages tels que l’internet mobile, la vidéo, les applications mobiles, etc. mais aussi grâce à la grande
disponibilité de nouveaux équipements (smartphones, tablettes, clé 3G+, etc.). L’idée d’une
évolution à long terme des réseaux mobiles de troisième génération est alors apparue à la 3GPP (3rd
Generation Partnership Project) et s’est concrétisée par la norme LTE (Long Term Evolution). Grâce
à l’amélioration considérable que le LTE a apportée, elle est à partir de la release 10 classée comme
faisant partie des réseaux mobiles de quatrième génération. Les performances de la LTE ont conduit
à la création de nouveaux services nécessitant de large bande passante tels que la vidéo en streaming,
l’IP TV (Internet Protocol TeleVision), les jeux en réseaux interactifs, etc. impossibles pour les
réseaux mobiles jusqu’alors.
L’introduction de ces nouveaux services cependant lève de nouvelles problématiques dans ces types
de réseaux. En effet, parmi les évolutions qui ont été attribuées à la norme LTE, le trafic d’appel
voix transite à travers le réseau par commutation de paquets et non plus par commutation de circuit
comme auparavant. Cela implique une gestion supplémentaire au niveau du réseau car ces différents
services possèdent des exigences strictes et différentes étant donné que certains sont par exemple
très sensibles au délai comme le trafic voix, d’autres aux débits, etc.
L’ensemble des mécanismes implantés au sein des réseaux LTE gérant ces principes de
différenciation entre les services est ce que les techniciens et ingénieurs connaissent sous le nom de
gestion de la qualité de service (QoS pour Quality of Service). Le présent mémoire traitera le thème
général des mécanismes de qualité de service au sein des réseaux LTE.
La gestion de la QoS étant nativement supportée à partir de la release 10 des spécifications 3GPP,
la constatation ainsi que les mesures ont montré que les paramètres de QoS sont difficilement
maitrisés sur le réseau d’accès radio. Une des fonctions permettant le respect des exigences en QoS
sur la partie radio est l’ordonnancement ou scheduling implanté au sein de la station de base.
Dans cette optique, ce mémoire intitulé « Influence du scheduling sur la qualité de service dans les
réseaux LTE » se concentrera sur l’évaluation et l’impact des algorithmes d’ordonnancement en
voie descendante sur les paramètres de QoS au sein du réseau d’accès LTE. Afin d’organiser au
mieux ce travail, il sera judicieux de voir dans le premier chapitre une formulation mathématique
du problème des files d’attente avec priorité et préemption qui constitue la base de toute conception
des mécanismes de différenciation de service. Le second chapitre sera plus axé sur la présentation

1
de l’architecture LTE/EPC (Long Term Evolution/Evolved Packet Core), informations et notions
indispensables pour situer les fonctions de gestion de QoS. Le troisième chapitre se focalisera
ensuite sur l’étude des notions concernant la qualité de service en LTE/EPC. Cela sera suivi par la
localisation de différentes fonctions de gestion de QoS au sein des nœuds du réseau et un
approfondissement sur la fonction d’ordonnancement dans l’eNodeB en chapitre quatre. Enfin, le
cinquième et dernier chapitre s’intéressera sur l’évaluation de l’influence du scheduling sur les
paramètres de QoS étudiés par simulation en s’intéressant particulièrement sur l’algorithme PPM
ou Packet Prediction Mechanism.

2
 CHAPITRE 1
THEORIE ET SYSTEMES DES FILES D’ATTENTE

1.1 Introduction

La théorie des files d’attente est à la base des mécanismes de qualité de service ou QoS (Quality of
Service). En effet, en termes de réseau, la QoS est définie comme « l’effet collectif des performances
d’un service qui détermine le degré de satisfaction de l’utilisateur du service » [1]. Cette définition
sous-entend que la QoS est un concept totalement abstrait.
Les concepteurs, opérateurs de réseaux et les fournisseurs de service préfèrent quant à eux une
définition plus concrète et quantifiable. La qualité de service dans les réseaux a donc été de plus en
plus associée au concept qui permet aux nouvelles applications, surtout les applications sur
plateforme mobile, d’obtenir au niveau de l’expérience utilisateur la meilleure satisfaction. Dans
cette optique de recherche de meilleure satisfaction, la mise en œuvre de ces applications exige des
contraintes liés aux réseaux qui sont variées selon leur type, la qualité de service se traduit donc
comme l’ensemble des mécanismes de traitement au niveau du réseau qui permettent de respecter
les exigences pour l’ensemble des services. Son but est de fournir un système de priorisation des
flux réseaux en cas de montée en charge réseau des équipements concernés, fournissant ainsi une
bande passante adéquate pour certains paquets ainsi que des paramètres de latence et de gigue bien
contrôlés. Le système de priorisation de flux est basé sur les concepts de la gestion de file d’attente
dans chaque nœud du réseau.
La théorie des files d’attentes sera donc traitée dans ce premier chapitre en précisant ses principaux
modèles mathématiques.

1.2 Concept de la théorie des files d’attente

La théorie des files d’attente est une approche mathématique permettant d’analyser les files
d’attente. Elle est basée sur l’étude des équipements téléphoniques automatiques réalisée au début
du XXe siècle par l’ingénieur danois en télécommunication, A. K. Erlang. L’application de cette
théorie n’a été généralisée à divers types de problèmes qu’après la Seconde Guerre mondiale. La
planification et l’analyse de la capacité de service sont des thèmes traités par cette théorie [2].

3
1.2.1 Origine des attentes

Il peut être surprenant d’apprendre que des files d’attente se forment même dans les systèmes non
congestionnés. A l’exemple d’un établissement de restauration rapide qui peut traiter en moyenne
200 commandes à l’heure voit malgré tout se former des files d’attente avec un nombre moyen de
150 commandes à l’heure. L’expression clé est « en moyenne ». Le problème vient du fait que les
arrivées des clients ont lieu à intervalles aléatoires plutôt qu’à intervalles fixes et il y a aussi la
notion dite heure de pointe et heure creuse. De plus, certaines commandes requièrent un temps de
traitement plus long. En d’autres termes, les processus d’arrivée et de service ont un degré de
variabilité élevé. Par conséquent, le système est soit temporairement congestionné (heure de pointe),
ce qui crée des files d’attente, soit vide (heure creuse), parce qu’aucun client ne se présente. Donc,
si le système n’est pas congestionné d’un point de vue macro (en moyenne), il l’est d’un point de
vue micro (instantanément). Par ailleurs, en cas de variabilité minimale ou inexistante (arrivée selon
les rendez-vous et temps de service constant), aucune file d’attente ne se forme.

1.2.2 Objectif de l’analyse des files d’attente

Il existe le concept de coût en théorie des files d’attente qu’il est nécessaire de décrire au préalable.
Le premier concept est le coût total, qui équivaut à la somme de deux coûts : le coût associé à la
capacité de service mise en place ou coût de service et le coût associé à l’attente des clients ou coût
d’attente.
Le coût de service est le coût résultant du maintien d’un certain niveau de service, par exemple le
coût associé au nombre de caisses dans un supermarché, au nombre de réparateurs dans un centre
de maintenance, au nombre de guichets dans une banque, au nombre de voies d’une autoroute, etc.
En cas de ressources inoccupées, la capacité est une valeur perdue, car elle est non stockable.
Les coûts d’attente sont constitués des salaires payés aux employés qui attendent pour effectuer leur
travail (mécanicien qui attend un outil, chauffeur qui attend le déchargement du camion, etc.), du
coût de l’espace disponible pour l’attente (grandeur de la salle d’attente dans une clinique, longueur
d’un portique de lave-auto) et, bien sûr, du coût associé à la perte de clients impatients qui vont chez
les concurrents. En pratique, lorsque le client est externe à l’entreprise, le coût d’attente est difficile
à évaluer, car il s’agit d’un impact plutôt que d’un coût pouvant être comptabilisé. Cependant, on
peut considérer les temps d’attente comme un critère de mesure du niveau de service. Le
gestionnaire décide du temps d’attente acceptable, « tolérable », et il met en place la capacité
susceptible de fournir ce niveau de service.

4
L’objectif de l’analyse des files d’attente est de minimiser le coût total en trouvant un compromis
entre le coût associé à la capacité de service et le coût d’attente des clients. La figure 1.01 illustre
ce concept. Notez que lorsque la capacité de service augmente, le coût de service augmente. Par
souci de simplicité, nous avons illustré un coût de service linéaire. Lorsque la capacité de service
augmente, le nombre de clients en attente et le temps d’attente tendent à diminuer, donc les coûts
d’attente diminuent [2][3][4]. Le coût total (la somme des coûts de service et d’attente) est
représenté sur le graphique par une courbe en pointillé.
Ceci modélise bien le problème de la qualité de service au niveau des réseaux. En effet, les paquets
transitant à travers les réseaux sont soumis à des retards. Ces retards se catégorisent en délai de
propagation ou propagation delay, délai de traitement ou processing delay et délai d’attente ou
queuing delay. La figure 1.02 illustre les retards occasionnés par les réseaux.

Figure 1.01 : Les délais dans les réseaux

La théorie mathématique des files d’attente étant assez complexe, il s’agit surtout dans la suite de
s’intéresser aux concepts et aux hypothèses relatifs à la résolution des problèmes d’attente.

1.2.3 Les caractéristiques des systèmes de files d’attente

Plusieurs modèles d’analyse ont été conçus dans le cadre de la théorie des files d’attente.
Le succès de l’analyse des files d’attente repose surtout sur le choix du modèle approprié. Plusieurs
caractéristiques sont à prendre en considération :
 La population.
 Le nombre de serveurs.

5
 Les tendances quant à l’arrivée et au service.
 L’ordre de traitement des clients.

La figure suivante illustre un système de file d’attente.

Figure 1.02 : Simple système de file d’attente

Il est nécessaire de procéder à l’étude de ces caractéristiques pour bien appréhender le principe.

1.2.3.1 La population

La « population » se décrit comme la source de clients potentiels dans la théorie des files d’attente.
Il sera judicieux de faire la distinction entre deux situations possibles. Dans une première situation,
la population est considérée comme infinie, c’est-à-dire que le nombre potentiel de clients est
infiniment grand en tout temps. Ces clients sont également supposés provenir de toutes les régions
possibles. Dans un deuxième cas, la population est considérée finie, donc le nombre de clients
potentiels est limité.

1.2.3.2 Le nombre de serveurs

La capacité de service dépend de la capacité de chaque serveur et du nombre de serveurs disponibles.

Le terme « serveur » représente ici la ressource et, en général, on suppose qu’un serveur ne traite
qu’un client à la fois.
Les systèmes de files d’attente fonctionnent avec serveur unique ou serveurs multiples (plusieurs
serveurs travaillant en équipe constituent un serveur unique, par exemple une équipe chirurgicale).
Les exemples de systèmes de files d’attente avec serveur unique sont nombreux : les petits magasins
avec une seule caisse. Les systèmes à multiples serveurs sont les banques, les billetteries
d’aéroports, les garages et les stations-service.

6
1.2.3.3 Les tendances quant à l’arrivée et au service

Les files d’attente résultent de la variabilité des tendances d’arrivée et de service. Elles se forment
parce que le degré élevé de variation dans les intervalles entre les arrivées et dans les temps de
service cause des congestions temporaires. Dans plusieurs cas, on peut représenter ces variations
par des distributions théoriques de probabilités. Dans les principaux modèles utilisés, il sera plus
approprié de supposer que le nombre d’arrivées dans un intervalle donné suit la loi de Poisson, alors
que le temps de service suit une loi exponentielle.

La distribution de Poisson donne un bon aperçu du nombre de clients qui arrivent par unité de temps
(par exemple le nombre de clients à l’heure). La figure suivante illustre un exemple des arrivées
distribuées selon la loi de Poisson pendant une période de trois jours. Durant certaines heures, on
note de trois à quatre arrivées ; à d’autres, un ou deux, et pour certaines, aucun.

Figure 1.03 : Processus d’arrivée distribué selon la loi de Poisson

La distribution exponentielle, quant à elle, donne une assez bonne approximation des temps de
service. La figure ci-dessous illustre le temps de service pour des clients qui arrivent selon le
processus illustré à la figure 1.03. La remarque se trouve sur le fait que la plupart des temps de
service sont très courts, certains sont proches de zéro et quelques-uns, assez longs. C’est la
caractéristique typique de la distribution exponentielle.

7
 Figure 1.04 : Temps de service distribués de façon exponentielle

Les files d’attente se forment plus souvent lorsque les arrivées se font en groupe ou que les temps
de service sont particulièrement longs ; elles se créent presque à coup sûr si ces deux facteurs se
réunissent. Par exemple, le temps de service particulièrement long pour le client numéro 7 au jour
1. À la figure 1.03, le client numéro 7 arrive à 10 heures et les 2 clients suivants arrivent juste après,
ce qui crée alors une file d’attente. Une situation similaire s’est présentée le jour 3 avec les 3 derniers
clients : le temps de service assez long pour le client numéro 13 (figure 1.04) combiné au temps
relativement court entre les deux arrivées suivantes (figure 1.04, jour 3) va certainement engendrer
(ou augmenter) une file d’attente.

Il existe une relation entre la distribution de Poisson et la distribution exponentielle. En d’autres

termes, si le temps de service suit la loi exponentielle, le taux de service (nombre de clients servis
par unité de temps) suit la loi de Poisson. De la même manière, si le taux d’arrivée suit la loi de
Poisson, le temps inter arrivées (temps entre deux arrivées successives) suit une loi exponentielle
[5] [6] [7].

8
Les modèles de files d’attente ont généralement comme processus d’arrivée un processus de Poisson
ou, de façon équivalente, des temps inter-arrivées exponentiels et des temps de service distribués
selon une loi exponentielle.

1.2.3.4 L’ordre de traitement des clients

Dans tous les modèles décrits dans les pages suivantes, on dispose de plusieurs règles de priorité
dont la plus communément utilisée est le Premier Entré, Premier Servi (PEPS) ou First In First Out
(FIFO). Elle procure aux clients un sentiment de justice, bien qu’elle pénalise les clients dont le
temps de service est court. Elle est appliquée dans les banques, les magasins, les cinémas, les
restaurants, les intersections avec arrêt obligatoire, les contrôles douaniers, etc.
Etant donné que le but est d’offrir un système de priorisation dans les systèmes appliqués aux
réseaux, il serait plus judicieux d’utiliser d’autres règles. Il existe notamment d’autres règles de
priorité comme :
 Le Dernier Entré, Premier Servi (DEPS) ou Last In First Out (LIFO)
 Le service partagé où tous les clients sont servis en même temps, mais avec une vitesse
inversement proportionnelle au nombre de clients
 Le choix aléatoire où le prochain client de la file d'attente à être servi est choisi au hasard
 Le Shortest Processing Time (SPT) dans lequel le prochain client de la file d'attente à être
servi est celui qui aura le temps de traitement le plus court.
 Les systèmes à priorité qui définissent des classes de priorité à chaque client et fait passer
en premier les clients ayant des priorités importantes.

La règle du LIFO n’étant pas du tout appropriée pour le système de priorisation dit de Qualité de
service au sein des réseaux, le service partagé peut être une solution mais ne peut pas aller tout seul.
Le choix aléatoire créera un désordre pas possible quant à lui, donc le SPT peut être une solution
envisageable. Cependant, la meilleure solution est surement les systèmes à priorité, mais encore
mieux les systèmes à priorités strictes avec préemption. Le problème devient alors un problème de
file d’attente avec client impatient [8].
La contrainte du temps réel est en effet devenue la préoccupation majeure ces derniers temps dans
l'élaboration des systèmes de Télécommunication. Ainsi, le modèle classique des files d'attente
demeure incapable de modéliser ces nouveaux besoins et la notion d'impatience est devenue, par la
suite, une alternative pertinente pour caractériser la "durée de vie" de l'information.

9
En général, une file d'attente est définie par :
 Un processus d'arrivée de clients, c’est-à-dire une suite croissante{ , = 0}, où est
l'instant d'arrivée du nième client. Le processus d'arrivée est alors la fonction de comptage
associée aux temps d'inter-arrivées. Si de plus la loi est une exponentielle, alors le processus
des arrivées est un processus de Poisson, et on utilise la notation M pour souligner le
caractère Markovien.
 Une suite de réels { , = 0} avec est la durée de service requise par le nième client. Nous
verrons que dans ce cas, si le processus d'arrivée est un processus de Poisson, alors
l’évolution de la taille de la file d'attente est une chaine de Markov.
 Une discipline de service : Distributions des inter-arrivées
Une file d’attente se note alors : / / ( / / ) ou / / / / / ( ) ou / / / / /
Avec :
A : le processus d'arrivée, S : le processus de sortie, C : le nombre de serveur, K : la capacité
maximale de la file, L : la population de clients et DS : la discipline de service

Les symboles utilisés pour décrire les processus d'entrée et de service sont :
 : Loi exponentielle (processus de Markov);
 : Loi générale;
 : Loi générale indépendante;
 : Loi constante (déterministe);
 : Loi Erlang-k;
 : Loi hyper exponentielle d'ordre k;
 : Loi de Cox-k.

1.3 File d’attente à priorités strictes avec préemption

Plusieurs chercheurs comme Boxma, Perry et Stadje ont étudié récemment la file ⁄ ⁄1 + avec
un temps de service et une probabilité d'abandon de distribution générale [9]. Ils étudient deux cas:
1) Le nouvel arrivant dispose d'informations sur les clients présents dans le système, comme
leur temps d'attente, leurs priorités, etc. et peut décider d'entrer ou non dans la file d'attente.
2) Le nouvel arrivant ne possède aucune information et rejoint directement la file.

10
1.3.1 Description du problème

Il s’agit dans la suite d’étudier les files d’attente avec possibilités d’abandon. Pour cela, le cas de
deux classes de clients sera considéré mais avec les contraintes suivantes :
 Les clients de la classe i arrivent suivant un processus de Poisson de taux .

 Le temps de service est le même pour tous les clients et suit une loi exponentielle de
paramètre .
 Les clients prioritaires ont une priorité stricte par rapport à ceux non prioritaires. C'est-à-dire
qu'à l'arrivée d'un client prioritaire, le client non prioritaire en service quitte le serveur et
rejoint la file d'attente et son temps de service déjà effectué est gardé en mémoire.
 Un client peut abandonner le système après un temps d'attente distribué suivant une loi
exponentielle de taux et ce, jusqu'au début de son service. Autrement dit, il ne pourra plus
quitter le système après être pris en charge par le serveur

Figure 1.05 : Un serveur avec deux classes de clients qui peuvent abandonner

1.3.2 Formalisation mathématique

1.3.2.1 File d’attente avec impatience

La présentation du modèle classique des files d’attente est nécessaire avant d’entamer le modèle
avec impatience.

 Modèle classique
Mathématiquement, une file d’attente est un espace probabilisé (Ω, ℱ, ) où les clients arrivent
suivant un ordre , , … etc. Donc, l’instant d’arrivée du client et sa durée de service
demandée. De plus, on suppose que presque sûrement les arrivées sont simples (un seul client à la
fois), ainsi la suite des instants d'arrivée { } est une suite de variable aléatoire presque sûrement

11
strictement croissante. D'autre part, on note { } qui compte à chaque instant le nombre de
clients entrés dans le système jusqu'à cet instant. Ainsi,

≔ 1{ (1.01)
}
∈ℕ∗

On notera par ailleurs ≔ − , ∀ > 1 le temps d’inter-arrivée avec ≔ . On

supposera de plus que les suites des inter-arrivées et des temps de services sont indépendantes
identiquement distribuées de même distribution que et , respectivement. De plus, on suppose
que ces variables aléatoires sont intégrables, c’est-à-dire :
[ ]<∞ [ ]<∞ (1.02)
Ce qui permet de noter :
1 1 (1.03)
≔ ≔
[ ] [ ]
On définit la charge du système par :
(1.04)
≔

 Modèle avec impatience

Afin de modéliser l'impatience des clients entrants dans le système, nous devons ajouter la notion
du délai au-delà duquel le client sera définitivement perdu (il sort sans service du système). Notons
la variable aléatoire caractérisant le délai associé au client . Ainsi, si à l’instant + le
client n’est pas en service alors il sort définitivement du système et sera par la suite considéré
comme perdu. Par conséquent, les délais sont considérés comme éliminatoires et jusqu’au début du
service.
D’autre part, la suite { } sera toujours supposée indépendante identiquement distribuée et ayant
la même distribution que . De plus, on suppose que : [ ] < ∞ et on note ≔ [ ]
.

1.3.2.2 Variables de performance

Définissons à présent les différentes variables aléatoires caractérisant notre problème et permettant
d'évaluer ses performances :
 Le nombre de client moyen dans le système (file+serveur) avec ≔ [ ]
 Le temps d’attente proposé au client est le temps qu’aura à attendre ce client avant la
fin de son service.

12
  Le temps de séjour est le temps que passe effectivement le client dans le système
(file+serveur) :
=( + )1{ } + 1{ } (1.05)
 Le temps d’attente est le temps que passe effectivement le client dans la file :
= 1{ } + 1{ } (1.06)
Pour toute file d’attente à perte, notons la probabilité de perte du client . Ainsi, est la
probabilité qu’un client se voit proposer un temps d’attente supérieur à son délai de patience.

Autrement dit,
≔ [ > ] (1.07)

1.3.3 Règles de priorité

Nous nous intéressons à des classes de clients avec priorité stricte de façon à ce que la classe de
rang inférieur soit la plus prioritaire. Ainsi, on ne commence à traiter la classe de rang + 1 que
lorsque celle de rang est devenue vide. D'autre part, on entend dire par préemption le cas où un
client, qui est en train d'être servi, se voit obliger de quitter le serveur en faveur d'un autre qui est
plus prioritaire que lui.
Pour avoir une file d’idée continue, il est préférable dans un premier temps de voir le cas où il
n’existe qu’une seule classe de client pour avoir un encadrement de la probabilité de perte qui a la
particularité d'être générale à toute distribution des arrivées et du temps de service. Cet encadrement
permet d'estimer à l'avance la probabilité de perte et ensuite généraliser le cas pour 2 ou plusieurs
classes.

1.3.4 Cas d’une file à une classe de clients

1.3.4.1 File / /1 +

Considérons la file M/M/1+M où les délais de patience des clients sont Markovien. Posons la
probabilité associée à l'état . Ainsi, et par conservation de flux nous obtenons la formule de
récurrence suivante :
= [ + ( + 1) ] (1.08)

13
Et on obtiendra après une démonstration par récurrence que
(1.09)
=
+

Par souci de simplification posons,

(1.10)
= ,∀ ≥ 1
+
Ainsi,
(1.11)
=

D'autre part, et comme les probabilités somment à 1 alors on déduit que :

1 (1.12)
=
1+∑ ∏
Enfin et par souci de simplification nous garderons toujours la constante dans l'expression de .

Figure 1.06 : Graphe des premiers états de la file M/M/1+M

 Calcul des mesures de performance

En gardant les simplifications précédentes, nous trouvons les résultats suivants :
a. Le nombre moyen de clients dans le système L
(1.13)
= = =

b. Le temps d'attente moyen :

En appliquant la loi de Little
= (1.14)

14
 On trouve :
(1.15)
= =

c. Probabilité de perte d'un client à l'état stationnaire :

∑ (1.16)
= = =

Les résultats obtenus lors du calcul des performances sont bien évidement purement théoriques.

1.3.4.2 File / /1 +

Considérons à présent la file / /1 + où les arrivées sont Markoviens de taux , le temps de

service est aussi Markovien de taux et le délai de patience est déterministe. Dans le cas où les
délais initiaux sont égaux à , Choi, Kim et Chung [10] proposent le calcul explicite des
performances par l'étude de la loi stationnaire du processus Markovien multidimensionnel
( , ≥ 0)à valeurs dans l'espace ({0} × {0,1}) ∪ ({1} × [0, ]) :

≔ (0, ) è ≤1
(1.17)
≔ (1, ) 2 è

Où est le temps passé dans le système à l'instant par le client en service à cet instant. Ainsi, on
peut calculer la loi stationnaire de et par suite, la densité de , la version stationnaire de . Par
ailleurs la propriété PASTA nous permet de trouver la probabilité de perte :
( ) (1.18)
=

Où est l'intensité du processus des entrées et on retrouve bien le résultat de Barrer :

( ) (1.19)
= [ = 0]

Et PASTA ou Poisson Arrivals See Time Averages, avec le théorème ergodique, veut dire qu'en
régime permanent un nouveau client verra clients devant lui avec une probabilité égale à la
proportion du temps pendant laquelle le système est occupé par clients.

15
1.3.4.3 Encadrement de la probabilité de perte d’un client

L'absence de mémoire de la loi exponentielle permet d'exhiber des modèles Markoviens simples
pour le calcul des performances et donne en particulier une formule close pour la probabilité de
perte .
Soit ≔ ( ⁄ )
Notons l’instant où quitte la file d’attente. S’il n’est pas perdu, est donc l’instant où il entre
en service et ∈[ , + [ sinon on a bien = + .
Soient les évènements suivants :
≔ à
(1.20)
≔
Le client est éliminé lorsque le serveur est occupé par un autre client à l'instant + . Cet
événement est réalisé si l'un des clients , ,…, entrés avant est en service à cet instant.
Dans ce cas, ce client en service à l'instant + l'était déjà à l'instant + sinon il aurait été
éliminé à cet instant.
Ainsi,

= | (1.21)

Comme les temps de service sont exponentiels, la probabilité qu’un client soit encore en service à
l’instant + sachant qu’il était déjà en service à l’instant + est donnée par :
[ > − ]= [ > ] (1.22)
Donc,

= [ > ] + [ > ] (1.23)

Or, ⊂ :
≤ [ > ] + [ > ] (1 − ) (1.24)
Comme le système est stable, on peut déduire que
= lim ≤ [ > ] (1.25)
→

D’autre part, on a :

= [ > ] + [ > ] (1.26)

16
Il vient ensuite que :
≥ [ > ](1 − (1 − ) [ < ]) (1.27)
En effectuant les transformations et par passage à la limite, on obtient :
≥ [ > ] − [ > ] [ < ](1 − ) (1.28)
Finalement, de (1.25) et (1.28), on en déduit que :
[ > ] [ > ]
≤ ≤ [ > ] (1.29)
1− [ > ] [ < ]

1.3.5 Cas d’une file à deux classes de clients

1.3.5.1 Cas particulier

Dans cette section nous allons étudier le cas où on aura deux classes de clients de même taux
d'abandon et avec priorité stricte.
Notons ( )= ( )+ ( ), qui est en suivant les notations précédentes, le nombre de clients
dans le système caractérisé par :
= + (1.30)
= = (1.31)
= = (1.32)

Figure 1.07 : Parallélisme avec une seule classe de clients

Ainsi, cette considération nous permet de constater que et évoluent comme un système à une
seule classe de clients. De plus, en exploitant les résultats déjà trouvés on pourra déduire les mesures
de performances de la deuxième classe comme suit :
= − (1.33)
= − (1.34)
Ainsi, nous pourrons généraliser ce procédé à classes de clients avec un calcul de proche en
proche.

17
1.3.5.2 Cas avec priorité stricte et avec préemption

Dans le cas d'une priorité stricte, nous considérons que la première classe est prioritaire par rapport
à la deuxième en se plaçant toujours dans le cas des délais éliminatoires jusqu’au début du service.
D'autre part, nous supposons que les clients de la classe 1 ont une priorité préemptive sur ceux de
la classe 2 et que ces derniers sont patients indéfiniment après le début de leur service. Autrement
dit, un client de la classe 2 n'est servi que s'il n'y a aucun client de la classe 1 dans le système et il
quitte immédiatement le serveur, pour rejoindre la file, dès l'arrivée d'un client de la classe 1 même
s'il n'a pas encore terminé son service.

Il est clair que le comportement de la classe prioritaire peut être approché par le cas d'une seule
classe de clients. On pourra, ainsi, reprendre tous les résultats déjà trouvés. Par contre, on ne peut
rien dire à priori sur le comportement de l'autre classe.

D'autre part, nous aurons besoin de la distribution de la période où le système est occupé par les
clients de la classe la plus prioritaire (classe 1). Ainsi, cette période est définie, lorsqu'elle est
générée par clients de la classe 1, comme étant la durée écoulée entre le moment où le serveur
commence à servir le premier client parmi ces clients de la classe 1 et le moment où aucun client
de la classe 1 n'est plus présent dans le système. Du moment où les clients de la classe 1 se
comportent comme étant les seuls présents dans le système, nous pouvons reprendre les résultats
établis par Rao [11] qui a étudié la file / /1 + avec une seule classe de clients impatients.
Posons ( ) la fonction de répartition de cette période initiée par clients de la classe 1 dans la
file et ( ) sa densité ayant ℒ ( ) comme transformée de Laplace. D'autre part, notons ( ) la
fonction de répartition du temps de service, ( ) = 1 − ( ) celle du temps de service
complémentaire et ℒ ( ) sa transformée de Laplace.

 Remarque :
La transformée de Laplace d’une fonction continue de ℝ dans ℝ , notée ℒ , est la fonction qui
à associe :

ℒ ( )= ( ) , (1.35)

si cette intégrale converge.

18
Comme le temps de service est Markovien de taux alors on a :
1 1
( )=1− => ℒ ( )= − (1.36)
+
Ainsi les résultats de Rao [11] se simplifient comme suit :

+∑ ( − 1, ) +
+ ! +
ℒ ( )= (1.37)
1+∑ ( − 1, )
!
+∑ (−1) ( − 1, ) ( , )
+ + +
ℒ ( )= , ∀ ∈ ℕ∗ (1.38)
1+∑ ( − 1, )
!
Avec

⎧ (−1)
≤
⎪ ! −
( , )=
⎨ (−1)
⎪ >
! −
⎩

+
(, )=
+ +

D'autre part, posons ( ) (respectivement ( )) la densité du temps d'attente d'un client de la

classe 1 (respectivement la classe 2) jusqu'à ce que son service soit initié pour la première fois.
Comme la préemption est autorisée, n'affecte pas .
Notons au passage que nous n’aurons besoin ici que de ( ) qui est la densité de la période active
initiée par un client de la classe 1 entrant dans un système vide.
Notre système alterne entre une phase inactive (PI) où il n'y a aucun client dans le système et une
phase active (PA) qui est initiée par l'arrivée d'un client. De plus, nous appelons cycle de phase,
l'union de ces deux phases. Ainsi, une PA s'arrête au moment où tous les clients ont quitté le système,
dû à des services ou à des abandons.
Selon que le client de la classe 2 arrive durant une PI ou une PA, la fonction est donnée par :
( )= ( | )ℙ( )+ ( | )ℙ( ), ∀ ∈ ℝ (1.39)

19
D'autre part, comme chaque client qui arrive durant une PI sera automatiquement pris en charge par
le serveur, la transformée de Laplace de ( | ) sera égale à 1. Par contre, pour un client qui arrive
durant une PA, il y a deux cas de figures à traiter.
a. Il arrive juste après l'initiation de la PA et doit attendre dans la file mais son temps d'attente
dépend du type du client qui a initié la PA. Si la PA a été initié par un client de la classe 1,
il doit attendre jusqu'à ce que ce client soit servi ainsi que tous les autres clients de la classe
1 rejoignant la file. Ce temps d'attente est égal à la période initiée par un client arrivant quand
le serveur est vide dans une file / /1 + avec une seule classe de clients impatients qui
est largement étudiée dans la littérature. Sinon, il doit attendre jusqu'à ce que le client de la
classe 2, qui a initié la PA, soit servi ainsi que tous les éventuels clients de la classe 1 qui
sont entrés dans le système. Nous allons définir ce temps d'attente comme le temps de
complétion de service d'un client de la classe 2, qui est le temps écoulé entre l'instant où il a
été pris en charge par le serveur pour la première fois et l'instant où il termine son service.
Posons ( ) la fonction de répartition de ce temps d'attente et ( ) sa densité ayant ℒ ( )
comme transformée de Laplace et qui peut être trouvée par [12]:

ℒ ( )= (1.40)
+ + ℒ ( )
Notons au passage, que la PA sera initiée par un client de la classe 1 avec une probabilité

de

Posons ( ) la fonction de répartition du premier saut dû de la phase active. Ainsi :

( )= ( )+ ( ), ∀ ∈ ℝ (1.41)
+ +
Nous constatons donc que la durée de PA décroit avec un taux de 1 jusqu'à ce qu'on atteigne
la PI ou jusqu'à ce qu'un autre client de la classe 2 entre dans le système. De plus, chaque
fois qu'un client de la classe 2 arrive durant la PA, la durée de PA saute avec le temps de
complétion de service de ce client et s'il n'y a aucun client, alors la PA arrive à son bout et
on entre en PI.
Afin de donner le nombre moyen avec lequel décroit la PA par rapport au nombre moyen
avec lequel elle croit au niveau x, nous pouvons nous baser sur les résultats donnés par Brill
[13] [14] :

[ ] ( | )= 1− ( )+ [ ] ( − ) ( | ) (1.42)

20
 Notons au passage que la partie droite de cette équation indique que le niveau peut être
dépassé si le saut initial dépasse avec une probabilité de 1 − ( ) ou si un client de la
classe 2 arrivant durant la PA est suffisamment patient pour attendre les clients qui sont
devant lui et ce, avec un nombre moyen de [ ]. Ainsi,
1− ( )
( | )= + ( − ) ( | ) (1.43)
[ ]

La résolution de cette équation dans le domaine de Laplace donne le résultat :

+
ℒ ( )=
1+( + ) [ ]
(1.44)
1 1−ℒ ( )
+ + + ℒ ( )ℒ ( + )
+

b. Il arrive à un instant arbitraire après l'initiation de la PA mais comme le système est

Markovien sans mémoire, on se ramène au premier cas.

1.3.5.3 Mesures de performances

Le système étant stable, posons pour ∈ {1,2} :

 , : Le temps d’attente moyen des clients de la classe qui rejoignent le serveur
 , : Le temps d'attente moyen des clients de la classe qui abandonnent la file
 , : Le temps d'attente moyen des clients de la classe qui restent dans la file
 , : Le temps d'attente moyen de tous les clients de la classe
 : La probabilité de perte d'un client de la classe
 ( ) : La fonction de répartition de la charge du travail apportée par la classe
Il est clair que le serveur est soit vide avec la probabilité [ ] soit il sert un client de la classe 1 ou
de la classe 2. Mais comme la présence des clients de la classe 2 n'a aucun impact sur les clients de
la classe 1, alors en posant la probabilité qu'aucun client de la classe 1 n'est présent dans le
système, le serveur servira un client de la classe 1 avec la probabilité 1 − . Ainsi, la probabilité
qu'un client de la classe 2 soit admis en service, , , est égale à − [ ].

21
Ainsi, Stanford [15] nous permet d'écrire :
1−
=1− (1.45)

− [ ]
=1− (1.46)

Avec

= =

De plus, Stanford montre que :

(0)
, =0 = (0) = (1.47)
1−
Comme un client de la classe 2 ne peut commencer immédiatement son service que si le système
est vide alors (0) = [ ]. Ainsi, les résultats suivants ont été obtenus :
( )
, ( )= (1.48)
1−

, ( )= 1− + ( ) (1.49)
(1 − ) , ( )− , ( )
, ( )= (1.50)

Ce sont ces résultats qui permettront ensuite d’optimiser ces types de système de file d’attente.

1.4 Conclusion

Il a été question dans ce chapitre de s’intéresser aux files d’attente à plusieurs classes de priorité
avec préemption. Nous allons voir plus tard que les mécanismes de gestion de files d’attente au sein
des réseaux LTE/EPC en sont basés. Ces modèles de systèmes de file d’attente constituent donc les
modèles mathématiques de la gestion des files d’attente qui joue un rôle important pour permettre
aux réseaux LTE/EPC d’offrir une qualité de service satisfaisante aux utilisateurs.
Avant d’expliquer dans les chapitres ultérieurs les mécanismes de qualité de service au sein des
réseaux LTE/EPC, Il est important de connaitre avant cela l’architecture de ces réseaux qui fera
l’objet du prochain chapitre.

22
 CHAPITRE 2
ARCHITECTURE LTE/EPC

2.1 Introduction

Le LTE désigne les évolutions de l’accès radio définies pour répondre aux exigences des réseaux
de quatrième génération. Ces exigences seront abordées dans le dernier chapitre. Les changements
requis par rapport aux systèmes précédents ne se limitent toutefois pas à l’accès radio et une
évolution du réseau cœur désignée par les termes SAE (System Architecture Evolution) ou EPC
(Evolved Packet Core) a été nécessaire. Il sera donc préférable de faire référence dans cet ouvrage
à l’architecture LTE/EPC. Notons que l’ensemble LTE (pour l’accès radio) et EPC (pour le réseau
cœur) est aussi appelé EPS (Evolved Packet System).
Ce chapitre a pour objectif de présenter les principes généraux de l’architecture LTE/EPC. Nous
nous concentrerons sur l’analyse des fonctions du LTE et présenterons les fonctions principales des
nœuds de l’EPC.

 Notions de plan usager et de plan de contrôle

On distingue deux types de données pouvant transiter sur les interfaces du système LTE/EPC : les
données utilisateurs, portées par le plan usager et les données de signalisation, qui transitent via le
plan de contrôle.
Le plan usager ou user plane d’une interface correspond aux protocoles et fonctions mis en œuvre
sur cette interface pour le traitement des données de l’utilisateur (en provenance ou à destination de
celui-ci) transitant sur le réseau mobile et liées au service auquel cet usager accède (appel voix,
Internet, streaming vidéo, réseau privé…).
Le plan de contrôle (control plane) de l’interface permet, comme son nom l’indique, de contrôler le
plan usager par l’établissement, la reconfiguration et la relâche de connexion, l’échange
d’information et de contexte associés à l’UE (User Equipment) ou équipement utilisateur. Il permet
ainsi d’établir le service et d’en assurer la continuité dans l’environnement du réseau mobile. On
notera que le plan de contrôle d’une interface ne porte pas nécessairement des messages en
provenance ou à destination de l’UE [16].

23
Toutes les interfaces du réseau mobile ne portent pas des données de l’un ou l’autre de ces deux
plans. Par exemple, l’interface entre les équipements du réseau cœur et la base de données des
abonnés (HSS ou Home Subscriber Server) ne porte pas de données du plan usager.
Lorsqu’ils sont mis en œuvre sur une interface, ces deux plans sont matérialisés par des piles
protocolaires différentes. Celles-ci partagent en général un tronc commun et se différencient sur les
couches supérieures, lorsqu’un traitement spécifiques et des fonctions différentes doivent être mises
en œuvre pour chacun de ces deux plans. Nous verrons dans la suite les piles protocolaires des plans
usager et de contrôle définies pour les interfaces entre l’UE et le réseau au sein du système
LTE/EPC.

2.2 Présentation générale de l’architecture

A l’instar des réseaux 2G et 3G, l’architecture LTE/EPC est définie d’un point de vue physique et
d’un point de vue fonctionnel.
D’un point de vue physique, l’architecture LTE/EPC est composée de trois domaines :
 L’UE ou User Equipment
 Le réseau d’accès appelé LTE ou E-UTRAN (Evolved UMTS Terrestrial Radio Acces
Network)
 Le réseau cœur appelé EPC.
L’architecture générale LTE/EPC est présentée sur la figure suivante.

Figure 2.01 : Architecture générale LTE/EPC

24
L’architecture générale LTE/EPC est présentée en détail au sein des spécifications 3GPP [17] [18].
Le domaine du réseau cœur est composé de plusieurs nœuds. Le domaine du réseau d’accès est
composé d’un seul nœud : l’eNodeB. Ces différents nœuds sont interconnectés par l’intermédiaire
d’interfaces normalisées par le 3GPP. Cette normalisation doit permettre l’interfonctionnement de
nœuds de constructeurs différents.
D’un point de vue fonctionnel, l’architecture LTE/EPC se présente sur la figure suivante.

Figure 2.02 : Architecture fonctionnelle LTE/EPC

Les principes de l’architecture fonctionnelle du réseau 3G sont repris avec la définition d’une Access
Stratum et d’un Non Access Stratum.

Figure 2.03 : Répartition des fonctions entre les nœuds de l’architecture LTE/EPC

25
L’Access Stratum (AS) regroupe les protocoles radio et les protocoles S1 tandis que la Non Access
Stratum regroupe les protocoles NAS.
Les principales fonctions nécessaires au sein du système LTE/EPC sont définies selon l’architecture
fonctionnelle présentée à la figure 2.03.

2.3 Le réseau cœur

Les principaux nœuds logiques de l’EPC sont :

- S-GW ou Serving Gateway ;
- MME ou Mobility Management Entity ;
- P-GW ou Packet Data Network Gateway ;
- HSS ou Home Subscriber Server.
En complément de ces nœuds, l’EPC inclut également le nœud PCRF (Policy Control and Charging
Rules Function) de manière optionnelle. Des interfaces introduites à la figure 2.01 existent entre les
nœuds de LTE/EPC :
 S1-MME entre MME et eNodeB ;
 S1-U définie entre S-GW et eNodeB ;
 S5/S8 définie entre P-GW et S-GW ;
 S6-a définie entre HSS et MME ;
 S11 définie entre MME et S-GW
 Gx définie entre PCRF et P-GW.
L’architecture LTE/EPC requiert l’établissement d’une connexion logique entre deux points de
terminaison : P-GW et UE. Cette connexion virtuelle est appelée bearer EPS.

Décrivons à présent les différents nœuds logiques au sein de l’EPC.

2.3.1 La Serving Gateway (S-GW)

Tous les paquets IP à destination d’utilisateurs sont transférés à travers la S-GW, qui sert de point
d’ancrage pour les bearers de données lorsque l’UE est en mobilité entre plusieurs eNodeB. La S-
GW conserve également des contextes sur les bearers de l’UE lorsqu’il est en veille. Si elle reçoit
des données destinées à un UE en veille, la S-GW contacte le MME pour notifier l’UE et rétablir
ainsi les bearers associés aux contextes. Par ailleurs, la S-GW gère quelques fonctions annexes au
sein du réseau visité dans le contexte d’itinérance, telles que l’envoi d’informations pour la

26
facturation et les interceptions légales. La S-GW sert également de point d’ancrage pour
l’interfonctionnement avec d’autres technologies 3GPP comme l’UMTS ou le GPRS.

2.3.2 Le Mobility Management Entity (MME)

Le MME est le nœud de contrôle qui gère la signalisation entre l’UE et le réseau cœur. Il est
notamment le point de terminaison des protocoles NAS au sein de l’EPC. Le MME est responsable
de la gestion des bearers et notamment des phases d’établissement, de configuration et de relâche
des bearers. Le MME a en charge la gestion de la connexion de signalisation et de la sécurité entre
le réseau et l’UE. La gestion de connexion ou connection management est prise en charge au sein
du protocole NAS. Enfin, le MME maintien un contexte de l’UE tant que celui-ci est enregistré au
réseau. Ce contexte contient notamment les paramètres de sécurité NAS et les capacités radio et
réseau de l’UE.

2.3.3 La Packet Data Network Gateway (P-GW ou PDN-GW)

La P-GW a pour premier rôle d’allouer une adresse IP (adresse Internet Protocol) à l’UE. Elle
permet également de mettre en application la qualité de service. Elle supporte la fonction appelée
DPI ou Deep Packet Inspection ou inspection approfondie des paquets, qui analyse les paquets du
plan usager, identifie la nature des flux, applique les règles prédéfinies pour tous les clients ou par
client en fonction de l’offre souscrite. Par exemple, la P-GW peut décider de brider le débit d’un
flux de type P2P en fonction de la politique de l’opérateur ou même détecter un usage soumis à la
souscription d’une option tel que l’usage modem. La P-GW alloue ainsi des paquets IP transférés
au sein de bearer de QoS différentes et joue un rôle déterminant dans le cadre de la gestion de la
qualité de service, notamment pour les bearers à débit garanti. Par ailleurs, la P-GW permet de
mettre en œuvre la facturation par flux de données, conformément aux règles définies par le PCRF.
Enfin, elle sert de point d’ancrage pour l’interfonctionnement avec d’autres technologies non 3GPP
telles que CDMA2000 et WIMAX.

2.3.4 Le Home Subscriber Server (HSS)

Le HSS contient les informations de souscription de l’utilisateur telles que le profil de QoS de
l’abonné ou les restrictions d’accès en itinérance. Il contient également les informations concernant
les réseaux de données (PDN) auxquels l’utilisateur peut se connecter. Ces informations peuvent se
retrouver sous la forme d’un nom de point d’accès ou APN (Access Point Name) ou sous forme
d’une adresse PDN. Par ailleurs, le HSS supporte des informations dynamiques telles que l’identité

27
du MME auquel l’utilisateur est actuellement attaché. Le HSS peut aussi intégrer le centre
d’authentification ou AuC (Authentification Center) qui permet l’authentification des abonnés et
fournit les clés de chiffrement nécessaires.

2.3.5 Le Policy Control and charging Rules Function (PCRF)

Le PCRF est un nœud optionnel au sein de l’architecture EPC. Toutefois, il permet d’appliquer des
règles de gestion évoluées sur le trafic et la facturation de l’utilisateur en fonction de son offre. Pour
mettre en œuvre ces règles, il communique avec le PCEF (Policy Control Enforcement Function),
fonction intégrée à la P-GW. Par exemple, lorsqu’un utilisateur atteint le seuil de volume de données
que sa souscription lui permet de transférer, le PCRF peut communiquer au PCEF un ordre afin que
ce dernier diminue le débit de l’utilisateur. Le PCRF peut également indiquer lors de l’établissement
d’une session ou en cours de session les caractéristiques de qualité de service (QCI : QoS Class
Identifier et débits) à appliquer par le PCEF sur le flux de données. Le PCRF s’assure que le
traitement appliqué est en accord avec le profil de souscription de l’utilisateur.

2.4 Le réseau d’accès

L’architecture du réseau d’accès LTE se présente comme suit :

Figure 2.04 : Architecture LTE

L’architecture LTE est composée de stations de base appelées eNodeB exposant à l’UE les piles
protocolaires des plans usager et de contrôle sur l’interface radio. L’eNodeB est connecté à l’EPC
par l’intermédiaire de l’interface S1. Plus précisément, les flux du plan usager sont gérés par
l’interface S1-U définie entre S-GW et eNodeB tandis que les flux du plan de contrôle sont pris en
charge par l’interface S1-MME définie entre MME et eNodeB.

28
2.5 L’architecture protocolaire

L’architecture fonctionnelle LTE/EPC fait appel à différents protocoles qui sont présentés dans cette
section.

2.5.1 Le plan usager

Un paquet IP destiné à un UE est encapsulé par la P-GW et est transféré de la P-GW vers l’eNodeB
au sein d’un tunnel, avant d’être transmis par l’eNodeB à l’UE. La fonction de tunneling est assurée
par un protocole propre au 3GPP appelé GTP-U pour GPRS Tunneling Protocol - User plane. Il est
utilisé au sein des interfaces S1, S5 et S8.

Figure 2.05 : Pile protocolaire du plan usager

2.5.2 Le plan de contrôle

La pile protocolaire du plan de contrôle définie entre le MME et l’UE est présentée sur la figure
suivante.

Figure 2.06 : Pile protocolaire du plan de contrôle entre les nœuds du LTE

29
La pile protocolaire du plan de contrôle défini entre les nœuds de l’EPC est présentée sur la figure
suivante.

Figure 2.07 : Pile protocolaire du plan de contrôle entre les nœuds de l’EPC

Cette pile protocolaire fait appel au protocole GTP-C (GPRS Tunneling Protocol – Control plane).
Ce protocole est utilisé pour permettre les échanges de signalisation pendant l’établissement de
bearer EPS et pour le transfert d’informations propres à chaque UE (contexte de l’UE) lors du
changement de MME.

2.6 Le bearer EPS

L’architecture LTE/EPC requiert l’établissement d’une connexion logique entre deux points de
terminaison : P-GW et UE. Cette connexion virtuelle est appelée bearer EPS.

Le LTE supporte différents types de services tels que la voix, le streaming vidéo, le téléchargement
de données, etc. La prise en charge de ces services implique des contraintes différentes au niveau
du réseau. Par exemple, une latence et un gigue réduits sont nécessaires au bon fonctionnement du
service voix. En revanche, les contraintes de latence sont relâchées pour le téléchargement de
données, mais ce dernier requiert un taux d’erreurs plus faible. Ce concept explique la qualité de
service et est défini dans le cadre du LTE. Il a pour objectif de répondre aux contraintes de chaque
service via la définition de règles de priorité entre les flux. Au sein de l’architecture, un bearer
différent peut être associé à chaque service, avec une qualité de service spécifique. Le 3GPP a défini
deux grandes catégories de bearers :
 Les bearers avec un débit garanti ;
 Les bearers sans débit garanti.

30
Il est à noter que le débit réel peut être inférieur si la source envoie moins de données que le débit
garanti.

2.6.1 Bearer avec débit garanti

Un bearer avec débit garanti ou Guaranteed Bit Rate (GBR) est alloué principalement aux services
dits temps-réel tels que la voix ou le streaming vidéo. Toutefois, on peut aussi imaginer l’allocation
d’un bearer GBR à un service de téléchargement pour des utilisateurs ayant souscrit à des
abonnements dits premium. Au sein du réseau, une ressource est dédiée pendant toute la durée de
vie du bearer EPS avec débit garanti.

2.6.2 Bearer sans débit garanti

Les bearers sans débit garanti ou Non-Guaranteed Bit Rate (N-GBR) sont principalement alloués
aux services non temps-réel tels que le téléchargement de données. Ces bearers n’ont pas de
ressource dédiée au sein du réseau.
Deux attributs de bearers ont été définis afin que le réseau les différencie et applique la qualité de
service :
 L’identifiant de classe de service ou QCI (QoS Class Identifier)
 La priorité d’allocation et de rétention ou ARP (Allocation and Retention Priority)
Au sein du réseau d’accès, l’eNodeB gère les flux d’un bearer EPS en fonction des valeurs de ces
deux paramètres.
Un bearer EPS traverse de multiples interfaces (S5, S8, S1, radio). Pour chacune de ces interfaces,
un bearer de couche inférieure est défini : bearer S5/S8, bearer S1 et bearer radio respectivement.
Le bearer S5/S8 transporte les paquets d’un bearer EPS entre la P-GW et la S-GW. La S-GW établit
alors une simple correspondance entre le bearer S1 et le bearer S5/S8. Le bearer est identifié par
l’identifiant de tunnel GTP (GTP tunnel ID) sur ces deux interfaces. Les paquets du bearer EPS sont
alors transportés de la S-GW vers l’eNodeB sur l’interface S1, puis de l’eNodeB vers l’UE sur
l’interface radio.

2.7 Les interfaces terrestres du LTE

S1 et X2 sont les interfaces terrestres du LTE. Les sections suivantes présentent les piles
protocolaires de ces deux interfaces traitant les flux du plan usager et du plan de contrôle.

31
2.7.1 Structure protocolaire des interfaces S1 et X2

Les piles protocolaires des interfaces S1 et X2 présentent une structure similaire, représentée sur la
figure suivante.

Figure 2.08 : Structure protocolaire des interfaces S1 et X2

Cette structure est basée sur le principe que les couches et les plans sont logiquement indépendants
les uns des autres. Ce principe est déjà appliqué pour le réseau 3G. La structure protocolaire des
interfaces consiste en deux couches principales, appelées couche radio ou RNL (Radio Network
Layer). Cette structure a pour objectif de donner à la norme une grande capacité d’évolution. Les
fonctions du LTE sont réalisées au sein de la couche radio, tandis que la couche de transport
représente la technologie de transport utilisée par l’opérateur pour porter ces interfaces. En
complément, on distingue le plan usager qui s’occupe des données utilisateurs, du plan de contrôle
qui traite la signalisation.
Le réseau de transport supportant les interfaces S1 et X2 est appelé réseau de collecte mobile ou
backhaul network. Ce réseau doit être conforme à la couche de transport définie par le 3GPP. Les
piles protocolaires des interfaces S1 et X2 seront détaillées dans les sections suivantes. On peut
indiquer que les protocoles de niveau 1 (couche physique ou PHY) et de niveau 2 (couche liaison)
ne sont pas normalisés par le 3GPP. Cette ouverture laisse le choix à l’opérateur de sa technologie
de transport. Ce choix est stratégique pour l’opérateur car le réseau de collecte est un centre ce coûts
majeur.

32
Dans le cadre du déploiement des réseaux 2G et 3G, BTS et NodeB sont connectés au contrôleur de
stations de base par trois types de solution :
 Les liaisons cuivre (liaison à modulation d’impulsions codée ou liaison x-DSL) ;
 Les faisceaux hertziens ;
 Les liaisons optiques.
Etant données les performances requises pour le LTE, les technologies de transport envisagées à ce
jour sont la fibre optique et le faisceau hertzien. On peut ainsi imaginer que les eNodeB seront
connectés au réseau par l’intermédiaire de fibres optiques dans les zones urbaines et suburbaines.
Les faisceaux hertziens pourraient être éventuellement utilisés dans les zones pour lesquelles le
déploiement de fibres optiques s’avèrerait trop coûteux.
En revanche, le niveau 3 (couche réseau) est défini de manière précise avec l’utilisation du protocole
IP, ce qui constitue une rupture avec la version originale de l’UTRAN pour laquelle le protocole
ATM (Asynchronous Transfer Mode) est utilisé. Ce choix s’explique par une bonne adaptation du
protocole IP au support de services de données. Ce protocole permet notamment d’accompagner la
croissance du trafic de données à des coûts raisonnables, contrairement à la technologie ATM. Les
protocoles IPv6 et IPv4 peuvent tous deux être utilisés afin de donner le maximum de latitude aux
opérateurs.

2.7.2 L’interface S1

S1 est une interface logique définie entre eNodeB et EPC, obligatoire au sein de l’architecture
LTE/EPC. Elle est comparable en plusieurs points à l’interface Iu-PS définie pour interconnecter
l’UTRAN et le réseau cœur GPRS. L’interface S1 est présentée dans les spécifications 3GPP [19]
[20].
S1 est elle-même décomposée en deux interfaces :
 S1-U, définie entre eNodeB et S-GW, traite les flux du plan usager ;
 S1-MME, définie entre eNodeB et MME, s’occupe des flux du plan de contrôle.

2.7.2.1 Le plan usager (S1-U)

L’interface S1-U traite la transmission des paquets entre l’eNodeB et la S-GW de manière non
garantie. Elle peut être considérée comme une évolution du plan usager de l’interface Iu-PS. La pile
protocolaire de l’interface S1-U est présentée sur la figure suivante.

33
 Figure 2.09 : Pile protocolaire du plan usager de l’interface S1

La couche physique et liaison ne sont pas normalisées comme évoqué plus tôt.
La couche de transport utilise le protocole IP. Le protocole UDP (User Datagram Protocol) est utilisé
en complément. Le LTE supporte une différenciation de qualité de service. Cette dernière est assurée
par la fonction DiffServ, portée par le champ DSCP (Differentiated Service Code Point marking)
situé dans l’en-tête IP transitant sur l’interface S1-U. L’opérateur peut alors configurer au sein du
réseau de transport une correspondance entre les valeurs de QCI définies pour chaque classe de
trafic et le champ DSCP de la couche IP.
Comme sur l’interface Iu-PS, le protocole GTP-U (Gateway Tunneling Protocol-User) est utilisé en
complément de UDP/IP pour transporter les paquets du plan usager entre eNodeB et S-GW. Le
protocole GTP-U vise entre autre à garantir la transmission des paquets de manière sécurisée entre
ces nœuds, les fonctionnalités de chiffrement et de compression d’en-tête étant traitées au sein de
l’eNodeB (et non de l’EPC). Le choix de ce protocole s’explique notamment par la simplification
des procédures de mobilité avec d’autres systèmes 3GPP.
Un bearer S1 est identifié par les points de terminaison de tunnel GTP ou TEID (Tunneling End
IDentifiers) et par les adresses IP source et destination. L’adresse IP de l’eNodeB d’un bearer donné
est récupérée par la S-GW via le protocole S1-AP. Dans le sens descendant, la S-GW peut alors
envoyer à l’eNodeB les paquets associés au bearer. De la même façon, l’eNodeB obtient l’adresse
IP de la S-GW pour ce bearer dans un message S1-AP, et peut dès lors envoyer à la S-GW les
paquets associés à ce bearer.

34
2.7.2.2 Le plan de contôle (S1-MME)

Le plan de contrôle de l’interface S1 est appelé S1-MME et est défini entre l’eNodeB et le MME. Il
peut exister plusieurs interfaces logiques S1-MME entre l’EPC et un eNodeB si la fonctionnalité
S1-Flex est utilisée. Il n’existe en revanche qu’une seule interface S1-MME par couple {MME,
eNodeB}. L’établissement de cette association est à l’initiative de l’eNodeB. Les fonctions de
l’interface S1-MME sont gérées par le protocole S1-AP (S1 Application Protocol). La pile
protocolaire du plan de contrôle de l’interface S1 est représentée sur la figure 2.10.

Figure 2.10 : Pile protocolaire du plan de contrôle de l’interface S1

L’exigence de fiabilité requise pour la transmission des informations de signalisation implique

l’utilisation du protocole SCTP (Stream Control Transmission Protocol). Une seule association
SCTP peut être établie par couple {MME, eNodeB}. Cette association supporte plusieurs flux qui
peuvent être associés au traitement de procédures S1-AP génériques ou spécifiques à un UE.

Au cours de l’association SCTP :

 Une paire unique d’identifiants de flux est réservée pour l’usage des procédures élémentaires
S1-AP n’ayant pas trait à une signalisation liée à l’UE.
 Au moins une paire d’identifiants de flux est réservée à l’usage unique des procédures
élémentaires S1-AP ayant trait à une signalisation liée à l’UE.

35
  Une unique paire d’identifiants de flux est utilisée pour la signalisation associée à un UE
donné. Cette paire ne change pas pendant la durée d’un appel.
Les flux SCTP d’une même association SCTP peuvent être multiplexés au sein du protocole S1-
AP. Le protocole S1-AP gère les procédures de la couche réseau radio entre l’EPC et le LTE. Il est
aussi capable de transporter la signalisation UE-EPC de manière transparente pour l’eNodeB,
comme le protocole RRC (Radio Resource Control) sur l’interface radio.
Les fonctions traitées par le protocole S1-AP sont ainsi divisées en deux groupes :
 Les fonctions génériques, indépendantes des UE et liées aux instances de l’interface S1 dans
sa globalité ;
 Les fonctions associées à un UE.

1. Les fonctions génériques

Les fonctions génériques ont principalement trait à la gestion de l’interface S1 :
 Etablissement de l’interface S1, permettant de fournir les informations de configuration ;
 Redémarrage de l’interface S1, pour assurer une initialisation rigoureuse de l’interface ;
 Mise à jour des informations de configuration de l’eNodeB et du MME ;
 Indication d’erreur, pour traiter les cas pour lesquels un message d’échec n’est pas défini ;
 Indication de surcharge, pour informer l’eNodeB d’une situation de surcharge d’un MME.

2. Les fonctions associées à un UE

Les principales fonctions associées à un UE gérées par le protocole S1-AP sont :
 Gestion du bearer établi entre la S-GW et l’UE, incluant son établissement, sa modification
et sa relâche sur l’interface S1 ;
 Transfert du contexte initial, utilisé pour :
o Etablir un contexte de l’UE, incluant ses capacités radio et de sécurité, au sein de
l’eNodeB ;
o Etablir une connectivité IP par défaut pour l’UE (bearer EPS par défaut) ;
o Etablir un ou plusieurs bearer(s) entre la S-GW et l’UE ;
o Transférer la signalisation NAS à l’eNodeB si nécessaire ;
 Indication par l’eNodeB au MME des capacités de l’UE ;
 Mobilité de l’UE en mode connecté, lors d’un changement d’eNodeB ou de technologie
d’accès ;

36
  Transfert des messages de paging en provenance du MME, permettant de joindre l’UE,
notamment pour l’établissement d’appels entrants sur le réseau.

2.7.3 L’interface X2

La distribution des fonctionnalités du contrôleur de stations de base au sein des eNodeB implique
une connectivité accrue entre ces derniers, afin notamment d’optimiser les procédures de mobilité,
faciliter la gestion des interférences intercellulaires et mettre en œuvre certaines fonctionnalités
d’auto-optimisation au sein du réseau. Aussi les eNodeB sont-ils interconnectés via une interface
appelée X2. Cette interface n’est pas obligatoire au sein de l’architecture. Un opérateur peut ainsi
faire le choix de ne pas en implémenter s’il désire simplifier la configuration de son réseau de
transport. En cas d’absence de l’interface X2, les procédures de mobilité sont basées sur l’interface
S1, ce qui a pour effet d’allonger la durée de la procédure de handover. L’interface X2 est présentée
en détail dans les spécifications 3GPP [21] [22].
X2 est une interface logique définie entre eNodeB afin de les interconnecter. Elle est comparable en
plusieurs points à l’interface Iur définie pour interconnecter deux RNC (Radio Network Controller)
au sein de l’UTRAN. Tous les eNodeB ne peuvent être interconnectés au sein du LTE, aussi
l’interface X2 est-elle définie entre deux eNodeB voisins. Un eNodeB est considéré comme voisin
d’un autre eNodeB si au moins une cellule contrôlée par ce dernier est voisine d’une cellule
contrôlé par le premier. Deux cellules sont considérées comme voisines lorsqu’elles sont contigües.
Un même eNodeB peut naturellement être interconnecté à plusieurs autres eNodeB voisins et peut
donc accepter plusieurs interfaces X2. L’interface X2 est décomposée en deux sous-ensembles :
 L’interface X2-U, qui s’occupe des flux du plan usager ;
 L’interface X2-C, qui traite les flux du plan de contrôle.

2.7.3.1 Le plan usager (X2-U)

L’interface X2-U est définie entre deux eNodeB voisins et gère la transmission des paquets de
manière non garantie entre ces derniers. Elle peut être considérée comme une évolution du plan
usager de l’interface Iur. La pile protocolaire formant l’interface X2-U est présentée sur la figure
2.11.

37
 Figure 2.11 : Pile protocolaire du plan usager de l’interface X2

Le plan usager de l’interface X2 est contraint aux mêmes exigences que celui de l’interface S1. Les
piles protocolaires des interfaces S1-U et X2-U sont donc identiques.

2.7.3.2 Le plan de contrôle (X2-C)

Le plan de contrôle de l’interface X2 est appelé X2-C et est défini entre deux eNodeB voisins. Les
fonctions de l’interface X2-C sont supportées par le protocole X2-AP (X2 – Application Protocol).
La pile protocolaire du plan de contrôle de l’interface X2 est représentée sur la figure suivante :

Figure 2.12 : Pile protocolaire du plan de contrôle de l’interface X2

Le plan de contrôle de l’interface X2 est contraint aux mêmes exigences que celui de l’interface S1.
Les piles protocolaires des interfaces S1-MME et X2-C sont identiques, à l’exception des protocoles
S1-AP et X2-AP. Le protocole SCTP est utilisé pour convoyer les messages du protocole X2-AP.

38
Il n’existe qu’une seule association SCTP établie entre une paire eNodeB/eNodeB. L’établissement
de l’association SCTP peut être démarré par n’importe quel eNodeB. Dans l’association SCTP d’une
paire d’eNodeB, la gestion des identifiants est similaire à celle utilisée sur l’interface S1. Le
protocole X2-AP permet de réaliser toutes les procédures de la couche réseau radio entre une paire
d’eNodeB. Comme pour S1-AP, les fonctions assurées par la couche X2-AP sont divisées en deux
groupes :
 Les fonctions génériques, indépendantes des UE et liées aux instances de l’interface X2 dans
sa globalité ;
 Les fonctions associées à un UE.

1. Les fonctions génériques

Les fonctions génériques ont principalement trait à la gestion de l’interface X2 :
 Etablissement de l’interface X2, permettant de fournir les informations de configuration ;
 Redémarrage de l’interface X2, pour garantir son initialisation rigoureuse ;
 Mise à jour des informations de configuration des eNodeB ;
 Indication d’erreur, pour traiter les cas pour lesquels un message d’échec n’est pas défini ;
 Echange d’indicateurs relatifs à la gestion des interférences intercellulaires.
2. Les fonctions associées à un UE
La principale fonction associée à un UE prise en charge par le protocole X2-AP est la gestion de la
mobilité. Elle permet à l’eNodeB de transférer à l’eNodeB cible le contexte de l’UE et les données
du plan usager. En cas d’absence de l’interface X2, la mobilité de l’UE est basée uniquement sur
les procédures de l’interface S1.

2.8 L’interface radio

L’interface radio assure le rôle clé de transférer par la voie des airs les données issues de la couche
IP associées au service demandé par l’utilisateur. Ce transfert doit respecter des exigences de qualité
de service (latence, débit) malgré un médium extrêmement variable, tout en optimisant l’accès à une
ressource spectrale limitée. En outre, la disponibilité du spectre impose de pouvoir s’adapter à
différents types de bandes disponibles.

Plan usager et plan de contrôle

Ces deux plans sont matérialisés par des piles protocolaires qui partagent un tronc commun et qui
se distinguent notamment dans les interactions avec les couches supérieures : alors que la

39
signalisation NAS est véhiculée par le plan de contrôle de l’interface radio, son plan usager permet
de transporter sur celle-ci les paquets délivrés ou à destination de la couche IP. Ces deux piles
protocolaires sont représentées sur la figure suivante.

Figure 2.13 : Piles protocolaires des plans usager et de contrôle sur l’interface radio

En LTE comme en GSM et UMTS, les protocoles du plan usager de l’interface radio correspondent
aux deux premières couches du modèle OSI (Open Systems Interconnection). La structure de
l’interface radio du système LTE possède de nombreuses similitudes avec celle définie pour
l’UMTS, comme le montre la figure 2.14 suivante.

Figure 2.14 : Piles protocolaires des interfaces radio en UMTS et en LTE

40
La principale différence réside dans le rôle de la couche PDCP (Packet Data Convergence Protocol).
En UMTS, son unique rôle est de réaliser une compression d’en-tête des paquets IP. En LTE en
revanche, le protocole PDCP est utilisé systématiquement, car il est impliqué dans la sécurité de
l’Access Stratum (chiffrement et intégrité). On notera cependant que toutes ces couches, si elles
portent le même nom en UMTS et en LTE, sont néanmoins très différentes dans ces deux systèmes.
Les données traitées par PDCP, RLC (Radio Link Control), MAC (Medium Access Control) et PHY
appartiennent :
 Au plan de contrôle lorsqu’il s’agit de données de signalisation communiquées par la couche
RRC ;
 Au plan usager lorsqu’il s’agit d’autres données (transmises par la couche IP).
Les notions de plan de contrôle et de plan usager sont transparentes aux couches RLC, MAC et
PHY : celles-ci traitent les données délivrées par la couche supérieure, suivant la configuration
indiquée par RRC, sans distinction à priori entre données de contrôle et données de l’usager. Nous
verrons plus loin que le traitement effectué par PDCP diffère en revanche suivant la nature des
données reçues.
Indépendamment de ces deux plans, chaque couche utilise dans son protocole des informations de
contrôle qu’elle échange avec l’entité paire distante, dans l’en-tête ajouté par la couche à l’unité de
donnée. Cela permet à l’entité paire distante de traiter les données transmises de façon appropriée.
Il s’agit donc d’informations de contrôle propres à la couche.

2.9 Conclusion

Ce chapitre nous a permis de voir les éléments et entités constitutifs du réseau LTE/EPC, ainsi que
le rôle de chacun dans le réseau. Il a aussi été vu sur certains points les différences et évolutions
qu’ont apportées l’architecture LTE/EPC par rapport à ses prédécesseurs, notamment l’UMTS et le
GPRS, autant dans le domaine fonctionnel que protocolaire.
L’architecture LTE/EPC a été présenté en vue de définir une notion de base sur les réseaux de
quatrième génération de type LTE/EPC. Ce chapitre sera déterminant car la suite des explications
concernant le mécanisme de priorisation de flux qu’est la qualité de service se passera au niveau des
différents éléments précédemment développés.
Le prochain chapitre entrera dans le vif du sujet qui n’est autre que la notion de qualité de service
en LTE/EPC et présentera ses principes généraux.

41
 CHAPITRE 3
QUALITE DE SERVICE EN LTE/EPC

3.1 Introduction

La qualité de service en réseau LTE/EPC se traduit techniquement par des systèmes et mécanismes
permettant d’offrir à chaque type de service ses propres exigences afin que l’utilisateur final soit
satisfait de l’utilisation de ces services. Ces mécanismes intègrent différents processus et notions
qui feront l’objet de ce chapitre.
Quand l’UE procède à son enregistrement sur le réseau LTE, cet enregistrement lui fournit
immédiatement une connectivité IP au PDN choisi. L’UE peut ainsi utiliser cette connectivité par
défaut pour transmettre et recevoir des données. Pour établir un appel avec une qualité de service
spécifique (par exemple, un appel VoIP), l’UE doit cependant lancer une procédure
complémentaire. Nous présenterons tout d’abord dans ce chapitre les notions de bearer et de bearer
EPS, déjà évoquées dans le chapitre précédent. Les concepts de bearer EPS par défaut et bearer EPS
dédié, propres au LTE, seront également présentés afin d’identifier leurs particularités. Nous
décrirons enfin les paramètres et la politique de gestion de la QoS normalisée par la 3GPP dans la
version 10 du réseau LTE.

3.2 La notion de bearer

Dans tout réseau, les ressources de traitement au sein des nœuds sont limitées et partagées entre les
utilisateurs. Selon la nature et la technologie du réseau, l’accroissement de ces ressources par
l’opérateur peut être complexe et coûteux. Dans un réseau mobile par exemple, la ressource radio
(spectre) est particulièrement onéreuse. Cette préoccupation a conduit à considérer des mécanismes
optimisant l’utilisation de ces ressources sur l’interface radio, mais également sur les autres
interfaces du réseau impliquées dans le plan usager UE – réseau. Ces mécanismes de Qualité de
service (ou QoS pour Quality of Service) visent à offrir à l’utilisateur le service demandé avec une
qualité satisfaisante, tout en minimisant les ressources utilisées pour y parvenir.

La figure 3.01 suivante illustre l’importance de tels mécanismes. Dans cet exemple, l’UE2 a un
appel voix en cours, avec un débit assez stable. L’UE1 navigue sur Internet et démarre un
téléchargement. En l’absence de mécanisme approprié de partage de ressources, l’UE1
monopoliserait à partir de cet instant la bande passante du système, privant l’UE2 de ressources

42
pour recevoir des données. En revanche, en autorisant un débit instantané maximal à l’UE1 et en
garantissant un débit minimal à l’UE2 pour son appel voix, le trafic de l’UE1 sera lissé, tandis que
l’UE2 pourra recevoir des données au rythme auquel elles sont produites, sans subir les variations
de débit de l’UE1.

Figure 3.01 : Besoin de mécanismes de QoS lors d’un accès à des ressources partagées

Pour affecter efficacement des ressources aux besoins d’un appel, la notion de bearer a été introduite
dans les Télécommunications, dès la conception du système GSM. Un bearer peut être vu comme
un tuyau entre deux entités du réseau qui communiquent entre elles sur une interface, tuyau dont
certaines caractéristiques sont négociées entre ces entités lors de son établissement et qui permet le
transfert de données. Le concept de bearer est ainsi décliné sur les interfaces du réseau dont les
ressources doivent être économisées, et en particulier sur :
 L’interface radio, entre l’UE et l’eNodeB ;
 L’interface S1 entre E-UTRAN et le réseau cœur ;
 Les interfaces du réseau cœur.

43
Les bearers de ces interfaces forment un bearer agrégé, entre l’UE et le réseau cœur : le bearer EPS
(ou EPS bearer).

3.2.2 Le bearer EPS

La connectivité à un réseau de données via l’E-UTRAN et l’EPC est assurée par un bearer EPS.
Celui-ci porte des flux de trafic qui doivent recevoir un même traitement de QoS entre l’UE et la P-
GW. Il est constitué des éléments suivants :
 Le radio bearer sur l’interface Uu, entre l’UE et l’eNodeB ;
 Le bearer S1, entre l’eNodeB et la S-GW (interface S1-U) ;
 Le bearer S5/S8, entre la S-GW et la P-GW.

Le radio bearer et le bearer S1 forment en outre une connexion logique entre l’UE et la S-GW : l’E-
RAB (pour E-UTRAN Radio Access Bearer), qui constitue un élément agrégé du bearer EPS. L’E-
RAB est tout à fait comparable dans son principe au RAB défini en UMTS entre l’UE et le SGSN
(Serving GPRS Support Node).
Enfin, l’association du bearer EPS et du bearer sur le réseau de données externe fournit le support
de bout-en-bout pour le service.

Ces éléments et les entités du réseau qui les portent sont représentés sur la figure suivante.

Figure 3.02 : Le bearer EPS dans le système LTE/EPC

En outre, un bearer EPS est caractérisé par des paramètres protocolaires, qui permettent le routage
de bout-en-bout des données transmises sur ce bearer, mais également par des paramètres de Qualité
de Service. Nous détaillerons les principaux paramètres dans la suite de ce chapitre.
Un radio bearer de données transporte les paquets de données d’un bearer EPS entre l’UE et
l’eNodeB. Pour un bearer EPS établi, il existe un seul radio bearer de données, parfois désigné par

44
la forme abrégée DRB, pour Data Radio Bearer, par opposition aux radio bearers de signalisation
(SRB pour Signaling Radio Bearer), utilisés aussi sur l’interface radio mais pour le transport des
messages RRC et NAS. Un DRB est établi par la procédure de reconfiguration de la connexion
RRC.
Le radio bearer est formé des éléments suivants :
 Un canal logique de données DTCH (Dedicated Traffic CHannel) pour un DRB, ou un canal
logique de signalisation DCCH (Dedicated Control CHannel) pour un SRB ;
 Une configuration PDCP, pour la compression d’en-tête (pour un DRB), la protection des
unités de données (pour un DRB ou un SRB) et la gestion des données lors du handover
(pour un DRB) ;
 Une configuration RLC, pour le paramétrage des acquittements en mode RLC-AM
notamment ;
 Une configuration MAC, qui indique notamment le groupe auquel appartient le radio bearer
pour le Buffer Status Report.

Ces paramètres de configuration sont déterminés par l’eNodeB en fonction des capacités du terminal
et des caractéristiques du bearer EPS communiquées par le MME.
Enfin, l’établissement d’un bearer EPS implique nécessairement la création d’un contexte de bearer
EPS au sein du MME, de la P-GW, de la S-GW et de l’UE. Ce contexte associé au bearer EPS
demeure actif dans ces équipements lorsque les bearers des interfaces radio et S1 sont relâchés sans
désactivation explicite du contexte de bearer EPS. Les terminaisons de tunnel GTP sur la S-GW et
la P-GW sont maintenues dans ce cas, avec le contexte EPS. Ce contexte de bearer EPS est similaire
au contexte PDP (Packet Data Protocol) utilisé en GPRS et UMTS, qui peut subsister alors que le
Radio Access Bearer (RAB) est relâché.

Lors de l’établissement d’une connexion logique sécurisée entre l’UE et le MME, un contexte radio
est créé au sein de l’eNodeB pour l’UE, à l’initiative du MME. Ce contexte contient des données
sur les bearers actifs de l’UE (DRB notamment), la connexion RRC, la mobilité de l’UE et la
sécurisation AS établie avec l’UE. Il est transmis à l’eNodeB cible lors d’un handover LTE. Il ne
s’agit pas d’un contexte de bearer EPS.

45
3.2.3 Bearer par défaut et bearer dédié

Le préalable à l’application de mécanismes de Qualité de service répondant aux besoins spécifiques

de chaque type de trafic est d’identifier et traiter distinctement des flux dont les caractéristiques et
les contraintes diffèrent de façon notable. Les concepts de bearer EPS par défaut et de bearer EPS
dédié ont été définis dans cette optique.

3.2.3.1 Le bearer par défaut (connectivité générique)

Pour accéder au service de transport de données fourni par le réseau mobile, l’UE doit demander
une connectivité vers le réseau de données PDN auquel il souhaite accéder (par exemple Internet).
Une connectivité PDN est établie lors de la procédure d’enregistrement au réseau. Elle est assurée
par l’activation d’un contexte EPS et l’établissement conjoint d’un bearer EPS par défaut,
permettant à l’UE d’échanger des données avec un réseau PDN immédiatement après son
enregistrement au réseau. L’intérêt de cette connectivité initiale est de réduire le délai d’accès aux
services de données et de rapprocher l’expérience utilisateur sur le réseau mobile de celle offerte
sur les réseaux d’accès fixe de type ADSL (Asymmetric Digital Subscriber Line) tant que l’UE est
enregistré au réseau (connectivité always-on). C’est une nouveauté par rapport au système UMTS,
dans lequel l’UE doit réaliser les procédures d’enregistrement au réseau et d’établissement du
contexte PDP de façon séquentielle. L’UE doit ainsi attendre la fin de cette seconde procédure pour
pouvoir échanger des données sur le plan usager, avec le réseau de données associé à l’APN
demandé.

On notera que le bearer EPS peut être relâché sans que le contexte EPS associé soit désactivé, par
exemple lorsque l’eNodeB décide de relâcher la connexion RRC sur inactivité, ou après une perte
de couverture. Ce comportement est identique à la gestion du RAB et du contexte PDP en UMTS,
ce dernier pouvant être maintenu alors que l’UE passe en mode veille. Cette connectivité always-
on est déjà mise en œuvre aujourd’hui par des terminaux de type smartphone, qui activent une
session de données en tâche de fond, après l’enregistrement au réseau, pour pouvoir recevoir des
notifications utilisées par certaines applications.

La connectivité PDN par défaut est générique : ses caractéristiques (APN, QoS) sont identiques pour
un grand nombre, voire pour tous les utilisateurs du réseau. La notion d’APN, héritée du réseau
cœur paquet GPRS, est déjà utilisée dans les technologies d’accès GPRS et UMTS. L’APN et les

46
paramètres de QoS du contexte de bearer EPS par défaut sont determinés par le profil de souscription
de l’abonné au sein du HSS. L’opérateur peut donc envisager d’utiliser un paramétrage différent
selon le type d’abonné. Le choix de l’opérateur de l’APN par défaut doit être judicieux, puisqu’il
peut déterminer les premiers services accessibles au client dès l’enregistrement du terminal au
réseau.

Un même PDN peut être associé à plusieurs APN. Par exemple, on peut imaginer un accès aux
plates-formes de services de l’opérateur mobile via deux APN différents, l’un dédié aux services
grand-public et l’autres aux services entreprises, avec toutefois un contrôle d’accès et une politique
tarifaire différents. Un APN dédié peut aussi être utilisé pour l’accès au réseau privé d’une
entreprise, par exemple.

La figure suivante illustre une configuration possible d’APN et de réseaux PDN associés.

Figure 3.03 : APN et réseaux PDN

Si l’UE a besoin d’établir une connectivité PDN vers un autre APN que celui choisi par défaut par
le réseau, il lance une nouvelle demande de connectivité en précisant l’APN souhaité. Un nouveau
bearer EPS par défaut est alors établi entre l’UE et la P-GW qui gère cet APN, si toutefois l’abonné

47
est autorisé à accéder à ce dernier. Cela peut être nécessaire pour que l’UE accède à un autre réseau
de données : par exemple vers Internet, alors que l’UE dispose d’une connectivité vers son réseau
d’entreprise. Cependant, ces connectivités sont indépendantes et à tout moment, l’UE ou le réseau
peut en relâcher une sans affecter l’autre.
Afin d’optimiser l’usage des ressources dans le réseau, la QoS associée au bearer par défaut est
relâchée, car ce bearer porte typiquement des flux http sans contrainte forte de délai ou de débit.

3.2.3.2 Le bearer dédié (besoin de QoS spécifique)

Au cours d’un appel ou d’une session de données, l’usage de l’utilisateur peut évoluer : par exemple,
il peut lancer une vidéo à la demande alors qu’il navigue sur le portail de l’opérateur. De même,
l’application qu’il utilise peut offrir des services très différents : par exemple, une suite de
communication lui permettant de partager des documents avec son correspondant pendant l’appel
ou de réaliser une visioconférence.

De ce fait, les besoins de QoS peuvent varier pendant un même appel. Le réseau doit donc être
capable d’adapter rapidement les ressources utilisées dans le réseau et sur l’interface radio. Cette
adaptation peut être faite de sa propre initiative (il détecte un nouveau type de flux) ou suite à une
demande de l’UE, lorsque l’utilisateur lance un service nécessitant une QoS spécifique. Pour cela,
le réseau enrichit d’un nouveau bearer la connectivité PDN existante. Différent du bearer par défaut
établi lors de la demande de connectivité, il sera dédié à ces nouveaux flux, pour lesquels la QoS du
bearer par défaut n’est plus suffisante.

Le bearer EPS dédié vise ainsi à assurer une QoS spécifique à certains flux applicatifs avec le même
réseau PDN et le même APN que le bearer EPS par défaut. Un bearer EPS dédié est en effet toujours
associé à une connectivité existante et donc à un bearer EPS par défaut. Une fois qu’il est établi,
l’UE et le réseau partagent donc deux bearers EPS sur la même connectivité PDN.

Il est alors nécessaire d’identifier les flux de trafic afin de les orienter sur ce bearer dédié et de leur
fournir la QoS associée. Pour ce faire, l’UE et le réseau déterminent des filtres de trafic, appliqués
dans le sens montant et descendant aux données à transmettre, dès que le bearer EPS dédié est établi.
Chaque filtre indique des caractéristiques protocolaires spécifiques à un flux qui utilisera ce bearer.

48
Un filtre caractérise donc un flux de trafic du bearer dédié et est défini par les éléments suivants :
 Une adresse IPv4 ou IPv6 distante ;
 L’identifiant du protocole de transport utilisé (TCP ou Transmission Control Protocol,
UDP) ;
 Un numéro ou une plage de numéros de ports (par exemple, le port 554 couramment utilisé
pour le protocole de streaming RTSP (Real Time Streaming Protocol) sur UDP ou TCP, ou
la plage de ports UDP 1024 à 65535 pour le protocole RTP : Real-time Transport Protocol) ;
 La valeur du paramètre « Type of Service » qui sera utilisée dans les en-têtes des paquets IP
associés au flux de trafic ;
 La valeur du paramètre IPv6 « Flow Label », utilisé typiquement pour différencier plusieurs
flux IPv6 partageant le même couple d’adresses source et destinataire ;
 Une priorité associée au filtre ;
 Et si le protocole IPsec est utilisé : le paramètre SPI (Security Parameter Index) identifiant
le contexte de sécurité associé au flux.

L’ensemble des filtres de trafic définis pour un bearer EPS dédié constitue un masque de trafic,
appelé Traffic Flow Template (TFT). Les flux qui satisfont à l’un des filtres du TFT bénéficieront
donc de la même QoS. Les filtres dédiés au sens montant sont utilisés par l’UE lorsqu’il doit
transmettre des données, tandis que la P-GW se base sur les filtres définis pour le sens descendant
pour orienter les données sur le bearer approprié. Pour un même flux, les filtres de trafic sur l’UE
et sur la P-GW diffèrent au moins par l’adresse IP destination. Les filtres de trafic sont une
particularité du bearer dédié et ne sont pas utilisés pour un bearer par défaut.

Lorsqu’il demande l’établissement d’un bearer dédié sur une connectivité PDN existante, l’UE
indique l’identifiant du bearer par défaut associé à la connectivité PDN, la QoS souhaitée et le ou
les filtres de trafic des flux associés au nouveau bearer. L’UE peut également indiquer dans ce
message des options de configuration protocolaire, par exemple pour échanger avec la P-GW des
informations liées au protocole d’authentification applicative, demander le MSISDN (Mobile
Station ISDN Number) si celui-ci n’est pas enregistré dans l’USIM (Universal Subscriber Identity
Module), ou encore obtenir l’adresse du serveur DNS (Domain Name Server). Dans sa réponse, le
réseau retourne un identifiant pour le nouveau bearer EPS, la QoS accordée, égale ou inférieure à
celle demandée par l’UE, et les filtres de trafic déterminés par la P-GW.

49
Ensuite, lorsqu’un paquet de données est créé et délivré pour transmission sur la voie montante,
l’UE compare les informations présentes dans les en-têtes IP et TCP/UDP du paquet avec le filtre
ayant la priorité la plus élevée parmi l’ensemble des filtres définis pour les différents bearers. Si le
paquet ne correspond pas à ce premier filtre, il procède de même avec le filtre de priorité
immédiatement inférieure et ainsi de suite. Lorsqu’une correspondance est trouvée, le paquet est
transmis sur le bearer EPS associé au filtre. Si, au contraire, le paquet ne se conforme à aucun des
filtres définis, il est transmis sur le bearer par défaut de la connectivité PDN : ainsi, le bearer par
défaut d’une connectivité PDN n’a pas de filtre de trafic et reçoit le trafic résiduel de cette
connectivité.

La figure suivante illustre l’application d’un filtre TFT par la P-GW et l’UE, afin d’orienter les
données du flux vidéo sur le bearer EPS dédié et les flux web sur le bearer EPS par défaut.

Figure 3.04 : Utilisation des TFT en UL et DL pour le multiplexage des données sur le plan
usager

Au niveau de l’UE, seuls les paquets de données destinés à une transmission sur la voie montante
passent dans le masque de trafic de l’UE UL TFT1, pour les orienter sur le bearer EPS adéquat ; les
données reçues de la P-GW sont, elles, remises l’application en fonction du bearer EPS par lequel
elles sont portées. Les flux web des applications « actu » et « météo » correspondent typiquement à

50
des requêtes http, portées sur TCP, vers le portail web de l’opérateur, tandis que le flux de l’appel
vidéo consiste en paquets destinés à l’UE distant et produits par le codec vidéo (par exemple H264
sur RTP/UDP). De façon similaire, la P-GW ne compare que les données pour la voie descendante
aux masques de trafic DL TFT1 et DL TFT2, et les données reçues de l’UE sont directement routées
vers l’entité distante désignée par l’adresse IP destination.

Le système LTE/EPC, par l’intermédiaire de la P-GW, peut prendre l’initiative d’établir un bearer
EPS dédié sans demande préalable de l’UE, par exemple s’il détecte un nouveau flux qui devrait,
dans la politique de l’opérateur, bénéficier d’un traitement spécifique en termes de QoS notamment.
C’est par exemple le cas si l’utilisateur, en naviguant sur le portail de l’opérateur, ouvre un contenu
vidéo ou audio en streaming. L’opérateur peut en effet faire le choix de différencier ce flux du trafic
de navigation alors que l’UE ne demande pas de QoS spécifique. De cette façon, l’application de la
politique de QoS de l’opérateur n’est pas dépendante de l’implémentation des terminaux.

On notera que les notions de bearer par défaut et bearer dédié ne sont pas connues de l’E-UTRAN :
l’eNodeB reçoit les mêmes paramètres lors de l’établissement de ces bearers et seules leurs valeurs
déterminent une différence de traitement des flux par l’eNodeB.
Comme nous le verrons par la suite, les caractéristiques des flux de trafic peuvent évoluer au fil de
l’appel. Ainsi, de nouveaux flux peuvent être ouverts, avec des besoins de QoS spécifiques, ou
simplement des paramètres protocolaires différents des flux existants. Par exemple, l’application
peut initier un flux utilisant des ports TCP différents, ou nécessitant un débit garanti qui n’est pas
assuré par un bearer EPS déjà établi pour la connectivité au PDN. Selon la nature de ces besoins et
les choix de l’opérateur, cette évolution des flux peut donc conduire à modifier les filtres de trafic
du bearer EPS dédié, sa QoS, ou à établir un nouveau bearer EPS dédié.

3.3 Les paramètres de QoS

Un bearer est décrit par un ensemble de paramètres qui s’appliquent à l’interface ainsi qu’aux
équipements qui le gèrent. On peut les regrouper en deux catégories : les paramètres de transport
(adresse IP, point de terminaison…) et les paramètres de QoS (latence, débit, taux d’erreur).

Certaines applications nécessitent un débit garanti par le réseau, par exemple une session de
streaming vidéo ou un appel voix. Le bearer EPS associé doit alors garantir ce débit. On fait

51
référence à un bearer GBR (Guaranteed Bit Rate), lorsque des ressources sont allouées de façon
persistante au sein du réseau pour ce bearer, ou à un bearer non-GBR sinon. Un bearer par défaut
est toujours un bearer non-GBR, tandis qu’un bearer dédié peut être GBR ou non-GBR.
La QoS du bearer EPS est caractérisée par des paramètres que nous présenterons de manière
détaillée dans les sections suivantes :
 La classe (ou label), appelée QoS Class Identifier (QCI) ;
 La priorité d’allocation et de rétention ou Allocation and Retention Priority (ARP) ;
 Le débit garanti ou Guaranteed Bit Rate (GBR), si applicable ;
 Le débit maximal ou Maximal Bit Rate (MBR).

Par ailleurs, le réseau indique à l’UE des débits maximaux agrégés sur plusieurs bearers EPS : il
s’agit des paramètres APN-AMBR (Access Point Name-Agregated Maximum Bit Rate) et UE-
AMBR (User Equipment- Agregated Maximum Bit Rate) décrits dans la suite. Ces paramètres sont
donc communs à un ensemble de bearers EPS.

3.3.1 Le QoS Class Identifier (QCI)

Le QCI est un paramètre défini au sein du système LTE/EPC pour différencier les Qualités de
Service entre les flux de services différents. L’UE et les nœuds du réseau tels que l’eNodeB, la S-
GW, la P-GW déterminent le traitement à appliquer aux paquets de données d’un bearer EPS en
fonction de la valeur de QCI définie pour ce bearer.
Neuf QCI sont identifiés dans la norme 3GPP, chacun étant défini par les caractéristiques suivantes :
 Le type de ressource (GBR/non-GBR) ;
 La priorité ;
 Le délai de transmission au sein du système LTE ;
 Le taux d’erreur résiduel.

L’objectif de ces QCI normalisés est d’assurer que les services reçoivent le même niveau de QoS
de bout-en-bout dans un environnement impliquant plusieurs constructeurs d’infrastructure. Par
exemple, le traitement appliqué par un eNodeB doit être cohérent avec celui appliqué par la S-GW
et la P-GW, sous peine de ne pas respecter les contraintes de qualité liées au service. Le tableau
suivant décrit les caractéristiques des QCI normalisés.

52
 Taux
Type de Délai de
QCI Priorité d’erreur Exemples d’utilisation
ressource transmission
résiduel
1 2 100 ms 10-2 Voix
2 4 150 ms 10-3 IPTV, Streaming vidéo
GBR
3 3 50 ms 10-3 Jeu interactif
4 5 300 ms 10-6 Vidéo à la demande
1 100 ms 10-6 Signalisation IMS (IP Multimedia
5
Subsystem)
Vidéo à la demande, services basés
sur TCP (navigation web, courriel,
6 6 300 ms 10-6
chat, FTP, transfert de fichier, peer-
N-GBR to-peer…)
7 7 100 ms 10-3 Voix, streaming video, jeu interactif
Bearer EPS par défaut pour les
8 8 300 ms 10-6
abonnés premium ou privilégiés
Bearer EPS par défaut pour des
9 9 300 ms 10-6
abonnés non premium

Tableau 3.01: Tableau de correspondance des paramètres QCI

Ces caractéristiques ne sont pas transmises explicitement dans la signalisation entre les
équipements ; seules les valeurs de QCI le sont. Si le tableau précédent des QCI normalisés est
utilisé dans le réseau de l’opérateur, les équipements feront la même correspondance entre QCI et
caractéristiques de QoS. Ces QCI sont cependant indicatifs et l’opérateur peut en utiliser d’autres,
ou associer d’autres valeurs aux QCI 1 à 9 et ainsi définir sa propre table de QCI, configurée au sein
des équipements qui traiteront les flux de données (eNodeB, S-GW, P-GW).

La priorité indiquée dans ce tableau fait référence à la priorité de traitement au sein des équipements
associés au QCI.

Le paramètre délai de transmission ou Packet Delay Budget (PDB) définit la limite de délai pour la
transmission des données entre l’UE et la P-GW. Pour un QCI donné, la valeur du PDB s’applique

53
dans les sens montant et descendant. Le PDB est ainsi destiné à aider les nœuds transmettant les
données du plan usager dans leurs fonctions d’ordonnancement et de configuration des couches de
liaisons de données (niveau 2 du modèle OSI). Au sein de l’eNodeB par exemple, le PDB peut être
pris en compte dans le cadre de la fonction de scheduling des données sur l’interface radio et du
paramétrage des couches RLC et MAC (nombres maximaux de retransmissions HARQ - Hybrid
Automatic Repeat reQuest - et RLC autorisées, configuration des retransmissions RLC, débit PBR
ou Prioritized Bit Rate).
Le PDB constitue une valeur limite souple : si le délai de certains paquets de données dépasse le
PDB, ils ne sont pas nécessairement supprimés. Il est toutefois attendu que les unités de données
seront pour la plupart délivrées avec un délai bien inférieur à ce seuil. Le PDB doit être interprété
ainsi : « 98% des unités de données sont transmises avec un délai inférieur ou égal à la valeur du
PDB ». Dans certains cas de congestion cependant, cet objectif peut ne pas être atteint.
La contribution essentielle au PDB provient de l’interface radio, alors que le transit sur le réseau de
l’opérateur (entre l’eNodeB et la P-GW) est de l’ordre d’une dizaine de millisecondes. Cependant,
ce délai entre l’eNodeB et la P-GW peut varier suivant la situation de l’UE et la stratégie de
l’opérateur : en cas d’itinérance internationale par exemple, et si l’opérateur d’origine fait le choix
de faire transiter les données par son réseau, le trafic à destination de l’UE transitera donc par la P-
GW du réseau d’origine avant d’atteindre le réseau visité ou VPLMN (Visited Public Land Mobile
Network). Le délai entre la P-GW et l’eNodeB pourra par exemple dépasser 50 ms pour une
itinérance intercontinentale et n’inclut donc pas le délai de transmission sur l’interface radio. On
comprend que certains services comme le jeu interactif peuvent être difficiles à assurer dans ce type
de scénario.

Le paramètre taux d’erreur résiduel ou Packet Error Loss Rate (PELR) désigne le taux d’erreur sur
la transmission des unités de données de niveau 2, par exemple le taux de paquets IP traités au sein
du réseau mais qui n’ont pu être délivrés à la couche PDCP de l’UE. Pour un QCI donné, la valeur
du PELR s’applique dans les sens montant et descendant. On notera que cet objectif de fiabilité
dans la transmission des données n’est pas forcément atteint en cas de congestion. L’objet du PELR
est de permettre une configuration appropriée des couches de liaisons de données (par exemple RLC
et MAC dans l’E-UTRAN). Le taux d’erreur entre l’eNodeB et la P-GW est considéré comme
négligeable (hors cas de congestion) ; le PELR s’applique donc essentiellement à l’interface radio,
entre UE et eNodeB.

54
3.3.2 L’Allocation and Retention Priority (ARP)

 Principe

Le paramètre ARP (Allocation and Retention Priority) a pour but de déterminer dans une situation
de congestion si l’établissement du bearer EPS peut être accepté, aux dépens d’un autre bearer déjà
établi, ou doit être rejeté. Il existe déjà en UMTS, pour le même usage.

L’ARP est constitué des éléments suivants :

 Le niveau de priorité (grandeur numérique de 1 à 15, 1 étant le niveau de priorité le plus
élevé) ;
 La capacité de préemption (valeur binaire : oui/non) ;
 La vulnérabilité à la préemption (valeur binaire : oui/non).

Le niveau de priorité permet, dans une situation de limitation des ressources, d’assurer que le bearer
de plus haute priorité sera établi. Par ailleurs, l’ARP peut être utilisé en cas de restriction de
ressources pour décider de relâcher un ou plusieurs bearers(s) EPS au profit d’un nouveau bearer de
plus haute priorité : il s’agit du mécanisme de préemption. La capacité de préemption indique si
l’établissement du bearer peut conduire à la relâche d’un bearer de plus faible priorité, pour libérer
les ressources nécessaires, si toutefois ce bearer moins prioritaire est vulnérable à la préémption.

L’opérateur peut décider d’attribuer les mêmes paramètres de préemption à tous les abonnés pour
un même QCI. Ils ne seront différents dans ce cas qu’entre des QCI différents. On peut aussi
imaginer d’utiliser ces paramètres de préemption pour différencier des classes d’abonnés, pour le
même QCI et la même priorité :
 Abonné « gold » : catégorie d’abonnés qui peuvent préempter et ne peuvent pas être
préempté ;
 Abonné « silver » : catégorie d’abonnés qui peuvent préempter et peuvent être préempté ;
 Abonné « bronze » : catégorie d’abonnés qui ne peuvent pas préempter et peuvent être
préempté.

55
L’ARP n’est utilisé que lors du contrôle d’admission et il n’influence pas le traitement des données
une fois le bearer établi. Les mécanismes de scheduling ou de contrôle de débit implémentés au sein
de l’eNodeB n’intègrent pas ce paramètre. Enfin, l’ARP est un paramètre interne au réseau de
l’opérateur et n’est pas communiqué à l’UE.

3.3.3 Les paramètres de débit

3.3.3.1 Le Guaranteed Bit Rate (GBR)

Le paramètre GBR caractérise le débit qui est offert par un bearer GBR. Ce débit est garanti, ce qui
signifie qu’il ne peut être inférieur au GBR.
Un GBR est défini par exemple pour un bearer EPS portant un service de streaming ou de VoIP. Le
débit réel peut cependant être inférieur au GBR si les sources (UE et serveurs) fournissent des
données à un rythme moins élevé. Lors d’un appel VoIP via l’IMS, l’UE ou le réseau peut prendre
l’initiative de modifier le codec utilisé et le GBR associé, pour s’adapter à l’évolution des conditions
radio, par exemple en cas de changement de RAT (Radio Access Technology).

En cas de congestion, l’équipement réseau priorise les paquets des bearers GBR par rapport aux
bearers non-GBR, afin d’assurer le GBR malgré la situation de surcharge. Par ailleurs, le
constructeur met souvent en place un mécanisme de contrôle d’admission qui assure qu’un bearer
GBR admis verra systématiquement son débit GBR respecté.

En LTE, l’eNodeB ne peut pas négocier la QoS lors de l’établissement du bearer EPS, ni demander
de modification du bearer EPS en cours de session. De ce fait, si l’eNodeB ne peut plus assurer le
GBR, il doit alors demander au MME la désactivation du bearer EPS.

3.3.3.2 Le Maximal Bit Rate (MBR)

Le paramètre MBR désigne le débit maximal autorisé sur le bearer EPS. Si le débit instantané
mesuré par un équipement du plan usager dépasse le MBR, cet équipement peut effectuer un lissage
du débit en supprimant des paquets, afin de respecter ce seuil. Ce lissage de trafic sera typiquement
réalisé par l’eNodeB dans le sens montant et par la P-GW dans le sens descendant. En Release 8, la
norme impose que le MBR soit toujours égal au GBR lorsque ce dernier est utilisé. Cela peut
nécessiter de surévaluer légèrement le GBR pour éviter le phénomène de lissage.

56
3.3.3.3 Les débits agrégés (UE-AMBR et APN-AMBR)

Des paramètres de QoS agrégés sont définis pour un ensemble de bearers EPS : il s’agit du débit
maximal agrégé par APN appelé APN-Agregated Maximum Bit Rate (APN-AMBR) et du débit
maximal agrégé par UE ou UE-Agregated Maximum Bit Rate (UE-AMBR).
a) APN-AMBR
L’APN-AMBR est le débit maximal autorisé à un UE par l’opérateur pour l’ensemble de ses bearers
non-GBR utilisant l’APN considéré. C’est un paramètre lié à la souscription de l’abonné ; il est donc
enregistré au sein du HSS dans le contexte de l’abonné et transmis par le HSS au MME lors de
l’enregistrement de l’UE au réseau. Le contrôle de ce débit agrégé est réalisé par la P-GW dans le
sens descendant, par l’UE et la P-GW dans le sens montant.

b) UE-AMBR
L’UE-AMBR désigne le débit maximal accordé à un UE pour l’ensemble de ses bearers non-GBR.
Il est limité par un paramètre de souscription transmis par le HSS au MME lors de l’enregistrement
de l’UE. Le MME produit l’UE-AMBR à partir de la somme des APN-AMBR des APN utilisés par
les bearers EPS de l’UE, ou de la valeur souscrite si celle-ci est inférieure à la somme des APN-
AMBR. Il existe une valeur UE-AMBR pour le sens montant, une autre pour le sens descendant. Le
MME communique ces deux paramètres à l’eNodeB, qui a la charge de les appliquer via l’allocation
ces ressources dans le sens montant et descendant.

3.4 Politique de gestion de la QoS

L’architecture de contrôle de politique réseau ou Network Policy Control et la politique de contrôle

et de charge ou Policy Control and Charging ou PCC sont fondamentales dans tous les réseaux de
données modernes y compris les réseaux LTE/EPC. La politique de contrôle est utilisée par les
services voix pour demander de façon dynamique la QoS afin d’avoir une communication de bonne
qualité, qui est absolument nécessaire dans un réseau tout IP. Le contrôle de politique réseau permet
aussi aux opérateurs de mesurer, gérer et taxer efficacement les différents types de services de
données.
Dans la définition de la 3GPP, le PCC ou Policy Control and Charging est un framework basé sur
les services pour le contrôle de la politique basée sur les flux et la taxation externe et interne au
réseau [23]. Le PCC supporte à la fois les règles de politiques statique et dynamique. Dans le
framework PCC, la vision initiale se traduit par le fait que les applications telles que les serveurs

57
d’application IMS, requérant des politiques dynamiques de contrôle de taxation, seront représentées
par des AF ou Application Function. L’AF est l’élément servant une application spécifique dans
une architecture IMS. L’AF est destinée à signaler le PCRF pour un contrôle dynamique et, si admis,
le PCRF va installer ou invoquer une règle dans le PCEF ou Policy and Charging Enforcement
Function qui va permettre le transport selon le protocole applicatif choisi. L’AF est supposée
supporter un changement dynamique de la politique et taxation à tout moment durant une session
de données souscrite en cours. Cette flexibilité se traduit par la possibilité d’activer un changement
dynamique dans l’accès au débit par exemple et dans la taxation à cause des besoins immédiats des
abonnés pour compléter une session associée à une tâche ou pour résoudre un non-paiement de
service. L’intégration de ces différents éléments à travers des interfaces standardisées est projetée
afin de faciliter l’implémentation des services IMS d’une manière consistente.

Figure 3.05 : Policy and Charging Control pour LTE/EPC

Le PCRF est décrit pour un déploiement dans le plan de contrôle et est prévu pour gérer le contrôle
dynamique de la bande passante, la QoS, la taxation et l’usage pour signaler le PCEF dans le plan
des bearers qui impose la politique sur les liens de communication. Le PCEF est défini comme

58
l’entité qui impose la politique, basée sur les flux, sur les liens du réseau et informe la règle de
taxation des informations au système de taxation externe (Online Charging System ou OCS) ou
interne (Offline Charging System ou OFCS). Le PCEF peut avoir à la fois une politique statique et
dynamique pour un bearer et un contrôle de flux de service de données et des mesures sur la taxation
(par exemple, le temps, le volume et les évènements comme l’accès à une application) et étant donné
son emplacement stratégique sur le plan bearer des abonnés, il a une complète visibilité sur le spectre
d’application Over-the-Top (OTT) qui comprend la majorité des trafics internet.
La Release 8 améliore le PCRF en élargissant la portée du framework PCC afin de faciliter l’accès
des technologies non 3GPP au réseau en utilisant le nœud logique BBERF ou Bearer Binding and
Event Reporting Function. Le BBERF est une représentation logique de passerelle non-3GPP (par
exemple, AGW ou Access GateWay en 3GPP2, ASN-GW ou Access Service Network GateWay en
WiMAX). Il est nécessaire de signaler les informations de QoS à partir du PCRF dans le domaine
3GPP vers le domaine d’accès réseau non-3GPP. La Release 9 introduit le monitoring en temps réel
des ressources et une amélioration de contrôle de QoS.
Nous allons pour notre part considérer les éléments du framework PCC dans la release 11.
La release 11 de la 3GPP ajoute une fonction de détection de trafic ou Traffic Detection Function
(TDF) avec une interface Sd vers le PCRF et une interface Sy entre l’OCS et le PCRF. Le but de
l’interface Sd est de permettre au PCRF d’avoir connaissance des protocoles de trafic et des
applications pour un meilleur contrôle de politique par le PCRF tandis que l’interface Sy fournit un
contrôle de politique et une facturation coordonnée en temps réel. Les deux nouvelles interfaces
accroissent la complexité de signalisation de l’architecture en général.

Figure 3.06 : Diagramme en bloc de 3GPP PCC en release 11

59
Voyons à présent les six fonctions principales des standards 3GPP PCC qui gèrent les services et la
QoS dans les réseaux modernes, à savoir :
 AF (Application Function): une par fournisseur de service
 SPR (Subscription Profile Repository)
 PCRF (Policy Charging Rules Function)
 PCEF (Policy Charging Enforcement Function)
 TDF (Traffic Detection Function): optionnel – peut être inclus dans le PCEF PCC
 OCS (Online Charging System): optionnel – peut être traité par l’usage de Gy/CCR

3.4.1 L’AF ou Application Function

L’AF peut fournir les informations suivantes reliées à la session applicative (c’est-à-dire basées sur
les protocoles SIP ou Session Initiation Protocol et SDP ou Session Description Protocol) :
 Identifiant de l’abonné – typiquement le MSISDN (Mobile Subscriber Integrated Services
Digital Network Number) de l’utilisateur, si connu par l’AF) ;
 L’adresse IP de l’UE ;
 Le type de Media et le format de Media ;
 La bande passante ;
 Les informations de la connectivité de données ;
 La description de flux (Adresse IP source et destination, numéro de port et de protocole) ;
 L’identifiant d’application AF ;
 L’identifiant de service de communication AF (IMS Communication Service Identifier) ;
 L’identifiant d’évènement de l’application AF ;
 Registre d’information AF ;
 L’état des flux ;
 Indicateur de priorité, qui peut être utilisé par le PCRF afin de garantir un service pour une
session applicative avec une priorité relativement supérieure ;
 Indicateur d’urgence ;
 Fournisseur de service applicatif.

3.4.2 SPR ou Subscription Profile Repository

Le SPR peut fournir les informations suivantes pour un abonné connecté à une passerelle spécifique
de paquets:

60
  Les services autorisés pour un abonné (liste d’identifiants de service) ;
 Pour chaque service autorisé, une priorité préemptive ;

 Les informations sur la QoS autorisée pour un abonné, incluant :

o La QoS en bande passante garantie pour un abonné;
o Une liste de QoS Class Identifiers avec la limite MBR et, pour une QoS en temps
réel, la limite GBR.
 Les informations reliées à la tarification d’un abonné ;
 Le profil de limite de consommation contenant une indication que la politique de décision
dépend des compteurs disponibles dans l’OCS qui ont des limites de consommation
associées ;
 La catégorie d’abonné ;
 Les informations reliées à la surveillance d’utilisation d’un abonné ;
 Le profil de configuration d’un abonné ;
 Le profil de connectivité de données
 Le Multimedia Priority Service (MPS);
 L’IMS Signaling Priority

3.4.3 PCRF ou Policy Charging Rules Function

Le PCRF a deux rôles clés dans le standard 3GPP PCC : fournir les règles de tarification au PCEF
(Effectué sur l’initiation de session), et créer ou détruire les contextes PDP des bearers dédiés (et
ceux des radio bearers) en réponse à une requête de l’Application Function (AF). Il est important de
noter que l’utilisation du PCRF est optionnelle; ce n’est guère un élément indispensable dans le
réseau 3GPP.

3.4.4 PCEF ou Policy Charging Enforcement Function

Le PCEF est le composant principal dans PCC, et son utilisation n’est pas optionnelle. Un opérateur
peut avoir des règles PCC prédisposées dans le PCEF (les autres règles basiques sont aussi disposées
dans le HLR/HSS). Le PCEF reçoit les informations de souscription de l’AAA (Authentication
Authorization Accounting) ou de l’interface S6a vers le HSS & AAA. Le PCEF exécute les
fonctions primaires suivantes:
 Gate enforcement : Le PCEF autorise un flux de service de données, qui est sujet à une
politique de contrôle, et passer à travers le PCEF si et seulement si la porte correspondante

61
 est ouverte. Cela fournit un moyen de blocage des trafics inconnus (et peut être utilisé pour
bloquer par exemple les utilisateurs ayant épuisés leurs crédits).
 Charging Trigger Function à travers le contrôle de crédit Diameter, il renvoie des
informations à l’Online Charging System dans le but de suivre l’utilisation.
 Charging Data Function à travers l’Offline Charging Records requis pour les services
typiquement post-paid.
 QoS enforcement:
o La correspondance entre QoS Class Identifier et un attribut spécifique de session IP.
Le PCEF convertit une valeur de QCI en une valeur d’attribut spécifique de session
IP (typiquement le DSCP ou Differentiated Service Code Point) et détermine la
valeur de QCI à partir d’une valeur d’attribut spécifique de session IP.
o L’exécution des règles PCC de QoS. Le PCEF exécute la QoS autorisée d’un flux de
service de données en accord avec la règle PCC active (par exemple, pour exécuter
le marquage DSCP en UpLink).
o L’exécution de la QoS sur un bearer de session IP. Le PCEF contrôle la QoS qui est
fournie à une combinaison d’ensemble de flux de service de données. L’exécution
de la politique assure que les ressources, qui peuvent être utilisées par un ensemble
de flux de service de données autorisé, sont parmi les ressources autorisées spécifiées
via l’interface Gx par la QoS autorisée. La QoS autorisée fournit une limite
supérieure sur les ressources qui peuvent être réservées (GBR) ou allouées (MBR)
pour un bearer de session IP. L’information de QoS autorisée est mappée par le
PCEF en attribut spécifique de QoS IP-CAN (IP Connectivity Access Network).
Durant l’exécution de la QoS sur le bearer IP-CAN, si les filtres de paquets sont
fournis à l’UE, le PCEF doit fournir les filtres de paquets avec le même contenu
dans les modèles de filtre de flux de service de données reçus sur l’interface Gx.

3.4.5 TDF ou Traffic Detection Function

Les spécifications techniques 3GPP [24] et [25] décrivent la relation entre le TDF, le Policy Control
and Charging Rules Function (PCRF), le Policy and Charging Enforcement Function (PCEF), des
interfaces Diameter variées et autres éléments tels que l’Online Charging System (OCS). L’interface
Diameter Sd est utilisée pour la communication entre le TDF et le PCRF utilisant la détection
d’application et les règles de control ADC (Application Detection and Control), décrite dans [26].

62
3.4.6 OCS ou Online Charging System

L’OCS est en dehors de la portée du PCC, mais possède une interface récente (et pas encore
largement adoptée) vers le PCRF dans le but de coordonner la politique de gestion. Une approche
commune est de représenter cette fonction via le PCEF directement. L’OCS, si utilisé, peut fournir
un statut sur le policy counter pour chaque policy counter pertinent vers le PCRF sur la nouvelle
interface Sy. En outre, le PCEF a une connexion via Gy vers l’OCS, et peut faire son propre
évaluation des règles basées sur les réponses crédit.

3.5 Conclusion

Ce chapitre a traité les notions de base concernant la qualité de service du réseau LTE dans son
release 10. Les notions de bearer EPS ainsi que les paramètres de QoS sont au cœur du mécanisme
de traitement différencié de services. A cela s’ajoute le traitement et la gestion de politique et de
règles dans le réseau de données pour atteindre une qualité de service satisfaisante aux utilisateurs.
La gestion de la qualité de service implique cependant plus que de simple notion. Cela fera l’objet
du prochain chapitre qui entrera dans les détails des fonctions et procédures d’application de QoS
dans les réseaux LTE de type 4G.

63
 CHAPITRE 4
FONCTION D’ORDONNANCEMENT DANS L’eNodeB

4.1 Introduction

Chacun des services ont des exigences différentes en termes de débit, délai de paquets, tolérance en
perte de paquets, etc. En outre, les opérateurs sont de plus en plus enclins à baser leur tarification
en fonction des exigences personnelles de chaque abonné. Ainsi, il y a un besoin en framework de
qualité de service au sein des réseaux, surtout les réseaux de type 4G LTE, qui fournit un traitement
différencié basé sur les abonnés, les services et les flux de trafic de données. Les principales
exigences incluent :
 Assurer une qualité de service élevée, spécialement pour les services clés en termes de délai,
perte de paquets et de débit.
 Activer la différenciation des utilisateurs pour permettre différentes offres de souscription
avec différentes disponibilités, débit minimum et garanti.
 Limiter les utilisateurs et applications indésirables tels que les téléchargements excessifs de
la part des utilisateurs souscrits à un offre de base
 Prioriser les services d’urgence pour fournir une meilleure fiabilité
 Réduire l’approvisionnement excessif pour les services à débit garanti pour assurer l’usage
efficient des ressources.
Les spécifications de la 3GPP qui ciblaient à l’origine un débit élevé, un faible délai, a standardisé
un framework de QoS avec des mécanismes pour remplir toutes les exigences précédentes. Elles
prévoient des dispositions extensives pour le mapping des services des opérateurs basé sur les
classes en traitement des paquets dans les nœuds du réseau. L’eNodeB qui se trouve entre l’UE et
le backhaul, contrôle l’allocation des ressources radio et joue un rôle important dans la réalisation
des besoins en QoS par UE et par bearer [27].

4.2 Architecture de QoS dans les réseaux 3GPP LTE

Dans l’architecture 3GPP, l’EPS Bearer est le plus petit niveau de granularité pour lequel le contrôle
de la QoS est défini [24]. L’EPS Bearer est une entité logique qui inclue tous les flux de paquets qui
reçoivent un traitement commun de QoS entre l’UE et la passerelle EPS. L’EPS Bearer est une
concaténation logique du Radio Bearer entre l’UE et l’eNodeB, et le bearer S1 entre l’eNodeB et
l’EPC. L’EPS Bearer est configuré selon la procédure de signalisation définie dans [18] et [28]. Un

64
flux de paquets est identifié par un filtre de paquets. Utilisant les filtres configurés durant la
configuration des bearers, un UE effectue un mapping des flux de paquets en bearer EPS en voie
descendante. Le premier bearer configuré quand l’UE s’attache au réseau est le bearer par défaut.
Contrairement aux précédents RANs ou Radio Access Network, en LTE, le bearer par défaut
demeure toujours associé à l’UE aussi longtemps que celui-ci se trouve attaché au réseau et retient
l’adresse IP fourni par l’APN. Le bearer par défaut fournit une connectivité best-effort basique à
l’UE, qui peut également être associé avec plus de sept bearers dédiés. Ces bearers dédiés activent
le réseau pour fournir différents QoS à différents flux de paquets associés à différents bearers.
L’opérateur peut contrôler lesquels des flux de paquets sont mappés en bearer dédié et le niveau de
QoS associé aux bearers dédiés, à travers la politique fournie dans le nœud Policy and Charging
Resource Function (PCRF) ou directement dans la passerelle (PCEF). Les paquets qui ne sont pas
mappés en bearer dédié seront mappés en bearer par défaut.

4.3 Fonction de gestion de la QoS et traitement au sein des nœuds

La QoS est une fonctionnalité distribuée dont les fonctions s’étendent à travers tous les nœuds du
réseau LTE: l’UE, l’eNodeB, le réseau intermédiaire backhaul, le MME, les passerelles (S-GW, P-
GW), et le PCRF. La figure 4.01 illustre la localisation des fonctions de QoS parmi les nœuds du
réseau et dans différentes couches de l’eNodeB.

L’opérateur décide du mapping entre les services offerts aux UEs et le QCI ainsi que le type de
bearer. Les débits tels que MBR/GBR, UE-AMBR, et l’ARP font également parti du profile de
souscription. Les politiques d’opérateurs sont codées en PCRF et permettent aux opérateurs de
réaliser à la fois la différenciation de services et de souscription. Les opérateurs incorporent
également des configurations semi-statiques de fonctions de QoS directement dans les nœuds du
réseau utilisant le système O&M ou Operation and Maintenance system. Le PCRF dans le réseau
détermine comment chaque flux de paquet de chaque abonné doit être manipulé en termes de
paramètres de QoS. Il déclenche l’établissement d’un nouveau bearer ou la modification d’un bearer
existant pour manipuler le flux de paquets. La procédure de manipulation du bearer en MME dans
le plan de contrôle expédie une configuration du bearer ou une requête de modification à l’eNodeB
et l’UE, et coordonne la configuration ou la modification du bearer EPS à l’intérieur de l’UE,
l’eNodeB, et les passerelles [29].

65
Figure 4.01 : Fonctions de QoS à travers les nœuds du réseau LTE

66
Durant la procédure de configuration ou modification du bearer, l’eNodeB et les Gateways
remplissent les fonctions de contrôle d’admission et de préemption afin de limiter leur charge. Dans
l’eNodeB, le RRM ou Radio Resource Management remplit ces deux fonctions. Faisant parti de la
fonction de contrôle d’admission dans l’eNodeB, le RRM décide si des ressources radio et des
ressources de traitement sont disponibles pour satisfaire les exigences en QoS des nouveaux bearers.
Dans une implémentation typique, les entrées dans la fonction de contrôle d’admission sont la
charge courante d’une cellule entière; la nature d’une requête courante, qui dépend si le bearer
appartient à un DRB (Data Radio Bearer) d’appel d’urgence, handover, GBR ou non-GBR, ou à un
SRB (Signaling Radio Bearer); le QCI du nouveau bearer et la charge estimée augmente à partir de
l’admission du nouveau bearer et dépendant sur les débits de celui-ci (GBR, AMBR) et le type de
ressources (GBR, non-GBR). La fonction admet le bearer si l’incrément de la charge dans la cellule
courante dû à l’admission du nouveau bearer se trouve en dessous du seuil de capacité autorisée
pour le système pour un type particulier de requête. Le RRM peut garder séparé le seuil de capacité
du système pour différents classes de QCI, valeurs d’ARP, et types de requêtes. Par exemple, un
seuil utilisé pour les requêtes d’handover est supérieur à celui d’un nouveau bearer dans le but de
réduire la probabilité de perte d’appel. Dans l’obligation de prévenir les bearers d’être admis dans
des conditions de surcharge, la fonction de contrôle de préemption du RRM utilise les valeurs ARP
des bearers pour identifier les bearers spécifiques qui ont besoin d’être relâchés afin de libérer les
ressources pour des bearers de priorité supérieure. Durant les conditions excessives de charge, la
fonction de contrôle de surcharge résidant dans le RRM de l’eNodeB et dans les Gateways peut
aussi initier une perte de charge en identifiant les bearers à relâcher selon leurs valeurs ARP.

Durant l’écoulement du trafic, les UEs effectuent un filtrage de paquets en voie montante pour faire
un mapping entre un paquet appartenant à un flux de paquets en voie montante et un bearer.
Similairement, les passerelles effectuent un filtrage de paquets en voie descendante pour mapper un
paquet appartenant à un flux de paquets en voie descendante au bearer requis. Les Gateways et
l’eNodeB implémentent également une fonction de limitation de débit pour assurer que les services
envoient des données avec un maximum de débit (MBR and AMBR), et pour protéger le réseau
d’être surchargé. Pour les bearers non-GBR, l’eNodeB effectue une limitation de débit basée sur la
valeur de l’UE-AMBR, alors que le PDN Gateway applique une politique de débit basée sur la
valeur de l’APN-AMBR dans les deux sens de voie, montante et descendante. Pour les bearers GBR,
la limitation de débit basée sur le MBR est effectuée dans le P-GW et l’eNodeB en sens descendant.

67
L’ordonnanceur de paquet dans l’eNodeB ou eNodeB packet scheduler distribue les ressources
radio entre les bearers établis en direction montante et descendante. La fonction d’ordonnancement
est responsable, dans une large ampleur, de la réalisation les caractéristiques QCI associées avec les
bearers. La fonction de contrôle dans le RRM de l’eNodeB est aussi responsable de la configuration
des protocoles de couche 1 et 2 du radio bearer conformément aux caractéristiques de QCI. Le mode
RLC-acknowledged ou RLC-unacknowledged est basé sur les exigences en PELR ou Packet Error
Loss Rate. Le PELR et le PDB (Packet Delay Budget) sont considérés en configurant le maximum
du nombre de retransmission HARQ en sens montants et descendants. Le minuteur de suppression
de paquet en PDCP ou Packet Data Convergence Protocol est configuré sur la base du PDB associé
au bearer de sorte que les paquets possédant un délai qui dépasse les limites PDB, pendant l’attente
dans le scheduler, peuvent être supprimés. La longueur de la file d’attente RLC de transmission en
voie descendante est configurée selon les débits GBR et AMBR et le PDB associé au bearer. Le
RRM configure aussi les paramètres du scheduler. La fonction de contrôle de bearer dans RRM
configure également des paramètres qui sont spécifiques aux bearers en voie montante. Les bearers
de données et de signalisation ayant des exigences commun en QoS sont groupés par le RRM dans
un Logical Channel Groups (LCGs), qui sont plus de quatre par UE. Un groupement typique de
bearers en LCG est: LCG 0 (SRB1, SRB2, DRB avec un QCI 5 utilisé pour la signalisation IMS),
LCG 1 (DRB avec un QCI 1 utilisé pour l’appel voix), LCG 2 (GBR DRBs avec des QCI 2, 3 et 4),
et LCG 3 (non-GBR DRBs avec des QCI 6, 7, 8 et 9). Ce type de groupement autorise la règle
d’ordonnancement d’être appliquée par LCG plutôt que par bearer. Pour une requête de ressource
pour une transmission en voie montante, l’UE peut spécifier la taille du buffer en attente de
transmission par LCG. L’eNodeB peut aussi communiquer l’accord par LCG à l’UE. Le RRM
configure la priorité, Prioritized Bit Rate (PBR), et Bucket Size Duration par bearer montant. L’UE
utilise ces paramètres pour distribuer l’accord reçu en voie montante de l’eNodeB parmi les bearers
dans un LCG. Le principe de l’algorithme de jeton de seau est appliqué quand, une fois dans chaque
durée de taille de seau, chaque bearer est crédité d’un jeton équivalent au PBR. L’accord reçu est
alloué au bearer avec la plus haute priorité jusqu’à ce que tous les jetons soient consommés, suivi
par un autre bearer en priorité jusqu’à ce que les jetons de tous les bearers dans un LCG soient
servis. Des surplus d’accords sont alloués préférentiellement aux bearers selon la priorité jusqu’à ce
que la taille du buffer d’attente atteigne zero. Dans un LCG, le RRM alloue les priorités au bearer
par les priorités de QCI. Le PBR est alloué proportionnellement au débit GBR. Le PDN Gateway et

68
l’eNodeB implémentent aussi la fonction de mapping du QCI en DSCP pour créer une transition
entre le niveau bearer du QoS en niveau de transport du QoS. Utilisant cette fonction, les paquets
associés à un QCI spécifique sont marqués avec un DSCP spécifique pour le transfert dans le réseau
backhaul. Le mapping du QCI en DSCP est basé sur la politique de l’opérateur configurée dans
l’eNodeB et le PDN gateway utilisant l’O&M. L’eNodeB effectue le mapping pour le sens montant
alors que le PDN gateway le fait pour le sens descendant. Le réseau de transport intermédiaire ou
backhaul doit implémenter les fonctionnalités de gestion de file d’attente et de transfert de trafic
selon la valeur DSCP. La fonction de détection de surcharge RRM de l’eNodeB surveille
constamment l’état de charge de la cellule et la performance statistique reportée périodiquement par
la couche 2 regardant les caractéristiques du niveau de conformité par classe de QCI telles que PDB,
PELR, et les débits. Si la conformité d’un QCI tombe en dessous d’un certain seuil, le contrôle de
surcharge active la fonction de préemption pour lâcher des bearers appartenant à la classe de QCI,
et la fonction de contrôle d’admission arrête l’admission de nouveau bearer de la classe de QCI.
Cela permet à l’eNodeB de prévenir et rétablir la condition de surcharge et améliore la conformité
de QCI du bearer en cours.

4.4 Considération du scheduling au sein de l’eNodeB

L’objectif de ce mémoire étant de se concentrer sur l’influence du scheduling ou ordonnancement

sur la qualité de service dans les réseaux LTE de type 4G. Cette partie sera consacrée à étudier cela
dans les détails.
Le concept adopté dans les réseaux d’accès radio telle que la 3GPP LTE consiste à introduire des
mécanismes de scheduling respectant les contraintes de QoS. Un scheduler respectant la QoS doit
satisfaire des exigences variées et contradictoires. Pour chaque UE admis pour lequel le trafic
s’écoule, le scheduler doit assurer que les ressources radio soient allouées de telles sorte que les
exigences signalées en termes de débit (GBR/AMBR), en termes de latence et en termes de PELR
ou perte de paquets soient suffisamment rencontrées pendant que les exigences en QoS des autres
utilisateurs sont équitablement allouées.
Le scheduler doit également assurer que le débit agrégé pour chaque cellule soit maximisé et que la
variation des conditions du canal de l’utilisateur soit prise en compte pour la maximisation des débits
des cellules. Par exemple, l’UE avec une basse priorité peut avoir une bonne condition de canal
radio et requiert de faible ressources radio pour transmettre le même nombre de bits que pour un
UE avec une priorité élevée et une mauvaise condition de canal radio.

69
Le scheduler a le devoir de choisir les UEs tels que ceux avec une mauvaise condition de canal ne
soient pas délaissés, tandis que ceux avec de bonne condition seront préférés, tout en maximisant le
débit agrégé pour les cellules [27].
L’eNodeB requiert aussi un ordonnancement rapide – une fois par milliseconde par exemple. Aussi,
le nombre de calcul effectué pour chaque allocation doit être aussi optimisé de telle façon que dans
les cycles disponibles du CPU (Central Processing Unit), le processeur et le scheduler soient
capables de transmettre les décisions au protocole MAC avec un espace temporel suffisant pour
envoyer des données et des informations d’allocation de ressource radio à la couche Physique pour
la transmission vers l’UE.
Il y a également de demande conflictuelle pour les bearers GBR et non-GBR. La majorité des
bearers admis dans une cellule typique sera des bearers non-GBR et pour maximiser le nombre de
bearers servis, la fonction de contrôle d’admission dans le RRM procèdera à une sur-allocation
quant à l’admission des bearers non-GBR. Pour maximiser de tel bearer en effet, la fonction de
contrôle d’admission admet que les bearers non-GBR n’utilisent pas la capacité uniformément
contrairement à la réservation d’une zone de capacité pour les bearers GBR dans une cellule, elle
permet ainsi la sur-allocation des bearers non-GBR. Les bearers garantis (GBR), portant des services
comme les appels VoIP, envoient des paquets presque de même taille que le débit signalé. Les
bearers non-GBR des services tels que la navigation internet ou les téléchargements en arrière-plan
sont plus tolérant pour la latence. Le scheduler assure qu’aux bearers GBR sont alloués une
meilleure priorité d’allocation tout en ne délaissant pas les bearers non-GBR à travers le temps. Un
scheduler typique peut manipuler cela en catégorisant les bearers en des catégories de bearer de
signalisation, GBR, et non-GBR.

La catégorie de bearer de signalisation inclue comme son nom l’indique des radio bearers de
signalisation, les bearers de haute priorité de classe de QCI 5 et les signalisations IMS (IP
Multimedia Subsystem) de basse latence. Les catégories GBR et non-GBR reste les classes de QCI
avec des ressources de type GBR et non-GBR. La figure 4.02 illustre comment la bande passante
est allouée aux différents flux.

70
 Figure 4.02 : Division de ressources entre trafic de signalisation, GBR et non-GBR

Les ressources sont allouées en premier lieu aux bearers de signalisation et GBR, jusqu’à la capacité
dédiée marquée. Les bearers non-GBR sont ensuite alloués à la capacité restante. La capacité dédiée
pour les bearers GBR est dérivée de l’agrégation GBR pour chaque bearer admis. Ce schéma peut
être optimisé de telle sorte que la capacité inutilisée des catégories de signalisation et GBR est
utilisée pour les non-GBR. Certains bearers GBR faiblement servis sont aussi considérés pendant le
scheduling de la capacité à allouer aux bearers non-GBR. La capacité dédiée pour les GBR peut être
ajustée sur un facteur de sur-allocation utilisé par le RRM pendant l’admission des bearers GBR.

Une fonction d’ordonnancement typique travaille en conjonction avec d’autres fonctions, comme
illustrée sur la figure 4.03.

La fonction de gestion de file d’attente ou buffering function est requise pour mettre en attente les
PDU ou Packet Data Unit qui attendent leur opportunité de transmission. La charge de file par bearer
de la fonction de buffering est utilisée en entrée par la fonction de scheduling dans la décision
d’allocation. La fonction de buffering manipule également la longueur de la file avec une limite
maximum configurée par la fonction de contrôle RRM de bearers et supprime les PDUs ayant
dépassés cette limite. Cette fonction maintient en outre le temps d’arrivée de chaque PDU.

71
Les PDUs qui excèdent la limite de temps configurée par la fonction de contrôle RRM de bearers
sont supprimés.

Figure 4.03 : Scheduler et les fonctions associées

La fonction de contrôle de flux réside entre le buffering et la fonction de scheduling. Typiquement,

un algorithme basé sur les jetons peut être implémenté pour créer périodiquement un jeton par bearer
au débit signalé GBR et UE-AMBR, et la fonction de scheduling limite l’opportunité de
transmission pour le bearer par le nombre de jeton restant. La fonction feedback du canal maintient
l’état du canal pour chaque UE qui est utilisé par la fonction de scheduling pour prioriser les UEs
avec de bonnes conditions de canal. Cette fonction utilise le CQI ou Channel Quality Indicator, un
feedback de l’UE, pour estimer la qualité du canal en downlink, et le feedback SRS (Sounding
Reference Signal) pour estimer la qualité du canal en uplink. La fonction HARQ contrôle la
retransmission des PDU MAC où le DL HARQ stock le PDU MAC transmis et si un feedback
négatif est reçu de la part de l’UE, il retransmet le PDU MAC jusqu’à la limite configurée par la
fonction de contrôle RRM de bearer. La fonction UL HARQ envoie un feedback positif ou négatif
pour un PDU transmis en UL à l’UE afin que ce dernier puisse retransmettre le PDU s’il reçoit un
feedback négatif. La fonction de scheduling requiert un feedback de la fonction HARQ pour qu’il
puisse ordonnancer les ressources pour les retransmissions. Une fonction de scheduling typique
donne la priorité aux retransmissions par rapport aux nouvelles transmissions pour l’UE. La fonction

72
d’allocation de ressource radio alloue les ressources fréquentielles sur les canaux PDCCH (Physical
Downlink Control CHannel), PDSCH (Physical Downlink Shared CHannel) et PUSCH (Physical
Uplink Shared CHannel).
L’algorithme de scheduling est le cœur de l’ordonnanceur. Son but est de sélectionner les UEs qui
s’ajustent le plus à une politique d’ordonnancement donnée pour l’allocation des ressources radio
en Uplink et downlink pendant un intervalle de temps TTI ou Transmission Time Interval, et une
quantité d’opportunité donnée à chaque UE. Les caractéristiques et exigences par bearer sont prises
en compte mais les ressources radio sont ultimement allouées par UE. Les UEs sélectionnés pour
une transmission en sens montant peut être différent des UEs sélectionnés pour la transmission en
sens descendant.

4.5 Formulation mathématique du problème d’allocation de ressources radio

On considère un système LTE où il y a N Scheduling Blocks (SB) avec une puissante égale partagée
sur tous les SBs, et supposons qu’il y a K utilisateurs et le débit minimal demandé par le k-ème
utilisateur est Mbit/s. Un SB est le minimale de ressource qui peut être allouée à un utilisateur,
il représente deux Resource Block RB consécutifs).

Figure 4.04 : Disposition du scheduling block et resource block

73
On définit un SB comme un ensemble de symboles OFDM (Orthogonal Frequency Division
Multiplexing) dans le domaine de temps TD et sous-porteuses dans le domaine de fréquence
FD, en plus, en raison des signaux de contrôles et d’autres pilots, seulement ( ) des sous-
porteuses seront utilisées pour transmettre les données du s-ème symbole OFDM, avec =
{1, 2, … , } et que ( )≤ . Supposant aussi = {1, 2, … , } avec est le nombre total de
schéma de modulation et codage ou MCS (Modulation and Coding Scheme) supporté, alors soit
( )
le code associé au MCS j, est la constellation du MCS j et est la durée du symbole OFDM,
( )
alors le débit atteignable par un seul SB est :
( )
log ( )
( )
= ( ) (4.01)

Maintenant, on définit , comme CQI (Channel Quality Indicator) de l’utilisateur k sur le n-ème
SB. Le CQI du k-ème utilisateur sur les N SBs est = , , , ,…, , et pour tous les
utilisateurs sur tous les BSs =[ , ,…, ]. Le CQI est défini suivant le schéma de modulation,
codage du canal.
Le , est renvoyé par l’utilisateur k à la station de base (eNodeB) pour que l’ordonnanceur
détermine quel MCS doit être sélectionné pour le n-ème SB associé à l’utilisateur k.

Pour l’utilisateur k, la valeur maximale CQI sur tous les SBs est :
∗
= arg , ∈
(4.02)
Par la suite, on définit , ( , ∗)
∈ {1, 2, … , } la plus grande valeur du MCS atteinte par

l’utilisateur k sur le n-ème SB pour la valeur CQI , ∗ , c’est-à-dire

( )
, ( , ∗)
= arg max log ( ) , ∗ (4.03)

Aussi il ne faut pas oublier le fait qu’un SB est alloué à un et un seul utilisateur, pour cela on définit
, l’indicateur d’allocation de ressource pour l’utilisateur k sur le n-ème SB, si , = 1 alors le
SB n est alloué à l’utilisateur k et que , = 0 pour tous ≠ .
Posons , le MCS choisi par l’utilisateur k sur tous les SBs qui lui sont alloués, , = 1 veut dire
que MCS j est choisi par l’utilisateur k.

74
Le débit atteint par l’utilisateur k sur une seule sous-trame est :
, ( , ∗)

( ) (4.04)
= ,

Donc, le problème d’allocation de ressources radio a pour but de maximiser le débit des utilisateurs
sous les contraintes suivantes :

(4.05)
, , ,

≥ ,∀ (4.06)
, = 1, , =0 ,∀ ≠ (4.07)
, ( , ∗)

, =1 (4.08)

L’équation (4.05) est la fonction objectif qui vise à maximiser le débit, (4.06) est une fonction visant
à assurer un débit minimal pour tous les utilisateurs (c’est-à-dire assurer une certaine QoS), (4.07)
assure qu’un SB peut être attribué à un seul utilisateur, (4.08) tous les SBs d’un utilisateur emploient
un seul MCS (contrainte sur les réseaux LTE).

4.6 Algorithmes d’ordonnancement

Les algorithmes d’ordonnancement se basent sur les formulations mathématiques déjà mentionnées,
et essayent de réaliser l’allocation de ressources radio aux utilisateurs du système d’une façon
efficace.
Les algorithmes d’allocation de ressources radio ont pour objectif d’améliorer les performances du
système en augmentant l’efficacité spectrale et l’équité dans le réseau. Il est donc essentiel de
trouver un compromis entre l’efficacité (augmentation en débit) et l’équité entre les utilisateurs [30].

4.6.1 Les algorithmes opportunistes

Ce type d’algorithmes utilise des files d’attentes infinies, ces files d’attente sont utilisées dans le cas
de trafic non temps réel. L’objectif principal de ce type d’algorithmes est de maximiser le débit
global du système. Plusieurs algorithmes utilisent cette approche comme : PF (Proportional Fair),
EXPPF (Exponential Proportional Fair), etc.

75
4.6.1.1 Proportional Fair (PF)

Son but est d’essayer de maximiser le débit global du système en augmentant le débit de chaque
utilisateur en même temps, il essaye de garantir l’équité entre les utilisateurs, la fonction objectif
(débit atteint par l’utilisateur k sur une seule sous trame) représentant l’algorithme PF est :
( )
= (4.09)

Où ( ) est le débit correspondant au CQI de l’utilisateur k,

est le débit maximum supporté par le RB

4.6.1.2 Exponential Proportional Fair (EXPPF)

C’est une amélioration de l’algorithme PF qui supporte les flux temps réel (multimédia), au fait, il
priorise les flux temps réel par rapport aux autres [31]. Un utilisateur k est désigné pour
l’ordonnancement suivant la relation suivante :
( ) ( )−
= exp (4.10)
̅ 1+√
1
= ( ) (4.11)

Où ( ) est le délai toléré par le flux,

est un paramètre strictement positif pour tout i.

4.6.2 Les algorithmes équitables

Plusieurs travaux de recherches ont visé l’équité entre les utilisateurs dans les réseaux LTE, ces
algorithmes présentent généralement une insuffisance au débit. A noter que l’équité ne veut pas dire
l’égalité.

4.6.2.1 Round Robin (RR)

C’est une stratégie classique d’allocation des ressources radio, l’algorithme alloue la même quantité
de ressource aux utilisateurs en partageant le temps, par conséquent, le débit diminue
considérablement vue que tous les utilisateurs du système utilisent les ressources radio suivant un
quantum de temps.

76
Round Robin, où des opportunités égales sont remises à chaque UE, est un algorithme très simpliste
qui ne tient pas compte des conditions de canal et n’est utile qu’à des fins comparatives.

4.6.2.2 Max-Min Fair (MMF)

L’algorithme distribue les ressources entre les utilisateurs successivement en vue d’augmenter le
débit de chaque utilisateur. Une fois que l’utilisateur alloue les ressources demandées pour atteindre
son débit, on passe à l’utilisateur suivant. L’algorithme s’arrête par épuisement des ressources ou
que les utilisateurs soient satisfaits.

4.6.3 Algorithmes considérant les délais

Ce type d’algorithme traite les délais d’arrivée et de délivrance des paquets. Conçue principalement
pour traiter les flux temps réel (multimédia et VoIP). Si un paquet dépasse ces valeurs de retard
tolérées, il sera supprimé de la liste des flux à ordonnancer ce qui dégrade considérablement la QoS.
MLWDF (Modified-Largest Weighted Delay First) est un exemple d’implantation de cette famille.

 Modified Largest Weighted Delay First (MLWDF)

Cet algorithme prend en charge des flux ayant des exigences de QoS différentes, il essaye de
pondérer les retards des paquets en utilisant la connaissance de l’état de canal, à un instant t,
l’algorithme choisit un utilisateur k pour l’ordonnancement via la formule (4.12).
( )
= ( ) (4.12)
̅

C’est pratiquement la même formule que l’algorithme EXPPF, sauf que = − log( ) , avec
: La probabilité que le délai ne soit pas respecté,
: Le délai que l’utilisateur i peut tolérer.

Cet algorithme s’adresse principalement au flux temps réel qui exige le respect des délais, il donne
de bons résultats dans ce contexte, par contre pour les flux non temps réel, ce n’est vraiment pas un
bon choix vu que le délai n’est vraiment pas un paramètre important.

4.6.4 Algorithmes optimisant le débit

Ce type d’algorithme essaye de maximiser la fonction objectif (formule 4.04) qui représente le débit,
cette approche traite les flux temps réel et non temps réel, l’allocation de ressources dépend de la

77
taille de la file de chaque utilisateur. Les exemples d’algorithme de cette famille sont EXP Rule,
Max-Weight, MT (Maximum Throughput), PF,etc.

4.6.5 Les algorithmes multi-classes

Cette approche considère les classes de flux où le traitement est différent pour chaque classe RT
(Real-Time) et NRT (Non Real-Time). Ce type d’algorithme privilégie les flux temps-réels par
rapport aux non temps-réels, ce qui le rend plus adéquat et plus efficace pour l’ordonnancement en
LTE, par contre l’équité n’est vraiment pas considérée.

4.7 Application des paramètres de QoS dans le réseau

Les valeurs des paramètres de QoS sont définies au sein du réseau cœur EPC en fonction de la
politique de l’opérateur, des caractéristiques du service et de la souscription de l’utilisateur
enregistrée dans le HSS. Le MME ne modifie pas ces valeurs et les transfère de façon transparente
à l’eNodeB et à l’UE. Par ailleurs, il n’existe pas de négociation de QoS entre le MME et l’eNodeB :
si ce dernier ne peut assurer la QoS requise pour le bearer EPS, il doit rejeter l’établissement de l’E-
RAB. Cela constitue une différence entre l’UMTS, dans lequel le RNC peut proposer une QoS
inférieure à celle demandée par le SGSN. Par ailleurs, l’eNodeB ne peut modifier ou demander au
MME de modifier les caractéristiques de QoS de l’E-RAB, en cas de congestion notamment ; dans
ce cas, il doit alors indiquer cette relâche de l’E-RAB au MME.
La figure suivante montre les paramètres de QoS connus par les différents équipements, lors d’un
appel. On voit par exemple que les paramètres de débit GBR et MBR sont transmis à tous les nœuds
du réseau impliqués dans le plan usager. Ils peuvent ainsi contrôler le respect de ces valeurs et mettre
en œuvre si besoin des mécanismes de lissage, ou au contraire allouer davantage de ressources.
L’UE reçoit également ces paramètres lors de l’établissement de l’appel, mais il ne contrôle pas le
respect de ces valeurs sur le plan usager pendant l’appel. En effet, c’est l’eNodeB qui veille à ne pas
dépasser le MBR ou à atteindre le GBR, dans le sens montant ou descendant, par les allocations sur
l’interface radio. La couche ESM de l’UE peut cependant indiquer ces paramètres de débit à
l’application utilisée, et celle-ci peut alors éventuellement adapter l’encodage des flux (par exemple
pour un flux vidéo).

78
 Figure 4.05 : Les paramètres de QoS du bearer EPS et les nœuds impliqués

Ainsi, on voit que certains paramètres peuvent être connus de l’équipement sans être appliqués
pendant l’appel.
L’UE doit en revanche veiller à ne pas dépasser dans le sens montant le débit maximal par APN
(APN-MBR), qui peut impliquer plusieurs bearers EPS, car l’eNodeB n’a pas la connaissance de
l’APN associé au bearer EPS (l’APN étant une information de niveau NAS). Un contrôle est
également effectué par la PDN-GW sur ce débit agrégé, dans les deux sens. Si le débit effectif
dépasse l’APN-AMBR, la P-GW supprime des paquets de données. Cette seconde vérification dans
le sens montant est importante : si l’UE ne respecte pas l’APN-AMBR, cela limite le débit applicatif
et donc aide à maitriser la QoS effective obtenue par l’utilisateur. Il est cependant préférable d’éviter
cette situation puisqu’elle conduit à un gaspillage de ressources, les paquets n’étant supprimés
qu’après avoir traversé le réseau mobile. La maîtrise des terminaux est donc primordiale pour
l’opérateur et motive la réalisation de tests de validation pour vérifier le respect de la norme pour
les terminaux.
Le profil de souscription de l’abonné, enregistré dans le HSS, indique pour chaque PDN autorisé
les APN auxquels l’abonné peut accéder et la QoS maximale autorisée : QCI, ARP, GBR (si
applicable), MBR et APN-AMBR. Ce profil est envoyé au MME, par le HSS ou l’ancien MME. Le

79
MME peut alors vérifier lors de l’établissement d’appel que l’UE est autorisé à accéder au PDN
indiqué avec la QoS demandée.
Pour superviser l’allocation des ressources radio à l’UE (scheduling), l’eNodeB peut utiliser le QCI
du bearer EPS, l’UE-AMBR et les paramètres GBR et/ou MBR.

4.8 Conclusion

Ce chapitre a traité l’architecture du framework de gestion de la qualité de service au sein des

réseaux LTE/EPC dans un premier temps, Il a ensuite mis l’accent sur le mécanisme
d’ordonnancement avant de montrer la manière d’appliquer les paramètres de QoS. Le prochain et
dernier chapitre se concentrera sur le vif du sujet qui est l’étude de l’influence du scheduling sur la
qualité de service par simulation.

80
 CHAPITRE 5
EVALUATION DE L’INFLUENCE DU SCHEDULING SUR LA QOS PAR
SIMULATION

5.1 Introduction

Dans notre étude sur la qualité de service au sein des réseaux LTE/EPC, nous avons, dans les
chapitres précédents, expliqué les notions et principes de gestion de la QoS. Dans la suite de cette
étude, il s’agira surtout de pouvoir évaluer la performance des algorithmes de scheduling le plus
connus au sein de ces systèmes dans un cadre qui approchera le plus la situation réelle et ensuite
implémenter un algorithme qui sera plus performant encore. Nous allons pour cela simuler
l’architecture du réseau LTE/EPC afin d’obtenir des résultats qui serviront ensuite à notre
évaluation. Le simulateur LTE-Sim semble répondre à notre besoin de simuler le réseau LTE/EPC
d’un point de vue plus orienté sur la qualité de Service.
Ce chapitre sera organisé de manière à présenter dans un premier temps les modèles d’évaluation
des QoS, ensuite évaluer la performance des algorithmes de scheduling en termes de QoS, les
algorithmes étudiés étant le Proportional Fair (PF), le Modified Largest Weighted Delay First
(MLWDF), l’Exponential Proportional Fair (EXPPF) et le Packet Prediction Mechanism (PPM). Le
PPM étant l’algorithme qui sera proposé comme amélioration car ce n’est pas encore un algorithme
connus ni implémenté, cependant il possède une performance intéressante.

5.2 Modèles d’évaluation des QoS

L’évaluation de la qualité de service au sein des réseaux est un concept qui fait intervenir deux types
de points de vue. Le premier consiste à mesurer les critères de performances du réseau en insérant
dans celui-ci un mécanisme de mesure afin de connaitre la situation réelle quant à l’état de ces
critères, qui aidera par la suite l’opérateur ou le fournisseur de services dans l’optimisation de son
réseau. Ces critères sont appelés les KPI ou Key Performance Indicator. Cependant, la situation des
KPI ne sont pas à la connaissance de l’utilisateur final. La qualité de service étant basée sur le
concept de satisfaction de l’utilisateur, les fournisseurs de services ont établi des documents qui
permettent de se conformer au besoin de l’utilisateur qui constitue leur clientèle. Ces documents
sont appelés SLA ou Service Level Agreement. Un SLA est établi entre un fournisseur de service
et un client. Le fournisseur de service s'engage à transmettre le trafic d'un client avec une qualité de
service mesurable, tant que le client respecte ses obligations et les spécifications de trafic. Nous

81
allons voir dans un premier temps les paramètres d’évaluation KPI au sein des systèmes LTE/EPC
avant de se concentrer sur les paramètres d’évaluation au sein des SLA.

5.2.1 Key Performance Indicator (KPI)

Les KPI sont des critères de QoS qui résument l'accomplissement des services à l’utilisateur final.
Selon les recommandations de la 3GPP [32], les KPI définis pour les systèmes LTE/EPC sont
divisés en trois groupes pour le réseau cœur: les KPI d’accessibilité, les KPI de mobilité et les KPI
d’utilisation et divisés en cinq catégories pour l’E-UTRAN : les KPI d’accessibilité, les KPI de
maintien, les KPI d’intégrité, les KPI de disponibilité et les KPI de mobilité (Cf. Annexe 1).

5.2.2 Paramètres de performance de QoS à base du Service Level Agreement (SLA)

Les paramètres de performance de la qualité de service qui sont connus par l’utilisateur, selon sa
souscription au fournisseur de service, sont les paramètres mentionnés dans le Service Level
Agreement ou SLA. Ces paramètres sont notamment :
 Le débit de transmission (ou throughput);
 Le délai de transit maximum d’un paquet à travers le réseau (ou end to end delay);
 La variation du délai de transit (ou jitter);
 Le taux de perte des paquets (ou packet loss)

5.2.2.1 Le débit de transmission ou throughput

Le throughput d'un flux se définit comme le nombre de bits correctement reçus pendant un intervalle
de temps divisé par la longueur de l'intervalle. Des paquets qui sont reçus corrompus ou dupliqués
ne sont pas comptés. Le calcul du throughput se formule par :
ç
ℎ ℎ ( )= (5.01)
−

5.2.2.2 Le délai de transmission ou delay

Le délai de transmission est défini comme étant l’intervalle de temps entre l’émission par la source
du premier d’un paquet et la réception par le destinataire du dernier bit du même paquet.

( )= 1 − (5.02)

82
Si on considère le délai de transit maximum d’un paquet à travers le réseau ou end-to-end delay, la
source est positionnée à l’extrémité du réseau alors que le destinataire se trouve à l’autre extrémité.
Dans le cas du système EPS, la source constitue l’UE et le destinataire n’est autre qu’un serveur ou
un nœud situé juste après le PDN-GW pour le sens montant et inversement pour le sens descendant.
Le délai de transmission dans un système EPS est de l’ordre de quelques millisecondes à plusieurs
dizaines de millisecondes mais peut même atteindre dans certaines conditions quelques centaines
de millisecondes. Cela est influencé par plusieurs critères comme la taille du réseau et de sa charge,
la vitesse des nœuds intermédiaires ou encore la taille du paquet :
= + + + (5.03)
Le délai de transit est donc constitué par :
 Le temps de traitement qui est le temps nécessaire à chaque nœud du réseau pour l’analyse
des paquets entrants afin d’éventuellement détecter et/ou corriger les erreurs et l’aiguiller
vers la file d’attente correspondant à sa destination.
 Le temps d’attente qui correspond au temps passé par le paquet dans la file d’attente avant
d’atteindre le média qui l’acheminera vers le prochain nœud.
 Le temps de transmission correspond au temps requis pour placer tous les bits du paquet sur
la liaison.
 Le temps de propagation est le temps nécessaire aux bits du paquet placés sur la liaison pour
effectuer le trajet entre l’émetteur et le récepteur.

5.2.2.3 La variation du délai de transit ou jitter

La variation du délai de transit est définie pour une paire de paquets P1 et P2. Elle est donnée par la
différence des délais de transit des deux paquets :
( , )= ( )− ( ) (5.04)
On s’intéresse en général à la valeur absolue du jitter ou encore de la gigue.

83
5.2.2.4 Le taux de perte des paquets ou packet loss

Un paquet est considéré comme correctement reçu, s’il arrive sans erreurs et après un délai de transit
maximum défini. Le taux de perte unidirectionnel de paquets est défini comme le rapport entre le
nombre de paquets expédiés sur un intervalle de temps et le nombre de paquets correctement reçus :

− ç
= (5.05)

La définition d’un paquet correctement reçu ne fait donc aucune différence entre un paquet perdu et
un paquet ayant un grand délai de transit.

5.3 Evaluation des performances par simulation

L’évaluation des performances du réseau LTE/EPC en termes de qualité de service est une étape
nécessaire avant de pouvoir proposer un moyen d’améliorer cette performance. L’évaluation des
performances se fera par simulation du système EPS conformément à la Release 10 de la
spécification 3GPP qui remplit déjà les exigences des réseaux de quatrième génération et peut être
considéré en tant que tels. Le framework LTE-Sim a été choisi pour la simulation étant donné que
c’est un framework qui possède une implémentation complète des mécanismes de qualité de service
au sein des réseaux LTE/EPC. En outre, LTE-Sim a le mérite d’être open-source.

5.3.1 Présentation du simulateur

LTE-Sim est un framework open-source basé sur C++ pour la simulation des systèmes LTE sous
plusieurs aspects. LTE-Sim est développé et maintenu par le department of Elettrotecnica ed
Elettronica dans l’Ecole Supérieure Politecnico di Bari en Italy. LTE-Sim englobe plusieurs aspects
des réseaux LTE, incluant à la fois l’Evolved Universal Terrestrial Radio Access (E-UTRAN) et le
Evolved Packet Core(EPC). Il supporte plusieurs fonctionnalités comme les environnements de
cellule unique et multi-cellule, la gestion de la QoS, l’environnement multi-utilisateurs, la mobilité
des UEs, les procédures de handover ainsi que les techniques de réutilisation de fréquence.

Trois types de nœuds réseau sont modélisés par LTE-Sim: l’User Equipment (UE) ou l’équipement
utilisateur, l’Enhanced Node-B (eNodeB) et le Mobility Management Entity/Gateway (MME/GW).

84
Plusieurs générateurs de trafic au niveau de la couche application ont été implémentés et la gestion
des Data Radio Bearer est pleinement supportée, sans oublier les schémas de modulation et de
codage adaptatifs AMC ou Adaptative Modulation Coding.
Le simulateur est composé de 4 grandes classes Simulator, NetworkManager, FlowManager,
FrameManager.
 Simulator:
Cette classe permet la gestion des événements. Elle contient 4 méthodes importantes :
 Schedule() Creates : permet la création et l’insertion de nouveaux événements sur le
calendrier des événements.
 RunOneEvent() : permet l’exécution des événements.
 Run() / Stop() : permet le démarrage et l’arrêt de la simulation .
 FrameManager : La mise en œuvre effective de la structure de trame LTE est garantie par
cette composante. Il est en charge de la programmation correcte des trames et sous-trames
(c'est-à-dire TTI) et de la synchronisation de tous les eNBs. Elle est composée de deux
méthodes importantes :
 StartSubFrame() : gère le début des sous trames LTE.
 StopSubFrame() : gère la fin des sous trames LTE.
 FlowManager : Permet la gestion des applications. Elle est composée d’une seule méthode :
 CreateApplication() .
 NetworkManager : Cette composante permet la création des équipements, gestion de la
position des UE, la mobilité, et la gestion des techniques de réutilisation des fréquences. Elle
est composée de 5 importantes méthodes:
 CreateUserEquipment() : permet de créer un équipement.
 CreateCell() : permet de créer les cellules.
 UpdateUserPosition() : permet la mise à jour de la position de l’utilisateur.
 HandOverProcedure() : permet la gestion des procédures d’Handover.
 RunFrequencyReuse() : implémente les techniques de réutilisation de fréquence.

5.3.2 Critères d’évaluation

L’évaluation portera sur la qualité de service dans les réseaux LTE/EPC dans un premier temps puis
nous proposerons une manière d’en améliorer les performances dans un second temps.
La notion de qualité de service étant gérée dans les réseaux comme étant le principe de priorisation
de flux à travers le réseau à l’aide des mécanismes de file d’attente de différenciation qui se trouve

85
au niveau des nœuds des réseaux comme le PDN-GW, le S-GW et l’eNodeB. Les mesures ont
cependant montré que la gestion de la qualité de service s’avère particulièrement compliquée sur le
lien radio car 90% des délais de paquets sont passé à travers le lien radio et 96% des pertes de
paquets se produit dans l’E-UTRAN. Il serait par conséquent très pertinent d’étudier le respect des
exigences de qualité de service dans cette partie du réseau. Dans l’E-UTRAN, les fonctions de
gestion des QoS sont implémentées au sein de l’eNodeB, notamment la gestion de la file d’attente
de différenciation ou Queueing Management et le principe d’ordonnancement ou Scheduling au
niveau de la couche MAC. La gestion des files d’attente n’influence pas directement les
performances des liens radio, c’est pour cela que notre étude portera plus sur la partie
ordonnancement qui a un impact direct sur la performance du lien radio toujours en termes de qualité
de service. Nous allons dans un premier temps évaluer les performances des algorithmes de
scheduling les plus utilisés, notamment le Proportional Fair, le Modified Largest Weighted Delay
First, l’Exponential Proportional Fair et le Packet Prediction Mechanism. Le choix de ces
algorithmes s’explique par le fait qu’ils englobent les catégories des algorithmes d’ordonnancement
citées dans le chapitre 4 (Cf. §4.6), car PF est un algorithme maximisant le débit, MLWDF quant à
lui est un algorithme considérant les délais, EXPPF est un algorithme qui considère les flux en
temps-réels tout en maximisant les débits et PPM est un algorithme multi-classe qui maximise le
débit et effectue à la fois la différenciation entre les classes de services. L’évaluation se focalisera
sur les paramètres de QoS inscrits dans le Service Level Agreement, c’est-à-dire le débit de
transmission ou Throughput, le délai de transmission de bout-en-bout, la gigue ou le Jitter, le taux
de perte de paquets ou Packet Loss Ratio. Ensuite, nous proposerons l’algorithme PPM ou Packet
Prediction Mechanism afin de mener une étude comparative entre les services toujours sur les
critères décrits auparavant.

5.3.3 Scénario et paramètres de simulation

5.3.3.1 Scénario de simulation

Afin d’évaluer l’impact des algorithmes d’ordonnancement en termes de qualité de service, nous
allons évaluer les résultats des simulations des quatres algorithmes PF ou Proportionnal Fair,
MLWDF ou Modified Largest Weighted Delay First, EXPPF ou Exponential Proportionnal Fair,
PPM ou Packet Prediction Mechanism effectuées à l’aide de LTE-Sim. Le scénario d’évaluation se
décrit par la transmission de trois différents flux de service à savoir un flux de trafic voix sur IP, un
flux de trafic vidéo et un flux de trafic normal sans beaucoup de contrainte de QoS comme la

86
navigation web appelé ici flux best effort (Cf. Annexe 2). La transmission se fait à partir de la PDN-
Gateway qui joue le rôle de source de donnée et se termine aux User Equipment ou équipements
utilisateurs qui seront les destinataires. La transmission s’effectuera alors en voie descendante et ne
sera mesuré que sur une seule cellule mais une cellule qui subira l’influence des cellules voisines.
Ce scénario est prédéfini dans LTE-Sim sous le nom de /lte-sim/src/scenarios/single-cell-with-
interference.h. Ce scénario considère les influences possibles des eNodeB voisins qui peuvent
générer des interférences radio produits par les eNodeB des cellules entourant la cellule centrale.

Figure 5.01 : Single-Cell with Interference scénario

Les mesures seront collectées par rapport à un nombre croissant d’utilisateurs (UE) dans la cellule
centrale étudiée pour voir le comportement des algorithmes si la cellule devient de plus en plus
encombrée.

5.3.3.2 Paramètres de simulation

Les paramètres de simulation seront illustrés dans le tableau ci-dessous. Les paramètres qui ne sont
pas explicitement mentionnés prendront les valeurs par défaut définis dans le simulateur [33]
Paramètres Valeurs
Nombre de cellule pris en compte 10
Nombre minimum d’UE dans la cellule 10
centrale
Intervalle entre les UEs 2
Nombre maximum d’UE dans la cellule 100
centrale

87
 Nombre d’eNodeBs 1 par cellule
Rayon de transmission des eNodeBs 3 km
Largeur de bande en lien descendante 10 MHz
Nombre de PRB (Physical Ressource Block) 100 (12 sous-porteuses par PRB)
Schéma de modulation et de codage QPSK, 4QAM, 16QAM
Nombre de flux Video émis par la source 1 en temps reels encodé par H.264 prélevé dans
flows/application/Trace/foreman_H264_128k.d
at
Débit d’émission de la Vidéo 128 kbps
Nombre de flux VoIP 1
Nombre de flux Best Effort 1
Générateur de trafic Trace-based
Ordonnanceur en Downlink PF, MLWDF, EXPPF, PPM
Structure de trame FDD (Frequency Division Duplex)
Modèle de mobilité des UEs Random Direction
Delay Bound 0.5 s
Durée des flux 120 s
Durée de la simulation 180 s

Tableau 5.01: Paramètres de simulation

5.4 Aspect et principe de simulation

Dans le cadre de l’évaluation du scheduling, un nouvel algorithme a été annoncé par la littérature
comme performant en termes de respect de la qualité de service. Cet algorithme se nomme PPM
(Packet Prediction Mechanism). Le travail consiste à l’implémenter au sein de l’eNodeB du
framework LTE-Sim et à en évaluer la performance.

5.4.1 Fonctionnement de l’algorithme PPM

Dans le but d’atteindre une performance optimale en download pour différentes applications afin de
satisfaire les exigences en QoS, Les algorithmes de scheduling en downlink jouent un rôle important
dans la détermination des PRB (Physical Resource Block) et la manière dont ils seront alloués à

88
chaque flux de bits. Les stratégies de scheduling pour les flux doivent prendre en compte l’allocation
des PRBs autant dans le domaine temporel que fréquentiel.
L’algorithme PPM consiste en trois phases : en premier lieu, il exploite efficacement les PRB dans
le domaine fréquentiel, il gère ensuite les files d’attente et prédit les comportements des futurs
paquets des files basés sur ceux en cours et reposant sur le concept de la queue virtuelle. Enfin, il
incorpore un processus cut-in pour réarranger l’ordre de transmission et se débarrasser des paquets
en retard basé sur les informations de prédiction des précédentes phases [34].

5.4.1.1 Phase 1 : Ordonnancement initial des PRB

Cette phase opère dans le domaine fréquentiel dans le but d’atteindre de bons débits, le PRB est
alloué à l’UE avec le meilleur CQI (Channel Quality Indicator) parmi tous les autres UE :

, = max , (5.06)

5.4.1.2 Phase 2 : Gestion des files d’attente et prédiction des délais des paquets

Contrairement à la phase précédente, la phase 2 traite les UE dont la valeur de leur CQI n’est pas
bonne. Les paquets émis par ces utilisateurs peuvent ne pas arriver à temps à leurs destinations. Si
l’algorithme ne considérait que la maximisation du débit, il y aurait plusieurs paquets en retard qui
seront supprimés à destination. Plutôt, le type de paquets, les délais et l’horodatage doivent être
considérés. L’horodatage se réfère à l’instant où les paquets sont générés à la couche application.
Les paquets continus se trouvant dans une même file MAC doivent être de même type et avoir la
même exigence en délai. Le paquet i dans la file k pour l’UE x ne sera pas transmis à temps si :

, − − , < , + (5.07)

1. Scénario A : La file k contient des paquets qui ne peuvent être transmis à temps, et le dernier
paquet de ces paquets en retard se trouve dans la file
Quand il y a des paquets anticipés comme n’arrivant pas à temps dans la file, il y a deux situations
possibles comme l’illustre la figure (5.03).
Dans la situation 1, il y a des paquets en retard dans la file mais le dernier paquet de la file peut être
transmis à temps. Dans la situation 2, la différence est que le dernier paquet fait partie des paquets
en retard et ne peut donc pas être transmis à temps.

89
 Figure 5.02 : Deux situations de paquets en retard, scénario A

Le premier et le dernier paquet dans la file k peuvent être identifiés comme suit :
= arg min( , − − , < , + ) (5.08)

ℎ = arg max( , − − , < , + ) (5.09)

Le taux de perte de paquets estimé est de :

ℎ + +1 (5.10)
=
+ℎ
Les exigences en QoS pour les paquets dans la file k ne peuvent être remplies si est plus grand
ou égal au seuil prédéfini , ensuite le processus cut-in de la phase 3 intervient. Autrement, les
paquets en retard seront supprimés car le fait d’avoir plus petit que signifie que la file peut
tolérer un taux plus élevé de perte de paquets. Dans ce cas, le processus cut-in ne sera pas appelé.

2. Scénario B : La file k contient des paquets qui ne peuvent être transmis à temps, et le dernier
paquet de ces paquets en retard ne se trouve pas dans la file
Pour les paquets qui ne sont pas dans la file k, une queue virtuelle sera utilisée pour les stocker. Le
but est de prédire l’arrivée et le temps de réception des futurs paquets entrants dans la file d’attente
physique k et/ou la queue virtuelle, basé sur les inter-arrivées et le temps de réception des paquets
en cours. Les prédictions peuvent déterminées si un nouveau paquet entrant peut être transmis à
temps ou non.

90
 Figure 5.03 : Deux situations de paquets en retard, scénario B

Pour trouver les positions du premier et du dernier paquet en retard dans la queue virtuelle, la
moyenne des inter-arrivées et des temps de réception des paquets courants dans la file k doit être
calculée d’abord :

1 , − ,
∆ = , − , = (5.11)

1 , − ,
∆ = , − , = (5.12)

Où est le nombre de paquets dans la queue k. Le ( − 1)-ième paquet, qui est le dernier paquet,
sera transmis dans le cycle:

, = (5.13)

Ainsi, le temps nécessaire pour transmettre paquets dans la file k est:

= , (5.14)

91
Ce temps ainsi que la moyenne des temps d’inter-arrivées calculée précédemment permet d’estimer
le nombre de nouvelles arrivées des paquets dans la queue k durant l’intervalle pendant laquelle
tous les paquets en cours dans la file seront transmis :

= (5.15)
∆
Le temps d’arrivée et le temps de réception estimés pour le paquet n dans la queue virtuelle pour la
file k sont respectivement:
, = , + ( + 1)∆ (5.16)

, = , + ( + 1)∆ (5.17)
Il est à noter que le compteur n est utilisé pour numéroter le nombre de paquet dans la queue virtuelle
afin de le différencier du compteur i utilisé dans la file d’attente physique k.
Ensuite, l’intervalle de transmission pour le n-ième paquet dans la queue virtuelle peut être estimé
par :
+ +1
, = (5.18)

D’un autre côté, le paquet n ne sera pas transmis à temps si :

, − − , < , + (5.19)
A la fin, les positions du premier et dernier paquets qui peuvent devenir en retard dans la queue
virtuelle de la file k peuvent être trouvées par :
= arg min( , − − , < , + ) (5.20)

= arg max( , − − , < , + ) (5.21)

Le taux estimé de perte de paquets est alors calculé par la formule suivante :
(ℎ −
+ 1)( ℎ − + 1)
⎧ 0≤( ℎ − )< ℎ
⎪ +ℎ + ℎ
= + ( ℎ − )≥ ℎ (5.22)
⎨(ℎ − + 1)
⎪ ê é
⎩ +ℎ
Où ℎ est un seuil dont la valeur peut être modifiée en une valeur plus large que la taille de la file
k, permettant d’évaluer si le taux d’arrivée des paquets est plus grand que le taux de départ, et est
un nombre petit qui assure l’entrée du processus cut-in pour manipuler la perte de paquets dans la
file k. Pour simplifier, ℎ est posé à 1 paquet plus large que la taille de la file k pour l’UE x et
égal à 0.1. Pour le cas où ne peut être trouvé, c’est le cas quand le paquet dans la dernière espace

92
de la file k est aussi le dernier paquet en retard, signifiant que les paquets en retard à travers la file
physique peuvent être omis.
Si l’ calculé est plus grand ou égal au seuil , les exigences en QoS des paquets dans la file
virtuelle/physique ne peuvent être satisfaites, le processus cut-in en phase 3 sera alors invoqué.

3. Scénario C : Tous les paquets dans la file seront transmis à temps

Dans ce cas, le processus cut-in n’entrera pas en jeu. Ce scénario n’implique aucune gestion de flux
ni prédiction de délai.

5.4.1.3 Phase 3 : Processus cut-in

Le processus cut-in essaie de trouver un UE z parmi tous les candidats basé sur la formule :

, = , − , (5.23)
Il cherche itérativement un UE z qui possède le moins de diminution en débit jusqu’à ce que tous
les utilisateurs candidats soient traités ou tous les PRB alloués. Si tous les candidats ont été traités,
les PRB restants seront alloués aux utilisateurs avec un débit maximal. Si tous les PRB ont été
alloués, les utilisateurs candidats ont besoin de plus de PRB que les PRB disponibles. Si le processus
cut-in n’est pas sollicité, le PRB y est alloué à l’utilisateur x supportant le maximum de débit. En
général, les utilisateurs candidats cut-in supportant les plus élevés débits sont sélectionnés pour
utiliser les PRB.

5.5 Interprétation des résultats

La simulation s’organise en deux parties. La première consiste à comparer les algorithmes respectant
la qualité de service (algorithmes multi-classes), soit EXPPF et PPM, avec les autres catégories
d’algorithmes comme le PF (algorithme opportuniste maximisant le débit) et le MLWDF
(algorithme considérant les délais). Les algorithmes équitables n’ont pas fait l’objet de comparaison
car la notion d’équité a été redéfinie due à l’existence de plusieurs classes d’utilisateurs. La seconde
partie se focalise sur l’évaluation en performance de QoS de l’algorithme le plus efficace.

5.5.1 Comparaison des algorithmes

La comparaison des algorithmes consiste à visualiser les résultats et performances de chaque

algorithme d’ordonnancement par rapport aux autres. Les algorithmes étudiés sont le PF, MLWDF,
EXPPF et PPM selon chaque type de trafic (BE, vidéo et VoIP) en fonction du délai de transmission,
de la gigue, du taux de perte de paquets et du débit de transmission [35] [36].

93
La simulation n’étant pas évaluée dans le temps mais en fonction du nombre d’utilisateurs dans une
cellule, les valeurs énumérées sur les figures qui vont suivre sont les moyennes de valeurs obtenues
lors d’une évaluation temporelle pendant 120 s (secondes).

5.5.1.1 Le trafic Best Effort ou BE

1. Délai de transmission à travers le réseau PDN

Figure 5.04 : Comparaison algorithmes pour trafic BE en délai

Le délai de transmission pour le trafic Best Effort ou BE varie entre 100 ms (millisecondes) et 1 s
pour PF, mais n’atteint pas 700 ms pour PPM comme le montre la figure 5.04. Pour tous les
algorithmes, on remarque une tendance haussière quand le nombre d’utilisateur augmente. Cela
s’explique par le fait que plus les utilisateurs deviennent nombreux, plus les ressources deviennent
insuffisantes et le trafic BE délaissé au profit des trafics temps réels. L’algorithme PF présente un
délai élevé par rapport aux autres car PF ne considère pas vraiment la minimisation des délais mais
considère plutôt la maximisation des débits et l’équité entre utilisateurs. EXPPF est une amélioration

94
de PF et considère le délai et MLWDF est conçu de façon presque similaire à EXPPF, ce qui
explique les résultats proches des deux algorithmes. De l’autre côté, PPM arrive quand même à
garder un certain niveau de délai même pour le flux BE et cela grâce à la différenciation de trafic.

2. Gigue des trafics

L’évaluation de la gigue pour le trafic BE se trouve sur la figure 5.05. PF affiche une valeur de gigue
entre 100 ms et 1,1s, MLWDF et EXPPF en enregistre entre 100 ms et 850 ms. L’algorithme PPM
ne dépasse pas les 700 ms. Le trafic BE n’étant pas soumis à des contraintes concernant la gigue,
on constate toujours que l’algorithme PPM reste le plus performant, cela découle même de
l’introduction du mécanisme de prédiction pour les flux.

Figure 5.05 : Comparaison algorithmes pour trafic BE en gigue

3. Taux de perte de paquets

On constate donc pour le résultat du taux de perte de paquets, figure 5.06, que les algorithmes ont
presque tous les mêmes performances pour le trafic BE. La valeur du taux de perte de paquets est

95
pour une situation de faible charge de l’ordre de 0.02 à 0.04, soit 40 paquets perdus pour 1000
envoyés. Pour une situation de moyenne charge, elle est de l’ordre de 0.06.
A partir d’une certaine valeur, le taux de perte a tendance à augmenter rapidement du fait que les
ressources ne suffisent plus et les trafics BE connaissent alors de plus importante perte de paquets.

Figure 5.06 : Comparaison algorithmes pour trafic BE en PELR

4. Débit de transmission
La figure 5.07 montre le résultat de la simulation pour le débit du trafic BE. On constate que les
algorithmes MLWDF et EXPF présentent les meilleurs performances en débit pour le trafic BE. La
tendance descendante des courbes est due au fait que les débits sont alloués aux flux plus prioritaires
donc une diminution des débits des flux BE pour une charge croissante. Les débits sont de l’ordre
de 10 à 40 Mbps (Mégabits par seconde).

96
 Figure 5.07 : Comparaison algorithmes pour trafic BE en throughput

5.5.1.2 Le trafic Vidéo

1. Délai de transmission à travers le réseau PDN

Pour le trafic vidéo, le délai est une des exigences importantes car il s’agit d’un flux de streaming
vidéo qui doit être fluide à la visualisation. Le streaming vidéo doit donc avoir un délai inférieur à
400 ms, qui est une limite largement atteinte (figure 5.08). L’algorithme MLWDF étant optimisé
sur les délais, il présente une bonne performance par rapport à PF et EXPPF. L’algorithme PPM
reste modeste dans les situations de faible charge mais se démarque de plus en plus pour la charge
croissante. Cette performance s’explique grandement par le mécanisme de prédiction présent dans
PPM, abordé dans les parties précédentes.

97
 Figure 5.08 : Comparaison algorithmes pour trafic vidéo en délai

2. Gigue des trafics

L’exigence la plus stricte pour le trafic vidéo streaming est la gigue. Elle doit avoir la valeur la plus
faible et constante possible. Ce qui met en évidence la performance de l’algorithme PPM, c’est qu’il
présente une gigue constante par rapport au nombre d’utilisateurs contrairement aux autres
algorithmes comparés comme la figure 5.09. En outre, l’algorithme PPM présente une valeur de
gigue la plus faible pour une situation de charge moyenne. La valeur se trouve entre 10 et 100 μs
(microsecondes) pour un nombre d’utilisateur inférieur à 100.

98
 Figure 5.09 : Comparaison algorithmes pour trafic vidéo en gigue

3. Taux de perte de paquets

La figure (5.10) illustre les résultats collectés en termes de taux de perte de paquets toujours pour le
flux de vidéo streaming. La valeur est de l’ordre de 0.004 et ne dépassant pas 0.01 pour PPM, mais
elle atteint jusqu’à 0.014 pour l’algorithme PF. Les trois algorithmes MLWDF, EXPPF et PPM
peuvent être considérés comme ayant des valeurs de taux de perte de paquets acceptables pour la
vidéo (ne dépassant pas 0.01). L’algorithme PF n’arrive pas à respecter cette contrainte car la
priorité prise en compte par cet algorithme est surtout le débit avec une tentative de maximiser au
mieux les paramètres d’équité de partage des ressources entre les utilisateurs. Le taux de perte de
paquets est également important car pour une perte importante, les retransmissions HARQ peuvent
impacter sur le délai des paquets donc de la fluidité du rendu vidéo à la destination.

99
 Figure 5.10 : Comparaison algorithmes pour trafic vidéo en PELR

4. Débit de transmission
Le débit du trafic vidéo streaming étant le paramètre étudié sur la figure 5.11, il est à remarquer
qu’il s’agit ici du débit de transmission et non pas du débit d’information. Le débit de transmission
(throughput) étant le nombre de bits effectivement transmis sur les supports par unité de temps
tandis que le débit d’informations (goodput) représente la quantité de bits porteurs d’information
utile pour l’utilisateur (sans la signalisation, les redondances, etc.) par mesure temporelle
élémentaire. Il est aussi à noter que la valeur collectée s’agit de l’ensemble des débits d’un flux, flux
vidéo ici, pour le nombre d’utilisateurs spécifiés et non un débit individuel. Pour un nombre faible
d’utilisateur, le nombre de flux vidéo transitant dans le réseau reste également faible, mais le débit
exigé par la vidéo lui est alloué, soit pour notre simulation un débit de 128 kbps (kilobits par
seconde) par utilisateur. Au fur et à mesure que le nombre d’utilisateur augmente, la bande passante
devient vite occupée par tous les flux vidéo envoyés par tous les utilisateurs, cependant le trafic
VoIP qui possède une priorité encore plus élevée que la vidéo, a déjà réservé une partie des

100
ressources empêchant alors la vidéo d’utiliser toute la bande, ce qui justifie la limite supérieure en
débit que rencontrent les algorithmes PPM et PF. Les algorithmes EXPPF et MLWDF ne sont pas
aussi efficaces que PF et PPM car ils n’ont pas été conçus pour la maximisation des débits mais
plutôt pour le traitement différencié des flux pour EXPPF et le respect des délais pour MLWDF. PF
est performant ici car son but est d’essayer de maximiser le débit global du système en augmentant
le débit de chaque utilisateur en même temps. PPM arrive presque à la performance de PF étant
donné la première phase de son fonctionnement qui n’est autre que la maximisation des débits en
fonction du CQI et à cela s’ajoute dans la troisième phase le processus cut-in.

Figure 5.11 : Comparaison algorithmes pour trafic vidéo en throughput

5.5.1.3 Le trafic VoIP

1. Délai de transmission à travers le réseau PDN

La figure 5.12 représente le délai des flux de trafic VoIP pour chaque algorithme étudié. Le trafic
VoIP est un des trafics les plus exigeants en termes de délai de transmission car un délai même pas

101
trop élevé mais dépassant une certaine limite seulement est directement perceptible par les
utilisateurs du réseau. La limite au-dessus de laquelle ce délai de transmission devient perceptible
par l’utilisateur est de 400 ms. La norme 4G impose cependant une limite de 300 ms. Pour notre
simulation, le délai ne dépasse pas les 150 ms et pour l’algorithme proposé (PPM), elle est entre 3
et 90 ms selon la charge de la cellule étudiée. La priorisation du trafic VoIP est complètement gérée
par l’algorithme PPM dans la phase 2 et elle est encore améliorée par l’introduction du mécanisme
de prédiction des situations des futures paquets entrants dans le file d’attente MAC. Les autres
algorithmes présentent également des performances assez intéressantes.

Figure 5.12 : Comparaison algorithmes pour trafic VoIP en délai

2. Gigue des trafics

L’illustration de la gigue est visualisée sur la figure 5.13 pour le trafic VoIP. La gigue doit être de
faible valeur constante surtout pendant la période ON du trafic (Voir Annexe 1) comme pour la
vidéo en streaming. Cette exigence est largement atteinte ici car la valeur de la gigue se trouve entre
2 et 85 μs, meilleure que pour la vidéo.

102
 Figure 5.13 : Comparaison algorithmes pour trafic VoIP en gigue

3. Taux de perte de paquets

On trouve sur la figure 5.14 le résultat de l’évaluation par simulation du trafic VoIP en termes de
taux de perte de paquets. Ce taux est de l’ordre de 0.01 à 0.014 en moyenne et il présente des résultats
moins bons que ceux de flux de vidéo en streaming. Cela s’explique par le fait que la VoIP n’a pas
d’exigence forte en perte de paquets à condition d’avoir rempli les conditions en délai car pour les
paquets perdus, le mécanisme de retransmission HARQ permet de renvoyer rapidement ces paquets
qui sont de plus de petite taille. L’algorithme PPM présente une courbe qui ne contient pas beaucoup
de variation par rapport aux autres, cela est dû au fait que la perte de paquet au niveau de cet
algorithme se produit de façon prévisible car l’algorithme lui-même prévoit la suppression des
paquets en cas de non-respect de délai.

103
 Figure 5.14 : Comparaison algorithmes pour trafic VoIP en PELR

4. Débit de transmission
L’évaluation des débits de transmission pour le trafic VoIP s’illustre sur la figure 5.15. On constate
que le débit possède une certaine proportionnalité avec le nombre d’utilisateurs pour certains
algorithmes. L’explication est que, pour les algorithmes qui considèrent les classes de services,
EXPPF et PPM dans notre cas, une certaine valeur de la bande passante est réservée pour être utilisée
par les flux exigeants comme la voix sur IP. Chaque appel VoIP doit donc forcément bénéficier de
sa propre bande passante. C’est pour cela que pour un nombre croissant d’utilisateurs dans une
cellule, le nombre de flux VoIP augmente également et le débit suivra la même tendance avec une
proportionnalité évidente car à tous les appels sont alloués des débits constants. Pour l’algorithme
PF, il essaie seulement d’augmenter les débits globaux du système sans prendre en compte les
classes de services et n’est plus efficace pour une charge de plus en plus grande. L’algorithme
MLWDF quant à lui ne gère pas les classes multiples et ne maximise pas le débit mais plutôt le
délai, ce qui explique son résultat.

104
 Figure 5.15 : Comparaison algorithmes pour trafic VoIP en throughput

5.5.2 Comparaison des services

Pour la comparaison des services, il s’agit de faire la différence entre les critères d’évaluation de
QoS pour chaque flux de service de données. Etant donné que l’algorithme PPM se démarque parmi
les autres d’après les résultats obtenus précédemment, car c’est un algorithme considérant la
différenciation de classe de service, il sera évalué sur les trafics Best Effort, vidéo et VoIP en termes
de délai de transmission à travers le réseau PDN, de la variation du délai ou gigue, du taux de perte
de paquets et du débit de transmission.

5.5.2.1 Délai end-to-end

La figure 5.16 montre le résultat de la simulation en termes de délai de transmission. La courbe

montre que la valeur du délai se trouve entre 3 et 90 ms (millisecondes) pour le trafic VoIP, ce qui
représente une valeur largement inférieure à la limite de 300 ms, à partir de laquelle l’utilisateur

105
pourrait remarquer ce délai perturbant. Le trafic vidéo quant à lui présente un délai entre 10 et 95
ms, qui est aussi inférieur à la limite pour les trafics en streaming de 400 ms. Le trafic Best Effort
cependant a un délai plus de 100 ms pour une charge faible et atteint jusqu’à 700 ms pour une charge
plus ou moins forte. Le trafic BE n’a pas de forte exigence en termes de délai par rapport aux deux
autres trafics. La courbe de délai augmente en fonction du nombre d’utilisateur étant donné
l’augmentation du nombre de flux prioritaire à prendre en compte. Ainsi, la différenciation de
service est ici mise en évidence et l’algorithme PPM offre une performance intéressante en termes
de délai de transmission pour les services temps-réels.

Figure 5.16 : Comparaison des services pour PPM en délai

5.5.2.2 Gigue des trafics

La figure 5.17 présente le résultat de la simulation pour la gigue. La gigue étant la variation entre
les délais des paquets, le flux vidéo en streaming présente une exigence stricte en termes de gigue

106
car la gigue ne doit pas dépasser la limite de 200 μs (microsecondes). Pour le flux VoIP, la gigue ne
dépasse pas les 100 μs et elle est encore mieux pour la vidéo car elle arrive à rester en dessous de
60 μs. Une fois de plus, le trafic BE ne nécessite pas de très bonne performance en gigue mais le
résultat montre qu’elle ne dépasse pas les gammes des 700 μs. L’algorithme PPM réussit à respecter
la contrainte en gigue des trafics qui en sont sensibles et cela grâce aux mécanismes de
différenciation de service.

Figure 5.17 : Comparaison des services pour PPM en gigue

5.5.2.3 Taux de perte de paquets

La simulation pour le taux de perte de paquets a donné le résultat de la figure 5.18 pour l’algorithme
PPM. On voit que PPM n’autorise pas une valeur élevée du taux de perte de paquet pour le trafic
vidéo surtout mais aussi pour le trafic VoIP contrairement au trafic BE. La gigue est particulièrement
importante pour les services en temps réels étant donné qu’une grande différence entre l’arrivée de

107
paquets consécutifs perturberait la fluidité du service et pour la vidéo, la taille du paquet étant assez
grande, une différence trop grande entre l’arrivée de deux paquets consécutifs sera considérée par
le récepteur comme une perte car le second paquet n’arrive pas en temps voulu. La notion de gigue
et de perte est donc étroitement liée, c’est pour cela qu’à une gigue moindre sera associée un taux
de perte de paquets faible. Pour les trafics en temps réels, le taux de perte ne dépasse pas 0.015, soit
15 paquets perdus pour 1000 paquets envoyés.

Figure 5.18 : Comparaison des services pour PPM en PELR

5.5.2.4 Débit de transmission perçu par l’utilisateur

Le débit de transmission est montré par la figure 5.19. On voit que le débit du trafic VoIP est
proportionnel aux nombres d’utilisateurs car le trafic VoIP réserve une partie des ressources et donc
chaque flux d’appel voix obtient un débit constant. Le flux vidéo en streaming obtient également
des débits jusqu’à ce que les ressources deviennent saturées en augmentant le nombre d’utilisateurs

108
dans une cellule. Le flux de trafic au mieux ou Best Effort quant à lui subit les variations de débits
des autres flux, il possèdera un débit élevé pour un nombre d’utilisateurs faible car les flux
prioritaires n’occupent encore qu’une faible partie des ressources. Au fur et à mesure que
l’occupation des flux prioritaires augmente, le débit du trafic BE diminue car il dispose de moins
de ressources étant donné qu’il n’utilise que les ressources restantes.

Figure 5.19 : Comparaison des services pour PPM en throughput

5.6 Conclusion

L’évaluation de l’influence des algorithmes de scheduling dans les réseaux LTE sur les paramètres
de QoS effectuée dans ce chapitre a permis de mettre en évidence l’efficacité de l’algorithme
d’ordonnancement Packet Prediction Mechanism ou PPM. L’algorithme n’a pas seulement permis
de respecter ces contraintes de QoS mais il a largement dépassé ces contraintes et son déploiement
dans un réseau LTE améliorera encore plus les performances déjà offertes par les exigences des
réseaux 4G.

109
 CONCLUSION GENERALE

Les réseaux LTE/EPC ne constituent pas seulement une évolution des réseaux de troisième
génération mais ils sont devenus la norme de réseau 4G la plus utilisée actuellement. Pour ces
réseaux, la qualité de service est un concept important pour la gestion d’un réseau tout IP. Les
concepts de file d’attente modélisant la différenciation de service basée sur les principes de
priorisation et de préemption ont été vus dans une première partie de ce mémoire. Cela a été suivi
par des informations sur l’organisation du réseau LTE/EPC. L’étude s’est alors poursuivie par
l’explication des mécanismes de qualité de service et du scheduling, nous avons alors pu mettre
l’accent sur quelques algorithmes d’ordonnancement qui ne sont autres que Proportionnal Fair,
Exponential Proportional Fair, Round Robin, Min-Max Fair, Modified Largest Weighted Delay
First et Packet Prediction Mechanism.
La dernière partie a permis de démontrer à partir des résultats de simulation que la qualité de service
sur le lien radio est effectivement influencée par les techniques d’ordonnancement, plus précisément
sur les paramètres de débit, de délai et perte de paquets, la gigue n’étant affectée que de façon
minime. Parmi les algorithmes étudiés, PPM présente la meilleure performance en termes de respect
des exigences en qualité de service et cela presque dans tous les paramètres, étant donné que c’est
un algorithme considérant les classes de services basé sur la prédiction. L’inconvénient de cet
algorithme réside néanmoins dans une performance moyenne en termes d’équité de partage entre
utilisateurs.

Ainsi l’algorithme PPM, qui a prouvé ses performances au niveau des réseaux de type 4G, pourrait
même pousser les limites et faire l’objet d’implémentation dans les futures générations de réseaux
(5G) en cours de normalisation, notamment la norme LTE-Advanced de type A et LTE-Advanced
de type B.

Bref, LTE a poussé les limites et les exigences en termes d’expérience utilisateur et a révolutionné
l’utilisation des terminaux mobiles. Il est aujourd’hui déployé dans de nombreux pays et
Madagascar en bénéficiera dans un futur proche étant donné que les opérateurs nationaux sont
actuellement dans les phases d’études pour son déploiement.

110
 ANNEXES

ANNEXE 1 LES PRINCIPAUX KPI EN LTE/EPC

Pour le réseau cœur EPC, les KPI sont les suivantes [32] :
A1.1. Les KPI d’accessibilité en EPC
 EPS Attach Success Rate : C’est un KPI qui décrit le taux de succès des procédures
d’attachement EPS par le rapport entre le nombre de procédures d’attachement exécutées et
le nombre de tentative d’attachement sur le réseau EPS.
∑ ℎ
= ∗ 100% (A1.01)
∑ ℎ

 Dedicated EPS Bearer Creation Success Rate : Ce KPI décrit le taux de succès de la création
de bearer EPS produit par le PDN-GW :
∑
= ∗ 100% (A1.02)
∑

 Dedicated Bearer Set-Up Time by MME(Mean) : Ce KPI décrit le temps de validation

moyenne de la procédure de configuration de chaque bearer dédié par le MME.

 Service Request Success Rate : C’est un KPI qui décrit le taux de succès des procédures de
requête de service effectué par l’UE :
∑
= ∗ 100% (A1.03)
∑

A1.2. Les KPI de mobilité en EPC

 Inter-RAT Outgoing Handover Success Rate (EPS=>GSM) : KPI indiquant le taux de succès
des procédures de handover sortant vers le réseau GSM :
∑ . .
= ∗ 100% (A1.04)
∑ . .
 Inter-RAT Outgoing Handover Success Rate (EPS=>UMTS) : KPI indiquant le taux de
succès des procédures de handover sortant vers le réseau UMTS :
∑ . .
= ∗ 100% (A1.05)
∑ . .

111
  Inter-RAT Outgoing Handover Success Rate (EPS=>CDMA2000) : KPI indiquant le taux
de succès des procédures de handover sortant vers le réseau CDMA2000 :
∑ . .
= ∗ 100% (A1.06)
∑ . .

 Inter-RAT Incoming Handover Success Rate (GSM=>EPS) : KPI indiquant le taux de succès
des procédures de handover entrant vers le réseau GSM :
∑ . .
= ∗ 100% (A1.07)
∑ . .

 Inter-RAT Incoming Handover Success Rate (UMTS=>EPS) : KPI indiquant le taux de

succès des procédures de handover entrant vers le réseau UMTS :
∑ . .
= ∗ 100% (A1.08)
∑ . .

 Inter-RAT Incoming Handover Success Rate (CDMA2000=>EPS) : KPI indiquant le taux

de succès des procédures de handover entrant vers le réseau CDMA2000 :
∑ . .
= ∗ 100% (A1.09)
∑ . .

 Tracking Area Update Success Rate : KPI indiquant le taux de succès de la procédure de
mise à jour de la zone de suivi pour évaluer la performance de mobilité en EPS.
∑( . + . )
= ∗ 100% (A1.10)
∑( . + . )

A1.3.Les KPI d’utilisation en EPC

 Mean Active Dedicated EPS Bearer utilization : KPI définissant le rapport entre le nombre
moyen de bearer EPS dédié actif par rapport au nombre maximal de bearer EPS dédié actif :
.
= ∗ 100% (A1.11)

112
Pour le réseau d’accès E-UTRAN, les KPI sont :
A1.4.Les KPI d’accessibilité en LTE
 E-RAB Accessibility : Probabilité du taux de succès de l’établissement d’un E-RAB

A1.5.Les KPI de maintien en LTE

 E-RAB Retainability : Une mesure qui montre combien de fois un utilisateur final perd
anormalement un E-RAB pendant le temps d’utilisation de l’E-RAB :
ERAB.RelActNbr.QCI QCI  x
R1QCI  x  (A1.12)
ERAB.SessionTimeQCI .QCI QCI  x

A1.6.Les KPI d’intégrité en LTE

 E-UTRAN IP Throughput : KPI indiquant le volume d’information utile au niveau IP par
unité de temps passé sur l’interface Uu :
Downlink ThpQCI  x  DRB.IPThpDlQCI  x (A1.13)

Uplink ThpQCI  x  DRB.IPThpUlQCI  x (A1.14)

 E-UTRAN IP Latency : KPI montrant la mesure de l’impact de l’E-UTRAN sur le délai des
paquets expérimenté par l’utilisateur final :
Downlink Lat QCI  x  DRB.IPLatDlQCI  x (A1.15)

A1.7.Les KPI de disponibilité en LTE

 E-UTRAN Cell Availability : Pourcentage de temps pendant lequel les cellules sont
considérées comme disponibles :
measurement_period -  RRU.CellUnavailableTime.[cause]
CellAvailability  cause
 100 (A1.16)
measurement _ period

A1.8.Les KPI de mobilité en LTE

 E-UTRAN Mobility : KPI mesurant le taux de succès de la procédure de handover
considérant à la fois les handovers inter E-UTRAN et inter-RAT :
HO.ExeSucc HO.PrepSuc c.QCI QCI  x
Mobility Success Rate QCI  x    100%  (A1.17)
HO.ExeAtt HO.PrepAtt .QCI QCI  x

113
 ANNEXE 2 : MODELES DE TRAFIC EN LTE

La caractérisation du trafic consiste à décrire ses composantes (voix, vidéo et données), à déterminer
les sources qui le génèrent et à identifier les paramètres qui l'influencent.

A2.1.Modélisation et caractérisation du trafic voix sur IP (VoIP)

Le trafic voix au niveau d’une source se caractérise par une période active pendant laquelle la source
parle suivie par une période inactive dite période de silence pendant laquelle la source garde le
silence. Durant la période active, la source émet des paquets à intervalles réguliers appelé temps de
paquétisation. Les durées des périodes actives et inactives étant complètement aléatoires, ces
périodes sont alors estimées par des lois exponentielles indépendantes [37].
Une application conversationnelle comme la voix sur IP peut être alors modélisée par un processus
ON/OFF. La période ON représente certainement la période d’activité et la période OFF représente
la période inactive.
La période ON peut représenter tout type d’activités dans les services applicatives, en fonction des
représentations mathématiques choisies, c’est-à-dire la distribution d’inter-arrivées et de la taille des
paquets.

Le modèle ON/OFF est un modèle markovien à deux états : la durée de chaque burst est
exponentiellement distribuée de moyenne 1 ms. Durant cette période, les paquets de voix sont

émis à un débit constant , le temps inter-arrivées étant de ms avec = . Cette période est suivie

par une période de silence qui est exponentiellement distribuée de moyenne 1 ms. On néglige les
identificateurs de silence de la période OFF [38].

Figure A1.01 : Trafic ON/OFF

114
  le taux d’arrivée des paquets durant la période ON :
= 1/ (A2.01)

 le taux moyen d’arrivée des paquets :

= (A2.02)
( + )

 la durée moyenne de la période ON :

= 1/ (A2.03)

 le burstiness du traffic ( p ) :
m
+
= (A2.04)

avec a et b les taux de transition : a est l’inverse de la durée moyenne du burst et b est l’inverse de
la durée moyenne de la période de silence.
Les paramètres du ON/OFF utilisés pour modéliser une source de voix sont :

 1 / a =352 ms
 1 / b =650ms
 T=20ms
Pour envoyer la voix sur un réseau numérique, il va falloir convertir le signal analogique de la voix
en un signal numérique en format PCM (Pulse Code Modulation). Une fois convertie, la voix, ainsi
numérisée, doit être compressée grâce à un codec (Codeur/Décodeur) pour l'insérer dans un paquet
IP. Le codage doit offrir la meilleure qualité de voix possible, pour un débit le plus faible possible
et un temps de compression le plus court possible.
Les codecs les plus utilisés sont illustrés dans le tableau suivant.

Nom du codec Debit du codec

G.711 64 kbps
G.723.1 6,4 kbps
G.726 32 kbps
G.729 8 kbps
Tableau A2.01 : Débit par codec audio

115
Pour les réseaux de type 4G, des optimisations ont été apportées pour donner naissance au VoLTE.
VoLTE est l’acronyme de Voice over LTE (voix sur LTE) et désigne la principale technique de
transport de la voix sur les réseaux de téléphonie mobile 4G LTE. Le codage de la voix est de type
« voix sur IP » (VoIP), mais il est optimisé pour la téléphonie mobile.
Pour assurer la compatibilité avec les autres réseaux mobiles et les téléphones / smartphones plus
anciens, la norme VoLTE impose que les terminaux mobiles soient compatibles avec le codec
AMR-NB (Adaptive Multi-Rate Narrowband), à bande étroite, déjà utilisé dans les réseaux GSM et
UMTS, mais le codec vocal préconisé pour la VoLTE est le codec large bande Adaptive Multi-Rate
Wideband (AMR-WB), également connu sous le nom HD Voice. Ce codec est défini par la norme
G722.2 de l'UIT.

Les débits et les délais de ce type de trafic doivent permettre à l'utilisateur d'avoir la qualité de
service exigée par ce type d'applications. Ce débit doit varier entre 32 kbps et 384 kbps, tandis que
le délai ne doit pas dépasser les 400 ms.

A2.2.Modélisation et caractérisation du trafic vidéo

Le système LTE/EPC a permis un certain nombre de service vidéo comme la visiophonie, la
vidéoconférence, le streaming vidéo, la vidéo à la demande (VoD :Video on Demand), etc. Selon
ces applications, les critères en termes de qualité de service peuvent être différents, certaines peuvent
avoir les mêmes exigences que la voix, d’autres sont plus tolérants. Le cas contraignant, par
exemple, de la vidéophonie qui consiste à converser avec un interlocuteur tout en le visualisant sur
l'écran du terminal mobile. La caractéristique majeure des applications de type vidéo est l'utilisation
d'une bande passante plus grande. En effet, ce type de trafic n'a fait son apparition que dans la
dernière décennie, à l'arrivée du GPRS qui a comblé le problème des ressources inadaptées pour la
transmission de la vidéo dans les systèmes GSM : la largeur de bande d'un canal de transmission
était égale à 200 kHz et le débit était égal à 9.14 kbps [39]. L'UMTS et les autres systèmes de la
troisième génération ont augmenté encore plus ces caractéristiques (3.84 MHz comme largeur de
bande de chaque canal de transmission et au moins 114 kbps pour le débit), ce qui a permis d'offrir
plus d'applications vidéo [39], [40]. La technologie LTE pousse encore plus loin cela car les
systèmes peuvent posséder une bande passante de largeur allant jusqu’à 20MHz avec un débit de
l’ordre de plusieurs Mbps (Mégabits par seconde).

116
Selon le service sollicité, les caractéristiques du trafic vidéo changent. Par exemple, pour le service
de la vidéophonie, le débit doit être au moins égal à 32 kbps et le délai peut atteindre 400 ms.
Toutefois, pour la visualisation d'une vidéo à partir d'un terminal mobile, le trafic exige un délai de
transmission maximal de 10 s et d'un débit variant entre 10 et 128 kbps [41]. En général, le délai de
bout-en-bout est considéré bon s'il ne dépasse pas 150 ms et acceptable s'il varie entre 150 ms et
300 ms.

A2.3.Modélisation et caractérisation du trafic web

Une source de trafic WWW (World Wide Web) est représentée par un ensemble de sessions (de
durée moyenne 200s) de consultations de sites web sur internet. Une session web est constituée
d’une suite d’appels de paquets (packet calls). Un packet call ou appel correspond à la demande de
téléchargement d’un fichier HTML (HyperText Markup Language). La taille d’un appel est une
variable aléatoire S qui suit une loi de Pareto bornée. La taille moyenne d’un packet call est alors
donnée par la formule suivante :

− (A2.05)
=
−1
Où k et m sont respectivement la taille minimale et la taille maximale d’un packet call et est le
facteur de Fano.
D’après les spécifications du 3GPP, les valeurs adoptées pour ces paramètres sont :
Si le trafic est de classe tâche de fond :
 =1.1,
 k=1858 octets,
 m=5000000 octets
et ils valent pour la classe interactive :
 =1.1,
 k=81.5,
 m=66666.
Entre deux packet calls successifs se trouvent un intervalle de temps appelé reading time. La
longueur de cet intervalle est une variable aléatoire qui suit une loi exponentielle d’une valeur
moyenne de 12 secondes. Le nombre de packet calls dans une session web est géométriquement
distribué avec une moyenne de 5.

117
A2.4.Modèle de trafic File Transfert Protocol (FTP)
On peut considérer une session FTP comme un transfert d’un seul fichier. La taille de ce fichier est
une variable aléatoire qui suit une distribution de Pareto normale. La taille d’un fichier FTP est
exprimée par :
(A2.06)
=
−1
Où k et m sont toujours respectivement la taille minimale et la taille maximale d’un paquet et est
le facteur de Fano.
La taille minimale d’un fichier FTP est k = 3000 octets mais la distribution de Pareto n’est pas
bornée ce qui permet d’avoir des fichiers de taille très élevée. La taille moyenne d’un fichier FTP
est égale à 53 Ko et la valeur choisie pour le facteur de Fano est 1.06.

118
 BIBLIOGRAPHIE

[1] A.N. Rakotomalala, « Amélioration des paramètres de qos dans les réseaux umts
au niveau du service level agreement (SLA) », Mémoire de fin d’études,
Département Télécommunication, ESPA, Université d’Antananarivo, Avril 2011
[2] S. Roche, « Gestion des opérations », Partie 5 : La gestion et l'exploitation du
système, Chapitre 19: les files d'attente, 2008
[3] G. Pujolle, S. Fdida, « Modèles de systèmes et de réseaux, tome II – Files
d’attente», Eyrolles, Paris, avril 1989
[4] J. Fetindrainibe, « Les mécanismes de qualité de service dans les réseaux IP »,
Mémoire de fin d’études, Département Télécommunication, ESPA, Université
d’Antananarivo, Avril 2014
[5] H. A. Taha, «Operations Research: An Introduction», McMillan Publishing
Company, 1992
[6] F. Baccelli, P. Brémaud, « Théorie de file d’attente », Springer-Verlag, Berlin,
1994
[7] M.H.A. Davis, « Markov models and optimization », Chapman & Hall, Londres,
1993
[8] S. Jouhri, « Mesures de performances pour des files d'attente multi-classes avec
abandon », laboratoire G-SCOP, Mai 2012
[9] O. Boxma, D. Perry, W. Stadje, « The M/G/1+G queue Revisited », Queueing
systems, Mars 2011
[10] B. Choi, B. Kim, J. Chung, « M/M/1 queue with impatient customers of higher
priority », Queueing systems, 2001.
[11] S. Rao, «Queuing with balking and reneging in M/G/1 systems», Metrika Comp.,
1967
[12] D. P. Gaver, «A waiting line with interrupted service, including priorities »,
Journal of the Royal Statistical Society, Series B (Methodological), Vol. 24, 1962.
[13] P. H. Brill, « System point theory in exponential queues », Dissertation Abstracts
International Part B: Science and Engineering, 1989.
[14] P. H. Brill, « An embedded level crossing technique for dams and queues », Journal
of Applied Probability, 1979.

119
[15] R. E. Stanford, « Reneging phenomena in single channel queues », Mathematics of
Operations Research, Vol. 4, Mai 1979.
[16] Y. Bouguen, E. Hardouin, F.X. Wolff, « LTE et les réseaux 4G », Edition Eyrolles,
Septembre 2013
[17] 3GPP Group Radio Access Network, « Evolved Universal Terrestrial Radio
Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-
UTRAN) », Release 8, TS 36.300, Décembre 2007
[18] 3GPP Group Services and System Aspects, « General Packet Radio Service
(GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access », Release 10, TS 23.401, Mars 2012
[19] 3GPP Group Radio Access Network, « Evolved Universal Terrestrial Radio
Access Network (E-UTRAN) : S1general aspects and principles », Release 11, TS
36.410, Septembre 2013
[20] 3GPP Group Radio Access Network, « Evolved Unversal Terrestrial Access
Network (E-UTRAN) : S1 data transport », Release 8, TS 36.414, Juin 2008
[21] 3GPP Group Radio Access Network, « Evolved Universal Terrestrial Radio
Access Network (E-UTRAN) : X2 general aspects and principles », Release 8, TS
36.420, Decembre 2007
[22] 3GPP Group Radio Access Network, « Evolved Universal Terrestrial Radio
Access Network (E-UTRAN) : X2 data transport », Release 10, TS 36.424, Juin
2011
[23] Sandvine, « Network Policy Control and the Migration to LTE », Intelligent
Broadband Network, Novembre 2013
[24] 3GPP Group Services and System Aspects, « Policy and charging control
architecture », Release 10, TS 23.203, Mars 2012
[25] ETSI, « Policy and Charging Control (PCC); Reference points », Release 10, TS
129.212, Janvier 2013
[26] 3GPP Group Core Network and Terminals, « Policy and Charging Control (PCC);
Reference points », Release 11, TS 29.212, Décembre 2012
[27] M. K. Rastogi, « Developping a QOS aware Framework for LTE », Aricent Group,
2012

120
[28] 3GPP Group Radio Access Network, « Evolved Universal Terrestrial Radio
Access Network (E-UTRAN); Radio Resource Control (RRC); Protocol
Specification », Release 10, TS 36.331, Novembre 2011
[29] Y. Ofuji, A. Morimoto, S. Abeta, M. Sawahashi, « Comparison of packet
scheduling algorithms focusing on user throughput in high speed downlink packet
access », Proceedings of the 13th IEEE Symposium on Personal, Indoor and
Mobile Radio Communications, Décembre 2002
[30] F. Bendaoud, M. Abdennebi, F. Didi, «Allocation des ressources radio en LTE»,
University of A.MIRA Bejaia, Avril 2014
[31] R. Basukala, H. M. Ramli, K. Sandrasegaran, « Performance analysis of exp/pf and
m-lwdf in downlink 3gpp lte system », IEEE First Asian Himalayas Conference,
Vol. 1, November 2009.
[32] 3GPP Group Core Network and Terminals, « Key Performance Indicators (KPI)
for the Evolved Packet Core (EPC); Definitions », Release 11, TS 32.455, Octobre
2012
[33] Groupe Projet MIRES, « Classification des fonctionnalités implémentées par le
logiciel LTE-Sim (version 4.0) », 2012
[34] W. Lai, C. Tang, « QoS-aware downlink packet scheduling for LTE networks »,
Computer Networks: The International Journal of Computer and
Telecommunications Networking, vol. 57 issue 7, Mai 2013
[35] M. A. Rakotomalala, « Réseaux 2G, 3G et 4G », Cours S9-TCO, Département
TCO-ESPA, AU 2013-2014
[36] A. A. Randriamitantsoa, « Outil de planification des réseaux », Cours S10-TCO,
Département TCO-ESPA, AU 2013-2014
[37] H. Hassan, « Modélisation générique de sources de trafic multimédia dans un outil
de simulation », Université Paul Sabatier, Laboratoire d’analyse et d’architecture
des systèmes, 2006
[38] M. H. Geha, « Modélisation des sources », Université Saint-Joseph, Diplôme
d’études approfondies, Décembre 2003
[39] J. Sanchez, M. Thioume, « UMTS, services, architecture, et WCDMA », Hermès
science, 2001

121
[40] J-F. Navienier, « Architecture reconfigurable pour les numérisations du signal
radio de récepteur mobile multi-standard », ENST-COMELEC, Février 2003
[41] X. Lagrange, « Réseau mobiles 2 G et 3G », Dép. RSM, ENST Bretagne, Décembre
2004

122
 FICHE DE RENSEIGNEMENTS

Nom : ANDRIAMIFIDY
Prénoms : Irina Nalijaona
Adresse de l’auteur : Lot 20 I 20 Andranomadio
Antsirabe 110 – Madagascar
Tel : +261 34 04 510 87
E-mail : nalijaon@yahoo.fr

Titre de mémoire :
« INFLUENCE DU SCHEDULING SUR LA QUALITE DE SERVICE DANS LES RESEAUX
LTE »

Nombre de pages : 123

Nombre de tableaux : 04
Nombre de figures : 52

Directeur de mémoire :
Nom : RAKOTOMALALA
Prénoms : Mamy Alain
Grade : Maître de conférences
E-mail : rakotomamialain@yahoo.fr
Tel : +261 33 12 036 09

123
 RESUME

Les opérateurs et fournisseurs de services ne cessent de chercher des idées pour rentabiliser leurs
réseaux tout en essayant d’offrir le maximum de satisfaction à leurs clients. Allouer les ressources
aux utilisateurs pouvant supporter des débits élevés peut rentabiliser le réseau mais délaisser des
utilisateurs en mauvaises conditions, ce qui diminue la qualité de service et l’expérience utilisateur.
Un algorithme qui gère les différentes classes de services qui, associé à l’implémentation des
différenciations des catégories d’utilisateurs, s’avère être un compromis intéressant étant donné la
priorisation de flux selon les services et la souscription de l’abonné.

Mots-Clés:
LTE, QoS, Ordonnancement, KPI, PPM.

ABSTRACT

Operators and service providers continue to look for ideas to monetize their networks while trying
to provide maximum satisfaction to their customers. Allocate resources to users that can support
high flow rates can monetize the network, but abandon users in poor conditions, which reduces the
quality of service and user experience. An algorithm that manages the different classes of services,
associated with the implementation of the differentiation of user categories proves to be an
interesting compromise since flows are prioritized according to the services and user subscription.

Keywords:
LTE, QoS, Scheduling, KPI, PPM.

124