These Samhat

8/8/2019 These Samhat

1/132

THESE DE DOCTORAT DE LUNIVERSITE PARIS 6

Specialite

Informatique

presentee par

Abed Ellatif SAMHAT

pour obtenir le grade de

DOCTEUR DE LUNIVERSITE PARIS 6

LA QUALITE DE SERVICE DANS LE RESEAU DACCES

RADIO TERRESTRE UMTS BASE SUR IP

Soutenance prevue le 11 Octobre 2004, devant le jury compose de :

Directeur de these M. Gerard Hebuterne Professeur a lINTRapporteurs M. Luigi Fratta Professeur a Politecnico di Milano

M. Samir Tohme Professeur a lUVSQExaminateurs M. Tijani Chahed Matre de Conferences a lINT

M. Guy Pujolle Professeur a lUniversite Paris 6M. James Roberts Directeur unite R&D, France TelecomM. Sami Tabbane Professeur a SUPCOM


2/132

.


3/132

Resume

Lingenierie pour la qualite de service dans les systemes de telecommunications

mobile de troisieme generation, tel que lUMTS, presente un defi important dans

le transport du trafic multimedia a haut debit dans le reseau dacces radio ter-

restre de lUMTS (UTRAN). En effet, tous les types de trafic, temps reel et non

temps reel, necessitent un transport temps reel dans lUTRAN a cause des fonc-

tions radio avances reliees a lutilisation du WCDMA (Wideband Code Division

Multiple Access) dans linterface radio.

Le but de ce travail est detudier, analytiquement et empiriquement, le trans-

port temps reel du trafic usager dans lUTRAN base sur IP. Nous nous interessons

tout dabord au trafic voix et proposons une methodologie de multiplexage de

petites trames FP dans des paquets IP de taille plus grande. Notre modele inclut

un temporisateur pour empecher un grand delai de remplissage. Nos resultats

montrent les compromis a trouver entre la performance, en terme de delai, et

dutilisation de la bande passante et permettent dobtenir les valeurs optimales

pour le temporisateur ainsi que le nombre de trames maximal par paquet IP.

Nous etudions ensuite le systeme en presence de deux types de trafic, voix

et data. Nous examinons la differenciation de service suivant deux types dor-

donnacement : Weighted Round Robin et Priority Queuing. Nous demontrons

que Priority Queuingrepond mieux aux exigences du trafic temps reels sans tropdegrader la performance du trafic non temps reel. En outre, il est plus simple a

implementer. ceci nous amene a proposer un dimensionnement approprie dans

lUTRAN.

Dans un troisieme temps, nous comparons les performances des protocoles

de transport dans lUTRAN, notamment IP versus AAL2/ATM. Pour la voix, nos

resultats montrent que lIP est plus interessant dans un systeme fortement charge.

Il est aussi nettement plus performant en terme de delai et plus economique en

terme de lutilisation de la bande passante pour le transport du trafic data. Enfin,

nous examinons les implementations possibles des architectures de qualite de

service dans le reseau dorsal de lUTRAN base sur IP.

Mots cles : UMTS, UTRAN base sur IP, transport temps reel, multiplexage,differenciation de service.


4/132

.


5/132

Absract

Intensive research is currently investigating the basic design of UMTS, and a

significant amount of this activity focuses on the UMTS Terrestrial Radio Access

Network (UTRAN) and the transport technology that shall be used therein. Spe-

cific to UMTS are the stringent delay bounds for the transport of various types of

user traffic real-time as well as non real-time, with various QoS needs, over the

UTRAN which are imposed by the Wideband Code Division Multiple Access

(WCDMA) advanced radio control functions. This delay bound is, for instance,

as small as 5 ms for real-time traffic, mainly compressed low bit rate voice. The

transport in the UTRAN should meet these requirements in a cost effective way

in terms of link utilization.

In this thesis, we investigate the transport of user traffic in the IP-based

UTRAN. We first focus on real-time voice traffic and present an analytical model

for the multiplexing and transport of voice channels using IP. The novelty of our

model is that it analytically includes and quantifies the performance of the timer

used in multiplexing arriving Frame Protocol (FP) frames into larger IP packets.

Our results show the trade-offs between performance, in terms of delay, and link

utilization, and quantify optimal values for the timer as well as the number of FP

frames per IP packet for a given output link capacity. Our results are validated

empirically on a test-bed emulating the UTRAN transport functionalities.We next consider IP service differentiation between voice and data traffic

in the UTRAN, both analytically and empirically. We study two scheduling

schemes, namely Weighted Round Robin and Priority Queuing and show that

the latter is simpler yet more efficient to meet the delay bound objectives. We

then use these results to propose an appropriate dimensioning of the UTRAN.

We eventually assess the attractiveness of IP in the UTRAN through a com-

parative study with the performance of AAL2/ATM therein. IP offers a very good

solution for the transport of data traffic. For voice traffic, ATM results in a very

good delay performance with overhead ratio worst than one for IP ; yet IP ful-

fills a good delay performance in an even more efficient way, in terms of linkutilization, especially for heavy loaded systems.

Keywords : UMTS, IP-based UTRAN , reel time transport , multiplexing,service differentiation.


6/132

.


7/132

Table des matieres

1 Introduction 15

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Problematique . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Organisation de la these . . . . . . . . . . . . . . . . . . . . . . 17

2 Le reseau dacces radio terrestre UMTS (UTRAN) 19

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Architecture globale du reseau UMTS . . . . . . . . . . . . . . 20

2.3 Le reseau dacces UTRAN . . . . . . . . . . . . . . . . . . . . 22

2.4 Les protocoles de lUTRAN . . . . . . . . . . . . . . . . . . . 24

2.5 Les interfaces des elements logiques de lUTRAN . . . . . . . . 26

2.5.1 Linterface Uu . . . . . . . . . . . . . . . . . . . . . . 26

2.5.1.1 La couche physique . . . . . . . . . . . . . . 27

2.5.1.2 La couche liaison de donnees . . . . . . . . . 28

2.5.1.3 La couche reseau . . . . . . . . . . . . . . . 29

2.5.2 Linterface Iub . . . . . . . . . . . . . . . . . . . . . . 29

2.5.3 Linterface Iur . . . . . . . . . . . . . . . . . . . . . . 31

2.5.4 Linterface Iu . . . . . . . . . . . . . . . . . . . . . . . 31

2.6 Qualite de service dans lUMTS . . . . . . . . . . . . . . . . . 32

2.6.1 Classes de services . . . . . . . . . . . . . . . . . . . . 32

2.6.2 Architecture de la qualite de service UMTS . . . . . . . 33

2.6.3 La qualite de service dans lUTRAN . . . . . . . . . . . 352.7 Topologies du reseau de transport dans lUTRAN . . . . . . . . 36

2.8 Contraintes de transport dans lUTRAN . . . . . . . . . . . . . 37

2.9 Solution de transport basee sur lAAL2/ATM . . . . . . . . . . 38

2.10 Solution de transport basee sur lIP . . . . . . . . . . . . . . . . 40

2.10.1 Multiplexage par le protocole PPP . . . . . . . . . . . . 42

2.10.2 AAL2 over IP . . . . . . . . . . . . . . . . . . . . . . . 42


8/132

8 TABLE DES MATIERES

2.10.3 Composite IP (CIP) . . . . . . . . . . . . . . . . . . . . 43

2.10.4 Lightweight IP Encapsulation (LIPE) . . . . . . . . . . 44

2.10.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 442.11 La problematique examinee dans cette these . . . . . . . . . . . 44

3 Transport du trafic temps reel dans lUTRAN 47

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2 Modelisation du Systeme . . . . . . . . . . . . . . . . . . . . . 47

3.2.1 Modele de lUTRAN . . . . . . . . . . . . . . . . . . . 49

3.3 Analyse du modele . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3.1 Modele du trafic voix . . . . . . . . . . . . . . . . . . . 50

3.3.2 Etude du delai de remplissage . . . . . . . . . . . . . . 50

3.3.3 Passage de lunite de remplissage a la file de transmission 53

3.3.4 Etude du delai de sejour dans la file dattente . . . . . . 55

3.3.4.1 Etude par chane de Markov : delai moyen . . 55

3.3.4.2 Etude par le modele Er/M/1 : quantiles . . . . 57

3.4 Plate-forme demulation de lUTRAN . . . . . . . . . . . . . . 59

3.4.1 Generation du trafic . . . . . . . . . . . . . . . . . . . . 59

3.4.2 Implementation des unites du multiplexeur . . . . . . . 60

3.5 Applications numeriques et validation empirique . . . . . . . . 61

3.5.1 Limitation du delai de remplissage . . . . . . . . . . . . 61

3.5.2 Performance du systeme : delai . . . . . . . . . . . . . 623.5.2.1 Delai moyen de sejour . . . . . . . . . . . . . 62

3.5.2.2 Quantiles du delai de sejour . . . . . . . . . . 63

3.5.3 Utilisation utile de la bande passante . . . . . . . . . . . 66

3.5.4 Dimensionnement dans lUTRAN . . . . . . . . . . . . 68

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4 Diff erenciation de service dans lUTRAN 73

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2 Transport du trafic data . . . . . . . . . . . . . . . . . . . . . . 73

4.2.1 Modele du trafic data . . . . . . . . . . . . . . . . . . . 744.2.2 Modelisation de lUTRAN . . . . . . . . . . . . . . . . 74

4.2.3 Etude de transport des canaux a 64 kbps . . . . . . . . . 75

4.2.4 Etude du transport dans les canaux a 144 kbps . . . . . . 78

4.2.5 Etude de transport des canaux a 384 kbps . . . . . . . . 80

4.3 Performance de lIP dans lUTRAN avec differenciation de service 81

4.3.1 Systeme etudie . . . . . . . . . . . . . . . . . . . . . . 81


9/132

TABLE DES MATIERES 9

4.3.2 Modelisation du systeme . . . . . . . . . . . . . . . . . 82

4.4 Differenciation de service par ordonnancement cyclique avec ponderation

(WRR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.4.1 Analyse de WRR . . . . . . . . . . . . . . . . . . . . . 82

4.4.2 Calcul du delai moyen de paquets voix . . . . . . . . . 83

4.4.3 Calcul du delai moyen de paquets data . . . . . . . . . . 84

4.4.4 Resultats numeriques et validation empirique . . . . . . 84

4.4.5 Plate-forme de differenciation de service . . . . . . . . 84

4.4.6 Validation du modele et ponderation . . . . . . . . . . . 85

4.4.7 Resultats empiriques . . . . . . . . . . . . . . . . . . . 86

4.4.8 Discussion des resultats . . . . . . . . . . . . . . . . . 88

4.5 Differenciation de service parPriority Queuing . . . . . . . . . 894.5.1 Analyse de Priority Queuing . . . . . . . . . . . . . . . 90

4.5.2 Trafic de haute priorite . . . . . . . . . . . . . . . . . . 90

4.5.3 Trafic de basse priorite . . . . . . . . . . . . . . . . . . 91

4.5.4 Resultats numeriques et validation empirique . . . . . . 92

4.5.4.1 Resultats en valeurs moyenne . . . . . . . . . 92

4.5.4.2 Resultats en quantiles . . . . . . . . . . . . . 94

4.5.5 Dimensionnement . . . . . . . . . . . . . . . . . . . . 96

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5 Implementation : Architectures et technologies 1015.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.2 Transport du trafic voix . . . . . . . . . . . . . . . . . . . . . . 102

5.2.1 Processus darrivee du trafic voix . . . . . . . . . . . . 102

5.2.2 Etude par les valeurs moyennes . . . . . . . . . . . . . 102

5.2.2.1 Analyse du multiplexeur base sur IP . . . . . 102

5.2.2.2 Analyse du multiplxeur AAL2/ATM . . . . . 103

5.2.3 Etude par les quantiles . . . . . . . . . . . . . . . . . . 105

5.2.3.1 Analyse du multiplexeur base sur IP . . . . . 105

5.2.3.2 Analyse du multiplexeur base sur AAL2/ATM 1055.2.4 Resultats numeriques . . . . . . . . . . . . . . . . . . 106

5.3 Transport du trafic data . . . . . . . . . . . . . . . . . . . . . . 108

5.3.1 Processus darrivee du trafic . . . . . . . . . . . . . . . 108

5.3.2 Analyse du transport base sur IP . . . . . . . . . . . . . 109

5.3.3 Analyse du transport base sur ATM . . . . . . . . . . . 109

5.3.4 Resultats numeriques . . . . . . . . . . . . . . . . . . . 109


10/132

10 TABLE DES MATIERES

5.4 Solutions possibles . . . . . . . . . . . . . . . . . . . . . . . . 110

5.5 Approches de qualite de service dans lUTRAN base sur IP . . . 112

5.5.1 Architecture des services differencies dans lUTRAN . . 1135.5.1.1 Le modele DiffServ . . . . . . . . . . . . . . 113

5.5.1.2 Reseau dorsal DiffServ de lUTRAN . . . . . 114

5.5.2 Architecture MPLS dans lUTRAN . . . . . . . . . . . 117

5.5.2.1 MPLS . . . . . . . . . . . . . . . . . . . . . 117

5.5.2.2 Avantages de MPLS dans lUTRAN . . . . . 117

5.5.2.3 Shemas de transport MPLS . . . . . . . . . . 118

5.5.2.4 Transport par des tunnels . . . . . . . . . . . 119

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6 Conclusion et perspectives 121

6.1 Contributions de la these . . . . . . . . . . . . . . . . . . . . . 121

6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123


11/132

Table des figures

2.1 LUMTS assure la convergence . . . . . . . . . . . . . . . . . . 20

2.2 Architecture generale du reseau UMTS . . . . . . . . . . . . . 21

2.3 Role du SRNC et du DRNC lors du soft handover . . . . . . . . 24

2.4 Modele de protocoles des interfaces de lUTRAN . . . . . . . . 25

2.5 Linterface radio vue en couches . . . . . . . . . . . . . . . . . 27

2.6 Pile protocolaire de linterface Iub dans le plan usager . . . . . . 31

2.7 Pile protocolaire de linterface Iur dans le plan usager . . . . . . 32

2.8 Architecture en couche de la qualite de service UMTS . . . . . 34

2.9 Reseau de transport dans lUTRAN : liaison directe . . . . . . . 37

2.10 Reseau de transport dans lUTRAN : plusieurs noeuds . . . . . 37

2.11 Differentes piles protocolaires pour la couche reseau de transport 43

3.1 Format dun paquet IP . . . . . . . . . . . . . . . . . . . . . . 48

3.2 Format simple dune trame PPP encapsulant plusieurs paquets IP 49

3.3 Schema du systeme . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4 Plate-forme demulation du transport dans lUTRAN . . . . . . 59

3.5 Implementation du systeme . . . . . . . . . . . . . . . . . . . . 60

3.6 Delai de remplissage en fonction du nombre des canaux simul-

tanement actifs . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.7 Delai moyen de sejour dans la file de transmission : comparaison

entre le modele de Markov, le modele Er/M/1 et les resultats

empiriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.8 Probabilite de depassement du delai de sejour (5-TCU)ms enfonction du nombre de canaux actifs . . . . . . . . . . . . . . . 65

3.9 Comparaison des resultats analytiques et empiriques du delai de

sejour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.10 Delai total empirique dans le multiplexeur . . . . . . . . . . . . 67

3.11 Profil darrivee des paquets IP dans la file de transmission avec

n=8 et TCU=2ms . . . . . . . . . . . . . . . . . . . . . . . . . 68


12/132

12 TABLE DES FIGURES

3.12 Utilisation utile en fonction du nombre des canaux actives pour

n=8 et differentes valeurs de TCU . . . . . . . . . . . . . . . . 69

3.13 Utilisation utile en fonction du nombre des canaux actives pourTCU=2 ms et differentes valeurs de n . . . . . . . . . . . . . . 70

3.14 Utilisation utile de la bande passante : analytique et empirique . 71

3.15 Probabilite de depassement du delai de sejour dans lUTRAN en

fonction de la capacite de la liaison filaire . . . . . . . . . . . . 72

4.1 Probabilite de depassement du delai en fonction du nombre des

canaux actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.2 La fonction de repartition du delai de sejour avec 15 canaux ac-

tifs : analytique et empirique . . . . . . . . . . . . . . . . . . . 77

4.3 La fonction de repartition du delai de sejour avec 20 canaux ac-

tifs : analytique et empirique . . . . . . . . . . . . . . . . . . . 78

4.4 Probabilite de depassement du delai en fonction du nombre des

canaux actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.5 Probabilite de depassement du delai de 10 ms en fonction de la

bande passante . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.6 Modelisation de lUTRAN avec differenciation de service . . . 82

4.7 Implementation du systeme avec differenciation de service . . . 85

4.8 Comparaison des delais a poids egaux : analytique et empirique 86

4.9 Comparaison des delais avec un poids superieur pour la voix :analytique et empirique . . . . . . . . . . . . . . . . . . . . . . 87

4.10 Fonction de repartition (CDF) du delai de la voix pour differents

poids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.11 Fonction de repartition (CDF) du delai de donnee pour differents

poids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.12 Fonction de repartition (CDF) du delai total de la voix . . . . . . 90

4.13 Delai moyen pour la voix : analytique et empirique . . . . . . . 93

4.14 Delai moyen pour le trafic data : analytique et empirique . . . . 94

4.15 Delai moyen pour le trafic data : Poisson et periodique . . . . . 95

4.16

percentile des delais voix et data avec et sans PQ . . . . . 96

4.17

percentile du delai de la voix et data avec et sans PQ . . . 97

4.18 CDF du delai total pour le trafic voix . . . . . . . . . . . . . . . 98

4.19 CDF du delai pour le trafic data . . . . . . . . . . . . . . . . . . 99

5.1 Schema du systeme modelisant lUTRAN . . . . . . . . . . . . 102

5.2 Format dune cellule ATM . . . . . . . . . . . . . . . . . . . . 104


13/132

TABLE DES FIGURES 13

5.3 Comparaison entre lIP et lATM en terme du delai moyen . . . 106

5.4 Comparaison entre lIP et lATM en terme de la probabilite de

violation du delai cible . . . . . . . . . . . . . . . . . . . . . . 1075.5 Comparaison entre lIP et lATM en terme de lutilisation utile

de la bande passante . . . . . . . . . . . . . . . . . . . . . . . . 108

5.6 Comparaison entre lIP et lAAL2/ATM en terme du delai moyen 110

5.7 Nombre de canaux DSCH en fonction de la charge correspondante111

5.8 Pile protocolaire pour un RNC connecte aux reseaux IP et ATM 112

5.9 DiffServ dans lUTRAN . . . . . . . . . . . . . . . . . . . . . 115

5.10 Transport du trafic UTRAN dans le reseau dorsal dans la classe EF116

5.11 Tranport du trafic UTRAN dans des tunnels . . . . . . . . . . . 119


14/132

14 TABLE DES FIGURES


15/132

Chapitre 1

Introduction

1.1 Motivation

Le systeme mobile universel de telecommunications (UMTS pour Univer-

sal Mobile Telecommunications System) est lun des principaux systemes mo-

biles de la troisieme generation connus sous IMT-2000 ( International Mobile

Telecommunications-2000) par lunion internationale des telecommunications

(ITU pourInternational Telecommunication Union). Pour specifier ces systemes

mobiles de troisieme generation, lITU a federe les propositions des organismes

de normalisation des differents pays pour les regrouper dans un projet de decision

nomme projet de partenariat pour la troisieme generation (3GPP pourThird Ge-

neration Project Partnership). Ce projet prend en compte toutes les instances de

normalisation provenant de linstitut europeen de normalisation des telecommunications

(ETSI), de lassociation des technologies de telecommunications (TTA Coree),

de la comite des technologies de telecommunications (TTC Japan) et lorganisme

T1 (Etats unis).

Apres le succes des systemes mobiles de deuxieme generation, qui ont ete

developpes pour le transport de la voix en mode circuit, ainsi que quelques

tele-services en mode paquet comme le service de messages courts, et lessor

de lInternet qui sest accompagne dun accroissement du trafic de donnees, ledeploiement dun reseau mobile adapte a la fois au transport du trafic Internet

et de la voix sest impose fortement. Dou les travaux elabores dans le cadre du

projet 3GPP pour developper lUMTS. Le premier deploiement de ce systeme

a eu lieu en 2001 au Japon. En Europe, une realite technico-economique du

developpement de lUMTS a mene a un changement du calendrier de deploiement

dans certains pays ; Il est deja une realite en Angleterre et en Italie et devrait etre


16/132

16 CHAPITRE 1. INTRODUCTION

lancee commercialement en France courant 2004. Ces premiers deploiements

sont fondes sur les specifications techniques de lUMTS, telles que les definit la

premiere version des specifications du 3GPP connue par Release 99.

LUMTS est un systeme multimedia offrant une bande passante plus large

avec de la commutation de paquets ainsi que de nouveaux services et des appli-

cations variees. Ces applications, dont les besoins en bande passante et en qualite

de service sont tres differents les unes des autres, utiliseront un meme support

de transmission, quil soit radio ou terrestre, en mode paquet ou en mode circuit.

A ces exigences sajoutent lutilisation efficace par le systeme des ressources

de transmission ; lUMTS devra fournir un service de transfert economique, en

reduisant au minimum les depenses dinvestissement et les couts dexploita-

tion. La conception et le deploiement de lUMTS presentent des enjeux tech-nologiques importants. Cote radio, une nouvelle technique dacces multiple par

repartition de codes a bande elargie (WCDMA pour Wideband Code Division

Multiple Access) a ete choisi en Europe. Cette technique permet davoir des

debits variables ainsi quune qualite de service variable sur linterface radio. Le

debit offert a lusager, dans des conditions de mobilite reduite, devra atteindre 2

Mbit/s, cest a dire comparable a celui dautres technologies fixes dacces haut

debit.

Le reseau cur est charge de la gestion de services souscrits par lusager et

de linterconnexion avec les reseaux externes fixes ou mobiles. Il devra maintenir

la communication tout en garantissant la qualite de service, meme lorsque lutili-

sateur est itinerant. Bien que la version 99 du 3GPP a decrit les procedures mises

en place dans le reseau cur et a aussi etudie les possibles implementations de

la qualite de service, des innovations sont apportees par les recentes versions

(Releases 4, 5 et 6) de la norme, notamment levolution vers le tout-IP (IP pour

Internet Protocol). En exploitant lenvironnement IP, lUMTS beneficiera direc-

tement de toutes les applications existantes de lInternet avec une facilite pour le

developpement de nouveaux services ainsi que lutilisation des reseaux IP exis-

tants ce qui permet aux operateurs de realiser des economies sur leurs depenses.

En ce qui concerne le reseau dacces radio terrestre (UTRAN pour UMTSTerrestrial Radio Access Network) qui fait lobjet de notre etude, il connecte le

reseau cur a linterface radio et represente une part importante des investis-

sements des operateurs. Il devra aussi contenir un environnement multiservice

puisquil contribuera a assurer la qualite de service de bout en bout pour les usa-

gers. La technologie WCDMA impose, aux elements qui constituent ce reseau

dacces, des fonctions radios avancees pour la gestion de la mobilite. Ceci consti-


17/132

CHAPITRE 1. INTRODUCTION 17

tue un defi pour les fournisseurs des equipements qui devront proposer des solu-

tions techniquement et economiquement interessantes.

1.2 Problematique

En comparaison au reseau dacces de deuxieme generation comme celui du

systeme global de telecommunications avec les mobiles (GSM pourGlobal Sys-

tem for Mobile communication), le reseau dacces UMTS presente, en plus de

lutilisation de la technologie WCDMA, des innovations comme lintroduction

de nouvelles interfaces et la gestion de la mobilite independamment du reseau

cur. Ces ameliorations exigent des fonctions radio avancees de controle de puis-

sance et de synchronisation entre les elements du reseau dacces. Pour remplir

ces exigences, le delai de transmission du trafic, quil soit temps reel ou non

temps reel, a travers le reseau dacces UTRAN devrait etre limite a des faibles

valeurs de lordre de 5 a 7 ms pour le trafic temps reel et de 10 a 50 pour le trafic

non temps reel.

La Release 99 des normes de lUMTS utilise le transfert asynchrone (ATM

pour Asynchronous Transfer Mode), notamment la couche dadaptation ATM

type 2 ( AAL2 pour ATM Adaptation Layer 2), comme protocole de transport

dans le reseau dacces terrestre. Les premieres infrastructures deployees pour

le transport du trafic usager dans lUTRAN sont basees sur lAAL2/ATM. Parcontre les phases futures consistent a faire evoluer ce reseau en sappuyant entierement

sur le protocole IP suivant les recommandations des recentes versions des specifications

du 3GPP (Releases 4, 5 et 6). Lutilisation de lIP pour un transport efficace du

trafic usager dans lUTRAN est un objectif a atteindre. Ce transport devrait sa-

tisfaire les contraintes temporelles exigees tout en maximisant lutilisation des

ressources. Ceci constitue une solution de transport economiquement efficace et

facilement adaptable avec les possibles phases de deploiement des infrastruc-

tures. Le travail de cette these est axe autour de cette problematique.

1.3 Organisation de la these

Les travaux de cette these sont structures de la facon suivante :

Au chapitre 2, nous presentons tout dabord un apercu de larchitecture du

systeme UMTS, ainsi que de son reseau dacces afin de mieux comprendre le

cadre de notre travail. Nous decrivons les roles des differents elements de larchi-


18/132

18 CHAPITRE 1. INTRODUCTION

tecture puis nous nous interessons a la qualite de service dans ce reseau dacces.

Par la suite, nous faisons le point sur la problematique posee par lUTRAN.

Nous faisons le tour des differentes solutions proposees pour le transport du tra-fic usager, celles basees sur lAAL2/ATM ainsi que celles basees sur IP. Dans ce

contexte, nous precisons les points essentiels examines dans cette these.

Dans le chapitre 3, nous considerons le transport du trafic temps reel tel que

la voix et nous evaluons les performances du transport IP, en termes du delai,

valeurs moyennes et quantiles, et defficacite dutilisation de la bande passante.

Nous presentons les resultats du modele analytique ainsi que les resultats empi-

riques des tests de validation effectues sur une plate-forme emulant les fonction-

nalites de transport dans lUTRAN.

Dans le chapitre 4, nous etudions le transport du trafic non temps reel qui

necessite lui aussi un transport temps reel et nous nous interessons par la suite

a la differenciation de service entre les flux temps reel et non temps reel. Nous

examinons les performances des mecanismes de differenciation de service pro-

poses pour cet objectif notamment weighted round robin et priority queuing . Les

resultats analytiques et empiriques sont aussi presentes et le chapitre se conclut

par un dimensionnement de lUTRAN.

Dans le chapitre 5, nous examinons limplementation des technologies de

transport dans lUTRAN en comparant les performances de lIP et celles de

lAAL2/ATM et nous nous interessons au reseau dorsal de lUTRAN par lana-

lyse des differentes implementations possibles pour le transport IP dans lUTRAN.Pour terminer, le chapitre 6 presente la conclusion et les perspectives de ce

travail.


19/132

Chapitre 2

Le reseau dacces radio terrestre

UMTS (UTRAN)

2.1 Introduction

LUMTS devra assurer des hauts debits jusqua 2Mbits/s par usager et of-

frir des services diversifies et developpes (voir figure 2.1). Il integre multimedia,

informatique et telecommunications. Selon lETSI, la norme UMTS devra rem-

plir plusieurs objectifs : un systeme multimedia unique et efficace, assurant unecouverture globale, une flexibilite dusage ainsi quune offre multiservices. Dans

cette perspective, les points principaux a retenir pour la norme UMTS sont : le

contexte mondial de normalisation, la convergence des technologies et lintro-

duction des services multimedia. De plus, le deploiement du reseau doit etre suf-

fisamment flexible pour sadapter aux evolutions attendues du trafic. LUTRAN

occupe une importance considerable lors du deploiement parce que les ressources

sont rares et cheres. La technologie dacces WCDMA a ete retenue sur linter-

face air et sera deploye en Europe, a la fois en mode TDD (Time Division Du-

plex) et en mode FDD ( Frequency Division Duplex). Pour le reseau terrestre,

nous nous interessons dans notre etude au transport du trafic usager et nous

etudions les performances du transport IP dans lUTRAN ainsi que ses possibles

implementations.

Dans ce chapitre, nous presentons brievement larchitecture de lUMTS et

nous focalisons letude sur la qualite de service ainsi que le transport dans lUTRAN.

Nous achevons le chapitre par la direction choisie dans cette these.


20/132

20 CHAPITRE 2. LE R ESEAU DACCES RADIO TERRESTRE UMTS (UTRAN)

UMTS

Multimdia

Visiophonie

Distribution radio et TV

Web

Email ...

Tlenseignement...

Internet

Nouvelles technologies

Voix, Data, SMS, Fax ...

Mobilit/Roaming

Tlcommunications

Transport mode circuit

Transport mode paquet

Accs radio large bande

FIG. 2.1 LUMTS assure la convergence

2.2 Architecture globale du reseau UMTS

Larchitecture du systeme UMTS est compatible avec les autres reseaux mo-

biles de deuxieme et de troisieme generation et garantie en meme temps une

evolution adaptable en fonctions des besoins des operateurs de telecommunications.

Cette architecture est perceptible de deux points de vue : lun physique ou on

parle des elements ou equipements qui composent le reseau, et lautre fonction-

nel ou on parle des strates afin didentifier les protocoles mis en uvre pour

assurer la communication entre ces elements.

Larchitecture generale du reseau UMTS est presentee dans la Figure 2.2. Les

elements de reseau du systeme UMTS sont repartis en trois groupes. Un corres-

pond au reseau dacces radio (UTRAN) qui supporte toutes les fonctionnalites

radio. Lautre correspond au reseau cur (CN pour Core Network) qui est res-

ponsable de la commutation et du routage des communications vers les reseaux

externes. Le systeme est complete par lequipement usager (UE pourUser Equi-

pement) qui se trouve entre lusager proprement dit et le reseau dacces radio.Lequipement usager est connecte a lUTRAN par linterface radio ou Uu. Il

est compose des deux parties suivantes :

Le terminal mobile (ME pourMobile Equipment) correspond au terminal

radio utilise pour les communications radio sur linterface Uu.

La carte USIM (UMTS Suscriber Identity Module) est une carte a puce

qui stocke entre autres lidentite de labonne, les algorithmes et les clefs


21/132

CHAPITRE 2. LE RESEAU DACCES RADIO TERRESTRE UMTS (UTRAN) 21

Node B

Node B

Node B

Node B

Uu

Iub

Iur

UTRAN

UE

UE

Iu CN

HLR

MSC/VLR GMSC

SGSN GGSN

CS

PS

Rseaux

externes

RNIS

RTCP

...

Internet

RNC

RNC

FIG. 2.2 Architecture generale du reseau UMTS

dauthentification et les clefs de chiffrements.

LUTRAN fournit a lUE les ressources radio et les mecanismes necessaires

pour acceder au CN par linterface Iu. Ses composantes sont detaillees dans la

section 2.3.

Dans le reseau cur, nous distinguons les domaines suivants :

1. Le domaine de commutation de circuit (CS pourCircuit Switching) pourlacces aux services en mode circuit. Cest un prolongement de lapproche

reseau GSM pour les services telephoniques et supplementaires en mode

circuit. Il comprend :

Le commutateur du service mobile (MSC/VLR pourMobile Services

Switching Center/Visitor Location Register), qui correspond au commu-

tateur (MSC) qui gere les connexions circuits et a la base de donnees

(VLR) qui contient une copie du profil de labonnee.

Le GMSC (Gateway MSC) qui est un commutateur connecte directe-

ment au reseau externe en mode circuit. Toutes les communications en-

trantes et sortantes, en mode circuit, passent par un GMSC.

2. Le domaine de commutation de paquets (PS pourPacket Switching) pour

lacces aux services en mode paquet. Cest une migration de lapproche

du service general de radio-communication en mode paquet (GPRS pour

General Packet Radio Services) vers un domaine multimedia IP, il com-

prend :


22/132


Le nud de support GPRS de desserte (SGSN pourServing GPRS Sup-

port Node) qui possede les memes fonctions que le MSC/VLR mais il

est utilise pour les communications paquet. Le nud de support GPRS de transit (GGSN pourGateway GPRS Sup-

port Node) qui possede des fonctionnalites tres proches de celles du

GMSC mais il ne traite que des connexions en mode paquet.

3. Un domaine commun, qui comprend :

Lenregistreur de location nominal (HLR pourHome Location Register)

qui est une base de donnees contenant toutes les informations relatives

a labonnement dun usager et aux droits dacces.

De plus, nous trouvons le EIR (Equipement Ithentification Register) qui

est le centre qui fournie au reseau lautorisation de fonctionner sur lereseau ainsi que lAuC (Authentification Center). Ce dernier est le centre

qui verifie lauthentification des mobiles et stockent les cles de chiffre-

ment.

Quant aux reseaux externes, ils sont en mode CS tels que le Reseau Numerique

a Integration de Services (RNIS) ou le Reseau Telephonique Commute Public

(RTCP), et en mode PS tels que le reseau Internet et dautres reseaux de trans-

mission de donnees.

En ce qui concerne les strates, le reseau UMTS est compose de deux strates,

appeles strate dacces (AS pour Access Stratum) et strate de non acces (NAS

pourNon Access Stratum). LAS regroupe toutes les fonctions de lUMTS liees

au reseau dacces, dont, par exemple, les fonctions de gestion des ressources ra-

dio et de handover 1. LUTRAN est par definition entierement inclus dans lAS.

Par ailleurs lAS comprend aussi une partie de lequipement mobile (celle qui

gere les protocoles de linterface radio) ainsi quune partie du reseau cur (cor-

respondant a linterface Iu). Le niveau NAS comprend toutes les autres fonctions

du reseau UMTS, independant du reseau dacces.

2.3 Le reseau dacces UTRANLUTRAN est constitue dun ensemble de sous-systemes reseau radio (RNS

pourRadio Network Subsystem). Chaque RNS regroupe un controleur de reseau

radio (RNC pourRadio Network Controller) et une ou plusieurs stations de bases

1Mecanisme permettant de transferer une connexion mobile-reseau dune ressource radio a

une autre.


23/132


( Node B). Deux RNCs sont connectes entre eux via linterface Iur. Linterface

entre un Node B et un RNC est linterface Iub (voir figure 2.2).

On associe le Node B a la station de base du GSM. Son role principal est das-

surer les fonctions de reception et de transmission radio pour une ou plusieurs

cellules de lUTRAN. Cest un nud logique qui gere la couche physique de lin-

terface radio ; Il regit principalement le codage du canal, lentrelacement, ladap-

tation du debit et letalement. Il est constitue dun port commun de controle et

dun ensemble de points de terminaison de trafic, chacun controle par un port de

controle dedie. Un point de terminaison de trafic peut controler plus dune cellule

et une cellule peut etre controlee par plus dun point de terminaison. Le Node B

participe activement au controle de puissance dans une cellule en transmettant

une commande a lUE afin quil ajuste sa puissance demission. Le mecanismede controle de puissance ou le Node B et lUE ajustent mutuellement leur puis-

sance demission est connu sous le nom boucle interne de controle de puissance

(inner-loop power control).

Le RNC est lentite de lUTRAN chargee principalement du routage des

communications dans le reseau dacces. Ses fonctions couvrent la gestion des

ressources radio, le controle de puissance, lallocation des codes pour des nou-

veaux liens radio, le controle de congestion, la gestion des interfaces vers le

Core Network ainsi que dautres fonctions liees a la mobilite de lusager. Dans

la boucle externe de controle de puissance (outer-loop power control), le RNC

assure la mise a jour, au niveau du Node B, du seuil de qualite afin dajuster la

valeur du rapport signal/interference (SIR pourSignal-to-Interference Ratio).

On distingue differents roles pour le RNC : Serving RNC(SRNC), Control-

ling RNC(CRNC) et Drift RNC(DRNC). Un meme equipement physique RNC

supporte generalement ces differentes fonctions logiques.

La figure 2.3 montrent les roles du RNC. Le RNC qui controle un Node B,

c. a d. le RNC qui est directement connecte a ce Node B par linterface Iub,

est appele CRNC. Le SRNC est, pour un mobile, le RNC qui gere linterface

Iu avec le reseau cur et etablit la connexion radio. Il est aussi en charge du

traitement des donnees transmises sur linterface air. Un UE ne peut avoir quunSRNC et un seul. Le DRNC assure le routage des donnees usagers vers le Ser-

ving RNC dans le sens montant et vers les Nodes B dans le sens descendant

lors dun soft handover. Il peut aussi effectuer la recombinaison de liens. Lors

dun soft handover, le trafic emis par lequipement usager en deplacement peut

secouler en parallele dans deux connexions. Lancienne est directement reliee

au SRNC via une interface Iub alors que le trafic utilisant la nouvelle connexion


24/132


passe par une autre interface Iub qui est reliee au DRNC. Ce dernier achemine le

trafic vers le SRNC via linterface Iur. Dans le SRNC, la recombinaison du tra-

fic provenant des deux connexions permet lenvoie dun seul flux vers le reseaucur. Ce mecanisme fait partie de la macro-diversite (macro-diversity) qui est

Iur

SRNC

Node B Node BNode B Node B

Rseau coeur (CN)

DRNC

Iu

Iub

Uu

FIG. 2.3 Role du SRNC et du DRNC lors du soft handover

une technique utilisee avec les interfaces radio du type WCDMA. Elle designe la

phase pendant laquelle le mobile maintient plusieurs liens radios avec differentesstations de base. Par consequent, dans les sens montants et descendants, une re-

combinaison de liens en fonction dinformations sur la qualite du lien radio doit

etre effectuee (par le mobile dans le sens descendant et par le reseau dans le sens

montant). Dans le sens montant, le choix entre la meilleure des informations en

fonction de lindicateur de qualite peut etre realise a differents niveaux du reseau

dacces.

2.4 Les protocoles de lUTRAN

Les protocoles des interfaces UTRAN ont ete structures selon le modele qui

est presente dans le figure 2.4. Cette structure est basee sur une decoupe horizon-

tale en couches ou verticale en plans. Les couches et les plans sont logiquement

independantes ce qui laisse la possibilite, en cas de besoin, quune partie de la

structure des protocoles sera changee dans le futur et les autres parties restent

intactes.


25/132


Signalling Bearer(s)Signalling Bearer(s) Data Bearer(s)

ALCAP

Couche du

rseau radio

Couche du

TNL

RNL

Couche physique

Plan de contrle Plan usager

Plan usager du

rseau de

transport

rseau de transport

transport

Plan usager du

rseau derseau de

transport

Protocole dapplication

Plan de contrle du

Flot(s) de donnes

FIG. 2.4 Modele de protocoles des interfaces de lUTRAN

La decoupe horizontale fait apparatre deux couches principales :

La couche du reseau radio (RNL pour Radio Network Layer), elle com-

prend les aspects specifiques lies a lUTRAN. La structure de cette couche

est tel que chacune des interfaces Iu, Iub et Iur comporte deux types de

protocoles. Le protocole dapplication (AP pourApplication Protocol), af-

fecte au plan de controle qui soccupe des echanges de signalisation entre

les differents equipements et le protocole de trame (FP pour Frame Proto-

col) affecte au plan usager qui se charge du transport de donnees usagers.

La couche du reseau de transport (TNL pour Transport Network Layer),

elle correspond a une technologie de transport standard choisie pour lUTRAN

mais qui ne lui est pas specifique. Elle est composee de la couche physique

(physical layer), des canaux de communications (signallinget data bearer)

et de la couche ALCAP ( Access Link Control Application Part), utilisee

pour etablir les chemins de transmission du plan usager (data bearer).

La decoupe verticale fait apparatre les plans suivants :

Le plan de controle (control plane) qui est utilise pour la signalisation de

controle specifique a lUMTS. Il comprend entre autres le protocole APqui initialise des supports vers lequipement usager ainsi que les supports

de signalisation (signalling bearer) pour la transmission des messages de

signalisation.

Le plan usager (user plane) par lequel transitent toutes les informations

recues ou envoyees par lusager, comme la voix ou les donnees. Ce plan

comprend les flux de donnees (data stream) qui utilisent les supports de


26/132


donnees (data bearer) echangees sur les interfaces.

Le plan de controle du reseau de transport (transport network control

plane). Ce plan presente la particularite de netre present quau niveau dela couche de transport, car il est utilise pour etablir les supports donnees

du plan usager. Il inclut egalement des supports de signalisation.

2.5 Les interfaces des elements logiques de lUTRAN

Les specifications de lUMTS sont structurees autour des interfaces entre les

elements logiques du reseau. Nous presentons les differents interfaces ouvertes

disponibles en relation avec lUTRAN : Uu, Iub, Iur, Iu.

2.5.1 Linterface Uu

Linterface logique Uu ou interface radio connecte lequipement usager au

Node B. Ses protocoles sappliquent aux trois premieres couches du modele OSI

(Open Systems Interconnections) qui sont montrees dans la figure 2.5 : la couche

physique (Couche 1), la couche liaison de donnees (Couche 2), et la couche

reseau (Couche 3). De plus, les specifications du reseau UMTS contiennent une

grande variete de canaux de communication, repartie en trois grandes classes

hierarchiques : Les canaux logiques, les canaux de transport et les canaux phy-

siques. Ces differentes classes de canaux ont etecreees pour garantir lindependance

entre les differents niveaux fonctionnels de linterface radio. La definition de

canaux propres a chaque niveau donne une grande flexibilite au reseau UMTS

en lui permettant de sadapter a la multitude dapplications envisagees pour le

reseau de troisieme generation.

Pour les canaux logiques, un ensemble de canaux a ete defini pour les differents

types de services de transfert de donnees. On distingue les canaux de controle qui

sont utilises pour le transfert des informations du plan de controle et les canaux

de trafic pour les donnees du plan usager. Les principaux canaux de controle

sont le canal de controle de diffusion (BCCH pour Broadcast Control Channel),le canal de controle de recherche (PCCH pourPaging Control Channel), le canal

dacces aller (FACH pour Forward Access Channel), le canal de controle dedie

(DCCH pourDedicated Control Channel). Comme canaux de trafic, nous citons

le canal de trafic dedie (DTCH pour Dedicated Traffic Channel) et le canal de

trafic commun (CTCH pourCommon Traffic Channel).

Aux canaux logiques correspondent des canaux de transport representant les


27/132


services offerts par la couche physique aux couches superieures. Ils peuvent etre

separes en canaux dedies comme le canal dedie (DCH pourDedicated Channel)

et canaux communs comme le canal partage de liaison descendante (DSCH pour(Down link Shared Channel), le canal de diffusion, le canal de recherche, etc.

Les canaux de transport sappuient, a leur tour, sur des canaux physiques pour

la transmission sur la voie radio. Un canal physique correspond a une frequence

specifique, un code ou plusieurs codes et a un dephasage relatif pour le lien mon-

tant. Comme canal dedie, il y a le canal physique de donnees dedie (DPCH pour

Dedicated Physical Data Channel), et comme canal commun il y a entre autres,

le canal physique de controle commun (CCPCH pour (Common Control Phy-

sical Channel), le canal physique partage de liaison descendante (PDSCH pour

( Physical Downlink Shared Channel), etc. La correspondance entre les canaux

logiques, de transport et physiques est detaillee dans [15].

PHY

RLC

MAC

BMCPDCP

RRCCouche 3

Couche 2

Couche 1

Canauxlogiques

Canaux de

transport

Plan de contrle Plan usager

Canaux physiques

FIG . 2.5 Linterface radio vue en couches

2.5.1.1 La couche physique

La couche physique (Couche 1) est basee sur le WCDMA qui est le plus im-

portant changement sur linterface radio par rapport aux systemes mobiles tels

que GSM. Cette technique utilise letalement de spectre par sequence directe

(voir [16]). Tous les usagers emettent sur un meme canal radioelectrique large


28/132


bande, mais ils se distinguent par une sequence detalement pseudo-aleatoire

propre, appelee code et connue du recepteur. Plusieurs codes peuvent etre al-

loues a un meme usager et transmis simultanement sur le meme canal radiopour augmenter son debit de transmission. Un controle de puissance efficace

est necessaire pour garantir que lensemble des signaux (signal utile + bruit)

soient recus avec des niveaux de puissance similaires permettant dassurer une

demodulation efficace. Des etudes de performances de la couche physique se

trouvent dans [15] p. 303-346.

2.5.1.2 La couche liaison de donnees

Elle comprend les sous-couches de commande dacces au support (MAC

pour Medium Access Control) et de commande de liaison radio (RLC pour Ra-dio Link Control) dans le plan de controle. Dans le plan usager, en plus des

couches MAC et RLC, le protocole de convergence de donnees en mode paquet

(PDCP pour Packet Data Convergence Protocol) et le protocole de controle de

diffusion (BMC pourBroadcast/Multicast Control Protocol) ont ete rajoutes. La

fonction principale de la couche MAC est le controle de lacces a la voie radio.

Elle permet de faire la correspondance entre les canaux logiques et les canaux

de transport et elle est responsable de la selection et la modification du format de

transport (TF pour Transport Format) approprie a chaque canal de transport en

fonction du ou des debits instantanes des canaux logiques. La couche MAC est

aussi charge de la gestion de priorite entre les flux de donnees au niveau terminal

ou entre plusieurs terminaux sur les canaux de transport. Des schemas de prio-

rite dacces sont proposes dans [62]. Entre autres fonctions cette couche gere le

volume du trafic et assure le multiplexage/ demultiplexage des unites de donnees

en mode paquet (PDU pour Packet Data Unit) de la couche RLC sur les canaux

de transport.

La couche RLC est la couche de protocole qui fournit des services de seg-

mentation et de retransmission pour les donnees usager et les informations de

controle suivant trois modes de fonctionnement : le mode transparent, le mode

non acquitte et le mode acquitte. Chaque instance RLC est configuree par lacouche de controle des ressources radio (RRC pour Radio Resource Control)

pour fonctionner dans lun de ces trois modes. Dans le mode transparent, le

RLC neffectue aucun controle des PDUs, dou le RLC PDU ne contient de

ce fait aucune entete. Ce mode est utilise par exemple pour la voix. Le mode

non acquitte (UM, Unacknowledged Mode) offre la possibilite de segmenter et

de concatener les RLC-PDUs. Lentite receptrice a la charge de reassembler les


29/132


differents segments avant de les envoyer a la couche utilisatrice. Il assure un

controle de numero de sequence des RLC-PDUs mais aucun protocole de re-

transmission nest utilise et la distribution des donnees nest donc pas garantie.Il peut etre par exemple utilise pour les services comme des messages courts

SMS Cell Broadcast provenant du GSM. Le mode acquitte (AM, Acknowled-

ged Mode) assure, en plus des fonctions presentes dans le mode non acquitte, le

controle de flux, lacquittement des RLC-PDUs transmises et la correction der-

reurs par retransmission. Le mode acquitte peut etre utilise par exemple pour

le Web. Voir [22] p. 236-241 pour une vue detaillee de ces modes de transfert.

Dautres travaux examinant les performances de la couche RLC sont presentes

dans [63, 64].

Le protocole PDCP nest utilise qu au niveau du plan usager et seulement

pour les services du domaine paquet. Le protocole PDCP comprend des m ethodes

de compression des entetes des protocoles TCP/IP ou RTP/UDP/IP au niveau

de lentite emettrice et decompression au niveau de lentite receptrice. Il gere

le transport de donnees usagers et supporte la procedure re-allocation SRNS 2

(SRNS Relocation) sans perte dinformations.

Le protocole BMC prend en charge les services de diffusion sur linterface

radio. Le seul service utilisant ce protocole est le service de diffusion des mes-

sages courts (SMS Cell Broadcast).

2.5.1.3 La couche reseau

Elle comprend la couche RRC qui appartient au plan de controle. La couche

RRC constitue le lien entre lAS et le NAS. Elle encapsule toute la signalisation

en provenance des couche hautes et a destination des couches 1 et 2. Elle gere en

particulier, letablissement, le maintient et le relachement de la connexion RRC

entre le mobile et lUTRAN. Elle soccupe egalement des fonctions comme la

gestion de la mobilite en mode connecte, le Paging 3, etc.

2.5.2 Linterface IubEn reprenant la figure 2.4, la couche radio de linterface Iub contient le pro-

tocole sous-systeme dapplication du Node B (NBAP pour Node B Application

2La procedure de re-allocation de Serving RNS consiste a changer dinterface physique entre

le reseau dacces UMTS et le reseau cur a la suite dun handover; le DRNC devient ainsi

SRNC.3Recherche du mobile lors dun appel de la station de base vers le mobile.


30/132


Part) dans le plan de controle et le protocole Iub-FP dans le plan usager. Le

protocole NBAP est utilise pour les echanges de signalisation entre le Node B

et le RNC. Il existe deux categories dechanges : ceux destines a un usager etceux destines a un ensemble dusagers. Les messages de la premiere categorie

permettent dassurer les fonctions suivantes :

Gestion des liens radio (creation ou suppression dun lien).

Gestion des mesures radio par le RNC (configuration des mesures pour un

mobile, et la remontee de ces mesures jusquau RNC).

Controle de puissance (outerloop).

Les messages de la seconde categorie permettent dassurer les fonctions sui-

vantes :

Gestion des canaux de transport communs de la ou des cellules du Node

B.

Configuration des informations systeme diffusees par cellule du Node B.

Gestion des mesures radio sur les canaux communs de la cellule.

Pour le plan usager, linterface Iub transporte le trafic circulant entre le SRNC

et le Node B. La pile protocolaire pour le transport du trafic usager est presentee

dans la figure 2.6. Le Node B fonctionne comme un simple relais qui achemine

le contenu des canaux de transport entre lequipement usager et le RNC. En tra-

versant les couches RLC et MAC, le trafic change de profil en comparaison avec

son profil a la source. Selon le mode de fonctionnement specifie pour le type du

trafic, la couche RLC achemine le trafic vers la couche MAC qui selectionne leformat de transport. Ce format transport specifie lintervalle de temps de trans-

mission (TTI pourTransmission Time Interval) des blocs de donnees. La couche

FP rassemble tous les blocs envoyes pendant un TTI et appartenant au meme

service, en une trame FP-PDU (FP Packet Data Unit) en ajoutant un en-tete. Le

transport des trames FP est assure par la couche de transport et il est transparent

aux connexions radio. Ce transport doit remplir les exigences de la qualite de

service ; Les fonctions radio avancees adoptees dans lUMTS, comme la macro-

diversite, ainsi que les caracteristiques particulieres des applications imposent de

fortes contraintes temporelles pour le transport de trafic via linterface Iub. Sur

la voie descendante, si la couche MAC du RNC envoie une trame sur linterface

Iub, cette trame devrait arriver au Node B dans un intervalle de temps precis pour

etre transmis sur linterface air.

Dans cette these, nous nous interessons a cette couche du reseau de trans-

port, notamment dans le cas ou elle est basee sur IP, pour assurer un dimension-

nement garantissant les ressources necessaires pour un transport respectant les


31/132


contraintes temporelles avec une utilisation utile de ces ressources.

MAC

RLC

MAC

RLC

Couche du

rseau de

transport

TNL

UE RNCNode B

IubUu

FPFP

physique physiquePhysique

(WCDMA)Physique Couche Couche

(WCDMA)

Couche du

rseau radio

RNL

UDP/IPUDP/IP

Couche liaison Couche liaisonde donnes de donnes

FIG . 2.6 Pile protocolaire de linterface Iub dans le plan usager

2.5.3 Linterface Iur

Linterface Iur a ete definie afin de supporter le handoverentre deux Node B

controles par des RNC differents, autrement dit le mecanisme de transfert (soft

handover) entre le SRNC et le DRNC. Dautres fonctionnalites ont ete ajoutees

durant le developpement de la norme comme la gestion des ressources et le sup-

port des canaux, dedies et communs, de trafic. La couche radio de linterface

utilise le protocole sous-systeme dapplication du reseau radio (RNSAP pour

Radio Network Subsystem Application Part) dans le plan de controle. Ce proto-

cole assure les echanges de signalisation entre deux RNCs. En ce qui concerne

le plan usager le protocole Iur-FP est utilise. Dans ce plan, linterface Iur trans-

porte le trafic des usagers en soft handover. Par consequent, le trafic Iur nest

autre quune partie du trafic Iub. La pile protocolaire pour le transport du trafic

usager est montree dans la figure 2.7.

2.5.4 Linterface Iu

Cest une interface ouverte qui separe lUTRAN du reseau cur. Elle peut

etre du type mode circuit (Iu CS) ou mode paquet (Iu PS). Le plan de controle est

commun aux deux interfaces Iu CS et Iu PS, mais le plan de controle du reseau

de transport est different afin doptimiser le transport au niveau du plan usager

en permettant lutilisation de differentes technologies de transport. Notre etude

ne couvre pas cette interface ; Des details concernant les piles de protocoles des


32/132


MAC

RLC

MAC

RLC

FP RNL

Couche du

rseau radio

Couche du

rseau de

transport

TNL

Couche liaison

de donnes

Couche liaison

de donnes

Couche liaison

de donnes

UE Node B

IubUu

FP

physique physiquePhysique

(WCDMA)Physique Couche Couche

(WCDMA)Couche

physique

Iur

SRNCDRNC

FP

UDP/IP UDP/IP UDP/IP

FIG . 2.7 Pile protocolaire de linterface Iur dans le plan usager

interfaces Iu Cs et Iu Ps des plans de controle, usager et de controle du reseau de

transport sont presentes dans [15].

2.6 Qualite de service dans lUMTS

La qualite de service se refere a leffet globale de la performance du service

qui determine le niveau de satisfaction de lusager. Elle doit etre fournit de bout

en bout. Le reseau UMTS peut etre vue comme une entite servant dinterface

dacces pour une connexion a un ensemble de reseaux externes fixes ou mobiles.

La qualite de service UMTS est definie dans [6] avec un ensemble dattributs qui

devraient repondre a certains criteres tels que la satisfaction par le systeme des

besoins de qualite de service de lusager, lutilisation efficace des ressources, la

flexibilite de gestion de la qualite de service et linteroperabilite avec les schemas

de qualite de service dautres reseaux.

2.6.1 Classes de services

LUMTS offre une panoplie de services ayant des qualites de service differentes.

Au niveau applicatif, des classes de service ont ete definies afin de regrouper lesservices en fonction de leurs contraintes. La principale caracteristique qui permet

de distinguer les applications qui appartiennent a ces differentes classes est leur

sensibilite au temps de transfert. Les quatre classes de services definies dans le

cadre de lUMTS sont :

Le trafic conversationnel (Conversational) : cette classe regroupe tous les

services symetriques ou bidirectionnels necessitant un temps de transfert


33/132


faible et constant donc, une faible gigue. Lapplication typique de cette

classe est la voix sur un service support circuit ou encore voix sur IP.

La videotelephonie et les jeux video interactifs font aussi partie de cetteclasse.

Le trafic a flux continu (Streaming) : Cette classe regroupe tous les ser-

vices impliquant un usager et un serveur de donnees. Les applications

de cette classe sont asymetriques du fait que les donnees etant majori-

tairement transferees du reseau au mobile. En comparaison avec la classe

conversationnelle, les delais toleres de transfert de linformation sont plus

importants. Les services representatifs de cette classe, entre autres, les ser-

vices de video a la demande, la diffusion radiophonique ou les applications

de transfert dimages.

Le trafic interactif (Interactive) : Cette classe regroupe tous les services

dans lesquels un usager entretient un dialogue interactif avec un serveur

dapplications ou de donnees. Contrairement aux classes precedentes, elle

ne necessite pas de performance temps reel particuliere. En revanche, il

est essentiel pour ce type dapplications que linformation transmise ne

subisse aucune alteration. Cette classe correspond a la navigation sur In-

ternet, le transfert de fichiers FTP, ou toutes les applications de commerce

electronique.

Le trafic darriere-plan (Background) : La principale caracteristiques des

applications de cette classe est que leurs usagers nont pas besoin de re-cevoir les informations correspondant a ces applications dans un delai tres

court, autrement dit la priorite de transmission est inferieure a celle de la

classe interactive. Le delai de transfert peut alors se mesurer en secondes

ou dizaines de secondes voir plus. Les applications de la classe background

sont, entre autres, le transfert de fax, la messagerie courtes ou multimedia

de type SMS (Short Message Service), MMS (Multimedia Message Ser-

vice) ou email.

2.6.2 Architecture de la qualite de service UMTS

La qualite de service UMTS resulte de celle assuree sur linterface radio,

dans lUTRAN et dans le reseau cur. Larchitecture de la qualite de service se

compose des differentes fonctions du reseau assurant a lutilisateur la qualite de

service appropriee. Larchitecture en couches decrite dans [6] est presentee dans

la figure 2.8. Chaque service support dune couche donnee fournit ses propres


34/132


services a la couche superieure en utilisant ceux des couches inferieures. Un

service UMTS est de bout-en-bout dun equipement terminal a un autre. Il utilise

le service support local TE/ME (TE/MT Local Bearer Service) qui ne fait paspartie du reseau UMTS, le service support UMTS (UMTS Bearer Service), ainsi

que le service support externe (External Bearer Service) qui peut etre un service

offert par dautres reseaux y compris un autre service support UMTS. A son tour,

le service support UMTS sappuie sur le service support dacces radio (Radio

Access Bearer Service) et sur le service support de cur du reseau (CN Bearer

Service) qui offre des services de transport au sein du reseau cur de lUMTS.

Le service support dacces radio, utilisant le service support radio (Radio Bearer

Service ) et le service support de linterface Iu ( Iu Bearer Service), assure le

transport des donnees entre le TE et lEdge CN. Les services fournis par lUTRA

FDD/TDD gerent les aspects lies au transport sur linterface radio.

TE MT UTRAN CN Iu

Egde node

CN

Gateway

TE

EndtoEnd Service

UMTS Bearer Service

RAB Service

Service

Radio Bearer Iu Bearer

Service

Service

Service

Service

Physical Bearer

External Bearer

Network Service

Backbone

TE/MT Local

Bearer Service

CN Bearer

TDD Service

UTRA FDD/

UMTS

FIG . 2.8 Architecture en couche de la qualite de service UMTS

Pour repondre aux besoins de la qualite de service de bout-en-bout exigee parles applications, la signalisation dans le plan de controle active les services sup-

ports necessaires pour assurer ces besoins. Dans le plan usager, les mecanismes

avances de qualite de service correspondants sont mis en place. Par exemple, le

service support UMTS est etabli par le protocole de donnees en mode paquet

(PDP Packet Data Protocol). Chaque PDP contexte comprend un ensemble dat-

tributs de qualite de service et de reservation de ressource qui lui sont associes.


35/132


Le profil de qualite de service est negocie durant la procedure dactivation du

PDP contexte et decrit la qualite du support UMTS qui sera allouee a lusager.

2.6.3 La qualite de service dans lUTRAN

La qualite de service dans le reseau dacces fait partie de la qualite de service

offerte par le service support dacces radio. Ce dernier assure le transport des

donnees entre le TE et le CN, autrement dit, de linterface Uu vers linterface

Iu. Donc, il sappuie sur les services support des interfaces Iub, Iur ainsi que

linterface radio. Le reseau dacces devrait etablir et maintenir le service support

dacces radio (RAB) avec les niveaux de qualite de service voulus. Dou limpact

de la qualite de service offerte sur les interfaces Uu, Iub, Iur et Iu. Cote radio,des techniques specifiques, comme le controle dadmission radio ou le controle

de puissance, tiennent compte des profils de qualite de service. La fonction de

controle dadmission radio autorise ou refuse lacces au ressources radio selon

des criteres comme la disponibilite des ressources, la prise en charge dun nou-

veau usager ne doit pas degrader la qualite de service offert aux autres usagers

(voir [60, 61]). Le controle de puissance permet de maintenir au plus bas le ni-

veau des interferences radioelectriques dans le systeme base sur le WCDMA.

Dans notre travail, nous examinons le service de transport du trafic sur les

interfaces Iub et Iur en utilisant la technologie IP. Ce service devrait remplir

des exigences temporelles et les attributs de qualite de service du RAB. Tout

dabord, il faut repondre aux besoins des applications elles-memes, qui peuvent

etre temps reel ou non temps reel. Mais surtout des contraintes strictes sur le

delai transport sont exigees dans lUTRAN ce qui fait que le transport, que ce

soit dun trafic temps reel ou non temps reel, est un transport temps reel. Ces

contraintes de transport sont liees aux fonctions radio avancees mises en oeuvre

dans le reseau dacces UMTS et dues a la synchronisation entre le RNC et le

Node B. Les mecanismes de synchronisation sont indispensables pour obtenir

de meilleures performances sur linterface radio. Par exemple, pour assurer la

macro-diversite lors du handover, la recombinaison des signaux provenant desdifferentes branches nest possible que si ces signaux sont relativement synchro-

nises. Le service voix exige un delai de transport court de lordre de 5-7 ms [13]

alors que le trafic non sensible au temps reel peut tolerer des delais plus impor-

tants sachant quil doit respecter certaines bornes sur le delai de lordre de 10 a

50 ms [13, 30]. Nous notons que dans notre etude, les bornes sur le delai pour

le transport sont les suivantes : 5 ms pour le trafic temps reel et 10 ms pour le


36/132


trafic non temps reel. Dans le cas ou un constructeur dequipements propose des

bornes plus grandes notamment pour le transport du trafic non temps reel, notre

modele ainsi que notre methodologie restent valables. En utilisant notre etude,loperateur peut determiner facilement le dimensionnement dans lUTRAN en

prenant dautres valeurs pour ces bornes.

2.7 Topologies du reseau de transport dans lUTRAN

Larchitecture de lUTRAN est hierarchique c. a. d. elle est basee sur une ges-

tion centralisee des ressources radio au niveau RNC. Un Node B communique

avec un RNC precis comme dans larchitecture du systeme GSM entre une sta-

tion de base et son controleur. Des propositions sont lancees pour evoluer versune architecture distribuee [12, 73] ou certaines fonctions seront deplacees vers

le Node B et ce dernier peut communiquer avec nimporte quel RNC. Cepen-

dant, la plupart des travaux, y compris le notre, se situent dans le cadre dune

architecture hierarchique.

Les elements logiques et les equipements de lUTRAN sont bien definis dans

les specifications alors que le reseau de transport sur les interfaces Iub et Iur est

ouvert aux choix retenus par les operateurs. Lobjectif de ce reseau de trans-

port est linterconnexion entre le Node B et le RNC. Il peut donc aller dune

simple connexion directe a un reseau metropolitain (MAN pour Metropolitan

Area Network), a la possibilite dutiliser les infrastructures des reseaux existants.

Dans notre travail, nous examinons linterconnexion entre le Node B et le RNC

dans les cas dune connexion directe (voir figure 2.9) et celle via un reseau de

plusieurs nuds comme le montre la figure 2.10. Dans ce cas, un ou plusieurs

nuds peuvent exister entre le Node B et le RNC, quon appelle reseau dorsal

de lUTRAN lensemble de ces nuds. Les nuds en liaison avec le Node B

et le RNC sont des nuds peripheriques (Edge Node). La liaison entre un Node

B et un nud peripherique est connu sous le nom Last Mile en Anglais, donc

nous lappelons dernier kilometre. Des liaisons de type E1/T1, donc a debits li-

mites, sont installees dans les premieres infrastructures. Cette partie du reseau detransport constitue le goulot detranglement.

Dans une connexion directe le Node B est donc directement lie au RNC par

le dernier kilometre. Ce RNC est combine avec le nud peripherique. Dans les

premiers deploiements bases sur lATM, un Node B est connecte par des liaisons

de bas debit a un concentrateur qui a son tour est directement liee au RNC au haut

debit. Ce cas peut etre vu comme etant une connexion directe lors des etudes de


37/132


FIG . 2.9 Reseau de transport dans lUTRAN : liaison directe

performance parce que le budget du delai est majoritairement consomme sur les

liaisons a bas debit.

FIG. 2.10 Reseau de transport dans lUTRAN : plusieurs noeuds

2.8 Contraintes de transport dans lUTRAN

Le transport du trafic usager devrait satisfaire des contraintes temporelles et

dautres technologiques. Les bornes sur le delai de transport devrait etre res-


38/132


pectees pour les differentes types du trafic afin de realiser les meilleures perfor-

mances sur linterface radio comme nous venons de le voir dans la section 2.6.3.

La contrainte temporelle se conjugue avec une contrainte technologique qui visea assurer une utilisation efficace de la bande passante surtout dans les derniers

kilometres. Dou la necessite detablir soigneusement la conception du schema

de transport ainsi que le bon dimensionnement dans lUTRAN.

2.9 Solution de transport basee sur lAAL2/ATM

Le mode de transfert asynchrone (ATM pour Asynchronous Transfer Mode)

se caracterise par la transmission des donnees sous forme de cellules suivant un

multiplexage par repartition dans le temps asynchrone [21]. Lunite de transmis-sion est donc la cellule qui est de taille fixe et egale a 53 octets.

Dans le cadre de lIMT-2000, notamment la Release 99 du 3GPP, lATM est

utilise dans la couche du reseau de transport des interfaces Iub et Iur. Ce choix

est justifie par les proprietes cles de lATM tels que sa possibilite de transporter

du trafic avec des debits variables, que ce soit pour des services a commutation

de paquets ou a commutation de circuits, ainsi que sa possibilite de preserver

la qualite de service des medias transportes, surtout pour des services tres sen-

sibles aux delais requis pour la transmission du trafic, a linstar de la voix et la

visiophonie. La couche dadaptation ATM type 2 ( AAL2 pour ATM Adaptation

Layer type 2) est utilisee parce quelle est appropriee pour le transport de la voix

compressee en temps reel et a bas debit.

Les travaux dans ce cadre se sont focalises sur levaluation de lAAL2/ATM

et la qualite de service quelle apporte dans le transport du trafic usager dans

lUTRAN. Dans ce cas, le reseau dorsal de lUTRAN est un reseau de trans-

port ATM, et la couche dadaptation AAL2 assure le multiplexage des trames de

plusieurs canaux dans les cellules ATM.

Dans ce contexte, plusieurs travaux de recherche ont ete menes par simula-

tions pour evaluer les performance de lAAL2/ATM dans lUTRAN. Ces etudes

ont porte sur le dimensionnement, la repartition des ressources et les mecanismesde differenciation de service ainsi que sur les aspects lies au parametrage lors de

limplementation. Pour le trafic temps reel notamment de la voix, le multiplexage

des trames voix dans des cellules ATM est examine. Le multiplexeur est com-

pose de deux parties principales, une unite de remplissage avec un temporisateur

(timer) pour limiter le delai de remplissage et une file dattente. Dans la reference

[30], limplementation du multiplexage au niveau AAL2 est propose sous deux


39/132


formes ; une qui combine le remplissage et la transmission (CAT pourCombined

Assembly and Transmission) et une autre qui les separe (ABT Assembly Before

Transmission). Une comparaison entre les deux formes est presentee dans deuxcas : avec un tampon de taille finie et avec un tampon de taille infinie. Dans le

cas dun tampon de taille finie, les resultats exprimes en terme de taux de perte

des trames montrent que ABT produit un taux de perte plus eleve que celui de

CAT. Ceci est justifie par le fait que CAT rejette des trames quand le tampon

est plein alors que ABT rejette des cellules ATM qui elles peut contenir plus

quune trame. Dans le cas dun tampon de taille infinie, la difference est moins

importante.

Dans la reference [31], une etude approfondie pour le choix de la valeur

du temporisateur est presentee et differents algorithmes dordonnancement sontsimules au niveau de la couche AAL2 pour assurer la differenciation de service

entre voix et data. Des ordonnanceurs comme premier entre premier sorti (FIFO

pourFirst In First Out), ordonnancement cyclique avec ponderation (WRR pour

Weighted Round Robin), (EDF pourEarliest Deadline First), ou priorite fixe (PQ

pour Priority Queuing). FIFO est recommande pour le cas dun reseau mono-

service alors que WRR est plus adapte dans le cas multi-service.

Aussi une comparaison entre la commutation au niveau de la couche AAL2

et au niveau de la couche ATM est presentee pour le cas dun commutateur

ou noeud de concentration reliant plusieurs Node B a un RNC. Dans ce cas,

le chemin virtuel (VP pour Virtual Path) de sortie du commutateur resulte de

lagregation des VPs provenant des Nodes B. Les resultats des simulations montrent

que la commutation au niveau AAL2 est plus performante en terme de lutilisa-

tion de la bande passante dans le cas des circuits virtuels a faible charge. Ce

resultat est aussi presente dans [84] ou la commutation au niveau AAL2 dans

les noeuds de concentration genere un gain statistique plus important quau ni-

veau ATM. Dans [33], deux approches pour assurer la differenciation de service

entre les classes de trafic sont simules. Dans la premiere, les algorithmes FIFO,

WRR et Priority Queueing sont etudies, et un seul circuit virtuel (VC pourVir-

tual Circuit) transporte le trafic voix et data. Dans la deuxieme approche, chaquetype de trafic est transporte dans un VC. WRR produit des resultats plus opti-

mistes que celle des autres algorithmes et le transport dans des VCs differentes

est plus efficace. Dans [36], les resultats montrent quune differenciation de ser-

vice au niveau ATM est preferable, mais ceci est en comparaison avec le schema

sans differenciation de service. Un schema de differenciation de service avec

un ordonnanceur cyclique avec ponderation dynamique (DWRR pour Dynamic


40/132


Weighted Round Robin) est propose dans [40] ; une version dynamique des poids

de WRR est plus efficace quune version fixe.

Les etudes analytiques ne sont pas nombreuses. La reference [24] presenteune etude analytique qui couvre le cas de la voix dans lUTRAN. Elle est basee

sur des chanes de Markov et evalue les performances de loption AAL2/ATM

en considerant le multiplexage des trames voix dans les cellules ATM ; le mul-

tiplexeur est compose dune unite de remplissage avec le temporisateur et dune

file dattente de taille fixe. Pour une bande passante fixe, le nombre des canaux

voix, qui peuvent etre supportees, est determine. De plus limpact du temporisa-

teur dans les performances du multiplexeur AAL2 est presente a travers des ap-

plications numeriques. Une autre etude du meme problematique mais tenant en

compte les caracteristiques de lUTRAN, a savoir larrivee periodique des trames

chaque TTI, fait lobjet de [27]. Dans ce dernier, un modele de type

est utilise avec un temporisateur egale a zero et une file dattente de taille infinie.

La bande passante necessaire pour transmettre un nombre determine de canaux

est calculee en fixant la probabilite de violation de contraintes temporelles. Les

aspects lies a la mis en correspondance entre les classes de services UMTS et

les capacites de transfert en mode ATM (ATC pour ATM Transfer Capability)

ainsi que la gestion de circuits virtuels des classes de services sont aussi etudies.

En particulier, les references [25, 28] analysent analytiquement la gestion des

circuits virtuels pour le trafic temps reel et non temps reel.

Bien que la technologie AAL2/ATM est parfaitement adaptee aux besoinsde transport du trafic temps reel a bas debit comme la voix, elle peut saverer

gourmande en capacite quand le trafic data est dominant dans lUTRAN ; les en-

tetes consomment une bande passante importante [27, 55]. Les recentes versions

du 3GPP proposent des evolutions vers un reseau tout-IP, y compris dans lacces

terrestre.

2.10 Solution de transport basee sur lIP

Les travaux de normalisation dun reseau mobile tout-IP sont presentes dansles recents travaux du 3GPP, a savoirReleases 4, 5 et 6. Etant une technologie ef-

ficace dinterconnexion, IP est deja present dans le cur du reseau UMTS. Lex-

tension vers le reseau dacces est discute dans [1] et [2]. Dans ce contexte, les

travaux examinant le transport IP sont des etudes a court terme par simulations

et visaient la demonstration de lefficacite ainsi que la viabilite dune solution IP

par rapport a lAAL2/ATM. Les etudes portant sur ce sujet sont en cours et ne


41/132


sont pas encore finalisees. En fait, lintroduction de lIP dans les reseaux mobiles

ouvre plusieurs voies dapplication, de la connectivite a la gestion de la mobi-

lite en passant par le support des applications multimedias IP. Dans un reseaudacces UMTS base sur IP, le reseau de transport reliant le Node B et le RNC est

fondamentalement forme de routeurs utilisant IP comme protocole de la couche

3.

Notre objectif est dassurer le transport du trafic usager tout en satisfaisant

les contraintes de qualite de service requises et assurant une utilisation effi-

cace des ressources. Un gaspillage des ressources des derniers kilometres a bas

debit resulte dune grande consommation due aux en-tetes. Dou la necessite

de la reduction des en-tetes par rapport au charges utiles. Ceci est atteint soit

par la compression des en-tetes, soit par le multiplexage, soit les deux simul-

tanement. Les techniques de compression des en-tetes peuvent etre accomplis

suivant les propositions de lIETF dans RFC 2507 [41] et RFC 2509 [42]. En ce

qui concerne le multiplexage, son implementation peut etre selon trois schemas

[2] :

Multiplexage sur le dernier kilometre : Dans ce cas, le multiplexage est

utilise seulement sur le dernier kilometre entre le Node B et le routeur

peripherique du reseau de transport. Ce schema necessite lajout de quelques

fonctions dans le routeur peripherique pour accomplir le multiplexage etle demultiplexage.

Multiplexage sur le dernier kilometre et entre le RNC et le nud peripherique :

Dans ce cas, deux sessions de multiplexages sont faites entre le Node B et

son routeur peripherique et entre ce dernier et le RNC. Cette solution est

plus optimale mais plus complexe.

Multiplexage de bout en bout : Dans ce schema, le multiplexage est ef-

fectue de bout en bout entre le Node B et le RNC, il est donc transparent

au noeuds intermediaires. Cest une solution simple pour un transport ef-

ficace.

Les methodes de multiplexage proposees par les industriels examinant le

transport dans lUTRAN sont regroupees dans la reference [2]. Elles peuvent

etre implementees suivant les trois schemas cites ci-dessus. Differents modes

dimplementation de la technologie IP dans lUTRAN avec des differentes piles

protocolaires sont presentes et valides par des simulations [1, 2]. Dautres tra-

vaux abordent aussi cette problematique par simulations dans [48] [70] et [71].


42/132


2.10.1 Multiplexage par le protocole PPP

Le protocole point-a-point (PPP pour Point-to-Point Protocol) est un proto-cole de niveau 2 du modele OSI assurant la liaison entre deux points du reseau.

Les paquets des couches superieures sont encapsules dans des trames PPP.

Le multiplexage utilisant ce protocole a ete propose dans le RFC 3153 [44]

visant le reduction de la charge introduite par len-tete PPP. La figure 2.11(a)

montre la pile protocolaire proposee dans [1] pour le transport dans lUTRAN.

Le multiplexage est fait par la concatenation de plusieurs paquets IP dans une

trame PPP de la facon suivante. Les trames FP, de taille variable, sont encap-

sulees dans des paquets IP qui a leur tour sont encapsules dans des trames PPP

dites mini-trames. Une compression de len-tete UDP/IP jusqua 2-4 octets est

envisagee. Len-tete compresseest designe par cUDP/IP. Le multiplexage consistea enchaner plusieurs mini-trames dans une trame PPP. Les formats des mini-

trames et des trames PPP sont detailles dans [1] et aussi dans [44]. Au des-

sous du protocole PPP, plusieurs protocoles sont proposes. Nous citons le pro-

tocole HDLC (High-level Data Link Control), AAL5/ATM . En comparaison

avec AAL2/ATM, les simulations menees par Motorola dans [2] montrent que

cUDP/IP/PPPmux/HDLC est plus performant que AAL2/ATM. Dans la reference

[44], une discussion portant sur la comparaison du multiplexage utilisant PPP

avec un multiplexage utilisant le protocole de transport en temps reel (RTP pour

Real Time Protocol) est presentee. PPPmux offre une amelioration de lutilisa-

tion de la capacite par rapport a RTP.

Plusieurs extentions du protocole PPP sont sujet dinvestigation pour etre uti-

liser avec PPP, comme la variant

These Samhat

Documents