Vous êtes sur la page 1sur 132

THÈSE DE DOCTORAT DE L’UNIVERSIT É PARIS 6

Spécialité
Informatique

présentée par
Abed Ellatif SAMHAT

pour obtenir le grade de


DOCTEUR DE L’UNIVERSIT É PARIS 6

LA QUALITÉ DE SERVICE DANS LE R ÉSEAU D’ACCÈS


RADIO TERRESTRE UMTS BAS É SUR IP

Soutenance prévue le 11 Octobre 2004, devant le jury composé de :

Directeur de thèse M. Gérard Hébuterne Professeur à l’INT


Rapporteurs M. Luigi Fratta Professeur à Politecnico di Milano
M. Samir Tohmé Professeur à l’UVSQ
Examinateurs M. Tijani Chahed Maı̂tre de Conférences à l’INT
M. Guy Pujolle Professeur à l’Université Paris 6
M. James Roberts Directeur unité R&D, France Telecom
M. Sami Tabbane Professeur à SUP’COM
.
Résumé

L’ingénierie pour la qualité de service dans les systèmes de télécommunications


mobile de troisième génération, tel que l’UMTS, présente un défi important dans
le transport du trafic multimédia à haut débit dans le réseau d’accès radio ter-
restre de l’UMTS (UTRAN). En effet, tous les types de trafic, temps réel et non
temps réel, nécessitent un transport temps réel dans l’UTRAN à cause des fonc-
tions radio avancés reliées à l’utilisation du WCDMA (Wideband Code Division
Multiple Access) dans l’interface radio.
Le but de ce travail est d’étudier, analytiquement et empiriquement, le trans-
port temps réel du trafic usager dans l’UTRAN basé sur IP. Nous nous intéressons
tout d’abord au trafic voix et proposons une méthodologie de multiplexage de
petites trames FP dans des paquets IP de taille plus grande. Notre modèle inclut
un temporisateur pour empêcher un grand délai de remplissage. Nos résultats
montrent les compromis à trouver entre la performance, en terme de délai, et
d’utilisation de la bande passante et permettent d’obtenir les valeurs optimales
pour le temporisateur ainsi que le nombre de trames maximal par paquet IP.
Nous étudions ensuite le système en présence de deux types de trafic, voix
et data. Nous examinons la différenciation de service suivant deux types d’or-
donnacement : Weighted Round Robin et Priority Queuing. Nous démontrons
que Priority Queuing répond mieux aux exigences du trafic temps réels sans trop
dégrader la performance du trafic non temps réel. En outre, il est plus simple à
implémenter. ceci nous amène à proposer un dimensionnement approprié dans
l’UTRAN.
Dans un troisième temps, nous comparons les performances des protocoles
de transport dans l’UTRAN, notamment IP versus AAL2/ATM. Pour la voix, nos
résultats montrent que l’IP est plus intéressant dans un système fortement chargé.
Il est aussi nettement plus performant en terme de délai et plus économique en
terme de l’utilisation de la bande passante pour le transport du trafic data. Enfin,
nous examinons les implémentations possibles des architectures de qualité de
service dans le réseau dorsal de l’UTRAN basé sur IP.

Mots clés : UMTS, UTRAN basé sur IP, transport temps réel, multiplexage,
différenciation de service.
.
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 link
utilization, especially for heavy loaded systems.

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


service differentiation.
.
Table des matières

1 Introduction 15
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . . 17

2 Le réseau d’accès radio terrestre UMTS (UTRAN) 19


2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Architecture globale du réseau UMTS . . . . . . . . . . . . . . 20
2.3 Le réseau d’accès UTRAN . . . . . . . . . . . . . . . . . . . . 22
2.4 Les protocoles de l’UTRAN . . . . . . . . . . . . . . . . . . . 24
2.5 Les interfaces des éléments logiques de l’UTRAN . . . . . . . . 26
2.5.1 L’interface Uu . . . . . . . . . . . . . . . . . . . . . . 26
2.5.1.1 La couche physique . . . . . . . . . . . . . . 27
2.5.1.2 La couche liaison de données . . . . . . . . . 28
2.5.1.3 La couche réseau . . . . . . . . . . . . . . . 29
2.5.2 L’interface Iub . . . . . . . . . . . . . . . . . . . . . . 29
2.5.3 L’interface Iur . . . . . . . . . . . . . . . . . . . . . . 31
2.5.4 L’interface Iu . . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Qualité de service dans l’UMTS . . . . . . . . . . . . . . . . . 32
2.6.1 Classes de services . . . . . . . . . . . . . . . . . . . . 32
2.6.2 Architecture de la qualité de service UMTS . . . . . . . 33
2.6.3 La qualité de service dans l’UTRAN . . . . . . . . . . . 35
2.7 Topologies du réseau de transport dans l’UTRAN . . . . . . . . 36
2.8 Contraintes de transport dans l’UTRAN . . . . . . . . . . . . . 37
2.9 Solution de transport basée sur l’AAL2/ATM . . . . . . . . . . 38
2.10 Solution de transport basée sur l’IP . . . . . . . . . . . . . . . . 40
2.10.1 Multiplexage par le protocole PPP . . . . . . . . . . . . 42
2.10.2 AAL2 over IP . . . . . . . . . . . . . . . . . . . . . . . 42
8 TABLE DES MATIÈRES

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


2.10.4 Lightweight IP Encapsulation (LIPE) . . . . . . . . . . 44
2.10.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 44
2.11 La problématique examinée dans cette thèse . . . . . . . . . . . 44

3 Transport du trafic temps réel dans l’UTRAN 47


3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Modélisation du Système . . . . . . . . . . . . . . . . . . . . . 47
3.2.1 Modèle de l’UTRAN . . . . . . . . . . . . . . . . . . . 49
3.3 Analyse du modèle . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1 Modèle du trafic voix . . . . . . . . . . . . . . . . . . . 50
3.3.2 Etude du délai de remplissage . . . . . . . . . . . . . . 50
3.3.3 Passage de l’unité de remplissage à la file de transmission 53
3.3.4 Etude du délai de séjour dans la file d’attente . . . . . . 55
3.3.4.1 Etude par chaı̂ne de Markov : délai moyen . . 55
3.3.4.2 Etude par le modèle Er/M/1 : quantiles . . . . 57
3.4 Plate-forme d’émulation de l’UTRAN . . . . . . . . . . . . . . 59
3.4.1 Génération du trafic . . . . . . . . . . . . . . . . . . . . 59
3.4.2 Implémentation des unités du multiplexeur . . . . . . . 60
3.5 Applications numériques et validation empirique . . . . . . . . 61
3.5.1 Limitation du délai de remplissage . . . . . . . . . . . . 61
3.5.2 Performance du système : délai . . . . . . . . . . . . . 62
3.5.2.1 Délai moyen de séjour . . . . . . . . . . . . . 62
3.5.2.2 Quantiles du délai de séjour . . . . . . . . . . 63
3.5.3 Utilisation utile de la bande passante . . . . . . . . . . . 66
3.5.4 Dimensionnement dans l’UTRAN . . . . . . . . . . . . 68
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4 Différenciation de service dans l’UTRAN 73


4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2 Transport du trafic data . . . . . . . . . . . . . . . . . . . . . . 73
4.2.1 Modèle du trafic data . . . . . . . . . . . . . . . . . . . 74
4.2.2 Modélisation de l’UTRAN . . . . . . . . . . . . . . . . 74
4.2.3 Etude de transport des canaux à 64 kbps . . . . . . . . . 75
4.2.4 Etude du transport dans les canaux à 144 kbps . . . . . . 78
4.2.5 Etude de transport des canaux à 384 kbps . . . . . . . . 80
4.3 Performance de l’IP dans l’UTRAN avec différenciation de service 81
4.3.1 Système étudié . . . . . . . . . . . . . . . . . . . . . . 81
TABLE DES MATIÈRES 9

4.3.2 Modélisation du système . . . . . . . . . . . . . . . . . 82


4.4 Différenciation de service par ordonnancement cyclique avec pondération
(WRR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.1 Analyse de WRR . . . . . . . . . . . . . . . . . . . . . 82
4.4.2 Calcul du délai moyen de paquets voix . . . . . . . . . 83
4.4.3 Calcul du délai moyen de paquets data . . . . . . . . . . 84
4.4.4 Résultats numériques et validation empirique . . . . . . 84
4.4.5 Plate-forme de différenciation de service . . . . . . . . 84
4.4.6 Validation du modèle et pondération . . . . . . . . . . . 85
4.4.7 Résultats empiriques . . . . . . . . . . . . . . . . . . . 86
4.4.8 Discussion des résultats . . . . . . . . . . . . . . . . . 88
4.5 Différenciation de service par Priority Queuing . . . . . . . . . 89
4.5.1 Analyse de Priority Queuing . . . . . . . . . . . . . . . 90
4.5.2 Trafic de haute priorité . . . . . . . . . . . . . . . . . . 90
4.5.3 Trafic de basse priorité . . . . . . . . . . . . . . . . . . 91
4.5.4 Résultats numériques et validation empirique . . . . . . 92
4.5.4.1 Résultats en valeurs moyenne . . . . . . . . . 92
4.5.4.2 Résultats en quantiles . . . . . . . . . . . . . 94
4.5.5 Dimensionnement . . . . . . . . . . . . . . . . . . . . 96
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5 Implémentation : Architectures et technologies 101


5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2 Transport du trafic voix . . . . . . . . . . . . . . . . . . . . . . 102
5.2.1 Processus d’arrivée du trafic voix . . . . . . . . . . . . 102
5.2.2 Etude par les valeurs moyennes . . . . . . . . . . . . . 102
5.2.2.1 Analyse du multiplexeur basé 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 basé sur IP . . . . . 105
5.2.3.2 Analyse du multiplexeur basé sur AAL2/ATM 105
5.2.4 Résultats numériques . . . . . . . . . . . . . . . . . . 106
5.3 Transport du trafic data . . . . . . . . . . . . . . . . . . . . . . 108
5.3.1 Processus d’arrivée du trafic . . . . . . . . . . . . . . . 108
5.3.2 Analyse du transport basé sur IP . . . . . . . . . . . . . 109
5.3.3 Analyse du transport basé sur ATM . . . . . . . . . . . 109
5.3.4 Résultats numériques . . . . . . . . . . . . . . . . . . . 109
10 TABLE DES MATIÈRES

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


5.5 Approches de qualité de service dans l’UTRAN basé sur IP . . . 112
5.5.1 Architecture des services différenciés dans l’UTRAN . . 113
5.5.1.1 Le modèle DiffServ . . . . . . . . . . . . . . 113
5.5.1.2 Réseau dorsal DiffServ de l’UTRAN . . . . . 114
5.5.2 Architecture MPLS dans l’UTRAN . . . . . . . . . . . 117
5.5.2.1 MPLS . . . . . . . . . . . . . . . . . . . . . 117
5.5.2.2 Avantages de MPLS dans l’UTRAN . . . . . 117
5.5.2.3 Shémas 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 thèse . . . . . . . . . . . . . . . . . . . . . 121
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Table des figures

2.1 L’UMTS assure la convergence . . . . . . . . . . . . . . . . . . 20


2.2 Architecture générale du réseau UMTS . . . . . . . . . . . . . 21
2.3 Rôle du SRNC et du DRNC lors du soft handover . . . . . . . . 24
2.4 Modèle de protocoles des interfaces de l’UTRAN . . . . . . . . 25
2.5 L’interface radio vue en couches . . . . . . . . . . . . . . . . . 27
2.6 Pile protocolaire de l’interface Iub dans le plan usager . . . . . . 31
2.7 Pile protocolaire de l’interface Iur dans le plan usager . . . . . . 32
2.8 Architecture en couche de la qualité de service UMTS . . . . . 34
2.9 Réseau de transport dans l’UTRAN : liaison directe . . . . . . . 37
2.10 Réseau de transport dans l’UTRAN : plusieurs noeuds . . . . . 37
2.11 Différentes piles protocolaires pour la couche réseau de transport 43

3.1 Format d’un paquet IP . . . . . . . . . . . . . . . . . . . . . . 48


3.2 Format simple d’une trame PPP encapsulant plusieurs paquets IP 49
3.3 Schéma du système . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Plate-forme d’émulation du transport dans l’UTRAN . . . . . . 59
3.5 Implémentation du système . . . . . . . . . . . . . . . . . . . . 60
3.6 Délai de remplissage en fonction du nombre des canaux simul-
tanément actifs . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.7 Délai moyen de séjour dans la file de transmission : comparaison
entre le modèle de Markov, le modèle Er/M/1 et les résultats
empiriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.8 Probabilité de dépassement du délai de séjour (5-TCU)ms en
fonction du nombre de canaux actifs . . . . . . . . . . . . . . . 65
3.9 Comparaison des résultats analytiques et empiriques du délai de
séjour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.10 Délai total empirique dans le multiplexeur . . . . . . . . . . . . 67
3.11 Profil d’arrivée des paquets IP dans la file de transmission avec
n=8 et TCU=2ms . . . . . . . . . . . . . . . . . . . . . . . . . 68
12 TABLE DES FIGURES

3.12 Utilisation utile en fonction du nombre des canaux actives pour


n=8 et différentes valeurs de TCU . . . . . . . . . . . . . . . . 69
3.13 Utilisation utile en fonction du nombre des canaux actives pour
TCU=2 ms et différentes valeurs de n . . . . . . . . . . . . . . 70
3.14 Utilisation utile de la bande passante : analytique et empirique . 71
3.15 Probabilité de dépassement du délai de séjour dans l’UTRAN en
fonction de la capacité de la liaison filaire . . . . . . . . . . . . 72

4.1 Probabilité de dépassement du délai en fonction du nombre des


canaux actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2 La fonction de répartition du délai de séjour avec 15 canaux ac-
tifs : analytique et empirique . . . . . . . . . . . . . . . . . . . 77
4.3 La fonction de répartition du délai de séjour avec 20 canaux ac-
tifs : analytique et empirique . . . . . . . . . . . . . . . . . . . 78
4.4 Probabilité de dépassement du délai en fonction du nombre des
canaux actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.5 Probabilité de dépassement du délai de 10 ms en fonction de la
bande passante . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.6 Modélisation de l’UTRAN avec différenciation de service . . . 82
4.7 Implémentation du système avec différenciation de service . . . 85
4.8 Comparaison des délais à poids égaux : analytique et empirique 86
4.9 Comparaison des délais avec un poids supérieur pour la voix :
analytique et empirique . . . . . . . . . . . . . . . . . . . . . . 87
4.10 Fonction de répartition (CDF) du délai de la voix pour différents
poids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.11 Fonction de répartition (CDF) du délai de donnée pour différents
poids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.12 Fonction de répartition (CDF) du délai total de la voix . . . . . . 90
4.13 Délai moyen pour la voix : analytique et empirique . . . . . . . 93
4.14 Délai moyen pour le trafic data : analytique et empirique . . . . 94
4.15 Délai moyen pour le trafic data : Poisson et périodique . . . . . 95
!"#$%&()' *+(
4.16 percentile des délais voix et data avec et sans PQ . . . . . 96
!"# %&()' *+(
4.17 percentile du délai de la voix et data avec et sans PQ . . . 97
4.18 CDF du délai total pour le trafic voix . . . . . . . . . . . . . . . 98
4.19 CDF du délai pour le trafic data . . . . . . . . . . . . . . . . . . 99

5.1 Schéma du système modélisant l’UTRAN . . . . . . . . . . . . 102


5.2 Format d’une cellule ATM . . . . . . . . . . . . . . . . . . . . 104
TABLE DES FIGURES 13

5.3 Comparaison entre l’IP et l’ATM en terme du délai moyen . . . 106


5.4 Comparaison entre l’IP et l’ATM en terme de la probabilité de
violation du délai cible . . . . . . . . . . . . . . . . . . . . . . 107
5.5 Comparaison entre l’IP et l’ATM en terme de l’utilisation utile
de la bande passante . . . . . . . . . . . . . . . . . . . . . . . . 108
5.6 Comparaison entre l’IP et l’AAL2/ATM en terme du délai moyen 110
5.7 Nombre de canaux DSCH en fonction de la charge correspondante111
5.8 Pile protocolaire pour un RNC connecté aux réseaux IP et ATM 112
5.9 DiffServ dans l’UTRAN . . . . . . . . . . . . . . . . . . . . . 115
5.10 Transport du trafic UTRAN dans le réseau dorsal dans la classe EF116
5.11 Tranport du trafic UTRAN dans des tunnels . . . . . . . . . . . 119
14 TABLE DES FIGURES
Chapitre 1

Introduction

1.1 Motivation
Le système mobile universel de télécommunications (UMTS pour Univer-
sal Mobile Telecommunications System) est l’un des principaux systèmes mo-
biles de la troisième génération connus sous IMT-2000 (International Mobile
Telecommunications-2000) par l’union internationale des télécommunications
(ITU pour International Telecommunication Union). Pour spécifier ces systèmes
mobiles de troisième génération, l’ITU a fédéré les propositions des organismes
de normalisation des différents pays pour les regrouper dans un projet de décision
nommé projet de partenariat pour la troisième génération (3GPP pour Third Ge-
neration Project Partnership). Ce projet prend en compte toutes les instances de
normalisation provenant de l’institut européen de normalisation des télécommunications
(ETSI), de l’association des technologies de télécommunications (TTA Corée),
de la comité des technologies de télécommunications (TTC Japan) et l’organisme
T1 (Etats unis).
Après le succès des systèmes mobiles de deuxième génération, qui ont été
développés pour le transport de la voix en mode circuit, ainsi que quelques
télé-services en mode paquet comme le service de messages courts, et l’essor
de l’Internet qui s’est accompagné d’un accroissement du trafic de données, le
déploiement d’un réseau mobile adapté à la fois au transport du trafic Internet
et de la voix s’est imposé fortement. D’où les travaux élaborés dans le cadre du
projet 3GPP pour développer l’UMTS. Le premier déploiement de ce système
a eu lieu en 2001 au Japon. En Europe, une réalité technico-économique du
développement de l’UMTS a mené à un changement du calendrier de déploiement
dans certains pays ; Il est déjà une réalité en Angleterre et en Italie et devrait être
16 CHAPITRE 1. INTRODUCTION

lancée commercialement en France courant 2004. Ces premiers déploiements


sont fondés sur les spécifications techniques de l’UMTS, telles que les définit la
première version des spécifications du 3GPP connue par Release 99.
L’UMTS est un système multimédia offrant une bande passante plus large
avec de la commutation de paquets ainsi que de nouveaux services et des appli-
cations variées. Ces applications, dont les besoins en bande passante et en qualité
de service sont très différents les unes des autres, utiliseront un même support
de transmission, qu’il soit radio ou terrestre, en mode paquet ou en mode circuit.
A ces exigences s’ajoutent l’utilisation efficace par le système des ressources
de transmission ; l’UMTS devra fournir un service de transfert économique, en
réduisant au minimum les dépenses d’investissement et les coûts d’exploita-
tion. La conception et le déploiement de l’UMTS présentent des enjeux tech-
nologiques importants. Côté radio, une nouvelle technique d’accès multiple par
répartition de codes à bande élargie (WCDMA pour Wideband Code Division
Multiple Access) a été choisi en Europe. Cette technique permet d’avoir des
débits variables ainsi qu’une qualité de service variable sur l’interface radio. Le
débit offert à l’usager, dans des conditions de mobilité réduite, devra atteindre 2
Mbit/s, c’est à dire comparable à celui d’autres technologies fixes d’accès haut
débit.
Le réseau cœur est chargé de la gestion de services souscrits par l’usager et
de l’interconnexion avec les réseaux externes fixes ou mobiles. Il devra maintenir
la communication tout en garantissant la qualité de service, même lorsque l’utili-
sateur est itinérant. Bien que la version 99 du 3GPP a décrit les procédures mises
en place dans le réseau cœur et a aussi étudié les possibles implémentations de
la qualité de service, des innovations sont apportées par les récentes versions
(Releases 4, 5 et 6) de la norme, notamment l’évolution vers le tout-IP (IP pour
Internet Protocol). En exploitant l’environnement IP, l’UMTS bénéficiera direc-
tement de toutes les applications existantes de l’Internet avec une facilité pour le
développement de nouveaux services ainsi que l’utilisation des réseaux IP exis-
tants ce qui permet aux opérateurs de réaliser des économies sur leurs dépenses.
En ce qui concerne le réseau d’accès radio terrestre (UTRAN pour UMTS
Terrestrial Radio Access Network) qui fait l’objet de notre étude, il connecte le
réseau cœur à l’interface radio et représente une part importante des investis-
sements des opérateurs. Il devra aussi contenir un environnement multiservice
puisqu’il contribuera à assurer la qualité de service de bout en bout pour les usa-
gers. La technologie WCDMA impose, aux éléments qui constituent ce réseau
d’accès, des fonctions radios avancées pour la gestion de la mobilité. Ceci consti-
CHAPITRE 1. INTRODUCTION 17

tue un défi pour les fournisseurs des équipements qui devront proposer des solu-
tions techniquement et économiquement intéressantes.

1.2 Problématique
En comparaison au réseau d’accès de deuxième génération comme celui du
système global de télécommunications avec les mobiles (GSM pour Global Sys-
tem for Mobile communication), le réseau d’accès UMTS présente, en plus de
l’utilisation de la technologie WCDMA, des innovations comme l’introduction
de nouvelles interfaces et la gestion de la mobilité indépendamment du réseau
cœur. Ces améliorations exigent des fonctions radio avancées de contrôle de puis-
sance et de synchronisation entre les éléments du réseau d’accès. Pour remplir
ces exigences, le délai de transmission du trafic, qu’il soit temps réel ou non
temps réel, à travers le réseau d’accès UTRAN devrait être limité à des faibles
valeurs de l’ordre de 5 à 7 ms pour le trafic temps réel et de 10 à 50 pour le trafic
non temps réel.
La Release 99 des normes de l’UMTS utilise le transfert asynchrone (ATM
pour Asynchronous Transfer Mode), notamment la couche d’adaptation ATM
type 2 ( AAL2 pour ATM Adaptation Layer 2), comme protocole de transport
dans le réseau d’accès terrestre. Les premières infrastructures déployées pour
le transport du trafic usager dans l’UTRAN sont basées sur l’AAL2/ATM. Par
contre les phases futures consistent à faire évoluer ce réseau en s’appuyant entièrement
sur le protocole IP suivant les recommandations des récentes versions des spécifications
du 3GPP (Releases 4, 5 et 6). L’utilisation de l’IP pour un transport efficace du
trafic usager dans l’UTRAN est un objectif à atteindre. Ce transport devrait sa-
tisfaire les contraintes temporelles exigées tout en maximisant l’utilisation des
ressources. Ceci constitue une solution de transport économiquement efficace et
facilement adaptable avec les possibles phases de déploiement des infrastruc-
tures. Le travail de cette thèse est axé autour de cette problématique.

1.3 Organisation de la thèse


Les travaux de cette thèse sont structurés de la façon suivante :
Au chapitre 2, nous présentons tout d’abord un aperçu de l’architecture du
système UMTS, ainsi que de son réseau d’accès afin de mieux comprendre le
cadre de notre travail. Nous décrivons les rôles des différents éléments de l’archi-
18 CHAPITRE 1. INTRODUCTION

tecture puis nous nous intéressons à la qualité de service dans ce réseau d’accès.
Par la suite, nous faisons le point sur la problématique posée par l’UTRAN.
Nous faisons le tour des différentes solutions proposées pour le transport du tra-
fic usager, celles basées sur l’AAL2/ATM ainsi que celles basées sur IP. Dans ce
contexte, nous précisons les points essentiels examinés dans cette thèse.
Dans le chapitre 3, nous considérons le transport du trafic temps réel tel que
la voix et nous évaluons les performances du transport IP, en termes du délai,
valeurs moyennes et quantiles, et d’efficacité d’utilisation de la bande passante.
Nous présentons les résultats du modèle analytique ainsi que les résultats empi-
riques des tests de validation effectués sur une plate-forme émulant les fonction-
nalités de transport dans l’UTRAN.
Dans le chapitre 4, nous étudions le transport du trafic non temps réel qui
nécessite lui aussi un transport temps réel et nous nous intéressons par la suite
à la différenciation de service entre les flux temps réel et non temps réel. Nous
examinons les performances des mécanismes de différenciation de service pro-
posés pour cet objectif notamment weighted round robin et priority queuing . Les
résultats analytiques et empiriques sont aussi présentés et le chapitre se conclut
par un dimensionnement de l’UTRAN.
Dans le chapitre 5, nous examinons l’implémentation des technologies de
transport dans l’UTRAN en comparant les performances de l’IP et celles de
l’AAL2/ATM et nous nous intéressons au réseau dorsal de l’UTRAN par l’ana-
lyse des différentes implémentations possibles pour le transport IP dans l’UTRAN.
Pour terminer, le chapitre 6 présente la conclusion et les perspectives de ce
travail.
Chapitre 2

Le réseau d’accès radio terrestre


UMTS (UTRAN)

2.1 Introduction

L’UMTS devra assurer des hauts débits jusqu’à 2Mbits/s par usager et of-
frir des services diversifiés et développés (voir figure 2.1). Il intègre multimédia,
informatique et télécommunications. Selon l’ETSI, la norme UMTS devra rem-
plir plusieurs objectifs : un système multimédia unique et efficace, assurant une
couverture globale, une flexibilité d’usage ainsi qu’une offre multiservices. Dans
cette perspective, les points principaux à retenir pour la norme UMTS sont : le
contexte mondial de normalisation, la convergence des technologies et l’intro-
duction des services multimédia. De plus, le déploiement du réseau doit être suf-
fisamment flexible pour s’adapter aux évolutions attendues du trafic. L’UTRAN
occupe une importance considérable lors du déploiement parce que les ressources
sont rares et chères. La technologie d’accès WCDMA a été retenue sur l’inter-
face air et sera déployé en Europe, à la fois en mode TDD (Time Division Du-
plex) et en mode FDD (Frequency Division Duplex). Pour le réseau terrestre,
nous nous intéressons dans notre étude au transport du trafic usager et nous
étudions les performances du transport IP dans l’UTRAN ainsi que ses possibles
implémentations.
Dans ce chapitre, nous présentons brièvement l’architecture de l’UMTS et
nous focalisons l’étude sur la qualité de service ainsi que le transport dans l’UTRAN.
Nous achevons le chapitre par la direction choisie dans cette thèse.
20 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

Internet Télécommunications
Web Mobilité/Roaming
E−mail ... Voix, Data, SMS, Fax ...

UMTS

Multimédia Nouvelles technologies


Visiophonie Transport mode circuit
Distribution radio et TV Transport mode paquet
Télé−enseignement... Accès radio large bande

F IG . 2.1 – L’UMTS assure la convergence

2.2 Architecture globale du réseau UMTS


L’architecture du système UMTS est compatible avec les autres réseaux mo-
biles de deuxième et de troisième génération et garantie en même temps une
évolution adaptable en fonctions des besoins des opérateurs de télécommunications.
Cette architecture est perceptible de deux points de vue : l’un physique où on
parle des éléments ou équipements qui composent le réseau, et l’autre fonction-
nel où on parle des strates afin d’identifier les protocoles mis en œuvre pour
assurer la communication entre ces éléments.
L’architecture générale du réseau UMTS est présentée dans la Figure 2.2. Les
éléments de réseau du système UMTS sont répartis en trois groupes. Un corres-
pond au réseau d’accès radio (UTRAN) qui supporte toutes les fonctionnalités
radio. L’autre correspond au réseau cœur (CN pour Core Network) qui est res-
ponsable de la commutation et du routage des communications vers les réseaux
externes. Le système est complété par l’équipement usager (UE pour User Equi-
pement) qui se trouve entre l’usager proprement dit et le réseau d’accès radio.
L’équipement usager est connecté à l’UTRAN par l’interface radio ou Uu. Il
est composé des deux parties suivantes :
– Le terminal mobile (ME pour Mobile Equipment) correspond au terminal
radio utilisé pour les communications radio sur l’interface Uu.
– La carte USIM (UMTS Suscriber Identity Module) est une carte à puce
qui stocke entre autres l’identité de l’abonné, les algorithmes et les clefs
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 21

Iu Réseaux
Uu UTRAN CN externes

UE Iub CS
Node B
MSC/VLR GMSC
RNC RNIS
RTCP
...
Node B

!# ('('('(' $!#&!% *)*)*)*) $#&%


UE Iur
('('' "!"!"!*)*)) """ HLR

Node B
PS

Internet

Node B
RNC SGSN GGSN

F IG . 2.2 – Architecture générale du réseau UMTS

d’authentification et les clefs de chiffrements.


L’UTRAN fournit à l’UE les ressources radio et les mécanismes nécessaires
pour accéder au CN par l’interface Iu. Ses composantes sont détaillées dans la
section 2.3.
Dans le réseau cœur, nous distinguons les domaines suivants :
1. Le domaine de commutation de circuit (CS pour Circuit Switching) pour
l’accès aux services en mode circuit. C’est un prolongement de l’approche
réseau GSM pour les services téléphoniques et supplémentaires en mode
circuit. Il comprend :
– Le commutateur du service mobile (MSC/VLR pour Mobile Services
Switching Center/Visitor Location Register), qui correspond au commu-
tateur (MSC) qui gère les connexions circuits et à la base de données
(VLR) qui contient une copie du profil de l’abonnée.
– Le GMSC (Gateway MSC) qui est un commutateur connecté directe-
ment au réseau 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 pour Packet Switching) pour
l’accès aux services en mode paquet. C’est une migration de l’approche
du service général de radio-communication en mode paquet (GPRS pour
General Packet Radio Services) vers un domaine multimédia IP, il com-
prend :
22 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

– Le nœud de support GPRS de desserte (SGSN pour Serving GPRS Sup-


port Node) qui possède les mêmes fonctions que le MSC/VLR mais il
est utilisé pour les communications paquet.
– Le nœud de support GPRS de transit (GGSN pour Gateway GPRS Sup-
port Node) qui possède des fonctionnalités très proches de celles du
GMSC mais il ne traite que des connexions en mode paquet.
3. Un domaine commun, qui comprend :
– L’enregistreur de location nominal (HLR pour Home Location Register)
qui est une base de données contenant toutes les informations relatives
à l’abonnement d’un usager et aux droits d’accès.
– De plus, nous trouvons le EIR (Equipement Ithentification Register) qui
est le centre qui fournie au réseau l’autorisation de fonctionner sur le
réseau ainsi que l’AuC (Authentification Center). Ce dernier est le centre
qui vérifie l’authentification des mobiles et stockent les clés de chiffre-
ment.
Quant aux réseaux externes, ils sont en mode CS tels que le Réseau Numérique
à Intégration de Services (RNIS) ou le Réseau Téléphonique Commuté Public
(RTCP), et en mode PS tels que le réseau Internet et d’autres réseaux de trans-
mission de données.
En ce qui concerne les strates, le réseau UMTS est composé de deux strates,
appelés strate d’accès (AS pour Access Stratum) et strate de non accès (NAS
pour Non Access Stratum). L’AS regroupe toutes les fonctions de l’UMTS liées
au réseau d’accès, dont, par exemple, les fonctions de gestion des ressources ra-
dio et de handover 1 . L’UTRAN est par définition entièrement inclus dans l’AS.
Par ailleurs l’AS comprend aussi une partie de l’équipement mobile (celle qui
gère les protocoles de l’interface radio) ainsi qu’une partie du réseau cœur (cor-
respondant à l’interface Iu). Le niveau NAS comprend toutes les autres fonctions
du réseau UMTS, indépendant du réseau d’accès.

2.3 Le réseau d’accès UTRAN


L’UTRAN est constitué d’un ensemble de sous-systèmes réseau radio (RNS
pour Radio Network Subsystem). Chaque RNS regroupe un contrôleur de réseau
radio (RNC pour Radio Network Controller) et une ou plusieurs stations de bases
1
Mécanisme permettant de transférer une connexion mobile-réseau d’une ressource radio à
une autre.
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 23

(Node B). Deux RNCs sont connectés entre eux via l’interface Iur. L’interface
entre un Node B et un RNC est l’interfaçe Iub (voir figure 2.2).
On associe le Node B à la station de base du GSM. Son rôle principal est d’as-
surer les fonctions de réception et de transmission radio pour une ou plusieurs
cellules de l’UTRAN. C’est un nœud logique qui gère la couche physique de l’in-
terface radio ; Il régit principalement le codage du canal, l’entrelacement, l’adap-
tation du débit et l’étalement. Il est constitué d’un port commun de contrôle et
d’un ensemble de points de terminaison de trafic, chacun contrôlé par un port de
contrôle dédié. Un point de terminaison de trafic peut contrôler plus d’une cellule
et une cellule peut être contrôlée par plus d’un point de terminaison. Le Node B
participe activement au contrôle de puissance dans une cellule en transmettant
une commande à l’UE afin qu’il ajuste sa puissance d’émission. Le mécanisme
de contrôle de puissance où le Node B et l’UE ajustent mutuellement leur puis-
sance d’émission est connu sous le nom boucle interne de contrôle de puissance
(inner-loop power control).
Le RNC est l’entité de l’UTRAN chargée principalement du routage des
communications dans le réseau d’accès. Ses fonctions couvrent la gestion des
ressources radio, le contrôle de puissance, l’allocation des codes pour des nou-
veaux liens radio, le contrôle de congestion, la gestion des interfaces vers le
Core Network ainsi que d’autres fonctions liées à la mobilité de l’usager. Dans
la boucle externe de contrôle de puissance (outer-loop power control), le RNC
assure la mise à jour, au niveau du Node B, du seuil de qualité afin d’ajuster la
valeur du rapport signal/interférence (SIR pour Signal-to-Interference Ratio).
On distingue différents rôles pour le RNC : Serving RNC (SRNC), Control-
ling RNC (CRNC) et Drift RNC (DRNC). Un même équipement physique RNC
supporte généralement ces différentes fonctions logiques.
La figure 2.3 montrent les rôles du RNC. Le RNC qui contrôle un Node B,
c. à d. le RNC qui est directement connecté à ce Node B par l’interface Iub,
est appelé CRNC. Le SRNC est, pour un mobile, le RNC qui gère l’interface
Iu avec le réseau cœur et établit la connexion radio. Il est aussi en charge du
traitement des données transmises sur l’interface air. Un UE ne peut avoir qu’un
SRNC et un seul. Le DRNC assure le routage des données usagers vers le Ser-
ving RNC dans le sens montant et vers les Nodes B dans le sens descendant
lors d’un soft handover. Il peut aussi effectuer la recombinaison de liens. Lors
d’un soft handover, le trafic émis par l’équipement usager en déplacement peut
s’écouler en parallèle dans deux connexions. L’ancienne est directement reliée
au SRNC via une interface Iub alors que le trafic utilisant la nouvelle connexion
24 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

passe par une autre interface Iub qui est reliée au DRNC. Ce dernier achemine le
trafic vers le SRNC via l’interface Iur. Dans le SRNC, la recombinaison du tra-
fic provenant des deux connexions permet l’envoie d’un seul flux vers le réseau
cœur. Ce mécanisme fait partie de la macro-diversité (macro-diversity) qui est

Réseau coeur (CN)

Iu

Iur
SRNC DRNC

Iub

Node B Node B Node B Node B

Uu

F IG . 2.3 – Rôle du SRNC et du DRNC lors du soft handover

une technique utilisée avec les interfaces radio du type WCDMA. Elle désigne la
phase pendant laquelle le mobile maintient plusieurs liens radios avec différentes
stations de base. Par conséquent, dans les sens montants et descendants, une re-
combinaison de liens en fonction d’informations sur la qualité du lien radio doit
être effectuée (par le mobile dans le sens descendant et par le réseau dans le sens
montant). Dans le sens montant, le choix entre la meilleure des informations en
fonction de l’indicateur de qualité peut être réalisé à différents niveaux du réseau
d’accès.

2.4 Les protocoles de l’UTRAN


Les protocoles des interfaces UTRAN ont été structurés selon le modèle qui
est présenté dans le figure 2.4. Cette structure est basée sur une découpe horizon-
tale en couches ou verticale en plans. Les couches et les plans sont logiquement
indépendantes ce qui laisse la possibilité, en cas de besoin, qu’une partie de la
structure des protocoles sera changée dans le futur et les autres parties restent
intactes.
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 25

Couche du
réseau radio Plan de contrôle Plan usager

RNL Protocole d’application Flot(s) de données

Plan usager du Plan de contrôle du Plan usager du


Couche du réseau de réseau de transport réseau de
réseau de transport transport
transport ALCAP

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

Couche physique

F IG . 2.4 – Modèle de protocoles des interfaces de l’UTRAN

La découpe horizontale fait apparaı̂tre deux couches principales :


– La couche du réseau radio (RNL pour Radio Network Layer), elle com-
prend les aspects spécifiques liés à l’UTRAN. La structure de cette couche
est tel que chacune des interfaces Iu, Iub et Iur comporte deux types de
protocoles. Le protocole d’application (AP pour Application Protocol), af-
fecté au plan de contrôle qui s’occupe des échanges de signalisation entre
les différents équipements et le protocole de trame (FP pour Frame Proto-
col) affecté au plan usager qui se charge du transport de données usagers.
– La couche du réseau de transport (TNL pour Transport Network Layer),
elle correspond à une technologie de transport standard choisie pour l’UTRAN
mais qui ne lui est pas spécifique. Elle est composée de la couche physique
(physical layer), des canaux de communications (signalling et data bearer)
et de la couche ALCAP (Access Link Control Application Part), utilisée
pour établir les chemins de transmission du plan usager (data bearer).
La découpe verticale fait apparaı̂tre les plans suivants :
– Le plan de contrôle (control plane) qui est utilisé pour la signalisation de
contrôle spécifique à l’UMTS. Il comprend entre autres le protocole AP
qui initialise des supports vers l’équipement 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
reçues ou envoyées par l’usager, comme la voix ou les données. Ce plan
comprend les flux de données (data stream) qui utilisent les supports de
26 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

données (data bearer) échangées sur les interfaces.


– Le plan de contrôle du réseau de transport (transport network control
plane). Ce plan présente la particularité de n’être présent qu’au niveau de
la couche de transport, car il est utilisé pour établir les supports données
du plan usager. Il inclut également des supports de signalisation.

2.5 Les interfaces des éléments logiques de l’UTRAN


Les spécifications de l’UMTS sont structurées autour des interfaces entre les
éléments logiques du réseau. Nous présentons les différents interfaces ouvertes
disponibles en relation avec l’UTRAN : Uu, Iub, Iur, Iu.

2.5.1 L’interface Uu
L’interface logique Uu ou interface radio connecte l’équipement usager au
Node B. Ses protocoles s’appliquent aux trois premières couches du modèle OSI
(Open Systems Interconnections) qui sont montrées dans la figure 2.5 : la couche
physique (Couche 1), la couche liaison de données (Couche 2), et la couche
réseau (Couche 3). De plus, les spécifications du réseau UMTS contiennent une
grande variété de canaux de communication, répartie en trois grandes classes
hiérarchiques : Les canaux logiques, les canaux de transport et les canaux phy-
siques. Ces différentes classes de canaux ont été créées pour garantir l’indépendance
entre les différents niveaux fonctionnels de l’interface radio. La définition de
canaux propres à chaque niveau donne une grande flexibilité au réseau UMTS
en lui permettant de s’adapter à la multitude d’applications envisagées pour le
réseau de troisième génération.
Pour les canaux logiques, un ensemble de canaux a été défini pour les différents
types de services de transfert de données. On distingue les canaux de contrôle qui
sont utilisés pour le transfert des informations du plan de contrôle et les canaux
de trafic pour les données du plan usager. Les principaux canaux de contrôle
sont le canal de contrôle de diffusion (BCCH pour Broadcast Control Channel),
le canal de contrôle de recherche (PCCH pour Paging Control Channel), le canal
d’accès aller (FACH pour Forward Access Channel), le canal de contrôle dédié
(DCCH pour Dedicated Control Channel). Comme canaux de trafic, nous citons
le canal de trafic dédié (DTCH pour Dedicated Traffic Channel) et le canal de
trafic commun (CTCH pour Common Traffic Channel).
Aux canaux logiques correspondent des canaux de transport représentant les
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 27

services offerts par la couche physique aux couches supérieures. Ils peuvent être
séparés en canaux dédiés comme le canal dédié (DCH pour Dedicated Channel)
et canaux communs comme le canal partagé de liaison descendante (DSCH pour
(Down link Shared Channel), le canal de diffusion, le canal de recherche, etc.
Les canaux de transport s’appuient, à leur tour, sur des canaux physiques pour
la transmission sur la voie radio. Un canal physique correspond à une fréquence
spécifique, un code ou plusieurs codes et à un déphasage relatif pour le lien mon-
tant. Comme canal dédié, il y a le canal physique de données dédié (DPCH pour
Dedicated Physical Data Channel), et comme canal commun il y a entre autres,
le canal physique de contrôle commun (CCPCH pour (Common Control Phy-
sical Channel), le canal physique partagé de liaison descendante (PDSCH pour
(Physical Downlink Shared Channel), etc. La correspondance entre les canaux
logiques, de transport et physiques est détaillée dans [15].

Plan de contrôle Plan usager

Couche 3
RRC

PDCP
BMC

RLC Couche 2

Canaux
logiques

MAC

Canaux de
transport

PHY Couche 1

Canaux physiques

F IG . 2.5 – L’interface radio vue en couches

2.5.1.1 La couche physique

La couche physique (Couche 1) est basée sur le WCDMA qui est le plus im-
portant changement sur l’interface radio par rapport aux systèmes mobiles tels
que GSM. Cette technique utilise l’étalement de spectre par séquence directe
(voir [16]). Tous les usagers émettent sur un même canal radioélectrique large
28 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

bande, mais ils se distinguent par une séquence d’étalement pseudo-aléatoire


propre, appelée code et connue du récepteur. Plusieurs codes peuvent être al-
loués à un même usager et transmis simultanément sur le même canal radio
pour augmenter son débit de transmission. Un contrôle de puissance efficace
est nécessaire pour garantir que l’ensemble des signaux (signal utile + bruit)
soient reçus avec des niveaux de puissance similaires permettant d’assurer une
démodulation efficace. Des études de performances de la couche physique se
trouvent dans [15] p. 303-346.

2.5.1.2 La couche liaison de données

Elle comprend les sous-couches de commande d’accès au support (MAC


pour Medium Access Control) et de commande de liaison radio (RLC pour Ra-
dio Link Control) dans le plan de contrôle. Dans le plan usager, en plus des
couches MAC et RLC, le protocole de convergence de données en mode paquet
(PDCP pour Packet Data Convergence Protocol) et le protocole de contrôle de
diffusion (BMC pour Broadcast/Multicast Control Protocol) ont été rajoutés. La
fonction principale de la couche MAC est le contrôle de l’accès à la voie radio.
Elle permet de faire la correspondance entre les canaux logiques et les canaux
de transport et elle est responsable de la sélection et la modification du format de
transport (TF pour Transport Format) approprié à chaque canal de transport en
fonction du ou des débits instantanés des canaux logiques. La couche MAC est
aussi chargé de la gestion de priorité entre les flux de données au niveau terminal
ou entre plusieurs terminaux sur les canaux de transport. Des schémas de prio-
rité d’accès sont proposés dans [62]. Entre autres fonctions cette couche gère le
volume du trafic et assure le multiplexage/ démultiplexage des unités de données
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 données usager et les informations de
contrôle suivant trois modes de fonctionnement : le mode transparent, le mode
non acquitté et le mode acquitté. Chaque instance RLC est configurée par la
couche de contrôle des ressources radio (RRC pour Radio Resource Control)
pour fonctionner dans l’un de ces trois modes. Dans le mode transparent, le
RLC n’effectue aucun contrôle des PDUs, d’où le RLC PDU ne contient de
ce fait aucune entête. Ce mode est utilisé par exemple pour la voix. Le mode
non acquitté (UM, Unacknowledged Mode) offre la possibilité de segmenter et
de concaténer les RLC-PDUs. L’entité réceptrice a la charge de réassembler les
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 29

différents segments avant de les envoyer à la couche utilisatrice. Il assure un


contrôle de numéro de séquence des RLC-PDUs mais aucun protocole de re-
transmission n’est utilisé et la distribution des données n’est donc pas garantie.
Il peut être par exemple utilisé pour les services comme des messages courts
SMS Cell Broadcast provenant du GSM. Le mode acquitté (AM, Acknowled-
ged Mode) assure, en plus des fonctions présentes dans le mode non acquitté, le
contrôle de flux, l’acquittement des RLC-PDUs transmises et la correction d’er-
reurs par retransmission. Le mode acquitté peut être utilisé par exemple pour
le Web. Voir [22] p. 236-241 pour une vue détaillée de ces modes de transfert.
D’autres travaux examinant les performances de la couche RLC sont présentés
dans [63, 64].
Le protocole PDCP n’est utilisé qu ’au niveau du plan usager et seulement
pour les services du domaine paquet. Le protocole PDCP comprend des méthodes
de compression des entêtes des protocoles TCP/IP ou RTP/UDP/IP au niveau
de l’entité émettrice et décompression au niveau de l’entité réceptrice. Il gère
le transport de données usagers et supporte la procédure ré-allocation SRNS 2
(SRNS Relocation) sans perte d’informations.
Le protocole BMC prend en charge les services de diffusion sur l’interface
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 réseau

Elle comprend la couche RRC qui appartient au plan de contrôle. La couche


RRC constitue le lien entre l’AS et le NAS. Elle encapsule toute la signalisation
en provenance des couche hautes et à destination des couches 1 et 2. Elle gère en
particulier, l’établissement, le maintient et le relâchement de la connexion RRC
entre le mobile et l’UTRAN. Elle s’occupe également des fonctions comme la
gestion de la mobilité en mode connecté, le Paging 3 , etc.

2.5.2 L’interface Iub


En reprenant la figure 2.4, la couche radio de l’interface Iub contient le pro-
tocole sous-système d’application du Node B (NBAP pour Node B Application
2
La procédure de ré-allocation de Serving RNS consiste à changer d’interface physique entre
le réseau d’accès UMTS et le réseau cœur à la suite d’un handover ; le DRNC devient ainsi
SRNC.
3
Recherche du mobile lors d’un appel de la station de base vers le mobile.
30 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

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


protocole NBAP est utilisé pour les échanges de signalisation entre le Node B
et le RNC. Il existe deux catégories d’échanges : ceux destinés à un usager et
ceux destinés à un ensemble d’usagers. Les messages de la première catégorie
permettent d’assurer les fonctions suivantes :
– Gestion des liens radio (création ou suppression d’un lien).
– Gestion des mesures radio par le RNC (configuration des mesures pour un
mobile, et la remontée de ces mesures jusqu’au RNC).
– Contrôle de puissance (outerloop).
Les messages de la seconde catégorie permettent d’assurer les fonctions sui-
vantes :
– Gestion des canaux de transport communs de la ou des cellules du Node
B.
– Configuration des informations système diffusées par cellule du Node B.
– Gestion des mesures radio sur les canaux communs de la cellule.
Pour le plan usager, l’interface Iub transporte le trafic circulant entre le SRNC
et le Node B. La pile protocolaire pour le transport du trafic usager est présentée
dans la figure 2.6. Le Node B fonctionne comme un simple relais qui achemine
le contenu des canaux de transport entre l’équipement usager et le RNC. En tra-
versant les couches RLC et MAC, le trafic change de profil en comparaison avec
son profil à la source. Selon le mode de fonctionnement spécifié pour le type du
trafic, la couche RLC achemine le trafic vers la couche MAC qui sélectionne le
format de transport. Ce format transport spécifie l’intervalle de temps de trans-
mission (TTI pour Transmission Time Interval) des blocs de données. La couche
FP rassemble tous les blocs envoyés pendant un TTI et appartenant au même
service, en une trame FP-PDU (FP Packet Data Unit) en ajoutant un en-tête. Le
transport des trames FP est assuré par la couche de transport et il est transparent
aux connexions radio. Ce transport doit remplir les exigences de la qualité de
service ; Les fonctions radio avancées adoptées dans l’UMTS, comme la macro-
diversité, ainsi que les caractéristiques particulières des applications imposent de
fortes contraintes temporelles pour le transport de trafic via l’interface Iub. Sur
la voie descendante, si la couche MAC du RNC envoie une trame sur l’interface
Iub, cette trame devrait arriver au Node B dans un intervalle de temps précis pour
être transmis sur l’interface air.

Dans cette thèse, nous nous intéressons à cette couche du réseau de trans-
port, notamment dans le cas où elle est basée sur IP, pour assurer un dimension-
nement garantissant les ressources nécessaires pour un transport respectant les
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 31

contraintes temporelles avec une utilisation utile de ces ressources.

Uu Iub
RLC RLC Couche du
MAC MAC réseau radio
FP FP RNL

UDP/IP UDP/IP Couche du


réseau de
Couche liaison Couche liaison transport
de données de données TNL
Physique Physique Couche Couche
(WCDMA) (WCDMA) physique physique

UE Node B RNC

F IG . 2.6 – Pile protocolaire de l’interface Iub dans le plan usager

2.5.3 L’interface Iur


L’interface Iur a été définie afin de supporter le handover entre deux Node B
contrôlés par des RNC différents, autrement dit le mécanisme de transfert (soft
handover) entre le SRNC et le DRNC. D’autres fonctionnalités ont été ajoutées
durant le développement de la norme comme la gestion des ressources et le sup-
port des canaux, dédiés et communs, de trafic. La couche radio de l’interface
utilise le protocole sous-système d’application du réseau radio (RNSAP pour
Radio Network Subsystem Application Part) dans le plan de contrôle. Ce proto-
cole assure les échanges de signalisation entre deux RNCs. En ce qui concerne
le plan usager le protocole Iur-FP est utilisé. Dans ce plan, l’interface Iur trans-
porte le trafic des usagers en soft handover. Par conséquent, le trafic Iur n’est
autre qu’une partie du trafic Iub. La pile protocolaire pour le transport du trafic
usager est montrée dans la figure 2.7.

2.5.4 L’interface Iu
C’est une interface ouverte qui sépare l’UTRAN du réseau cœur. Elle peut
être du type mode circuit (Iu CS) ou mode paquet (Iu PS). Le plan de contrôle est
commun aux deux interfaces Iu CS et Iu PS, mais le plan de contrôle du réseau
de transport est différent afin d’optimiser le transport au niveau du plan usager
en permettant l’utilisation de différentes technologies de transport. Notre étude
ne couvre pas cette interface ; Des détails concernant les piles de protocoles des
32 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

Uu Iub Iur
RLC RLC Couche du
MAC MAC réseau radio
FP FP FP RNL

UDP/IP UDP/IP UDP/IP Couche du


réseau de
Couche liaison Couche liaison Couche liaison
transport
de données de données de données
TNL
Physique Physique Couche Couche Couche
(WCDMA) (WCDMA) physique physique physique

UE Node B D−RNC S−RNC

F IG . 2.7 – Pile protocolaire de l’interface Iur dans le plan usager

interfaces Iu Cs et Iu Ps des plans de contrôle, usager et de contrôle du réseau de


transport sont présentés dans [15].

2.6 Qualité de service dans l’UMTS


La qualité de service se réfère à l’effet globale de la performance du service
qui détermine le niveau de satisfaction de l’usager. Elle doit être fournit de bout
en bout. Le réseau UMTS peut être vue comme une entité servant d’interface
d’accès pour une connexion à un ensemble de réseaux externes fixes ou mobiles.
La qualité de service UMTS est définie dans [6] avec un ensemble d’attributs qui
devraient répondre à certains critères tels que la satisfaction par le système des
besoins de qualité de service de l’usager, l’utilisation efficace des ressources, la
flexibilité de gestion de la qualité de service et l’interopérabilité avec les schémas
de qualité de service d’autres réseaux.

2.6.1 Classes de services


L’UMTS offre une panoplie de services ayant des qualités de service différentes.
Au niveau applicatif, des classes de service ont été définies afin de regrouper les
services en fonction de leurs contraintes. La principale caractéristique qui permet
de distinguer les applications qui appartiennent à ces différentes classes est leur
sensibilité au temps de transfert. Les quatre classes de services définies dans le
cadre de l’UMTS sont :
– Le trafic conversationnel (Conversational) : cette classe regroupe tous les
services symétriques ou bidirectionnels nécessitant un temps de transfert
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 33

faible et constant donc, une faible gigue. L’application typique de cette


classe est la voix sur un service support circuit ou encore voix sur IP.
La vidéotéléphonie et les jeux vidéo interactifs font aussi partie de cette
classe.
– Le trafic à flux continu (Streaming) : Cette classe regroupe tous les ser-
vices impliquant un usager et un serveur de données. Les applications
de cette classe sont asymétriques du fait que les données étant majori-
tairement transférées du réseau au mobile. En comparaison avec la classe
conversationnelle, les délais tolérés de transfert de l’information sont plus
importants. Les services représentatifs de cette classe, entre autres, les ser-
vices de vidéo à la demande, la diffusion radiophonique ou les applications
de transfert d’images.
– Le trafic interactif (Interactive) : Cette classe regroupe tous les services
dans lesquels un usager entretient un dialogue interactif avec un serveur
d’applications ou de données. Contrairement aux classes précédentes, elle
ne nécessite pas de performance temps réel particulière. En revanche, il
est essentiel pour ce type d’applications que l’information transmise ne
subisse aucune altération. Cette classe correspond à la navigation sur In-
ternet, le transfert de fichiers FTP, ou toutes les applications de commerce
électronique.
– Le trafic d’arrière-plan (Background) : La principale caractéristiques des
applications de cette classe est que leurs usagers n’ont pas besoin de re-
cevoir les informations correspondant à ces applications dans un délai très
court, autrement dit la priorité de transmission est inférieure à celle de la
classe interactive. Le délai 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 multimédia
de type SMS (Short Message Service), MMS (Multimedia Message Ser-
vice) ou email.

2.6.2 Architecture de la qualité de service UMTS


La qualité de service UMTS résulte de celle assurée sur l’interface radio,
dans l’UTRAN et dans le réseau cœur. L’architecture de la qualité de service se
compose des différentes fonctions du réseau assurant à l’utilisateur la qualité de
service appropriée. L’architecture en couches décrite dans [6] est présentée dans
la figure 2.8. Chaque service support d’une couche donnée fournit ses propres
34 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

services à la couche supérieure en utilisant ceux des couches inférieures. Un


service UMTS est de bout-en-bout d’un équipement terminal à un autre. Il utilise
le service support local TE/ME (TE/MT Local Bearer Service) qui ne fait pas
partie du réseau UMTS, le service support UMTS (UMTS Bearer Service), ainsi
que le service support externe (External Bearer Service) qui peut être un service
offert par d’autres réseaux y compris un autre service support UMTS. A son tour,
le service support UMTS s’appuie sur le service support d’accès radio (Radio
Access Bearer Service) et sur le service support de cœur du réseau (CN Bearer
Service) qui offre des services de transport au sein du réseau cœur de l’UMTS.
Le service support d’accès radio, utilisant le service support radio (Radio Bearer
Service ) et le service support de l’interface Iu (Iu Bearer Service), assure le
transport des données entre le TE et l’Edge CN. Les services fournis par l’UTRA
FDD/TDD gèrent les aspects liés au transport sur l’interface radio.
UMTS

TE MT UTRAN CN Iu CN TE
Egde node Gateway

End−to−End Service

TE/MT Local External Bearer


Bearer Service UMTS Bearer Service Service

CN Bearer
RAB Service Service

Radio Bearer Iu Bearer Backbone


Service Service Network Service

UTRA FDD/ Physical Bearer


TDD Service Service

F IG . 2.8 – Architecture en couche de la qualité de service UMTS

Pour répondre aux besoins de la qualité de service de bout-en-bout exigée par


les applications, la signalisation dans le plan de contrôle active les services sup-
ports nécessaires pour assurer ces besoins. Dans le plan usager, les mécanismes
avancés de qualité de service correspondants sont mis en place. Par exemple, le
service support UMTS est établi par le protocole de données en mode paquet
(PDP Packet Data Protocol). Chaque PDP contexte comprend un ensemble d’at-
tributs de qualité de service et de réservation de ressource qui lui sont associés.
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 35

Le profil de qualité de service est négocié durant la procédure d’activation du


PDP contexte et décrit la qualité du support UMTS qui sera allouée à l’usager.

2.6.3 La qualité de service dans l’UTRAN


La qualité de service dans le réseau d’accès fait partie de la qualité de service
offerte par le service support d’accès radio. Ce dernier assure le transport des
données entre le TE et le CN, autrement dit, de l’interface Uu vers l’interface
Iu. Donc, il s’appuie sur les services support des interfaces Iub, Iur ainsi que
l’interface radio. Le réseau d’accès devrait établir et maintenir le service support
d’accès radio (RAB) avec les niveaux de qualité de service voulus. D’où l’impact
de la qualité de service offerte sur les interfaces Uu, Iub, Iur et Iu. Côté radio,
des techniques spécifiques, comme le contrôle d’admission radio ou le contrôle
de puissance, tiennent compte des profils de qualité de service. La fonction de
contrôle d’admission radio autorise ou refuse l’accès au ressources radio selon
des critères comme la disponibilité des ressources, la prise en charge d’un nou-
veau usager ne doit pas dégrader la qualité de service offert aux autres usagers
(voir [60, 61]). Le contrôle de puissance permet de maintenir au plus bas le ni-
veau des interférences radioéléctriques dans le système basé 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 qualité de service du RAB. Tout
d’abord, il faut répondre aux besoins des applications elles-mêmes, qui peuvent
être temps réel ou non temps réel. Mais surtout des contraintes strictes sur le
délai transport sont exigées dans l’UTRAN ce qui fait que le transport, que ce
soit d’un trafic temps réel ou non temps réel, est un transport temps réel. Ces
contraintes de transport sont liées aux fonctions radio avancées mises en oeuvre
dans le réseau d’accès UMTS et dues à la synchronisation entre le RNC et le
Node B. Les mécanismes de synchronisation sont indispensables pour obtenir
de meilleures performances sur l’interface radio. Par exemple, pour assurer la
macro-diversité lors du handover, la recombinaison des signaux provenant des
différentes branches n’est possible que si ces signaux sont relativement synchro-
nisés. Le service voix exige un délai de transport court de l’ordre de 5-7 ms [13]
alors que le trafic non sensible au temps réel peut tolérer des délais plus impor-
tants sachant qu’il doit respecter certaines bornes sur le délai de l’ordre de 10 à
50 ms [13, 30]. Nous notons que dans notre étude, les bornes sur le délai pour
le transport sont les suivantes : 5 ms pour le trafic temps réel et 10 ms pour le
36 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

trafic non temps réel. Dans le cas où un constructeur d’équipements propose des
bornes plus grandes notamment pour le transport du trafic non temps réel, notre
modèle ainsi que notre méthodologie restent valables. En utilisant notre étude,
l’opérateur peut déterminer facilement le dimensionnement dans l’UTRAN en
prenant d’autres valeurs pour ces bornes.

2.7 Topologies du réseau de transport dans l’UTRAN


L’architecture de l’UTRAN est hiérarchique c. à. d. elle est basée sur une ges-
tion centralisée des ressources radio au niveau RNC. Un Node B communique
avec un RNC précis comme dans l’architecture du système GSM entre une sta-
tion de base et son contrôleur. Des propositions sont lancées pour évoluer vers
une architecture distribuée [12, 73] où certaines fonctions seront déplacées vers
le Node B et ce dernier peut communiquer avec n’importe quel RNC. Cepen-
dant, la plupart des travaux, y compris le notre, se situent dans le cadre d’une
architecture hiérarchique.
Les éléments logiques et les équipements de l’UTRAN sont bien définis dans
les spécifications alors que le réseau de transport sur les interfaces Iub et Iur est
ouvert aux choix retenus par les opérateurs. L’objectif de ce réseau de trans-
port est l’interconnexion entre le Node B et le RNC. Il peut donc aller d’une
simple connexion directe à un réseau métropolitain (MAN pour Metropolitan
Area Network), à la possibilité d’utiliser les infrastructures des réseaux existants.
Dans notre travail, nous examinons l’interconnexion entre le Node B et le RNC
dans les cas d’une connexion directe (voir figure 2.9) et celle via un réseau de
plusieurs nœuds comme le montre la figure 2.10. Dans ce cas, un ou plusieurs
nœuds peuvent exister entre le Node B et le RNC, qu’on appelle réseau dorsal
de l’UTRAN l’ensemble de ces nœuds. Les nœuds en liaison avec le Node B
et le RNC sont des nœuds périphériques (Edge Node). La liaison entre un Node
B et un nœud périphérique est connu sous le nom Last Mile en Anglais, donc
nous l’appelons dernier kilomètre. Des liaisons de type E1/T1, donc à débits li-
mités, sont installées dans les premières infrastructures. Cette partie du réseau de
transport constitue le goulot d’étranglement.
Dans une connexion directe le Node B est donc directement lié au RNC par
le dernier kilomètre. Ce RNC est combiné avec le nœud périphérique. Dans les
premiers déploiements basés sur l’ATM, un Node B est connecté par des liaisons
de bas débit à un concentrateur qui à son tour est directement liée au RNC au haut
débit. Ce cas peut être vu comme étant une connexion directe lors des études de
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 37

F IG . 2.9 – Réseau de transport dans l’UTRAN : liaison directe

performance parce que le budget du délai est majoritairement consommé sur les
liaisons à bas débit.

F IG . 2.10 – Réseau de transport dans l’UTRAN : plusieurs noeuds

2.8 Contraintes de transport dans l’UTRAN


Le transport du trafic usager devrait satisfaire des contraintes temporelles et
d’autres technologiques. Les bornes sur le délai de transport devrait être res-
38 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

pectées pour les différentes types du trafic afin de réaliser les meilleures perfor-
mances sur l’interface radio comme nous venons de le voir dans la section 2.6.3.
La contrainte temporelle se conjugue avec une contrainte technologique qui vise
à assurer une utilisation efficace de la bande passante surtout dans les derniers
kilomètres. D’où la nécessité d’établir soigneusement la conception du schéma
de transport ainsi que le bon dimensionnement dans l’UTRAN.

2.9 Solution de transport basée sur l’AAL2/ATM


Le mode de transfert asynchrone (ATM pour Asynchronous Transfer Mode)
se caractérise par la transmission des données sous forme de cellules suivant un
multiplexage par répartition dans le temps asynchrone [21]. L’unité de transmis-
sion est donc la cellule qui est de taille fixe et égale à 53 octets.
Dans le cadre de l’IMT-2000, notamment la Release 99 du 3GPP, l’ATM est
utilisé dans la couche du réseau de transport des interfaces Iub et Iur. Ce choix
est justifié par les propriétés clés de l’ATM tels que sa possibilité de transporter
du trafic avec des débits variables, que ce soit pour des services à commutation
de paquets ou à commutation de circuits, ainsi que sa possibilité de préserver
la qualité de service des médias transportés, surtout pour des services très sen-
sibles aux délais requis pour la transmission du trafic, à l’instar de la voix et la
visiophonie. La couche d’adaptation ATM type 2 ( AAL2 pour ATM Adaptation
Layer type 2) est utilisée parce qu’elle est appropriée pour le transport de la voix
compressée en temps réel et à bas débit.
Les travaux dans ce cadre se sont focalisés sur l’évaluation de l’AAL2/ATM
et la qualité de service qu’elle apporte dans le transport du trafic usager dans
l’UTRAN. Dans ce cas, le réseau dorsal de l’UTRAN est un réseau de trans-
port ATM, et la couche d’adaptation AAL2 assure le multiplexage des trames de
plusieurs canaux dans les cellules ATM.
Dans ce contexte, plusieurs travaux de recherche ont été menés par simula-
tions pour évaluer les performance de l’AAL2/ATM dans l’UTRAN. Ces études
ont porté sur le dimensionnement, la répartition des ressources et les mécanismes
de différenciation de service ainsi que sur les aspects liés au paramétrage lors de
l’implémentation. Pour le trafic temps réel notamment de la voix, le multiplexage
des trames voix dans des cellules ATM est examiné. Le multiplexeur est com-
posé de deux parties principales, une unité de remplissage avec un temporisateur
(timer) pour limiter le délai de remplissage et une file d’attente. Dans la référence
[30], l’implémentation du multiplexage au niveau AAL2 est proposé sous deux
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 39

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


Assembly and Transmission) et une autre qui les sépare (ABT Assembly Before
Transmission). Une comparaison entre les deux formes est présentée dans deux
cas : avec un tampon de taille finie et avec un tampon de taille infinie. Dans le
cas d’un tampon de taille finie, les résultats exprimés en terme de taux de perte
des trames montrent que ABT produit un taux de perte plus elevé que celui de
CAT. Ceci est justifié 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
qu’une trame. Dans le cas d’un tampon de taille infinie, la différence est moins
importante.
Dans la référence [31], une étude approfondie pour le choix de la valeur
du temporisateur est présentée et différents algorithmes d’ordonnancement sont
simulés au niveau de la couche AAL2 pour assurer la différenciation de service
entre voix et data. Des ordonnanceurs comme premier entré premier sorti (FIFO
pour First In First Out), ordonnancement cyclique avec pondération (WRR pour
Weighted Round Robin), (EDF pour Earliest Deadline First), ou priorité fixe (PQ
pour Priority Queuing). FIFO est recommandé pour le cas d’un réseau mono-
service alors que WRR est plus adapté 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 présentée pour le cas d’un commutateur
ou noeud de concentration reliant plusieurs Node B à un RNC. Dans ce cas,
le chemin virtuel (VP pour Virtual Path) de sortie du commutateur résulte de
l’agrégation des VPs provenant des Nodes B. Les résultats des simulations montrent
que la commutation au niveau AAL2 est plus performante en terme de l’utilisa-
tion de la bande passante dans le cas des circuits virtuels à faible charge. Ce
résultat est aussi présenté dans [84] où la commutation au niveau AAL2 dans
les noeuds de concentration génère un gain statistique plus important qu’au ni-
veau ATM. Dans [33], deux approches pour assurer la différenciation de service
entre les classes de trafic sont simulés. Dans la première, les algorithmes FIFO,
WRR et Priority Queueing sont étudiés, et un seul circuit virtuel (VC pour Vir-
tual Circuit) transporte le trafic voix et data. Dans la deuxième approche, chaque
type de trafic est transporté dans un VC. WRR produit des résultats plus opti-
mistes que celle des autres algorithmes et le transport dans des VCs différentes
est plus efficace. Dans [36], les résultats montrent qu’une différenciation de ser-
vice au niveau ATM est préférable, mais ceci est en comparaison avec le schéma
sans différenciation de service. Un schéma de différenciation de service avec
un ordonnanceur cyclique avec pondération dynamique (DWRR pour Dynamic
40 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

Weighted Round Robin) est proposé dans [40] ; une version dynamique des poids
de WRR est plus efficace qu’une version fixe.
Les études analytiques ne sont pas nombreuses. La référence [24] présente
une étude analytique qui couvre le cas de la voix dans l’UTRAN. Elle est basée
sur des chaı̂nes de Markov et évalue les performances de l’option AAL2/ATM
en considérant le multiplexage des trames voix dans les cellules ATM ; le mul-
tiplexeur est composé d’une unité de remplissage avec le temporisateur et d’une
file d’attente de taille fixe. Pour une bande passante fixe, le nombre des canaux
voix, qui peuvent être supportées, est déterminé. De plus l’impact du temporisa-
teur dans les performances du multiplexeur AAL2 est présenté à travers des ap-
plications numériques. Une autre étude du même problématique mais tenant en

!"#$%&'$%&()
compte les caractéristiques de l’UTRAN, à savoir l’arrivée périodique des trames
chaque TTI, fait l’objet de [27]. Dans ce dernier, un modèle de type
est utilisé avec un temporisateur égale à zéro et une file d’attente de taille infinie.
La bande passante nécessaire pour transmettre un nombre déterminé de canaux
est calculée en fixant la probabilité de violation de contraintes temporelles. Les
aspects liés à la mis en correspondance entre les classes de services UMTS et
les capacités de transfert en mode ATM (ATC pour ATM Transfer Capability)
ainsi que la gestion de circuits virtuels des classes de services sont aussi étudiés.
En particulier, les références [25, 28] analysent analytiquement la gestion des
circuits virtuels pour le trafic temps réel et non temps réel.
Bien que la technologie AAL2/ATM est parfaitement adaptée aux besoins
de transport du trafic temps réel à bas débit comme la voix, elle peut s’avérer
gourmande en capacité quand le trafic data est dominant dans l’UTRAN ; les en-
têtes consomment une bande passante importante [27, 55]. Les récentes versions
du 3GPP proposent des évolutions vers un réseau tout-IP, y compris dans l’accès
terrestre.

2.10 Solution de transport basée sur l’IP


Les travaux de normalisation d’un réseau mobile tout-IP sont présentés dans
les récents travaux du 3GPP, à savoir Releases 4, 5 et 6. Étant une technologie ef-
ficace d’interconnexion, IP est déjà présent dans le cœur du réseau UMTS. L’ex-
tension vers le réseau d’accès est discuté dans [1] et [2]. Dans ce contexte, les
travaux examinant le transport IP sont des études à court terme par simulations
et visaient la démonstration de l’efficacité ainsi que la viabilité d’une solution IP
par rapport à l’AAL2/ATM. Les études portant sur ce sujet sont en cours et ne
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 41

sont pas encore finalisées. En fait, l’introduction de l’IP dans les réseaux mobiles
ouvre plusieurs voies d’application, de la connectivité à la gestion de la mobi-
lité en passant par le support des applications multimédias IP. Dans un réseau
d’accès UMTS basé sur IP, le réseau de transport reliant le Node B et le RNC est
fondamentalement formé de routeurs utilisant IP comme protocole de la couche
3.

Notre objectif est d’assurer le transport du trafic usager tout en satisfaisant


les contraintes de qualité de service requises et assurant une utilisation effi-
cace des ressources. Un gaspillage des ressources des derniers kilomètres à bas
débit résulte d’une grande consommation due aux en-têtes. D’où la nécessite
de la réduction des en-têtes par rapport au charges utiles. Ceci est atteint soit
par la compression des en-têtes, soit par le multiplexage, soit les deux simul-
tanément. Les techniques de compression des en-têtes peuvent être accomplis
suivant les propositions de l’IETF dans RFC 2507 [41] et RFC 2509 [42]. En ce
qui concerne le multiplexage, son implémentation peut être selon trois schémas
[2] :

– Multiplexage sur le dernier kilomètre : Dans ce cas, le multiplexage est


utilisé seulement sur le dernier kilomètre entre le Node B et le routeur
périphérique du réseau de transport. Ce schéma nécessite l’ajout de quelques
fonctions dans le routeur périphérique pour accomplir le multiplexage et
le démultiplexage.
– Multiplexage sur le dernier kilomètre et entre le RNC et le nœud périphérique :
Dans ce cas, deux sessions de multiplexages sont faites entre le Node B et
son routeur périphérique et entre ce dernier et le RNC. Cette solution est
plus optimale mais plus complexe.
– Multiplexage de bout en bout : Dans ce schéma, le multiplexage est ef-
fectué de bout en bout entre le Node B et le RNC, il est donc transparent
au noeuds intermédiaires. C’est une solution simple pour un transport ef-
ficace.

Les méthodes de multiplexage proposées par les industriels examinant le


transport dans l’UTRAN sont regroupées dans la référence [2]. Elles peuvent
être implémentées suivant les trois schémas cités ci-dessus. Différents modes
d’implémentation de la technologie IP dans l’UTRAN avec des différentes piles
protocolaires sont présentés et validés par des simulations [1, 2]. D’autres tra-
vaux abordent aussi cette problématique par simulations dans [48] [70] et [71].
42 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

2.10.1 Multiplexage par le protocole PPP


Le protocole point-à-point (PPP pour Point-to-Point Protocol) est un proto-
cole de niveau 2 du modèle OSI assurant la liaison entre deux points du réseau.
Les paquets des couches supérieures sont encapsulés dans des trames PPP.
Le multiplexage utilisant ce protocole a été proposé dans le RFC 3153 [44]
visant le réduction de la charge introduite par l’en-tête PPP. La figure 2.11(a)
montre la pile protocolaire proposée dans [1] pour le transport dans l’UTRAN.
Le multiplexage est fait par la concaténation de plusieurs paquets IP dans une
trame PPP de la façon suivante. Les trames FP, de taille variable, sont encap-
sulées dans des paquets IP qui à leur tour sont encapsulés dans des trames PPP
dites mini-trames. Une compression de l’en-tête UDP/IP jusqu’à 2-4 octets est
envisagée. L’en-tête compressé est désigné par cUDP/IP. Le multiplexage consiste
à enchaı̂ner plusieurs mini-trames dans une trame PPP. Les formats des mini-
trames et des trames PPP sont détaillés dans [1] et aussi dans [44]. Au des-
sous du protocole PPP, plusieurs protocoles sont proposés. Nous citons le pro-
tocole HDLC (High-level Data Link Control), AAL5/ATM . En comparaison
avec AAL2/ATM, les simulations menées par Motorola dans [2] montrent que
cUDP/IP/PPPmux/HDLC est plus performant que AAL2/ATM. Dans la référence
[44], une discussion portant sur la comparaison du multiplexage utilisant PPP
avec un multiplexage utilisant le protocole de transport en temps réel (RTP pour
Real Time Protocol) est présentée. PPPmux offre une amélioration de l’utilisa-
tion de la capacité par rapport à RTP.
Plusieurs extentions du protocole PPP sont sujet d’investigation pour être uti-
liser avec PPP, comme la variante PPP multi-liaison (PPP-ML pour PPP Multi-
Link) [45] et son extension PPP multi-liaison multi-classe (MC-MP-PPP pour
Multi-Class Multi-Link PPP). ML-PPP propose une méthode de regroupement
de plusieurs liaisons indépendantes entre deux nœuds dans une liaison virtuelle
offrant une bande passante plus élevée. Avec MC-MC-PPP plusieurs classes de
services sont définies et identifiées par des bits non utilisés dans l’en-tête MP-
PPP.

2.10.2 AAL2 over IP


Cette proposition, citée dans la référence [1] et simulée dans [39], consiste à
employer AAL2 pour accomplir le multiplexage au dessus de UDP/IP, la pile
protocolaire est donc AAL2/UDP/IP. Les travaux de normalisation de AAL2
existent déjà et seront réutilisés, mais en tenant compte de la taille variable d’un
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 43

paquet IP, il n’est pas nécessaire de limiter la taille des datagrammes UDP à 48
octets et de fragmenter les segments AAL2 comme dans ATM. Cette solution
facilite l’interopérabilité entre AAL2/ATM et IP. Les résultats des simulations
dans [39] montrent que la solution AAL2/UDP/IP est plus efficace, en terme
d’utilisation utile de la bande passante que les piles AAL2/IP et RTP/UDP/IP.

2.10.3 Composite IP (CIP)

Dans cette méthode, les trames FP sont rassemblées dans des paquets IP.
Comme la taille des trames FP est variable, deux mécanismes sont employés :
– L’agrégation des petites trames, généralement de la voix, pour réduire l’en-
tête UDP/IP.
– La segmentation des trames FP de grande taille en petits blocs afin d’éviter
un grand délai de transmission.
Chaque petite trame est encapsulée dans un container nommé Composite IP
container (CIP). Plusieurs CIPs sont rassemblés dans un paquet IP. L’en-tête du
CIP contient les champs nécessaires pour identifier les segmentations et la lon-
gueur de la charge utile du CIP. Cette solution rend le multiplexage indépendant
de la couche 2. Comme dans la méthode précédente, PPP/HDLC et PPP/AAL5/ATM
sont utilisées pour compléter la pile protocolaire (voir figure 2.11(b) ). Les simu-
lations faites par Alcatel dans [2] pour comparer CIP à la solution de transport
AAL2/ATM dans une liaison de type E1 montrent que CIP est plus performant
que AAL2/ATM en terme du délai et de la bande passante.

FP FP FP RNL

UDP/IP, cUDP/IP CIP/UDP/IP UDP/IP TNL

PPP, PPP−mux PPP PPP

HDLC, AAL5/ATM HDLC, AAL5/ATM HDLC

PHYSIQUE PHYSIQUE PHYSIQUE


(a) (b) (c)

F IG . 2.11 – Différentes piles protocolaires pour la couche réseau de transport


44 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)

2.10.4 Lightweight IP Encapsulation (LIPE)


Cette méthode consiste à rassembler plusieurs trames FP de type multimédia
(voix ou vidéo) dans un paquet IP, donc au niveau UDP/IP. Un en-tête de mul-
tiplexage (MH pour Multiplexed Header) de 3 octets est ajouté à chaque trame
FP. Un nombre variable de trames sont multiplexées dans le paquet IP ayant l’en-
tête UDP/IP. L’en-tête MH contient des informations concernant la trame comme
l’identité, le numéro de séquence, etc. Pour la couche liaison, PPP/HDLC sont
proposées (voir figure 2.11(c) ). La validation de cette proposition a été faite par
Lucent à travers une série de simulation. Leurs résultats montrent qu’une solu-
tion de transport basée sur IP est une solution efficace en comparaison avec celle
basée sur AAL2/ATM.

2.10.5 Discussion
Comme nous pouvons le constater, les simulations lancées conformément
au méthodes suggérées dans [1] avaient pour objectif de tester l’efficacité des
solutions basées sur IP par rapport à AAL2/ATM. En se basant sur ces résultats,
le MWIF recommande IP comme une option de transport efficace dans l’UTRAN
[2]. En ce qui concerne la comparaison des performances des méthodes basée sur
IP, des résultats préliminaires de Motorola pour le transport de la voix montrent
que LIPE est légèrement plus avantageuse que PPPmux. Dans la section suivante,
nous précisons les points essentiels examinés dans cette thèse.

2.11 La problématique examinée dans cette thèse


Dans cette thèse, nous étudions analytiquement et empiriquement le transport
IP dans l’UTRAN. Nous proposons un modèle analytique examinant le transport
de la voix, comme étant un trafic temps réel, et le web comme un trafic non temps
réel et permettant de dimensionner les interfaces terrestres de l’UTRAN tout en
respectant les contraintes de transport temps réel sur ces interfaces. Notre modèle
examine le multiplexage des trames voix dans des paquets IP et évalue l’efficacité
de cette solution en terme de délai et de l’utilisation de la bande passante. Nous
validons nos études sur une plate-forme émulant les fonctionnalités de transport
dans l’UTRAN. Bien que le multiplexage étudié et expérimenté sur notre plate-
forme est implémenté au niveau de la couche 3, le modèle analytique couvre le
multiplexage au niveau de la couche 2, notamment le cas de la solution PPPmux
(voir section 3.2), et les conclusions tirées restent aussi valables.
CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN) 45

Le transport dans l’UTRAN est une mission temps réel. Néanmoins, le tra-
fic data peut être transmis avec des délais plus longs que le trafic voix. Pour
le trafic data, nous examinons le transport en tenant compte de la segmenta-
tion des longues trames data, et en présence des deux types du trafic, nous nous
intéressons à la différenciation de service via des mécanismes d’ordonnance-
ment, tel que WRR et PQ. Nous étudions analytiquement et empiriquement ces
techniques d’ordonnancement pour examiner le partage efficace de la bande pas-
sante. Nous achevons ce travail par une comparaison entre les performances de
l’IP et celles de l’ATM dans l’UTRAN et par une partie examinant le réseau
dorsal de l’UTRAN pour en proposer des possibles implémentations.
46 CHAPITRE 2. LE RÉSEAU D’ACCÈS RADIO TERRESTRE UMTS (UTRAN)
Chapitre 3

Transport du trafic temps réel dans


l’UTRAN

3.1 Introduction
Dans ce chapitre, nous proposons un modèle analytique pour l’étude du trans-
port IP du trafic temps réel, la voix, dans l’UTRAN. Le multiplexage de plusieurs
trames voix provenant de canaux différents est modélisé afin d’évaluer l’effica-
cité de ce transport et déterminer les valeurs optimales de certains paramètres à
utiliser lors de l’implémentation. Pour valider notre modèle, nous avons émulé
les fonctionnalités de transport de l’UTRAN sur une plate-forme, et nous avons
implémenté les différentes composantes de notre modèle. Nous présentons les
travaux qui ont été effectués ainsi que les résultats empiriques validant l’utilité
de notre modèle.

3.2 Modélisation du Système


Le trafic voix est généré par le codeur multidébit adaptatif (AMR pour Adap-
tive Multi-Rate) à un débit de 12,2 kbps. Il est transporté sur l’interface radio dans
des canaux de transport dédiés où un canal est dédié à chaque usager. La couche
RLC est transparente pour le trafic voix. En sortant de la couche MAC, il consiste
en une succession de périodes d’activité et de silence. Pendant les périodes d’ac-
tivité, des trames voix de taille fixe de 31 octets sont générées périodiquement
tous les intervalles de temps TTI, TTI=20 ms pour le cas du trafic voix. Pendant
les périodes de silence, aucune trame n’est générée. Le protocole FP encapsule
48 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

les trames voix de 31 octets dans des trames FP en ajoutant un en-tête de 5 octets.
Pendant les périodes d’activité d’un canal, des trames FP de 36 octets arrivent
périodiquement tous les TTI à la couche du réseau de transport. Le transport des
ces trames dans l’UTRAN vers le RNC sur la voie montante et vers le Node B
sur la voie descendante doit être effectué avec un délai inférieur à 5 ms. Nous
considérons la voix montante et le modèle est valable pour la voie descendante.
Il est évident qu’un transport encapsulant une trame FP de taille 36 octets
dans un paquet IP dont l’en-tête UDP/IP seul est de 28 octets pour !"#$%& (48
octets pour !"'$() ), mène à une mauvaise utilisation de la bande passante ; par
exemple, sur 2 Mbps l’en-tête utilise 875 kbps. Comme nous l’avons vu dans
le chapitre 2, pour transporter le trafic voix avec une utilisation efficace de la
bande passante tout en satisfaisant les bornes sur le délai, les solutions suivantes
sont à étudier : La première consiste à encapsuler plusieurs trames FP provenant
de différents canaux dans un paquet IP, donc un multiplexage au niveau de la
couche 3. la deuxième consiste à encapsuler une trame FP dans un paquet IP et
compresser l’en-tête UDP/IP, puis transporter un ou plusieurs paquet IP dans des
trames de la couche 2, c’est donc un multiplexage au niveau de couche 2.
Selon la première méthode, le multiplexage des trames provenant de plu-
sieurs canaux actifs consiste à ajouter à chaque trame FP un en-tête de multi-
plexage de 3 octets (MH pour Multiplexing Header) dont un octet d’identifi-
cation unique pour chaque canal. Le format de cet en-tête peut être similaire à
celui utilisé dans le multiplexage par AAL2 ou bien celui de la solution LIPE.
Les trames FP sont par la suite rassemblées dans un paquet IP comme le montre
la figure 3.1.
En−tête
MH Trame FP UDP/IP
3 octets 36 octets

F IG . 3.1 – Format d’un paquet IP

Dans le cas d’une solution de multiplexage par PPPmux (couche 2), une
trame FP est encapsulée dans un paquet IP dont l’en-tête UDP/IP est compressé
à 2-4 octets selon les méthodes de compression proposées dans les références
[41, 42]. L’en-tête compressé est cUDP/IP. Plusieurs paquets IP sont ensuite en-
capsulés dans une trame PPP dont le format simple est montré dans la figure
3.2 (voir [44] pour plus de détails). En général, la couche de liaison organise les
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 49

données en trames et gère les aspects liés aux erreurs et retransmissions. Donc
le paramétrage dans ce cas est un compromis entre la capacité de la liaison et
le taux de pertes des trames (Frame loss) incluant le taux d’erreur. Néanmoins,
l’application de notre modèle permet de tenir en compte le paramètre délai .
En−tête Paquet IP Champ du
cUDP/IP charge utile protocole PPP

F IG . 3.2 – Format simple d’une trame PPP encapsulant plusieurs paquets IP

3.2.1 Modèle de l’UTRAN


Dans ce travail, nous nous concentrons sur l’étude analytique et empirique du
multiplexage au niveau de la couche 3. La méthodologie ainsi que les résultats
exprimés en terme des paramètres de performance, tels que délai et utilisation de
la bande passante, restent valable pour le multiplexage au niveau de la couche 2.
L’étude se fait par le changement de valeurs de quelques paramètres en remplaçant
l’en-tête MH par l’en-ête cUDP/IP et le paquet IP par la trame PPP.
Nous proposons de modéliser le multiplexage sur l’interface Iub de l’UTRAN
de la manière suivante (voir figure 3.3). C’est un multiplexeur composé de deux
parties principales :
– Une unité de remplissage où les paquets IP sont remplis par des trames
FP jusqu’à la taille maximale fixée ; un temporisateur dénoté TCU pour
Timer Common Usage est associé à cette composante pour limiter le délai
de remplissage.
– Une file d’attente où les paquets attendent avant leur transmission sur le
lien de sortie.

3.3 Analyse du modèle


Notre objectif est d’étudier le délai des trames dans le système considéré ainsi
que l’utilisation de la bande passante. Le délai résulte de deux composantes :
– Délai de remplissage dans l’unité de remplissage et
– Délai de séjour dans la file d’attente.
L’utilisation de la bande passante est affecté par le remplissage des paquets IP.
50 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

TTI

Unité de File d’attente


TTI Remplissage

! "#$" Lien
de sortie

TTI
Multiplexeur

F IG . 3.3 – Schéma du système

3.3.1 Modèle du trafic voix


Une source de voix codée par le codeur AMR [10, 11] permet un changement
du débit en temps réel (4,75 à 12,2 kbps). Comme nous l’avons cité dans la
section 3.2, nous nous focalisons sur le cas où le codeur fonctionne au débit
maximal donc de 12.2 kbps. La source peut être modéliser par un modèle de
type ON/OFF représentant les périodes d’activité et de silence. Les durées de ces
périodes peuvent être modélisées par des variables aléatoires exponentiellement
distribuées [2]. Nous nous intéressons au profil du trafic à l’entrée de la couche du
réseau de transport donc à la sortie de la couche FP. La couche MAC sélectionne
le format de transport pour la transmission de la voix sur le canal avec TTI=20 ms
et des trames FP de 36 octets. Les trames FP voix, provenant d’un canal, arrivent

%&'
donc périodiquement chaque 20 ms au multiplexeur. Nous considérons le cas des
bonnes conditions radio où un nombre de canaux sont simultanément actifs.
Comme la probabilité qu’un canal émet à un instant arbitraire à l’intérieur de la

()*+,-/01 .
période TTI suit une distribution uniforme [2], le processus d’arrivée des trames
au multiplexeur peut être modélisé par un processus de Poisson de taux
trames/ms.

3.3.2 Etude du délai de remplissage


Soit234 la première trame d’un paquet IP assemblé. Lors du remplissage,

254 6 7 7
si le temporisateur n’est pas utilisé, le délai de remplissage est maximal pour
. Il est égal à , le temps nécessaire pour l’arrivée de trames, où est le

6 7
nombre maximal de trames par paquet IP correspondant à une taille maximale

(
du paquet IP. est donc la somme des temps des interarrivées des trames.
Puisque le processus d’arrivée des trames est Poissonnien de taux , les temps
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 51

interarrivées sont indépendants et exponentiellement distribués avec paramètre


. Par conséquent, ! est la somme de "#$%&'()* variables aléatoires indépendantes
et exponentiellement distribuées de moyenne identique. ! est alors distribué
selon la loi d’Erlang- "#$'&+(,-./* avec une valeur moyenne calculée par

$'&1(
! 0 (3.1)

Maintenant, nous introduisons le temporisateur pour éviter un grand délai de


remplissage et nous supposons que l’axe de temps est discret avec 234 comme
unité de temps. Le délai maximal de remplissage est donc 56789:;<234 . Juste au
début d’une 2=4 , les trames FP arrivent et un ou plusieurs paquets IP de taille
maximale sont immédiatement générés s’il y a suffisamment de trames FP pour
les constituer. Le temporisateur est déclenché à l’arrivée de la première trame
>?@ . Il est incrémenté par 1 au milieu d’une 2A4 . Si la valeur du temporisateur est

"#567B9C&D(E*F;G2H4 au début d’une 2H4 , un paquet IP est généré avec les trames FP

existantes, même si la taille du paquet IP est inférieure à la taille maximale. Donc


dans ce cas, le temps passé par > @ dans l’unité de remplissage est compris entre
"#567B9I&+()*J;K2H4 et 56789L;K2H4 ; une erreur d’une 2H4 .

Soit MHN le débit moyen des trames exprimé en trames par 2O4 , c.à.d, MPN n’est
autre que normalisé par 2=4 . Comme le processus d’arrivée des trames est Pois-
sonien de débit M=N , la probabilité que Q trames FP arrivent à l’unité de remplis-
sage dans 2H4 est
T Z
M N
RSTF0 [ (3.2)
QOUVWXY

Soit \ le processus décrivant le nombre de trames FP dans l’unité de rem-


plissage. Considérons les matrices suivantes qui caractérisent les variations de \
durant une 2=4 :
– Cas d’arrivée des trames dans une unité de remplissage vide sans génération
de paquets IP. Soit ] ^ , de dimension (_;`"a$b&I()* , la matrice de transition
de \c0de à \fg+e durant une 2=4 sans génération de paquets IP. Alors,

] ^ 0hi m nonon (3.3)


RjklR Rpq k_r

Y
– Cas d’arrivée des trames dans une unité de remplissage non vide sans
génération de paquets IP. Soit ] ^s^ , de dimension "#$<&c()*/;C"#$t&u()* , la
matrice de transition de \vgwe à \vgLe durant une 2A4 sans génération de
paquets IP. Alors,
52 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

$% 8,9
% ' ! '() ' * +,+-+ './ * 9
% 9
%
% 1 ' ! '2) +,+-+ './ 0 9
9
!"! # 1 1 ' ! +,+-+ './ 0354 (3.4)
&
.. .. .. .. ..0 :
. . . . .
1 +,+-+6+-+-+7+,+-+ ' !

– Cas d’arrivée des trames dans une unité de remplissage vide avec génération
de ; paquets IP. Soit ! < , de dimension =>?@A , la matrice de transition de
BC#D1 à B durant une EFG avec génération de ; paquets IP. Alors,

! < # H ' </ ' < /-IJ) +,+-+ ' < /-IK/ )LM (3.5)
0
– Cas d’arrivée des trames dans une unité de remplissage non vide avec
génération de ; paquets IP. Soit < , de dimension NOAPQ6=RST?UA , la ma-
trice de transition de B7VW1 à B durant une EXG avec génération de ; paquets
IP. Alors,
$% 8,9
% ' </ ) ' </ ' < /YIJ) +-+-+ ' < /YIK/ * 9
% 9
' </ 0 * ' </ ) ' </ +-+-+ ' < /YIK/ 0
< # .. 0 .. 0 .. .. (3.6)
&
.. 034 :
. . . . .
' </ /YIJ)Z' < / /YI * +-+-+ +-+-+ ' </
0 0
– Cas d’expiration du temporisateur. Soit [I ! , de dimension N\A]Q^=RS_?`A , la
matrice de transition lors de l’expiration du temporisateur. Alors,
$% / * 8 9
% b 9
% +-+,+ 9
% 0 'fc 1 1 1 9
% 9
% cde ! 9
% / 9
% b 9
% 034 'fc 1 1 +-+,+ 1 9
aI ! # %
% cde !
9
9 (3.7)
% .. .. .. .. .. 9
. . . . .
!
b
& +-+,+ :
'fc 1 1 1
cde !

Dans EgG , soit aucun paquet IP n’est généré, soit un ou plusieurs paquets IP
sont générés donc un groupe de paquets. Soit B h la valeur de B juste après la
<jOkl hml
génération du i groupe de paquets et soit n h l’unité EgG correspondante. Soit
<jOkl hml <jjkl hfl
o h le temps séparant la génération du i et du N\ipqr=YS groupe de paquets
IP, alors o h h
#sn IJ)mQtn . h
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 53

Soit ! le nombre de trames FP arrivants durant " ! et # ! $%& le nombre de


01342 !53
paquets IP générés dans le '()*+,-./ groupe de paquets IP. Nous avons alors
la relation suivante :

: si le temporisateur expire et # ! $%&78;-


6 ! $%&78*9 !
6 +< ! =>?@# ! $%& sans expiration du temporisateur
(3.8)
avec, # ! $%&78ABCDEF I F J 1
$GH
Nous déterminons maintenant les probabilités stationnaires des états de 6 .
Soit KLMN8O'PKQ'4:R/STCKQ'U-./STRKV'4WX/ET YZYZY[YZY[YZYZY TCKQ'P?\=,-./]/ le vecteur des probabilités station-
naires correspondantes avec K ^ 8_KQ'4:R/ et KL$\8;'PKQ'U-./STCKQ'1WX/ST Y[YZY TCKV'(?`=a-./]/ alors,

i i
KLMb8 Kc$7'deQfgh l j^n^ & o l 0 +pl n^ ^ &N
l $ ^/
jZk%& m 0% k & eQfgh m
i i & io l 0 + io l ^0 p
+ K^ o q ^ M & ' eQfgh l ^ l j^n^ + l ^ l ^n^ & lr$ ^ / (3.9)
M4k%& m jZk%& m 0 k%& 0%k & Qe fgh m
j &
Le terme KL$7'1s jZk%& l ^n^ s 0 k%& l 0 / correspond à 6 ! tu: et des paquets IP
eQfgh m o & lr$ ^ / à 6 ! ta: et un paquet partiel-
complètement remplis, le terme Kv$w'Pl ^n^
M & m j &
lement rempli. Le terme K ^ ' s M4k%& q ^ eQfg' s h jZk%& l ^ l ^n^ s 0 k%& l 0 + s 0 k%& l ^ 0 /x/ à
o m eQfgLeh terme m ^ o o
6 ! 8,: et des paquets complètement remplis. K '4s M1o k%& q ^ M & l ^ l ^n^ & lr$ ^ /
m eQfgh m
à 6 ! 8,: et un paquet partiellement rempli.

3.3.3 Passage de l’unité de remplissage à la file de transmis-


sion
Notons le vecteur unitaire de dimension ?z{|} , le nombre moyen ~ des
y
paquets IP générés dans un groupe est
‚
i i‚
~ 8 KL$7'eQ€g l jn^ ^ & o ƒ4l
+pl n^ ^ &N l $ ^/
jZk%& eQ€g m
m k%& y
‚
i i i‚
+ ^ M & 'eV€g l ^ l j^n^ & o ƒ1l
K^ o
m jZk%&
M1k%&„… m ‚ k%&

+ l ^ l ^n^ & lN$ ^ + i ‚ o ƒ4l ^ / (3.10)


eQ€g m k%& y
1 †‡ˆ‰Š
= entier naturel inférieur ou égal à ˆ .
54 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

et le temps moyen entre les générations des groupes de paquets est

9
, - 1 ,9 8 1
! ' )*+ 32 4 76 6
"#$%& ( 4 :;<=>?@=4 76 6 4A$ 6 B
-./01 5 / 1
0 '()*+ 5 C
9
, , ,9
: " 6 8 6 D 1 &H'()*+ &IJK:L2MBN4 6 4 -676 1 8 4
DE/01FG 5 .- /01 5 /01 9
1 , 9
: &EJK:L<O>?@ABN4 6 4 676 4A$ 6 :PJ 8 4 6 B (3.11)
'()*+ 5 /01 C

Le débit moyen de génération des paquets IP Q qui n’est autre que le débit
moyen d’arrivée des paquets, partiellement et complètement remplis, dans la file
d’attente est
S
QR! (3.12)
Nous calculons aussi le nombre moyen T de paquets IP partiellement remplis
dans un groupe

1 ,
TU!V"W$04 76 6 4A$ 6 :X" 6 8 6 D 1 4 6 4 676 1
4A$ 6 (3.13)
'()*+ 5 C ED /01 G 5 ' )*+
Y 5 C

et le nombre moyen Z des trames FP dans ces paquets partiellement remplis


ab e 9 r s
b d s
b ,9 s
b 5 &]f0:g\hB s
b / 6 G 9 s
b d s
b ,9 s
b s
\ 1 , b 5ij &]f0:PklB s
Z[! &]"W$^4 76 6 :;" 6 8 6 D 1 4 6 4 676 1
B_` b / 6 G s
T b s
'()*+ 5 ID /01 G 5 ' )*+ 5
( b .. s
6
. 9
c ,9 t
&mf^:V&]nopq\hBMB
/ 6 G
(3.14)
Le nombre moyen u des trames FP dans un paquet IP est
T T
ug!gZ^& BF:;n%&N\vp B (3.15)
S S

Nous définissons le paramètre d’utilisation utile de la bande passante w comme


étant le rapport de la charge utile d’un paquet, donc sans les en-têtes MH et
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 55

UDP/IP, sur la taille totale. Pour IPv4,

!" $&(# % )*& +,- (3.16)


#$'
3.3.4 Etude du délai de séjour dans la file d’attente
Nous avons calculé le délai de remplissage ainsi que l’utilisation utile de la
bande passante qui résulte du remplissage. Dans cette section nous déterminons
le délai dû à l’attente dans la file de transmission (voir figure 3.3). Cette dernière
est composée d’un serveur de type FIFO et d’un tampon de taille infinie, donc
sans perte. Le délai de séjour dans la file dépend du trafic entrant et de la capacité
du lien de sortie. Le profil du trafic entrant dans la file d’attente est le même que
celui sortant de l’unité de remplissage. Ce dernier est affecté par le remplissage
ainsi que l’utilisation du temporisateur. En tenant compte de ces effets, nous
.
avons déterminé le débit moyen des arrivées de paquets IP, partiellement et
complètement remplis, dans la file d’attente par l’équation 3.12. Dans la suite de
cette section, nous étudions le délai de séjour dans la file d’attente selon deux
approches :
– Etude par chaı̂ne de Markov : ce modèle est inspiré du modèle présenté
dans la référence [24] pour le cas de l’AAL2/ATM. Nous analysons le
système par une chaı̂ne de Markov et le délai est exprimé en valeur moyenne.
– Etude par le modèle Er/M/1 : nous utilisons l’idée de service par bloc ce
qui nous permet la détermination du délai par les quantiles.

3.3.4.1 Etude par chaı̂ne de Markov : délai moyen

Pour l’étude par chaı̂ne de Markov, nous faisons un changement de l’échelle


de temps utilisée lors de l’étude du remplissage ; soit STU (pour Service Time
Unit) l’unité de temps, elle est égale au temps nécessaire pour servir un paquet
/
IP de taille maximale c. à d. contenant trames FP. Soit le débit moyen nor- .01 .
3 .21
/3
malisé par STU, c. à. d. exprimé en paquets/STU. est donc égale à la charge
du serveur. est le taux moyen d’arrivée des trames FP si chaque paquet IP
/
contient trames ; c’est une surestimation parce que des paquets partiellement

345 6
remplis peuvent avoir une taille inférieure à la taille maximale. Nous supposons
également que le système est stable, c.-à-d., . En utilisant l’approxima-
8
/3
tion de l’indépendance (voir [24]) qui suppose que les trames arrivent suivant
un processus de Poisson avec taux moyen , nous calculons la probabilité 7
9
que paquets IP arrivent à la file d’attente de transmission dans une unité de
56 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

temps STU. C’est approximativement équivalent à l’arrivée de !"#$ trames dans


une unité de temps STU. Pour un comportement réaliste, quand il n’y a pas de
génération de paquet IP, la probabilité que % trames arrivent à l’unité de remplis-
sage est pondérée par &'()* . Le poids devient * quand il y a des paquets IP qui
&
sont générés. Nous avons donc,
&

.//
// 4&)(23 $9:;% $ =>? *
, , (2CD&EF5G , H-IJ
0 $ < %2@AB
+ - /// 4 *5678
/1 &)(23 % $ =>? C (23KGL&MNO* 4&'(23 9 $ :;% $ =>? &MNO*
2
( D
C E
& P
F G U (2CD&EFPG H-WSXYZ[\Y]^_^`^
$ < Q:RS ? $TUV% ? @ B $ < K$TUV% ? @ B
*56!3 <P< P* 678 < (3.17)
Nous définissons maintenant la chaı̂ne de Markov incluse a comme étant le
nombre de paquets IP existant dans la file d’attente à la fin du service d’un pa-
,
quet. Les transitions ont lieu seulement à ces instants et forment un espace à état
discret ; a représente l’état de la chaı̂ne quand paquets sont présents dans la
file de transmission à la fin du service d’un paquet. Le temps entre les transitions
d’état est constant et égal à STU quand au moins un paquet est toujours dans la
,
file d’attente ; il est égal à la période entre les arrivées des paquets dans le cas où
, ,
la file d’attente est vide (voir [81]). Soit b la probabilité de transition de l’état
*
a vers l’état a * . La matrice de transition c b (5Yd%e-fJgY]SXYZ[\Yh^`^`^ ) prend la forme
*!
suivante :
"# ()*
#
#
+8 + 3 +%& +%' h^ ^h^ *
*
#
# +8 + 3 +%& +%' ^h^h^ *
*
- J +8 + 3 +%& ^h^h^ (3.18)
i $ J J +8 + 3 ^h^h^ +
.. .. .
.. .
.. ..
. . .

La probabilité stationnaire , ? d’avoir paquets IP dans la file de transmis-


< est déterminé par
sion à la fin du service d’un paquet

,j-
- , (3.19)
i
avec ,k- ? ? ? ?
, J Y., S Y/, [ Yh^h^h^ . Sachant que
= est le taux d’arrivée et 0 le
nombre moyen< < de paquets
< < d’IP dans la file de transmission, nous appliquons
la formule de Little et nous trouvons 1 , le délai de séjour moyen dans la file de
transmission par
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 57

#
! !" "! #$% $%& " '&' ' )
( (3.20)

Enfin, le délai moyen (


dans le système y compris la composante due au
remplissage et celle due au séjour dans la file d’attente est déterminé par

( !)* *+*+1./+ .0 / -, '


,-'
+ ,-./.0 /
+ 23./00 / (3.21)

3.3.4.2 Etude par le modèle Er/M/1 : quantiles

4 4 56 78
Dans ce cas, nous supposons que tous les paquets IP ont une taille moyenne,
c.à.d. contiennent trames, 1! 23 2 où 3 est le nombre moyen des trames FP
dans un paquet IP calculé par l’équation (3.15). Alors le temps séparant l’arrivée

4
consécutive de 2 paquets IP dans la file d’attente est distribué selon la loi de
Erlang- de taux 4 , ou autrement dit l’arrivée d’un paquet IP résulte de l’arrivée

9 4 :
de trames. Le temps de service est distribué selon la loi exponentielle de taux
, avec & égale au temps de transmission d’un paquet IP contenant trames 4
0
sur la liaison de capacité . La file d’attente est donc du type 56 et les ;<=>?@+-?
ABC
paramètres de performances stationnaires de cette file peuvent être obtenus par
l’application des résultats de la file G/M/1 dans [81]. Il suffit de calculer ,)
(
la transformée de Laplace de la loi d’interavrivée des paquets IP, qui est donnée
par

A C , ) ! 484047+94 , ) = (3.22)
et puis résoudre l’équation D( ( D
!EA C 9 : 9 ) D (3.23)
(
Notons que cette équation possède une unique solution telle que ; < < 6 et
que 1 est toujours une racine. Les probabilités stationnaires aux instants d’arrivée

' D D
des paquets IP possèdent une distribution géométrique. Lorsqu’un paquet arrive,
#
la probabilité stationnaire ' ) de trouver ' paquets dans la file est calculée par,
( '
' ) ! =6 : ) (3.24)
( (
et le temps moyen de séjour dans la file est
6 D
0! 9 6 : ) (3.25)
2 F>?GH = entier naturel supérieur ou égal à ? . (
58 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

Le délai de remplissage est toujours borné par la valeur du TCU. Il est donc
intéressant de borner le délai dû au séjour dans la file d’attente. Nous dérivons
la fonction de répartition, (CDF pour Cumulative Distribution Function) ! "
$ ! , du temps de séjour dans la file de transmission y compris l’attente!" et
#le service." Puis nous calculons la probabilité de dépassement d’un délai fixé.
En effet, lorsqu’un paquet IP arrive dans la file, il trouve, avec une probabilité
"

#
!
% , % paquets dans le système. Il quittera donc le système après la transmission
de %&'() ! paquets (le service pour % paquets ainsi que son propre service). Cet
intervalle de temps constitue son temps de séjour dans la file, il est la somme
de %*'+) ! variables aléatoires indépendantes et exponentiellement distribuées
de paramètre $ . Il en résulte que la transformée de Laplace de la distribution
du temps de séjour est le produit de %,'-) ! transformées de Laplace de la loi
exponentielle de paramètre $ . Elle est calculée comme suit, avec l’événement %
qui désigne ’% paquets dans la file’, /
$
% .&' % ! " ! 012 (3.26)
. ' $

Nous avons, )

3/ )78 !*$ )

% .! " ( % .&' % ! # % ! " (3.27)


.9' $
8 $

456
En inversant la transformée de Laplace, la fonction densité de probabilité de
)
est
! " :" ! " )78 !*$ < =>2?-< .@/A 0 B
,
C (3.28)
# ;
Nous calculons!+ par la suite la+ fonction de répartition +1
de2 qui est la proba-
bilité cumulée ! des valeurs inférieures ou égales à x. Elle est déterminée
par 3"

! " $ ! " 456


! 7

3"
# " 6 3+ , +
" )78 < =>2?<-@. A B C (3.29)
; 6
"82
Nous nous intéressons à la probabilité de dépassement du délai cible et nous
la calculons par

8;<=>DE !F! "


,
79: AB
< =>2?<-@. AG= <?@C (3.30)
# ; 6 HIJ "82
Le temps de séjour
3"
tel que ! K
" L , avec p est la valeur de la fonction
quantile 3 de , est " 3"
3
La fonction quantile de A est l’inverse de la fonction de répartition de A
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 59

#
!" ! %# " #& $%& ' # "() & *
"
(3.31)

$ $
3.4 Plate-forme d’émulation de l’UTRAN
Dans cette section, nous décrivons notre plate-forme de transport dans l’UTRAN
où nous avons émulé les fonctionnalités nécessaires pour la validation de notre
étude, et nous montrons ses composantes logicielles et techniques. La plate-
forme est composée d’un certain nombre d’ordinateurs opérant avec le système
d’exploitation FreeBSD. Toutes les machines de la plate-forme sont synchro-
nisées en utilisant le système GPS (Global Position System), qui est nécessaire
pour la mesure des délais (voir Figure 3.4).

F IG . 3.4 – Plate-forme d’émulation du transport dans l’UTRAN

La figure 3.5 montre l’implémentation du transport de la voix : la génération


du trafic est réalisée à partir du PC1. Sur PCr, le multiplexage est effectué et les
paquets IP sont transmis vers la machine PC2.

3.4.1 Génération du trafic


Nous avons implémenté la génération du trafic voix au niveau de la couche FP
par des sockets en mode non connecté, donc utilisant le protocole de datagramme
d’usager (UDP) et le modèle Client/Serveur. Un socket présente un point de com-
munication pour lequel un processus peut émettre ou recevoir des informations.
Il permet la communication soit à travers un réseau soit localement à l’intérieur
d’une machine. En utilisant ce socket, des trames FP de taille 36 octets sont en-
voyées de la machine PC1 vers l’unité de multiplexage implémentée sur PCr. La
60 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

Génération du Unité de
Trafic Voix remplissage
Trames FP (Temporisateur)
N canaux
Génération des
PC1 paquets IP

Réception des File de


paquets IP transmission

Capacité de
2 Mbps

PC2 PCr

F IG . 3.5 – Implémentation du système

génération des trames est faite dans deux cas : périodique comme dans la réalité
et suivant la loi Poisson. Dans le cas périodique pour un canal actif, une trame
FP est générée chaque 20 ms. Dans le cas du trafic envoyé par plusieurs canaux
simultanément actifs, l’instant de début de l’émission est aléatoiremnt choisi à
l’intérieur de l’intervalle TTI.

3.4.2 Implémentation des unités du multiplexeur


Les composantes à implémenter sont l’unité de remplissage et la file d’at-
tente. Pour l’unité de remplissage, le fonctionnement est déjà décrit dans la sec-
tion 3.2.1. Le remplissage des paquets et le temporisateur sont deux tâches qui
tournent en parallèle et dépendent l’une de l’autre, autrement dit, ces deux ac-
tivités s’exécutent de façon parallèle et se contrôlent mutuellement. Le tempo-
risateur arrête l’encapsulation quand le délai de remplissage dépasse la valeur
de TCU. Il est déclenché à l’arrivée de la première trame FP dans l’unité de
remplissage vide et aussi initialisé à 0 quand le nombre de trames reçues est
égal à . Pour l’implémentation, nous avons utilisé les threads ou les processus
légers, qui permettent l’exécution parallèle des activités. Dans le programme,
deux threads vont être sollicités plusieurs fois au cours de l’exécution. Ces deux
threads sont l’un pour le remplissage des paquets en ajoutant l’en-tête UDP/IP,
et l’autre pour le temporisateur. Sur des machines monoprocesseur, l’utilisation
des threads conduit à des gains de performances et une meilleure utilisation des
ressources par rapport à l’utilisation des processus indépendants. En effet, créer
un nouveau thread est significativement moins coûteux que créer un processus
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 61

du fait que l’espace d’adressage ne fait pas partie des attributs d’une activité,
mais du processus qui l’héberge [108]. Il en va de même du changement de
contexte entre threads d’un même processus qui ne sollicite pas le gestionnaire
de mémoire. Cette minimisation de l’accès à la mémoire nous offre un gain
important en terme de temps de traitement. En ce qui concerne la liaison de
bas débit, Dummynet [110] est un outil flexible avec le système d’exploitation
FreeBSD pour la gestion de la bande passante. Il est appliqué au niveau IP pour
simuler le goulot d’étranglement de 2Mbps.
Tcpdump [111] et d’autre programmes localement codés sont utilisés pour
enregistrer le temps lors du passage (time stamp) de chaque trame FP sur plu-
sieurs points entre PC1 et PC2 et en passant par PCr, ce qui permet de déterminer
de délai de remplissage et le délai de séjour dans la file de transmission ainsi que
le délai total de séjour dans le multiplexeur. Nous déterminons aussi le nombres
de trames FP dans chaque paquet IP. Eventuellement, des procédures statistiques
sont utilisées pour calculer les quantiles et les autres paramètres de performances.
Pour la série de tests de multiplexage pour la voix, la durée de chaque test est de
l’ordre de 20 secondes, équivalent à !"#"#"$% . !"!#$

3.5 Applications numériques et validation empirique


Dans cette section, Nous présentons les résultats numériques et empiriques
obtenus pour le remplissage et l’attente. Un compromis entre les paramètres de
performance permettra un choix optimal de & , le nombre maximale de trame FP
voix dans un paquet IP, c. à d. la taille maximale d’un paquet IP et de '( la!%&
valeur du temporisateur.

3.5.1 Limitation du délai de remplissage


La Figure 3.6 montre le délai de remplissage '
en fonction du nombre de
canaux simultanément actifs pour différentes valeurs de & qui, rappelons le, est le
nombre de trames FP par paquet IP de taille maximale. Nous observons d’abord
que le délai de remplissage est plus petit quand la valeur de & est plus petite ce
qui est prévu parce que les paquets IP les plus petits sont remplis plus rapide-
ment. D’ailleurs, le délai de remplissage décroı̂t avec l’augmentation du nombre
de canaux. Par conséquent, dans un système fortement chargé , le délai de rem-
plissage n’est pas très significatif comme on peut le constater dans la figure.
Rappelons que le délai du trafic voix dans l’UTRAN devrait être inférieur à
62 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

18
n=3
n=4
n=5
16 n=6
n=8
n=10

14

12
Délai de remplissage [ms]

10

0
0 20 40 60 80 100 120 140
Nombre de canaux simultanément actifs

F IG . 3.6 – Délai de remplissage en fonction du nombre des canaux simul-


tanément actifs

5ms. C’est toujours le cas pour !"#$


. Cependant, le coût est dans ce cas une
mauvaise utilisation da la bande passante ; l’utilisation utile de la bande passante
n’est que 56%. L’effet négatif de l’en-tête UDP/IP est ammortie en augmentant
la valeur de , l’utilisation est évidemment plus importante. Numériquement,
l’en-tête UDP/IP est de 28 octets pour IPv4 et s’élève à 48 bytes pour IPv6. Le
tableau 3.1 permet de voir les valeurs maximales de l’utilisation utile de la bande
passante pour différentes valeurs de .
Par conséquent, pour maximiser l’utilisation de la bande passante, il est sou-
haitable d’avoir une grande valeur et un temporisateur !" pour limiter le %&
délai de remplissage.

3.5.2 Performance du système : délai


3.5.2.1 Délai moyen de séjour

Dans la figure 3.8, nous comparons le délai moyen de séjour dans la file
de transmission calculé par les modèles de Markov et #$%&'()*' ainsi que les '$
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 63

"#$ "#$
!!"#$ !!"%&
3 0.74 0.65
4 0.78 0.7
6 0.82 0.76
8 0.84 0.8
10 0.86 0.82
12 0.87 0.83

TAB . 3.1 – Utilisation maximale U pour différentes valeurs de

résultats empiriques pour les deux cas où les trames FP sont générées périodiquement,
comme dans la réalité, et suivant la loi de Poisson. Nous traçons le délai moyen
de séjour en fonction de ' pour ()% * $ =2 ms, =8 et une bande passante de ca-
"
pacité égale à 2Mbps. Nous remarquons que les modèles analytiques sont plus
conservatifs que les résultats empiriques. Pour le modèle de Markov, Il donne
une bonne approximation dans le cas d’un système à charge moyenne et forte.
Dans un système faiblement chargé, le délai est plus important que celui mesuré.
Ceci est prévisible parce que les paquets IP sont supposés complétement rem-
plis dans l’étude analytique. Par contre le modèle +,-./012&/ ' est plus conservatif
dans le cas du système fortement chargé. Ceci s’explique par l’utilisation de la
distribution exponentielle de la loi de service. Les résultats emiriques du délai de
séjour moyen des paquets IP dans la file sont approximativement les mêmes pour
le cas des trames FP générées selon la loi Poisson et le cas périodique. Cela peut
être expliqué par le fait que le temporisateur affecte le profil du trafic surtout à
faible charge.

3.5.2.2 Quantiles du délai de séjour

La figure 3.8 montre 345 )8()%* $ *%9 + * , la probabilité de dépassement


de la borne du délai dans! la( file (6de
7 transmission, calculée par l’équation (3.30)
en soustrayant le délai consommé pour le temporisateur, en fonction de ' pour
plusieurs valeurs de et (), * $ et une bande passante de 2Mbps. "
Nous remarquons que la probabilité de dépassement du délai toléré est af-
fectée par les valeurs de ()*,$ et ; pour un système faiblement chargé, cette
probabilité est plus sensible à la valeur de (), * $ qu’à la valeur de . Pour
-. , croı̂t quand la valeur de (),
! * $ est plus grande parce que le délai toléré
/ ! *
):(;%* $ ms devient plus petit. Pour une valeur fixe de ()% * $ , est plus grande
(67 !
64 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

TCU=2 ms, n=8, Capacité du lien 2Mbps


5
Analytique par Markov
Analytique par Er/M/1
4.5 Empirique: Poisson
Empirique: Périodique

3.5
Délai moyen de séjour [ms]

2.5

1.5

0.5

0
0 10 20 30 40 50 60 70 80 90 100 110
Nombre de canaux simultanément actifs

F IG . 3.7 – Délai moyen de séjour dans la file de transmission : comparaison entre


le modèle de Markov, le modèle Er/M/1 et les résultats empiriques

quand augmente comme on peut le voir dans les cas =6,8 et !"!" =2 ms. Ceci
peut être expliqué par le fait que le trafic peut devenir plus sporadique avec plus
grand. Le dépassement du délai devient aussi plus probable avec l’augmentation
de nombre de canaux simultanément actifs.
Pour la validation empirique, le résultat analytique du délai de séjour, cal-
culé par l’équation (3.31), est illustré dans la Figure 3.9 avec le résultat enre-
gistré lors des expérimentations sur la plate-forme avec des trames FP générées
périodiquement. La Figure montre précisément le délai de séjour quand la fonc-
tion quantile a une valeur de 0.95, et ceci en fonction du nombre de canaux si-
multanément actifs # et pour plusieurs valeurs de et %"#" . Pour les résultats
analytiques et empiriques$ le délai de séjour augmente avec l’augmentation de la
charge du trafic. Il est aussi proportionnel à . Comme dans le cas des valeurs
moyennes, l’étude analytique donne une bonne approximation dans le cas d’un
système à faible charge mais s’avère conservatrice (pessimiste) quand la charge
augmente. C’est dû principalement à l’hypothèse qui suppose que le temps de
service est distribuée suivant la loi exponentielle.
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 65

Bande passante : 2 Mbps


0
10

−1
10
P(d>(5−TCU)ms)

−2
10

−3
10

n=10,TCU=3ms
n=10,TCU=2.5ms
n=8,TCU=2.5ms
n=8,TCU=2ms
n=6,TCU=2ms
n=6,TCU=1.5ms
n=6,TCU=1ms
−4
10
0 20 40 60 80 100 120
Nombre des canaux simultanément actives

F IG . 3.8 – Probabilité de dépassement du délai de séjour (5-TCU)ms en fonction


du nombre de canaux actifs

La Figure 3.10 montre le délai total de la première trame FP ! , remplissage


et séjour, mesuré lors des expérimentations quand la fonction quantile est 0.95,
et ceci en fonction de " pour différentes valeurs de TCU et .
#
Dans le cas où le système est à faible charge, l’impact du temporisateur est
dominant. Quand " augmente, nous remarquons que pour des valeurs fixes
#
du temporisateur, le délai augmente avec des valeurs plus grandes de ; ceci
confirme empiriquement le résultat analytique cité ci-dessus. D’ailleurs, Au fur
et à mesure que " augmente, le délai s’avère être plus sensible à qu’à TCU ;
# est plus grand pour le cas de =12 et $%!
par exemple, le délai & " =1 ms que dans
le cas de =8 et $%# & " =2 ms. Nous constatons qu’un paquet IP de grande taille
n’est pas performant pour le délai et le temporisateur ne devrait pas être plus que
2 ms, sinon la borne de 5 ms sur le délai peut être rapidement dépassée.
Nos résultats montrent que les choix d’ingénierie devrait prendre en considération
que le délai est le paramètre à satisfaire en premier. Un temporisateur de valeur
inférieure ou égale à 2 ms et un paquet IP qui contient moins de 10 trames FP, 6
ou 8, constitue un paramétrage optimisé. Dans le cas où = 8 et $%# & " = 2 ms, la
66 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

Bande passante : 2 Mbps, a:analytique, e:empirique


25
e:n=6, TCU=2ms
a:n=6, TCU=2ms
e:n=8, TCU=2ms
a:n=8, TCU=2ms
e:n=10, TCU=2ms
20 a:n=10, TCU=2ms
Délai de transmission [ms] (95 percentile)

15

10

0
0 10 20 30 40 50 60 70 80 90 100 110
Nombre de canaux simultanément actifs

F IG . 3.9 – Comparaison des résultats analytiques et empiriques du délai de séjour

figure 3.11 montre l’impact de ces valeurs sur le profil de génération des paquets
IP, qui n’est autre que le profil d’arrivée des paquets IP dans la file de transmis-
sion, pour différentes valeurs de . Pour une faible charge où =10, le temps
d’inter-arrivée des paquets IP est entre 2 et 3 ms pour 42% du trafic et entre 7 et ! !

8 ms pour 40 %. Nous remarquons aussi la nature périodique du trafic pour un


faible nombre de sources. Avec =50, 38% des paquets enregistrent un temps
d’inter-arrivée entre 0 et 1 ms et le reste est distribué sur les autres intervalles. A !

forte charge avec =100, le pourcentage du trafic avec un temps d’inter-arriveée


des paquets entre 0 et 1 ms augmente à 60 % et le trafic généré sans expiration du
!

temporisateur est de l’ordre de 70%, ce qui confirme que l’effet du temporisateur


est faible à forte charge.

3.5.3 Utilisation utile de la bande passante


Une utilisation efficace de la bande passante est accomplie avec des valeurs
de qui s’approchent de . La figure 3.12 montre U, l’utilisation utile de la !

bande passante, calculée par l’équation (3.16) en fonction de pour différentes


!
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 67

Bande passante: 2 Mbps


8
n=6, TCU=1ms
n=6, TCU=2ms
n=8, TCU=1ms
n=8, TCU=2ms
7 n=8, TCU=3ms
n=10, TCU=1ms
n=10, TCU=2ms
n=10, TCU=3ms
n=12, TCU=1ms
6
Délai [ms] (95 percentile)

1
0 10 20 30 40 50 60 70 80 90 100 110
Nombre de canaux simultanément actifs

F IG . 3.10 – Délai total empirique dans le multiplexeur

valeurs de !" ! . La valeur maximale de ! , correspondant au cas d’un paquet


IP de taille maximale pour "#$%& , est environ '() &#$ ou, autrement dit, &#$%& de
la bande passante. Il est intéressant de noter que quand le nombre de canaux est
faible, ! est nettement inférieure à '() &#$ . Ceci signifie que la plupart des paquets
ont été générés lors de l’expiration du temporisateur. Au fur et à mesure que le
nombre de canaux augmente, ! croı̂t et, les courbes tendent vers la valeur limite
0.84, donc des paquets totalement remplis. D’ailleurs, ! est plus faible pour de
petites valeurs de !" ! , surtout à faible charge. Par conséquent une valeur élevée
de !"*! se traduit par une utilisation plus efficace de la bande passante, mais elle
peut mener à un dépassement du délai et ensuite une dégradation de la qualité de
service.
La figure 3.13 montre ! en fonction de ' pour !"*! =2 ms et différentes
valeurs de " . On note que, quand le nombre de( canaux est faible, ! est faible et
approximativement la même pour toutes les valeurs " . Au fur et à mesure que
le système devient chargé, l’utilisation utile est plus efficace quand " augmente,
mais la valeur supplémentaire de l’utilisation devient peu significative pour "
68 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

Profile d’arrivée des paquets IP

0.6 Nv=10

0.4

0.2

0
0 1 2 3 4 5 6 7 8 9 10 11
Densité de probabilité

0.6 N =50
v

0.4

0.2

0
0 1 2 3 4 5 6 7 8 9 10 11

0.6 N =100
v

0.4

0.2

0
0 1 2 3 4 5 6 7 8 9 10 11
Temps d’inter−arrivée entre deux paquets IP [ms]

F IG . 3.11 – Profil d’arrivée des paquets IP dans la file de transmission avec n=8
et TCU=2ms

plus grande.
La figure 3.14 montre la validation empirique de l’étude analytique de l’unité
de remplissage. L’utilisation , calculée par l’équation (3.16) et celle mesurée
empiriquement pour un trafic périodique sont illustrées en fonction de . Nous
remarquons que les résultats analytiques sont conformes avec les résultats empi- !

riques.

3.5.4 Dimensionnement dans l’UTRAN


La conception de l’UTRAN nécessite des données de départ traduisant les
besoins des opérateurs en matière de couverture, du trafic et de qualité de ser-
vice ce qui débouche sur des problématiques de dimensionnement des RNCs,
des Nodes B et des liaisons de transmission. Le volume de trafic dans l’UTRAN
est typiquement dicté par l’interface radio suivant la disponibilité des ressources
radio. Les ressources radio sont plus critiques et rares ce qui donne que les
ressources sur les interfaces filaires de l’UTRAN ne devraient pas être restric-
tives. Les règles de dimensionnement radio tiennent en compte ce facteur en
déterminant la capacité du Node B. Le pic de trafic voix global au niveau du
Node B, résultant du nombre de canaux actifs, oriente le dimensionnement de
l’interface Iub en ajoutant les surdébits dus aux en-têtes. Selon le critère de qua-
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 69

n=8
0.85

0.8

0.75
U

0.7

0.65
TCU=1.5ms
TCU=2ms
TCU=2.5ms
TCU=3ms
TCU=3.5ms
0.6
0 20 40 60 80 100 120
Nombre de canaux simultanément actifs

F IG . 3.12 – Utilisation utile en fonction du nombre des canaux actives pour n=8
et différentes valeurs de TCU

lité de service adopté par l’opérateur, ce dernier peut déterminer la bande pas-
sante appropriée de l’interface Iub en se basant sur notre modèle. La figure 5.3
montre !"# !&'()"# $*+,-%$
en fonction de la capacité de lien pour =10, ) .
. . $%
=50 et =100 dans le cas =8 et & '/') #
=2 ms.

3.6 Conclusion
Dans ce chapitre, nous avons étudié le transport du trafic voix dans l’UTRAN,
en respectant la borne sur le délai tout en maximisant l’utilisation de la bande
passante. Nous avons examiné le multiplexage des trames FP voix dans des pa-
quets IP et la transmission de ces paquets sur la liaison de sortie selon deux ap-
proches : par chaı̂ne de Markov et par un modèle de service par bloc . 01234567489 $
Nous avons validé notre modèle empiriquement par des expérimentations sur une
plate-forme émulant les fonctionnalités de transport dans l’UTRAN. Nous avons
montré que l’IP est une solution viable dans l’UTRAN avec le multiplexage des
trames FP de petites tailles dans des paquets IP. Nous proposons un paramètrage
70 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

TCU=2ms
0.95

0.9

0.85

0.8
U

0.75

0.7

n=4
0.65 n=6
n=8
n=10
n=12
0.6
0 20 40 60 80 100 120
Nombre des canaux simultanément actifs

F IG . 3.13 – Utilisation utile en fonction du nombre des canaux actives pour


TCU=2 ms et différentes valeurs de n

optimal satisfaisant la contrainte temporelle et assurant une utilisation efficace


du lien avec un temporisateur inférieur ou égal à 2 ms et un paquet IP contenant
de 6 à 8 trames FP voix. Dans le chapitre suivant, nous nous focalisons sur le
transport du trafic data non temps réel, tel que le trafic Web, et nous examinons
la différenciation de service en présence des deux types du trafic, voix et data.
CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN 71

Bande passante : 2 Mbps, a:analytique, e:empirique


0.95

0.9

0.85

0.8
U

0.75

0.7

e:n=6, TCU=1ms
a:n=6, TCU=1ms
0.65 e:n=8, TCU=2ms
a:n=8, TCU=2ms
e:n=10, TCU=2ms
a:n=10, TCU=2ms
0.6
0 20 40 60 80 100 120
Nombre des canaux simultanément actifs

F IG . 3.14 – Utilisation utile de la bande passante : analytique et empirique


72 CHAPITRE 3. TRANSPORT DU TRAFIC TEMPS RÉEL DANS L’UTRAN

n=8,TCU=2ms
0
10
N=10
N=50
N=100
−1
10

−2
10
P(d>(5−TCU)ms)

−3
10

−4
10

−5
10

−6
10
1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6
Bande passante [Mbps]

F IG . 3.15 – Probabilité de dépassement du délai de séjour dans l’UTRAN en


fonction de la capacité de la liaison filaire
Chapitre 4

Différenciation de service dans


l’UTRAN

4.1 Introduction

Dans le chapitre précédant, nous avons étudié le transport du trafic temps


réel, voix, dans l’UTRAN. Dans ce chapitre, nous étudions d’abord le transport
du trafic data non temps réel tel que le trafic Web et puis nous examinons la
différenciation de service entre le trafic voix et le trafic data. Rappelons que le
transport des deux types du trafic doit être effectué de manière temps réel et que
le délai toléré par le trafic voix est plus petit que celui toléré par le trafic Web.
Pour l’implémentation de la différenciation de service, nous examinons analyti-
quement et empiriquement les ordonnanceurs weighted round robin et priority
queuing.

4.2 Transport du trafic data

Le trafic data acheminé dans l’UTRAN regroupe le trafic des applications


Web, E-mail, FTP, etc. Dans ce travail, nous examinons le cas typique pour le
trafic data celui du trafic Web sur la voie descendante. Le canal de transport
sur l’interface radio est un canal partagé DSCH (Downlink Shared CHannel).
Plusieurs usagers téléchargant des pages Web peuvent partager le canal sur l’in-
terface radio. Ce canal partagé peut opérer à un débit de 64, 144 ou 384 kbps.
74 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

4.2.1 Modèle du trafic data


Une connexion Web est une suite de requêtes/réponses pendant lesquels l’usa-
ger envoie des requêtes de téléchargement de pages à un serveur, qui renvoie en
réponse le contenu des pages Web demandées. L’essentiel du trafic Web concerne
donc la voie descendante. Le modèle de source Web sur la voie descendante est
une succession d’appels paquets séparés par des périodes de silence, donc du
type ON/OFF. Un appel paquet correspond au téléchergement d’une page Web.
Durant un appel paquet, plusieurs paquets sont transmis ; typiquement, ces pa-
quets sont envoyés en rafale. Ce trafic subit l’action des couches traversées jus-
qu’à la couche FP et c’est le profil de trafic à ce niveau qui nous intéresse dans
notre étude. Donc pour un canal partagé par des appels paquet, ou autrement
dit, des périodes d’activité simultanées de téléchargement du trafic, la couche
RLC assure la fiabilité du transport radio en opérant en mode acquitté (voir sec-
tion 2.5.1.2). Elle segmente les paquets de données, envoyés par les couches
supérieures, en blocs de transports (TB) et fournit à la couche MAC les RLC-
PDUs. La couche MAC spécifie le format de transport sur le canal de transport,
autrement dit le nombre de blocs à transmettre pendant l’intervalle de temps TTI,
TTI=40 ms pour le trafic Web. Sur le canal DSCH, les blocs du trafic de plusieurs
usagers sont agrégés avec une possible gestion de priorité entre les RLC-PDU
des différents usagers. Les données transmises par la couche MAC chaque TTI
sont rassemblés dans une trames FP qui à son tour sera transportée dans des pa-
quets IP. Nous considérons dans notre étude le cas où le canal de transport DSCH
est suffisamment chargé et que les usagers bénéficient de bonnes conditions ra-
dio, donc le transport de trafic pendant la période d’activité du canal DSCH.

4.2.2 Modélisation de l’UTRAN


Comme dans le cas de la voix, l’interface Iub peut être modélisé par une unité
de remplissage et une file de transmission (voir figure 3.3). La file de transmis-
sion est formée d’un tampon de taille infinie et d’un serveur de type FIFO ayant
une capacité égale à . Pour les canaux de 64 kbps, au niveau de la couche FP
et dans une période d’activité, une trame de taille 320 octets est généré chaque
40 ms et est encapsulée dans une trame FP en ajoutant un en-tête de 5 octets.
La trame FP est de l’ordre de 725 octets pour un canal de débit 144 kbps et de
1925 octets pour 384 kbps. Il n’est pas très avantageux d’avoir un grand paquet
IP, un paquet IP de 1500 octets bloque la liaison de sortie de 2 Mbps pour une
durée de 6 ms. D’où le fait que nous n’examinons pas l’agrégation des trames
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 75

data dans notre étude. Néanmoins, notre modèle analytique de multiplexage pour
le cas de la voix peut être directement appliqué dans le cas où une telle étude est
nécessaire. Nous nous focalisons dans la suite de ce travail sur l’encapsulation
d’une trame dans un paquet IP dans le cas d’un canal opérant à 64 kbps. Dans
l’unité de remplissage, un temporisateur n’est pas nécessaire et dans le cas des
canaux avec des débits de 144 kbps et 384 kbps les trames FP de grande taille
sont segmentées.

4.2.3 Etude de transport des canaux à 64 kbps


Pour un canal DSCH à un débit de 64 kbps, une trame FP de 325 octets ar-
rive au multiplexeur chaque 40 ms. Nous examinons le cas où une seule trame de
données est encapsulée dans un paquet IP en ajoutant l’en-tête UDP/IP. La taille
!" du paquet IP s’élève à 353 octets dans ce cas. Supposant que le temps d’en-
voyer le paquet de l’unité de remplissage à la file d’attente de transmission est
négligeable, le système est alors équivalent à la file de transmission seulement.
Le profile du trafic à l’entrée de la file de transmission est donc le même que
celui à l’entrée de l’unité de remplissage.
Pour # " canaux de données simultanément actifs, le processus d’arrivée des
paquets IP à la file d’attente de transmission peut être modélisé par un processus
de Poisson avec un taux $%& paquets/ms. Le système est donc modélisé par une
'
file ()*+,-*./ avec une capacité 0 . Nous normalisons l’axe de temps, pour les
processus d’arrivée et de service, au temps nécessaire pour servir un paquet data
de taille 1" avec une capacité 0 . Soit !2" la charge du système. Nous appliquons
la formule de Pollaczek-Kinchin obtenue pour ()*+34*5/ dans [81] pour la file
()*+,6*5/ et nous calculons le délai moyen de séjour 7 " d’un paquet IP dans la file
de transmission et donc dans le multiplexeur,
$
# % !"
2
7 "
"
# '/ % 2! "() (4.1)

&
Pour évaluer la probabilité de dépassement du délai cible, nous calculons
d’abord la fonction de répartition du délai de séjour dont la transformée de La-
place 8 9 *) pour la file ()*+34*5/ est donnée dans la référence [81] (voir page
199) &
*) ":; +% !2",)
*) /
=?; 9 *)
8 9 9
& & <=-
% & .
>
(4.2)

avec ; 9 *) " &


0/ 5@ , la transformé de Laplace de la distribution du service dans
notre cas.& Le calcul de la fonction inverse de la transformé de Laplace 8 9 *) est
&
76 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

très difficile par la méthode de recherche des zéros. Nous calculons cette fonc-
tion en utilisant la méthode d’approximation (voir [79] page 391), la fonction
de répartition du temps de séjour d’un paquet IP dans ) la file de transmission est
)
donc
$ # # !/!
! " # # $%$ ! % * ) &&'()'( . # ,
- ' 234 '(4.&& '()5676 (4.3)
*+ '" 0 1
!" +,- +
Nous nous intéressons à la probabilité de dépassement du délai cible, / 0 1
! qui est donnée par
2 /
0
1
! 3 " #84 # ! (4.4)
2 !2
Nous traçons dans la figure 4.1 la probabilité de dépassement du délai cible
en fonction de 5 6 , le nombre de canaux simultanément actifs, pour une bande
passante
2 de 2 Mbps. Le nombre de canaux qui peuvent être acceptés varie selon
la borne du délai ainsi que le critère de qualité de service adopté. Nous observons
que 20 canaux simultanément actifs sont supportés sur une liaison de 2 Mbps
7
avec une probabilité de dépassement du délai de 10 ms de l’ordre de #9: ' .

Canaux de données à 64 kbps, Bande passante: 2Mbps


0
10
x=10 ms
x=20 ms
x=50 ms
−2
10

−4
10
P(Délai > x)

−6
10

−8
10

−10
10

−12
10
0 5 10 15 20 25
Nombre de canaux simultanément actifs

F IG . 4.1 – Probabilité de dépassement du délai en fonction du nombre des


canaux actifs 2
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 77

Pour valider le modèle, nous avons utilisé notre plate-forme comme dans le
cas du trafic voix. Le trafic data est généré par la machine PC1. Le temporisa-
teur n’est pas utilisé et l’unité de remplissage encapsule une trame FP dans un
paquet IP en ajoutant l’en-tête UDP/IP. Le trafic data provenant de canaux !

simultanément actifs est généré périodiquement et suivant la loi de Poisson.


La figure 4.2 montre la fonction de répartition du délai de séjour calculée par
l’équation (4.3) et celle mesurée lors des expérimentations lancées pour des tra-
fics périodique et Poissonnien et ceci pour =15 et une liaison de 2 Mbps. Les
!

résultats montrent que le modèle analytique donne une bonne approximation sur
l’état du système. Le trafic est en réalité périodique, mais l’approximation par la
loi de Poisson est acceptable dans notre contexte d’étude comme le démontrent
les résultats empiriques. Le même commentaire est valable pour la figure 4.3
avec = 20.
!

N =15; Capacité du lien 2Mbps


d
1

0.9

0.8

0.7

0.6
CDF

0.5

0.4

0.3

0.2

0.1 Analytique
Empirique: Poisson
Empirique: Périodique
0
0 5 10 15
Délai [ms]

F IG . 4.2 – La fonction de répartition du délai de séjour avec 15 canaux actifs :


analytique et empirique
78 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

Nd=20; Capacité du lien 2Mbps


1

0.9

0.8

0.7

0.6
CDF

0.5

0.4

0.3

0.2 Analytique
Empirique: Poisson
Empirique: Périodique
0.1
0 5 10 15
Délai [ms]

F IG . 4.3 – La fonction de répartition du délai de séjour avec 20 canaux actifs :


analytique et empirique

4.2.4 Etude du transport dans les canaux à 144 kbps


Pour un canal de 144 kbps, une trame FP data de 725 octets arrive chaque
40 ms au multiplexeur. L’encapsulation d’une trame dans un paquet IP peut
être étudiée selon le modèle de la section précédente. Nous nous focalisons sur
l’étude de la segmentation ; la trame de 725 octets est divisée en deux segments,
un en-tête de 3 octets, contenant les informations nécessaires à la reconstitution
de la trame, est ajoutée à chaque segment. L’unité de remplissage génère donc
deux paquets IP. Par conséquent, l’arrivée d’une trame FP au multiplexeur est
équivalent à l’arrivée d’un bloc de 2 paquets IP dans la file de transmission.
Nous supposons que les délais de segmentation dans l’unité de remplissage et
de l’envoie vers la file de transmission sont négligeables. Comme dans le cas
précédent, le processus d’arrivée des trames FP de plusieurs canaux au multi-
plexeur est modélisé par un processus de Poisson avec le taux !"#$% , où &'( est
le nombre de canaux data simultanément actifs. Notre système est considéré
comme un système avec des arrivées en bloc et nous le modélisons alors par
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 79

la file d’attente de type !"#$%&'"()


, dans lequel chaque trame FP doit passer par 2
étapes de service pour accomplir son service total. Une étape de service corres-
pond au service d’un paquet IP et le temps de service total est , égale au temps +*
de service de la trame FP avec le surdébit des en-têtes. Nous normalisons aussi
l’axe de temps pour le processus d’arrivée et de service sur le temps nécessaire
-, .
pour servir une trame FP avec les en-têtes. est également la charge du système.
Nous appliquons la formule de Pollaczek-Khinchin obtenue pour la file d’attente
!"#/0"() dans [81] à la file de type !"1$%&'"()
et nous obtenons le délai moyen de
23.
séjour dans le système par

2-.45 6 ") 7,8,--. . # (4.5)


6
Dans ce cas, 9:; # la transformé de! Laplace de la distribution de service est
!<=
9; #5 #& (4.6)
!>= ! ?1@ =
En reprenant l’équation 4.2, nous pouvons ?1@AB calculer la fonction de répartition
du délai de séjour dont la transformée de Laplace C ; # est donnée par
& )$D,-. # !<=
C ; 5 & 6 EF ! #
#
GF # (4.7)
!>= = !6 @ = B 6 @ !@ @
En inversant la transformé deB Laplace,
&
C # 5JK CL5 # 5M6 NOP! ) 7,NOP -. %QRSTUV %QRST UV #'W
#
(4.8)
!HI
N P et N P sont les racines ! I @& ! IX# YZ[
de l’équation
6 :F 6 :F 5 . Nous avons,
#
en normalisant per rapport au temps= de service,
& B ! @ = B =1@ et! @ F # =& ,\. , donc[ l’équation #bc ,
N P et N P = existent ], -
6 et sont. #
6! ) & E, - . # 5 . Comme ^,-. _)`a '
P@ 6 P 5 ) ^, - .
que N ! N #De et[
devient
!
N Pfg N P 5 ()B h,-. #ic . La = [
B probabilité de dépassement du délai ! N , K C cEN)# ,[ est
négatives du fait
6 d,
! - .
donnée par!
6 [ B !
K C c])N # 5 j!k C # 2
! !H-I . # I )
5 6 N ! P N P N P %QR T R N ) P %QR T R #'WlN
R ) " 7, (4.9)
! YZ[
du délai cible N en fonction de m:. canaux à 144 kbps, pour une bande passante
Pour une application numérique, la figure 4.4 montre la probabilité de dépassement
80 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

de 2 Mbps. Avec une probabilité de dépassement du délai de 10 ms de l’ordre de


$
, 8 canaux simultanément actifs de 144 kbps peuvent être supportés. Nous
!"#
pouvons aussi tracer la probabilité de dépassement du délai de 10 ms en fonction
de la bande passante pour différentes valeurs de %&' comme le montre la figure
4.5.

Canaux de données à 144 kbps, Bande passante: 2Mbps


0
10
x=10 ms
x=20 ms
x=50 ms
−2
10

−4
10
P(Délai > x)

−6
10

−8
10

−10
10

−12
10
2 3 4 5 6 7 8 9 10 11 12
Nombre de canaux simultanément actifs

F IG . 4.4 – Probabilité de dépassement du délai ( en fonction du nombre des


canaux actifs

4.2.5 Etude de transport des canaux à 384 kbps


Pour un canal DSCH de 384 kbps avec TTI=40 ms, une trame de 1925 oc-
tets arrive au multiplexeur chaque 40 ms. Une segmentation est nécessaire et
un modèle similaire à celui dans la section précédente, de type )*+,-./0+1 , peut
être utilisé selon le nombre 2 de segments générés par la trame. Donc, nous ne
détaillons pas ce cas et nous passons à l’étude de la différenciation de service
dans la section suivante.
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 81

Canaux de données à 144 kbps


0
10
Nd=5
Nd=10
Nd=15
−1
10

−2
10
P(Délai > 10 ms)

−3
10

−4
10

−5
10

−6
10
0 1 2 3 4 5 6
Bande passante en [Mbps]

F IG . 4.5 – Probabilité de dépassement du délai de 10 ms en fonction de la bande


passante

4.3 Performance de l’IP dans l’UTRAN avec diff érenciation


de service
4.3.1 Système étudié
Nous avons étudié le transport du trafic temps réel et du trafic non temps
réel séparément. Dans cette section, les deux types de trafic partagent la même
liaison de sortie et des techniques d’ordonnancement comme WRR et PQ sont
examinées pour assurer une différenciation de service. Les types de trafic que
nous envisageons sont aussi le trafic voix, en mode AMR 12,2 Kbps, commme
trafic temps réel et le trafic Web, sur la voie descendante, comme trafic non temps
réel. Nous rappelons que le trafic voix est transporté dans des canaux de transport
DCH, bidirectionnels, tandis que le trafic Web de voie descendante est transporté
dans des canaux DSCH. Dans la suite de l’étude, nous considérons que tous les
canaux DSCH mis en oeuvre ont le même débit binaire de 64 kbps. Les processus
d’arrivée des trames FP voix et data sont aussi modélisés par des processus de
82 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

Poisson.

4.3.2 Modélisation du système


Nous modélisons l’interface Iub de l’UTRAN par le système illustré dans la
figure 4.6. Ce système regroupe les unités déjà rencontrées lors de l’étude du
transport de la voix et des données en ajoutant un ordonnanceur pour le partage
de la bande passante.
Unité de remplissage File voix
Trames FP voix
Ordonnanceur

Trames FP data

Unité de remplissage File data

F IG . 4.6 – Modélisation de l’UTRAN avec différenciation de service

Les trames voix et data arrivent aux unités de remplissage et sont séparément
encapsulées dans des paquets IP. Ces derniers sont alors mis en attente dans
deux files d’attente différentes avant leur transmission sur une liaison commune
de capacité où l’ordonnanceur permet de gérer l’utilisation des ressources.
Nous commençons par l’étude de l’ordonnanceur cyclique avec pondération
(WRR pour Weighted Round Robin) pour une différenciation de service entre ces
deux types de trafic lors du service. En fait, WRR a été prouvé plus efficace que
d’autres algorithmes tels que Earliest Deadline First (EDF) dans le contexte de
l’AAL2/ATM [31] et il est plus simple que la gestion équitable des files d’attente
avec pondération (WFQ pour Weighted Fair Queuing) lors de l’implémentation.

4.4 Différenciation de service par ordonnancement


cyclique avec pondération (WRR)
4.4.1 Analyse de WRR
L’ordonnanceur WRR permet le partage la bande passante de capacité
entre les différentes files d’attente ou classes en utilisant la technique du tour-
niquet pondéré. A chaque classe ! , où !"#$%&' ( )*+ 1 , est assigné un poids ,-. qui
1
Les indices inférieurs / et 0 désignent voix et data respectivement
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 83

"! #$%&'
traduit le nombre maximal des octets que la file d’attente correspondante est au-

( )*'+!,-.0 /
torisée à transmettre dans un tour. La longueur d’un tour est octets.
En d’autres termes, WRR garantit à la classe une fraction de la bande
passante. L’implémentation de WRR permet un traitement au niveau octet ainsi

(
qu’un traitement au niveau paquet.
Nous définissons une période d’attente pour la classe (backlogged period)
comme étant une période où des octets appartenant à cette classe existent sans
interruption dans le système. Théoriquement, nous supposons que les deux types
de trafic existent dans le système. La condition de stabilité du système est res-

(
pectée c. à d., la charge totale du trafic est inférieure à la capacité du serveur.

12'
Nous calculons maintenant la borne supérieure du délai pour la classe . Le délai
maximal est le délai, d’attente et de service, vu par un paquet qui arrive à

34' (
un instant où le serveur vient de finir le service de sa file et commence à ser-

15'
vir l’autre file. Soit le nombre de paquets en attente pour la classe à cette
époque, est calculé par

61 '7! 89 : ' 34%&' ' < = >?%&' ' &B C <


!
!"!

; ;
(4.10)

avec, ' 34' D E


< 'FGHIJK %&' et ' est la taille du paquet
! ! ;@A de la classe ( .
: évaluer cette borne, nous : devons déterminer 3L' . En général, le calcul
; A
de la valeur instantanée de 34' est mathématiquement difficile. Nous pouvons
Pour

néanmoins calculer la valeur moyenne. Dans ce cas, la valeur moyenne de 3M' est

( avec une bande passante de capacité )N'OC . Nous considérons donc chaque file
égale au nombre moyen de paquets dans une file alimentée par le même trafic

d’attente à tour de rôle. Nous commençons par la voix.

4.4.2 Calcul du délai moyen de paquets voix


PQR
)*'SC
Pour une file d’attente où le trafic d’entrée est canaux voix actifs et une
bande passante est , l’étude de la section 3.3.4.1 est appliquée sur la voie

3QR C)N'OC
descendante. Elle permet de déterminer le nombre moyen de paquets voix dans
la file en remplaçant par .

3QRT! V 'WUX (Z[ ( !


(4.11)

avec [@! [ ^_ [ < `_ [ ^_


! ! bcbcb le vecteurY des probabilités stationnaires qui est
! !

déterminé par\] l’équation (3.19). Nous pouvons donc calculer 1dR , le délai maxi-
a
84 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

mal des paquets voix, par


" ) * " ,
!"#$ %&' ( .- " / % 01-." " !".! 4 5 ,
!
(4.12)
+ + +23
4.4.3 Calcul du délai moyen de paquets data
Pour le trafic data, nous examinons le cas du trafic Web sur la voie des-
cendante transporté dans des canaux DSCH à 64 kbps. Comme dans la section
4.2.3, une seule trame data est encapsulée dans un paquet IP en ajoutant l’en-
tête UDP/IP. Pour 678 canaux DSCH simultanément actifs alimentant une file
d’attente de capacité 9:8;5 , le modèle <=>?@>A, est appliqué et nous calculons le
nombre moyen )B8 de paquets IP comme suit,

)78.$ C D8
,F0GCH8 ! (4.13)

Donc I8 ,le délai maximal des paquets


E data, est
J8K$ %&' ( 8 L) K- 8 8 , / % 0G-K8 8 !#.! 4 5 ,
!
(4.14)
+ + +23
4.4.4 Résultats numériques et validation empirique
Dans cette section, nous décrivons d’abord la plate-forme employée pour la
validation empirique de nos résultats. Dans la suite de cette section et pour le
cas du trafic voix, le nombre maximal de trames par paquet IP M est égal à 8 et
la valeur du temporisateur NO5!P est égale à 2 ms. La longueur maximale d’un
paquet voix est " = 340 octets. Pour le trafic data, la longueur du paquet est
8 =353 octets. (
(
4.4.5 Plate-forme de différenciation de service
Notre plate-forme est déjà décrite dans la section 3.4 et montrée dans la fi-
gure 3.4. Nous implémentons les multiplexeurs ainsi que la différenciation de
service comme le montre la figure 4.7. Le trafic voix est généré à partir de la
machine PC1 ; chaque canal envoie une trame FP de 36 octets chaque 20 ms. Les
trames FP voix sont rassemblées dans l’unité de remplissage et attendent dans
la queue correspondante. Le trafic data est généré à partir de la machine PC2 ;
chaque canal envoie une trame FP de 325 octets chaque 40 ms. Les trames FP
data sont encapsulées dans des paquets IP lors de leur passage dans l’unité de
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 85

remplissage en ajoutant l’en-tête UDP/IP. Ensuite, les paquets IP data attendent


dans la queue data. L’ordonnanceur gère l’attribution de la bande passante aux
queues et les paquets sont reçus sur la machine PC3. Comme dans le cas des
tests précédents, tcpdump et autres logiciels sont utilisés pour enregistrer les pa-
ramètres de performance requis.

Génération du
trafic voix Unité de Génération des
Trames FP remplissage paquets IP voix

PC1 Réception des


paquets IP

Génération du
trafic donnée Unité de
Trames FP remplissage PC3
Génération des
paquets IP donnée
PC2 PCr

F IG . 4.7 – Implémentation du système avec différenciation de service

4.4.6 Validation du modèle et pondération


La figure 4.8 montre le délai pour le cas du trafic voix et data en fonction de la
bande passante en Mbps. Pour une meilleure présentation, le délai est normalisé
par le budget du délai toleré par la classe correspondante, c. à d. 5 ms pour le
trafic voix et 10 ms pour le trafic data. Les quatre courbes rapportent des résultats
analytiques et empiriques pour le trafic voix et le trafic data. Ceci a été effectué
pour le cas où le nombre des canaux de voix simultanément actifs !"
est égal à
50 et le nombre des canaux data simultanément actifs #$
est égal à 10. Dans ce
cas, le volume du trafic est approximativement le même pour la voix et le trafic
data. Les poids WRR sont comme suit : %&"'( +* ,
et .%-$.( +* ,
) )
Nous notons que les résultats analytiques obtenus bornent les résultats empi-
riques. Ils s’approchent surtout avec l’augmentation de la capacité de la liaison
et ceci pour les deux types de trafic.
En ce qui concerne les poids affectés aux classes, nous remarquons que le fait
de donner le même poids pour les classes voix et data n’est pas une bonne option
pour la voix parce que son budget de délai tolérable qui est égale à , /0123!4 !

ms est inférieur à celui du trafic data. Alternativement, nous montrons dans la


figure 4.9 les délais normalisés pour le cas où le poids attribué à la voix est plus
86 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

N =50,φ = 0.5, budget=(5−TCU)ms, TCU=2ms ; N =10,φ =0.5, budget=10ms


v v d d
200
analytical voice bound
empirical voice delay
180 analytical data bound
empirical data delay

160

140
Délai normalisé par le budget

120

100

80

60

40

20

0
2 3 4 5 6 7 8
Bande passante [Mbps]

F IG . 4.8 – Comparaison des délais à poids égaux : analytique et empirique

élevé, c.-à-d., !"#$ &'()* et +,-$ & * . Dans ce cas, les résultats empiriques
%
et analytiques sont aussi proches en% particulier quand la capacité de la liaison
.
augmente. Par rapport à la figure 4.8, nous observons que délai de la voix est
plus petit et ceci à un prix raisonnable pour le trafic data. Ce résultat suggère
que l’implémentation donnant plus de poids pour le trafic voix optimise mieux
l’utilisation de la bande passante.

4.4.7 Résultats empiriques


Nous présentons dans cette section des résultats empiriques pour le délai avec
une bande passante fixe égale à 2 Mbps et pour différents poids. Les charges des
trafics voix et data sont similaires et égales à 0,36. La charge totale du système
est donc égale à 0,72. Nous traçons la fonction de répartition du délai (CDF
pour Cumulative Distribution Function) dans les figures 4.10 et 4.11 pour mieux
expliciter les avantages de l’attribution d’un poids élevé à la voix. Les poids
examinés sont : /"0$ &1* et 2,3$ &'* ; 2"4$ &1()* et +,5$ & * ; 2"0$ &67)7
et 2,8$ & 9 . Nous remarquons
% que% même lorsque
% le trafic data
% a un poids % plus
.
% %
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 87

N =50,φ = 0.75, budget=(5−TCU)ms, TCU=2ms ; N =10,φ =0.25, budget=10ms


v v d d
200
analytical voice bound
empirical voice delay
180 analytical data bound
empirical data delay

160

140
Délai normalisé par le budget

120

100

80

60

40

20

0
2 3 4 5 6 7 8
Bande passante [Mbps]

F IG . 4.9 – Comparaison des délais avec un poids supérieur pour la voix : analy-
tique et empirique

faible, son délai n’excède pas excessivement son budget de délai de 10 ms.
Pour le délai total du trafic voix, y compris le délai de remplissage et celui de
transmission, la figure 4.12 montre sa fonction de répartition. Ce délai total est
vu par la première trame encapsulée dans un paquet IP quand la capacité de la
liaison est de 2 Mbps. Nous considérons les cas suivants où la charge totale est
approximativement égale à 0,72 :
1. % ;'()$*+ ;,-".$ / % !"#$
2. % & ;'()$*+ & ;,-".$ & / 01%
!"#$
3. 0 & ;'()$ % & ;,-")$ &/ %
!"#$
4. 0 & ;'()$ % ;,-")$ & / 01%
!"#$
On peut voir qu’en& donnant plus& de poids pour le trafic voix, le pourcentage des
trames voix ayant un délai total inférieure à 5 ms augmente. Cette augmentation
est de l’ordre de 10%. D’ailleurs, nous notons que même quand le nombre de
canaux de voix augmente, c.-à-d., de 50 à 70 dans notre cas, et pour le même
poids, le délai total diminue. Ce résultat est principalement dû à la diminution
88 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

Bande passante: 2 Mbps, ρv=0.36, ρd=0.36


100

90

80

70
CDF

60

50

40

30 φv=0.5
φv=0.75
φv=0.99
20
1 2 3 4 5 6 7 8 9 10 11
Délai [ms]

F IG . 4.10 – Fonction de répartition (CDF) du délai de la voix pour différents


poids

du délai de remplissage au fur et à mesure que le nombre de canaux de voix


simultanément actifs augmente.

4.4.8 Discussion des résultats

Un transport efficace des trafics avec une différenciation de service peut être
bien implémenté avec WRR en donnant un poids plus important au trafic voix
qu’au trafic data. Ceci nous conduit à approfondir notre étude pour examiner la
stratégie donnant une priorité stricte au trafic voix par rapport au trafic data. Nous
étudions par la suite l’algorithme de priorité non pré-emptive (PQ pour Priority
Queuing). L’algorithme PQ est caractérisé par sa simplicité d’implémentation
pour la mise en œuvre de la différenciation de service.
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 89

Bande passante: 2 Mbps, ρv=0.36,ρd=0.36


100

90

80

70

60
CDF

50

40

30

20

φd=0.5
10 φd=0.25
φd=0.01
0
0 2 4 6 8 10 12 14
Délai [ms]

F IG . 4.11 – Fonction de répartition (CDF) du délai de donnée pour différents


poids

4.5 Différenciation de service par Priority Queuing


Dans ce cas, le modèle de l’UTRAN est le même que celui présenté dans
la figure 4.6. Nous remplaçons la discipline de service WRR par la discipline
PQ. Avec une priorité stricte mais non pré-emptive de la voix par rapport au
trafic data, les paquets IP voix sont toujours servis en premier puisqu’ils ont une
contrainte plus exigeante du délai. Les paquets IP data sont servis seulement
quand la file des paquets voix est vide. Nous notons que le facteur principal
influençant la gigue du trafic voix est l’incapacité d’interrompre le service d’un
paquet data qui a juste commencé son service au moment où le paquet voix arrive
dans la file. Pour minimiser cet effet, la taille des paquets data ne devrait pas être
très élevée comme nous l’avons déjà expliqué ; par exemple pour une capacité de
2 Mbps, un paquet de données de 1500 octets bloque le serveur pour une durée
de 6 ms, une valeur élevée compte tenu du au budget toléré par le trafic voix. La
différenciation de service utilisant PQ devrait également s’assurer que le trafic
data de basse priorité n’est pas trop pénalisé et recevra les ressources nécessaires
90 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

Bande passante : 2Mbps


100

90

80

70
CDF du délai total du trafic voix

60

50

40

30

20

Nv=50; Nd=10; φv=0.5


10 Nv=50; Nd=10; φv=0.75
Nv=70; Nd=5; φv=0.5
Nv=70; Nd=5; φv=0.75
0
1 2 3 4 5 6 7 8 9 10 11
Délai [ms]

F IG . 4.12 – Fonction de répartition (CDF) du délai total de la voix

pour son service. Dans ce cas, un dimensionnement approprié répondra à ces


besoins.

4.5.1 Analyse de Priority Queuing


Pour une vue générale des études analytiques examinant les priorités dans les
files d’attente, voir les références [82, 83]. Dans notre cas, il existe deux classes
de services. Nous étudions la file de haute priorité en absence de l’autre classe
et puis nous ajoutons la gigue qui représente l’effet de la présence du trafic data.
Pour le trafic data qui est de basse priorité, la file est étudiée comme un système
avec vacations où les périodes de vacations de ce système correspondent aux
période d’activité (Busy Period) dues au trafic de haute priorité.

4.5.2 Trafic de haute priorité


L’analyse du trafic voix a été déjà faite dans la section 3.3.4.1, nous calculons
donc le délai moyen de séjour des paquets voix pour une file alimentée par !"
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 91

canaux simultanément actifs et avec une capacité . Nous pouvons aussi exami-
ner le délai moyen total dans le système en ajoutant le délai de remplissage des
paquets ! , ce délai "#$ est calculé par l’équation (3.21) comme suit

" ! * , ! -./012
"#$%&'(
/ 32 * 4 /032 (4.15)
" 0 + , !
)
+
En raison de la présence du ) trafic data avec des paquets de taille égale à 5 ,
le délai moyen total 67$ du trafic voix dans le système est donné par +
5
61$%&8"#$ (4.16)
+
)
9
4.5.3 Trafic de basse priorité
Le trafic data est le même que dans le cas du WRR. Pour :;5 canaux simul-
tanément actifs, le processus d’arrivée des paquets IP data à la file de transmis-
sion est aussi modélisé par un processus de Poisson et la file d’attente elle-même
est considérée comme une file de type !.<=6><?@ avec vacations. Les vacations
correspondent aux périodes où le serveur est occupé par le trafic de haute prio-
rité. Soit A une variable aléatoire décrivant la durée des vacations. Les valeurs de
A sont ainsi les durées des périodes d’activité du serveur dues au trafic voix. En
normalisant l’axe de temps, pour les processus d’arrivée et de service, au temps
nécessaire pour servir un paquet IP de données de taille 5 à la capacité , la
formule de Pollaczek-Khinchin pour la file !.<=6B<C@ nous + permet de calculer le
délai moyen de séjour "D5 pour un paquet de données par

G IE5
H
"E5F& (4.17)
@%GJIE5 !

9
avec I#5 la charge du trafic de données.9 Le délai moyen de séjour pour une file
!.<=6><?@ avec vacations est déterminé par [20]
OPQ
L>MNA
635K&8"E5 Q (4.18)
L>MNA
Q OPQ
avec L>MNA et LRMSA respectivement les ) moments
9 du premier et deuxième ordre
de A et correspondent aux moments du premier et deuxième ordre des périodes
d’activité dues à la voix. Sachant que T , et UV/W2 , la probabilité stationnaire
!

d’avoir , paquets dans la file et le temps de service d’un paquet, respectivement,


sont donnés dans la section 3.3.4.1, les moments sont calculées par
92 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

(
!"#$ % & ' .- /012345 6 - (4.19)
)*+ ,
! !

et

(
7"8$ 9 % & ' .- /;12345 9 6 - < (4.20)
):+ ,
! !

4.5.4 Résultats numériques et validation empirique


Dans cette section, nous présentons la validation empirique de notre modèle.
Nous montrons des résultats en valeurs moyennes et quantiles. La plate-forme
d’émulation est la même utilisée dans le cas WRR mais en implémentant l’al-
gorithme PQ comme discipline de différenciation de service. Pour les résultats
de validation des modèles en valeurs moyennes, les tests sont faits dans les deux
cas, en générant un trafic Poissonnien et périodique.

4.5.4.1 Résultats en valeurs moyenne

Dans la figure 4.13, nous comparons le délai moyen =>?


pour le trafic priori-
taire, calculé analytiquement et obtenu empiriquement à partir des expérimentations
sur la plate-forme pour un nombre de canaux de voix simultanément actifs @A?
égale à 100 et en présence du trafic data. PQ assure la différenciation de service.
L’axe des abscisses montre différentes valeurs de la capacité du lien. CommeB
prévu,=C? diminue avec l’augmentation de la capacité du lien. On peut voir que
le délai empirique est moins important que l’analytique, ceci est expliqué par le
fait qu’analytiquement il y a une surestimation due principalement à la suppo-
sition que tous les paquets sont complètement remplis par des trames voix. En
plus, la gigue mesurée est plus petite que celle calculée analytiquement.
La figure 4.14 compare le délai moyen, analytique et empirique, pour =7D
FE D
le trafic data en fonction de la charge . Les trois ensembles de courbes corres-
EF?
pondent à trois valeurs différentes de , la charge du trafic voix : nulle, moyenne

EC&GEH? FE D J K
et forte. La bande passante est fixée à 2 Mbps. Les courbes sont tronquées aux
valeurs où la charge totale reste strictement moins de 1, c.-à-d., .
Nous notons que les courbes empiriques sont produites par un processus de Pois-
son pour l’arrivée des trames data.
I
Nous remarquons que le délai moyen =>Daugmente au fur et à mesure que
la charge augmente. Quand le trafic voix n’est pas présent, les résultats obtenus
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 93

Haute priorité pour la voix, Nv=100


11
Analytique
Empirique: Poisson
10 Empirique: Périodique

8
Délai moyen du tarfic voix [ms]

1
1.5 2 2.5 3 3.5 4 4.5 5 5.5 6
Bande passante en [Mbps]

F IG . 4.13 – Délai moyen pour la voix : analytique et empirique

analytiquement s’assortissent très étroitement avec ceux enregistrés empirique-


ment quand le processus d’arrivée des paquets data est Poissonnien. Quand la
charge du trafic de voix est moyenne ou forte, les courbes analytiques et empi-
riques diffèrent légèrement. C’est principalement dû au terme représentant les
vacations dans le modèle analytique.

Dans la figure 4.14, nous reproduisons les mêmes expérimentations que dans
le cas précédent. Les courbes sont cependant empiriques et correspondent à
deux différents processus de génération du trafic data : Poisson et périodique.
Le dernier représente mieux le système en réalité parce qu’il reproduit la nature
périodique des arrivées, chaque TTI, des trames. Les résultats prouvent que l’ap-
proximation par Poisson est acceptable. Nous notons que pour une faible charge
du trafic data, c.-à-d. un nombre faible de canaux DSCH, le trafic périodique
est moins sporadique que le trafic Poissonnien. Quand le nombre des canaux
augmente, le trafic périodique peut devenir plus sporadique suite à de possibles
synchronisations entre les sources.
94 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

Bande passante : 2Mbps, ρ=ρ +ρ


d v
7
a:ρv=0
e:ρv=0
a:ρ =0.36
v
6 e:ρv=0.36
a:ρ =0.625
v
e:ρv=0.625
5
Délai moyen du trafic data [ms]

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
ρ
d

F IG . 4.14 – Délai moyen pour le trafic data : analytique et empirique

4.5.4.2 Résultats en quantiles


Les figures 4.16 et 4.17 confirment les avantages de l’utilisation de la différenciation
de service avec PQ à travers les résultats par les quantiles. En effet, nous traçons
#$&'% ()&
dans ces figures le !" percentile de chacun des trois paramètres :
1. Délai total de la voix (désigné par délai total dans la figure), comprenant
le délai de remplissage, la délai de séjour dans la file de transmission et la
gigue due à la présence du trafic de données.
2. Délai de séjour dans la file de transmission avec la gigue en présence du
tarfic data, il est désigné par délai de trans dans la figure.
3. Délai du trafic data.
La figure 4.16 montre les résultats des délais mentionnés ci-dessus avec et
sans l’utilisation de PQ pour !" = 0,36 et une bande passante de capacité égale à
2 Mbps. L’axe des abscisses montre la charge totale #$%&" () . Nous observons
que sans différenciation de service, les délai de transmission de la voix et celui du
'
trafic data sont presque égales. Le délai total de la voix est donc plus grand due
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 95

Bande passante : 2Mbps, ρ=ρ +ρ


d v
7
periodic:ρ =0
v
poisson:ρ =0
v
periodic:ρv=0.36
6 poisson:ρv=0.36
periodic:ρ =0.625
v
poisson:ρ =0.625
v

5
Délai moyen du trafic data [ms]

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
ρd

F IG . 4.15 – Délai moyen pour le trafic data : Poisson et périodique

au remplissage et dépasse le budget du délai de la voix pour presque toutes les


valeurs de !" . En utilisant PQ, le délai total et et le délai de transmission observés
sont moins que la limite de 5 ms, au dépens d’un grand délai pour le trafic data,
pourtant au-dessous du budget du trafic data. Les mêmes observations peuvent
être faites pour la figure 4.17 où #$ =0,5. Cependant, dans ce cas la charge totale
qui peut être supportée est inférieure à celle du cas précédent. C’est dû au fait
que le trafic voix a la contrainte la plus critique. Ceci sera aussi le cas au fur et à
mesure que son pourcentage augmente dans la charge totale.
La figure 4.18 montre la fonction de répartition (CDF) du délai total de la
voix quand !$ =0,36 et pour différentes valeurs de %" . La différence entre les
courbes est la gigue due à la présence du trafic data. Dans l’abscense du trafic
data, nous notons que 98,15 & du trafic de voix ont un délai inférieur à 5 ms.
Quand !" =0,2 et 0,36 ce paramètre est environ 96,75 & et 95,53 & respective-
ment.
La figure 4.19 montre la fonction CDF du délai du trafic data avec %" =0,2 et
pour différentes valeurs de !$ . Nous notons que, lorsque la charge du trafic voix
96 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

Bande passante : 2Mbps, ρ =0.36, ρ =ρ−ρ


v d v
12
Voice: trans delay without PQ
Voice: trans delay with PQ
Voice: total delay without PQ
11 Voice: total delay with PQ
Data: without PQ
Data: low priority with PQ
10

9
Délai [ms] (95 percentile)

2
0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85
ρ

#$&'% ()&
F IG . 4.16 – !" percentile des délais voix et data avec et sans PQ

est faible ou moyenne, la borne sur le délai data est respectée. Pour les systèmes
fortement chargés par la voix, quand *+, =0,625 ou plus grand, nous observons
que 88 - du trafic data subie un délai inférieur à 10 ms.

4.5.5 Dimensionnement
Nous avons déjà montré analytiquement le dimensionnement de l’interface
Iub pour le transport séparé des trafics voix et data. En partageant la liaison de
sortie, notre étude permet la détermination de la capacité de la liaison à déployer.
Des paramètres d’entrées, notamment le pic de trafic au niveau du Node B, sont
nécessaires et sont généralement donnés par l’opérateur. Ce dernier, adoptant
une topologie du réseau d’accès, spécifie des contraintes de départ comme la
couverture, le trafic et la qualité de service. Ces données déterminent le dimen-
sionnement des RNCs et des Nodes B à déployer. Pour un nombre d’usager
de trafic de type . ainsi que leurs débits et le facteur d’activité pour le service
. , nous déterminons la capacité nécessaire à déployer. Comme nous venons de
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 97

Bande passante : 2Mbps, ρv=0.5, ρd=ρ−ρv


8
Voice: trans delay without PQ
Voice: trans delay with PQ
Voice: total delay without PQ
7.5 Voice: total delay with PQ
Data: without PQ
Data: low priority with PQ
7

6.5
Délai [ms] (95 percentile)

5.5

4.5

3.5

3
0.5 0.52 0.54 0.56 0.58 0.6 0.62 0.64 0.66 0.68 0.7
ρ

$# &'% ()&
F IG . 4.17 – !" percentile du délai de la voix et data avec et sans PQ

mentionner dans la section 3.5.4, les ressources radio sont les plus chères et un
dimensionnement approprié des liaisons filaires garantie le non gaspillage des
ressources radio. Pour satisfaire les fortes contraintes temporelles, un surdimen-
sionnement est nécessaire pour l’interface Iub.
Considérons un trafic de type * , *+,-./0 1 234 et un critère de qualité de service
défini comme étant la probabilité de dépassement du délai par n’importe quel
type de trafic, c.-à-d., 5 67# 89: # ;<=># , où : # est le délai maximal toléré pour le
!

trafic de type * dans l’UTRAN. Nous pouvons donc distinguer trois cas :
1. La présence du trafic voix seulement dans l’UTRAN. Dans ce cas, : ?@A 5ms.
Soit B C ? la charge maximale du trafic voix à écouler dans l’UTRAN en sa-
tisfaisant le critère de qualité de service.
2. La présence du trafic data seulement. Dans ce cas, : D7A 10ms. Soit B C D la
charge maximale du trafic data à écouler dans l’UTRAN dans ce cas.
3. La présence du trafic voix et du trafic data dans L’UTRAN. PQ est utilisé

!"
avec une priorité stricte pour la voix. Dans le cas le plus défavorable, le
délai du trafic voix est borné par ( : ?7E FG ms dû à la nature non pré- !
98 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN

Bande passante : 2Mbps, ρv=0.36


1

0.9

0.8

0.7

0.6
CDF

0.5

0.4

0.3

0.2 ρ =0
d
ρ = 0.2
d
ρ =0.36
d
0.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Délai [ms]

F IG . 4.18 – CDF du délai total pour le trafic voix

emptive de PQ. Soit " # la charge maximale du trafic voix correspondant à


!
ce budget de délai. Pour le trafic data, la borne sur le délai est ( $ %&' $ # ) et
soit " % la charge maximale du trafic data dans ce cas.
!

Pour un trafic global offert () *# ,% , un dimensionnement approprié


devrait satisfaire les contraintes suivantes :
+
– Pour ,%&) "#. , ./0
– Pour *#1) - "%. , ./0
– Pour ,% 2 - 2 , ,# /3 " # et ,%4/0 " % .
and *#
- - ! !
Pour l’interface Iur qui transporte le trafic entre deux RNCs lors du handover,
son dimensionnement résulte de la détermination du débit pic du trafic des usa-
gers en handover, qui n’est qu’une partie du trafic de l’interface Iub, en ajoutant
les surdébits des en-têtes. Le paramètre d’entrée dans ce cas est le pourcentage
d’usagers en handover.
CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN 99

Bande passante : 2Mbps, ρd=0.2, ρ=ρd+ρv


1

0.9

0.8

0.7

0.6
CDF

0.5

0.4

0.3

0.2

ρv=0.09
0.1 ρv=0.36
ρv=0.5
ρv=0.625
0
0 2 4 6 8 10 12 14 16 18
Délai [ms]

F IG . 4.19 – CDF du délai pour le trafic data

4.6 Conclusion
Dans ce chapitre, nous avons étudié analytiquement la différenciation de ser-
vice IP dans l’UTRAN entre le trafic temps réel et le trafic non temps réel exi-
geants des contraintes temporelles de transport. Nous avons évalué les perfor-
mances des ordonnanceurs WRR et PQ. Les études analytiques sont validées
sur une plate-forme émulant la différenciation de service dans l’UTRAN. Les
deux ordonnanceurs permettent de gérer les contentieux pour l’utilisation des
ressources avec un avantage pour la discipline PQ qui minimise plus la gigue et
est plus facile à implémenter. Le chapitre se termine par un dimensionnement
approprié dans l’UTRAN.
100 CHAPITRE 4. DIFFÉRENCIATION DE SERVICE DANS L’UTRAN
Chapitre 5

Implémentation : Architectures et
technologies

5.1 Introduction

L’AAL2/ATM a été défini comme protocole de transport pour la Release


99 de l’UMTS. Les premiers déploiements suivant cette Release sont basés sur
l’AAL2/ATM et les constructeurs des équipements commencent à proposer des
infrastructures pour un réseau UTRAN basé sur IP, parce que l’IP est le prochain
protocole de transport. Les nouvelles versions des normes 3GPP prennent en
considération l’interface Iub sur IP avec une possible configuration mixte pen-
dant la phase de migration. Dans ce chapitre, nous comparons analytiquement
le transport basé sur IP au transport basé sur l’AAL2/ATM. Nous nous focali-
sons sur la voix comme trafic temps reél et sur le trafic Web comme trafic non
temps réel. Pour le transport basé sur IP, nous reprenons les modèles analysés
dans les chapitres précédents et nous développons des modèles simples pour le
cas de l’AAL2/ATM. La comparaison des performances de deux technologies
est présentée en fonction du délai et de l’utilisation de la bande passante. Nous
terminons ce chapitre ainsi que les études de cette thèse par une investigation du
réseau dorsal de l’UTRAN basé sur l’IP où nous proposons différentes solutions
d’implémentation.
102 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

5.2 Transport du trafic voix


Dans cette section, nous comparons les performances du protocole IP à celles
de l’AAL2/ATM pour le transport du trafic voix AMR-12.2 Kbps. L’interface Iub
de l’UTRAN est, indépendament du protocole de transport, modélisé comme
dans la section 3.2.1 pour le transport basé sur IP. La figure 5.1 montre l’unité
de remplissage où les paquets IP et les cellules ATM sont remplis et une file de
transmission où ils sont en attente pour la transmission sur la liaison de sortie.

TTI

Unité de File d’attente


TTI Remplissage

! $#" $" Lien


de sortie

TTI
Multiplexeur

F IG . 5.1 – Schéma du système modélisant l’UTRAN

5.2.1 Processus d’arrivée du trafic voix


L’arrivée du trafic voix, provenant de %&'
canaux simulatnément actifs, est
aussi indépendant de la technologie de transport utilisée sur l’interface Iub. Donc,
il est aussi modélisé pour les deux cas par un processus de Poisson de débit
moyen ()* ./+,.0- 1
trames/ms, avec TTI= 20 ms pour le cas de la voix (voir section
3.3.1).

5.2.2 Etude par les valeurs moyennes


5.2.2.1 Analyse du multiplexeur basé sur IP

L’étude du transport de la voix dans des paquets IP a été faite dans la section
3.3. Nous rappellons les formules donnant les valeurs moyennes du délai et de
l’utilisation de la bande passante.
2
L’utilisation utile de la bande passante est calculée pour par, 345&6/7
2 81 9 * ;: <=> (5.1)
:;?=>@ABC=D
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 103

où est le nombre moyen de trames FP voix dans un paquet IP.


Le délai moyen ! "#$ dans le multiplexeur y compris la composante due au
remplissage % et celle due au séjour dans la file d’attente & est (Equation (3.21)),
)
"'$ & % +,- % ./01234
! ( * (5.2)
& 01234 +,- % 5601234
*
où 01274 est le valeur du temporisateur associé à l’unité de remplissage.

5.2.2.2 Analyse du multiplxeur AAL2/ATM

Dans cette section, nous considérons l’option où des cellules ATM sont rem-
plis par les trames voix dans l’unité de remplissage de la figure 3.3. La file de
transmission est inchangée, donc de taille infinie où les cellules attendent afin
d’être transmis. Le même modèle utilisé dans la cas de la techonologie IP peut
être utilisé pour l’étude du multiplexage dans le cas AAL2/ATM [24]. Mais
l’étude devrait être faite à l’échelle octet au lieu de l’échelle trame voix ; une
cellule ATM ne contient pas plusieurs trames FP voix complètes de 36 octets
mais des segments de ces trames voire une trame, d’où l’analyse au niveau octet.
Dans ce cas, l’état du processus décrivant le système correspond à un nombre
d’octets et le nombre d’état devient plus grand rendant le temps de calcul plus
long. Pour cela, nous proposons un modèle plus simple, permettant d’atteindre
les objectifs de notre étude.
Pour le trafic bas débit, typiquement la voix, la couche AAL2 est recom-
mandé par l’ITU-T, car elle permet le multiplexage des trames FP voix pro-
venant de plusieurs canaux dans des cellules ATM. La couche AAL2 se com-
pose d’une sous-couche Common Part Sublayer (CPS) qui permet aux trames
d’être assemblées et transmises dans un circuit virtuel(VC). Comme la taille
d’une trame FP voix est de 36 octets, plus qu’une trame sont nécessaire pour
remplir complètement la charge utile, de longueur 47 octets, d’une cellule ATM.
Quand la longueur de la seconde trame excède la longueur de la charge libre
restante dans la cellule, la trame est divisée en deux parties qui seront transmises
dans des cellules consécutives. Chaque partie de la trame aura un en-tête CPS
de 3 octets. Un octet est ajouté à la charge utile de 47 bytes comme étant un en-
tête pour former une unité de données CPS (CPS-PDU) qui constitue la charge
d’une cellule ATM (voir figure 5.2). Dans ce cas, les en-têtes sont donc : 5 octets
comme en-tête ATM, un octet comme en-tête CPS-PDU et 6 octets comme étant
2 en-têtes de multiplexage). L’utilisation utile de la bande passante est calculée
104 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

par
!" #$% &'( )*+,-./ (5.3)
()
00
00
500 octets
En−tête En−tête ATM
CPS
3 octets Packet
11
11
11

CPS−PDU
48 octets

F IG . 5.2 – Format d’une cellule ATM

Quand une cellule ATM est complètement remplie, elle est générée immédiatement
par l’unité de remplissage. Supposons que les cellules ATM sont formées par
deux (parties) trames voix au maximum, c.-à-d., nous négligeons le cas où trois
trames contribuent à la formation d’une cellule ATM. Dans ce cas, quand une
trame ou bien une partie d’une trame est présente dans l’unité de remplissage,
une cellule ATM est remplie et générée à l’instant où la prochaine trame voix
arrive et remplit la charge libre restante de la cellule. L’instant de génération
des cellules ATM est donc égale à l’instant d’arrivée de la prochaine trame. Par
conséquent, la génération des cellules ATM suit un modèle Markovien. L’ar-
rivée des cellules sortantes de l’unité de remplissage et entrantes dans la file de
transmission peut être modélisée ainsi par un processus de Poisson avec un débit
moyen 23" #$% &4567 2 :; 7<= . Dans ce cas, la file > ; ? ; modèle bien le mul-
/89 -
tiplexeur [79]. La capacité de la liaison de sortie est @ . En normalisant l’axe de
temps, pour l’arrivée et le service, au temps de service d’une cellule ATM, la
charge du système, dénotée par A<" #$% , est donc égale au débit d’arrivée du trafic.
Dans ce cas, le délai moyen de séjour dans la file de transmission est donné par
[81] :

AC" #$%
BCD6E.FGHI& /8+
CA " #$%
(5.4)
5
/ -J+
Nous examinons maintenant le délai de remplissage des cellules ATM ; d’après
notre modèle, le délai de remplissage est égale au temps d’inter-arrivée de deux
trames FP consécutives qui n’est autre que 5 ; 2 KL M . Pour des grandes valeurs
-
de N , ce terme devient très petit et le délai de remplissage sera inférieur à la
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 105

valeur du temporisateur. Un temporisateur de 2 ms ou 1 ms n’a pas d’effet sur le


trafic d’entrée dans le cas d’un système fortement chargé ; son effet commence à
apparaı̂tre quand le nombre des canaux est plus petit que 10 et 20 respectivement,
c.-à-d., le délai de remplissage est plus grand que 2 ms ou 1 ms respectivement.
Ce résultat est aussi confirmé par les simulations faites dans [31] pour le trans-
port AAL2/ATM.
Comme dans le cas de IP, le délai moyen !" #$%
dans le multiplexeur y com-
pris la composante due au remplissage et celle due au séjour dans la file d’attente
est donné par,
' 32 32 5
!" $# % & )( * +,-./ 1
0 si 4 6789:
()* +,-./ 0 76 89: si 3 2 ;<6=8>: (5.5)

5.2.3 Etude par les quantiles


5.2.3.1 Analyse du multiplexeur basé sur IP

Dans ce cas, le modèle de transport a été aussi présenté dans la section 3.3.4.2
où la file de transmission est étudiée par le modèle ?@A B C B D
. Nous rappellons
la formule qui détermine la probablité que le délai de séjour dépasse un délai (
E
cible sachant que le temporisateur possède une valeur égale à : 6=8>:
#$\]^
FGHI(J;KHLE M 6=89: & N" OPQ,RS2TOUVWXLRYZ[O X_` Eabcd
!
(5.6)

où e est le taux de service des paquets et f est la racine comprise entre 0 et 1 de
l’équation (3.23).

5.2.3.2 Analyse du multiplexeur basé sur AAL2/ATM

De même, nous reprenons le modèle utilisé dans la section 5.2.2.2, mais pour
conserver les mêmes hypothèses que dans le cas IP, le processus de service est
egh
iQ 2 j
distribué suivant la loi exponentielle avec un taux , avec le temps de service
8
d’une cellule ATM par un serveur de capcité . Le modèle de la file est donc
M/M/1. Nous calculons la probablité de dépassement du délai cible , avec E 6=89:
la valeur du temporisateur, par :

FkHl(J;mHLE M 6=89: #
& " PO QWjnRS2TOPopjqXLRYZ[O #$\]^ X ` Erbcd (5.7)
106 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

5.2.4 Résultats numériques


Dans cette section, nous examinons numériquement le système étudié. Nous
considérons plusieurs cas en changeant les valeurs de et !"#$% . La capacité de
la liaison de sortie est de 2 Mbps.
La figure 5.3 montre le délai moyen de séjour dans le multiplexeur en fonc-
tion du nombre de canaux simultanément actifs pour l’IP et l’AAL2/ATM en
considérant les cas : =6 and TCU=2ms ; =8 and TCU=2, 2.5ms ; =10 and
TCU=2.5, 3ms. Nous notons que le délai dans le cas de l’AAL2/ATM est inférieur
à celui rencontré dans le cas de l’IP en raison de la petite taille des cellules ATM ;
en fait, AAL2/ATM a été conçu pour transporter le trafic bas débit sensible au
délai comme la voix compressée. Dans le cas de l’AAL2/ATM, le temporisatuer
n’a pas un impact fort sur l’étude, à l’exception des cas de faibles valeurs du
nombre des canaux. Pour l’IP, la taille du paquet est plus grande que celle des
cellules ATM, par conséquent le délai est plus large. Mais l’IP reste une solution
viable surtout dans un système fortement chargé.
Bande pasante: 2 Mbps
7
ATM
IP:n=10,TCU=3ms
IP:n=10,TCU=2.5ms
IP:n=8,TCU=2.5ms
IP:n=8,TCU=2ms
6
IP:n=6,TCU=2ms

5
Délai moyen [ms]

0
0 20 40 60 80 100 120
Nombre des canaux DCH actifs

F IG . 5.3 – Comparaison entre l’IP et l’ATM en terme du délai moyen

Les résultats, en terme du délai, obtenus de l’analyse des quantiles rejoingnent


CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 107

ceux de l’analyse par valeur moyenne. Dans la figure 5.4, nous montrons la pro-
babilité de dépassement du délai cible
! " #$%&' ms, ()*+,-. ! " #$%/' 01 2 ,
en fonction du nombre des canaux simultanément actifs. Nous remarquons aussi
l’avantage de l’AAL2/ATM par rapport à l’IP dans un système avec une charge
faible ou moyenne. Dans un système fortement chargé le dépassement du délai
cible devient plus probable pour l’AAL2/ATM que pour l’IP rendant l’IP plus
efficace. Ceci est dû au fait qu’au fur et à mesure que le nombre des canaux
augmente, le surdébit des en-têtes est plus important pour l’AAL2/ATM que
pour l’IP. Par conséquent, dans ce cas la charge totale du système pour le cas de
l’AAL2/ATM est plus grande que celle pour le cas de l’IP, d’où ce dépassement.

Bande passante : 2 Mbps


0
10

−1
10

−2
10

−3
10
P(S>(5−TCU)ms)

−4
10

−5
10

−6
10

ATM,TCU=1ms
−7 ATM,TCU=2ms
10 IP:n=10,TCU=3ms
IP:n=10,TCU=2.5ms
IP:n=8,TCU=2.5ms
IP:n=8,TCU=2ms
IP:n=6,TCU=2ms
−8
10
0 20 40 60 80 100 120
Nombre de canaux DCH actifs

F IG . 5.4 – Comparaison entre l’IP et l’ATM en terme de la probabilité de viola-


tion du délai cible

La figure 5.5 montre l’utilisation utile de la bande passante pour l’IP et


l’AAL2/ATM. Nous remarquons qu’au fur et à mesure que le nombre des ca-
naux augmente, l’IP s’avère être la meilleure option, en terme d’utilisation de
la bande passante, pour le transport dans l’UTRAN. L’utilisation utile augmente
avec l’augmentation de 3 et de #$%/' .
108 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

Bande passante: 2 Mbps


0.95

0.9

0.85
Utilisation utile

0.8

0.75

0.7

ATM
0.65 IP:n=10,TCU=3ms
IP:n=10,TCU=2.5ms
IP:n=8,TCU=2.5ms
IP:n=8,TCU=2ms
IP:n=6,TCU=2ms
0.6
0 20 40 60 80 100 120
Nombre des canaux DCH actifs

F IG . 5.5 – Comparaison entre l’IP et l’ATM en terme de l’utilisation utile de la


bande passante

5.3 Transport du trafic data


Nous examinons dans cette section le cas typique pour le trafic data, celui du
trafic Web sur la voie descendante. Le canal de transport sur l’interface radio est
le canal partagé DSCH à 64 kbps. Au niveau de la couche FP, le trafic transporté
par ce canal se compose d’une succession de périodes d’activité et de silence.
Dans une période d’activité, une trame de taille 320 octets est produite chaque
TTI = 40 ms et elle sera encapsulée dans une trame FP en ajoutant un en-tête de
5 octets.

5.3.1 Processus d’arrivée du trafic


Comme pour le cas de la voix, le processus d’arrivée des trames FP data
provenant de plusieurs canaux !" simultanément actifs peut être modélisé par
un processus de Poisson de taux #$&'( % trames/ms.
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 109

5.3.2 Analyse du transport basé sur IP


L’étude dans ce cas est similaire à celle de la section 4.2.3 et nous trouvons
le délai moyen de séjour dans le système, , par!"#$%&
'"#$(&!) / *+, -.-." " (5.8)
* 01,
où -." est la charge du système.

5.3.3 Analyse du transport basé sur ATM


Dans le cas de l’AAL2/ATM, une trame FP data de 325 octets devrait être
segmentée afin de remplir des cellules ATM. En comptant les en-têtes CPS (un

6 ) 9
octet), CPS-PDU (3 octets) et ATM (5 octets), l’utilisation utile de la bande pas-
sante est donc
232 ,45 2 7 8 : ;37
. La division de 325 octets par la charge utile par
cellule qui est 44 octets, montre que l’arrivée d’une trame implique l’arrivée d’un
bloc de 8 cellules ATM. Notre système est alors considéré comme un système

< 6 >= ? 6 0
avec des arrivées en bloc et nous le modélisons par un système de file d’attente
de type , dans lequel chaque cellule ATM doit passer par 8 étapes de
service pour accomplir son service total. Une étape de service correspond au
-@"
< 6ABC6 0
service d’une cellule ATM. est également la charge du système. Nous appli-
quons la formule de Pollaczek-Khinchin obtenue pour la file d’attente
dans [81] à la file de type < 6 >= ? 6 0
et nous trouvons le délai moyen de séjour
dans le système
D"#E FGH ) I0 J+/ , KL-.-."" (5.9)
0MJ 10 ,
5.3.4 Résultats numériques
Pour le trafic data, la figure 5.6 montre le délai moyen pour les cas de trasport
IP et AAL2/ATM en fonction du nombre des canaux DSCH simultanément ac-
tifs. Nous remarquons qu’avec l’augmentation de la charge le délai augmente
plus rapidement dans le cas de l’ATM que dans le cas de l’IP. Cette observation
demeure même quand le temps de service d’un paquet IP data est supposé dis-
tribué suivant la loi exponetielle comme le montre la courbe dans le cas de la file
M/M/1 pour IP. L’explication de cette observation est que les en-têtes sont plus
significatifs dans le cas de l’ATM introduisant une charge supplémentaire. Ceci
est clairement illustré dans la figure 5.7 où nous montrons le nombre de canaux
DSCH correspondant à la charge supportée par le système dans chaque cas. Nous
110 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

notons que pour un système légèrement chargé, le nombre de canaux DSCH est
approximativement semblable. Au fur et à mesure que le système devient chargé,
le nombre des canaux DSCH augmente avec un avantage pour l’IP par rapport
à l’AAL2/ATM à charge égale. En d’autres termes, l’IP apporte une utilisation
plus efficace de la bande passante.

Bande passante : 2Mbps


30
IP: M/D/1
IP: M/M/1
ATM

25

20
Délai moyen de séjour [ms]

15

10

0
0 5 10 15 20 25 30
Nombre de canaux DSCH actifs

F IG . 5.6 – Comparaison entre l’IP et l’AAL2/ATM en terme du délai moyen

5.4 Solutions possibles


Nous avons comparé le transport des trafics voix et data dans l’UTRAN basé
sur l’IP et sur l’AAL2/ATM. L’IP offre la solution la plus efficace pour le trans-
port du trafic data. Pour le trafic voix, l’AAL2/ATM assure un délai inférieur à
celui rencontré par l’IP. Pourtant l’IP remplit mieux les besoins en terme de délai
et de l’utilisation utile de la bande passante particulièrement pour les systèmes
fortement chargés.
La technologie de transport implémentée lors des premiers déploiements a
été basé sur l’AAL2/ATM et avec l’introduction de l’IP, la couche du réseau
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 111

Bande passante: 2Mbps


30
IP
ATM

25
Nombre de canaux DSCH actifs

20

15

10

0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Charge

F IG . 5.7 – Nombre de canaux DSCH en fonction de la charge correspondante

de transport dans l’UTRAN peut devenir hétérogène, basée sur l’AAL2/ATM


et sur l’IP. En fait, le principe d’independance entre la couche du réseau ra-
dio et la couche du réseau de transport garantie la possibilité d’interconnexion
des éléments de l’UTRAN sans se soucier du protocole de transport dans la
couche du réseau de transport. Par exemple, pour un RNC connecté à deux
réseaux de transport de technologies différentes l’un IP et l’autre AAL2/ATM,
l’implémentation d’une pile protocolaire hétérogène comme celle montrée dans
la figure 5.8 est possible. Cette solution est simple et performante pour la phase
migration de l’ATM vers l’IP. Une autre solution est proposée dans [1] pour
connecter un RNC avec une pile protocolaire basée sur IP et un autre avec une
pile basée sur ATM, par l’utilisation d’une unité d’interconnexion (IWU Inter-
Working Unit) au niveau de la couche TNL. L’unité d’interconnexion est logi-
quement présente entre le RNC-IP et le RNC-ATM, mais peut être placée phy-
siquement dans n’importe quel nœud entre les RNCs. Cette solution par l’unité
d’interconnexion nécessite une configuration particulière et introduit un délai
suplémentaire pour le trafic, ce qui fait qu’une pile hétérogène est préférable.
112 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

RLC

MAC RNL
TNL
FP

UDP/IP AAL2

Liaison de données ATM

Physique Physique

F IG . 5.8 – Pile protocolaire pour un RNC connecté aux réseaux IP et ATM

Nous pouvons constater qu’en se basant sur les études de performances des
technologies IP et ATM, l’IP est nettement plus performant dans un réseau d’accès
ou le trafic data est majoritaire dans le trafic global. L’IP s’impose dans l’UTRAN
avec la croissance de l’utilisation de l’Internet mobile par l’UMTS offrant l’ac-
cessibilité aux services à tout moment en tout lieu. En ce qui concerne le trafic
temps réel, les efforts de l’IETF pour enrichir le protocole IP afin d’y introduire
la qualité de service favorise la migration de l’UTRAN vers l’IP à moyen et à
long termes. A ces facteurs et comme nous venons de le dire dans le premier cha-
pitre, s’ajoute le fait que les opérateurs seront toujours intéressés par une solution
efficace au niveau technique mais aussi au niveau économique. Les études sur les
coûts des technologies montrent que l’IP est moins cher vue son indépendance
de la couche de liaison des données qui peut être de l’Ethernet où l’optique.

5.5 Approches de qualité de service dans l’UTRAN


basé sur IP
Les phases futures de l’UTRAN consistent à en faire un réseau de transport
basé sur IP, mais la vitesse ainsi que la décision des opérateurs de faire de nou-
veaux déploiements basé sur IP ou bien de migrer leur réseau de transport de
l’ATM vers l’IP sont affectés aussi par des facteurs économiques et techniques.
Dans cette section, nous nous intéressons aux solutions possibles d’intercon-
nexion pour assurer la qualité de service requise dans l’UTRAN basé sur IP. Le
protocole IP, qui n’offre aucune qualité de service, sera enrichi par d’autres so-
lutions et protocoles developpés par l’IETF qui peut être utilisé afin d’améliorer
au mieux ses capacités à satisfaire les besoins de transport dans l’UTRAN. L’in-
dependance de l’IP de la couche de liaison (couche 2) est un avantage qui laisse
aux opérateurx le choix d’utiliser à ce niveau des technologies efficaces et pas
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 113

chères. En plus, les travaux menés par l’IETF concernant la qualité de service
et la gestion efficace de la bande passante font de l’IP une solution attractive
dans l’UTRAN. Pour une vue d’ensemble de ces travaux concernant l’Inter-
net, voir [96, 97]. Nous détaillons dans notre travail les schémas exploitables
dans notre contexte d’étude. Nous examinons en particulier l’architecture de
différenciation de service [98] (DiffServ pour Differentiated service) ainsi que
celle de la commutation multiprotocole avec étiquetage des flux (MPLS pour
Multi-Protocol Label Switching) [100] pour le réseau dorsal de l’UTRAN. Ces
solutions bénéficient de progrès fait dans les réseau IP en général ainsi que dans
le réseau cœur de l’UMTS tout-IP, en particulier.

5.5.1 Architecture des services différenciés dans l’UTRAN


5.5.1.1 Le modèle DiffServ

Pour mieux comprendre le concept de DiffServ, nous rappellons que la première


approche de la qualité de service dans l’Internet envisagée par l’IETF était fondée
sur l’intégration de services (IntServ pour Integrated Services). Dans une telle ar-
chitecture, l’objectif est de garantir un taux de perte et un délai d’acheminement
observés par un flux individuel, tout en contrôlant la distribution des ressources
entre les flux (voir [99] pour plus de détails). La philosophie de ce modèle re-
pose sur la réservation de ressources sur tous les routeurs traversés et pour chaque
flux. D’où des difficultés d’implémentation et des limitations de déploiement à
grande échelle qui se sont présentées au niveau du déploiement. Pour échapper
à cette problématique de passage à l’échelle, le groupe de travail DiffServ in-
troduit la notion de l’agrégation des flots en quelques classes offrant des ser-
vices spécifiques par agrégat (per Aggregate). Dans ce modèle il n’y a pas de
réservation de ressources à travers les nœuds, tel que IntServ, mais un traitement
différencié, appelé PHB (Per Hop Behavior) qui est basé sur la priorité par classe
pour répondre à la qualité de service demandée. Pour un réseau multi-services,
deux services, autre que le traditionnel service best effort, sont définis : Ache-
minement Expédié (Expedited Forwarding) et Acheminement Assuré (Assured
Forwarding).
L’architecture générique pour un domaine DiffServ fait la distinction entre
le système qui constitue le cœur du réseau ou routeurs internes du domaine, et
les nœuds réalisant l’accès ou routeurs périphériques du domaine. Les fonctions
principales des routeurs constituant le cœur consistent à acheminer les paquets
aussi vite que possible selon la priorité de la classe du paquet, cette priorité est
114 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

traduite par l’étiquette du champ DSCP (DiffServ Code Point) de l’en-tête IP. En
IPv4, le DSCP se substitue à l’ancien champ TOS (Type Of Service) et en IPv6
il se situe au champ TS (Traffic Class) de l’en-tête. Les routeurs périphériques
se chargent des fonctions d’agrégation, de classification, de conditionnement, de
contrôle d’intégrité et d’admission des paquets dans le réseau. Dans l’UTRAN,
les Nodes B sont connectés aussi aux routeurs périphériques du domaine Diff-
Serv et le RNC est connecté au routeur périphérique ou aussi assure la fonction
d’un routeur périphérique.

5.5.1.2 Réseau dorsal DiffServ de l’UTRAN

Comme nous venons de voir précédemment, le traitement différencié des


paquets IP dans un domaine DiffServ est une mise en œuvre de la qualité de ser-
vice au niveau de la couche IP donc couche 3. Ce schéma est aussi compatible
avec le mode non orienté connexion de l’IP et ne nécessite aucune signalisa-
tion suplémentaire au niveau de la couche IP. Les informations nécessaires de
la qualité de service sont transmises dans les messages spécifiques de l’UMTS.
Dans l’UTRAN, le RNC définit la différentiation de service en se basant sur les
contraintes relatives et strictes de la qualité de service des supports d’accès ra-
dio (RAB), selon les informations concernant la couche du réseau radio (RNL).
Le RNC peut aussi intégrer un routeur périphérique (voir figure 5.9). Dans ce
cas sur la voie descendante, il assure les mécanismes d’un routeur périphérique
tels que la classification des paquets IP dans des classes de service par l’attri-
bution de l’étiquette DSCP en tenant compte de la nature du trafic, du condi-
tionnement du trafic ainsi que l’ordonnancement adequat pour respecter les be-
soins des différents types de trafic. Sur le dernier kilomètre connectant le Node
B au routeur périphérique, une priorité stricte du trafic temps réel par rapport
au trafic non temps réel est recommandé comme nous l’avons conclu dans le
chapitre précédent. La correspondance entre les classes de qualité de service de
l’UMTS et les services différenciés IP est configurable par l’opérateur. Comme
le service EF est spécifié pour un trafic caractérisé par un délai court, une faible
gigue et sans perte de paquets, le trafic temps réel exige un tel service comme la
classe conversationnelle. La classe à flux continu (Streaming) peut aussi utiliser
ce service. La commutation assurée (AF) offre différents degrés d’assurance de
commutation. Quatres classes AF indépendantes sont définis avec, pour chaque
classe, trois niveaux de priorité de rejet. Le degré d’assurance de l’acheminement
dépend principalement de la bande passante allouée à la classe et de la charge
de cette classe ainsi que du niveau de priorité à la perte. Ayant des contraintes
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 115

de qualité de service moins critiques que le trafic conversationnel, le trafic à flux


continu peut être aussi transporté dans une classe AF satisfaisant ses besoins.
Pour le trafic non temps réel, une classe AF est capable de répondre aux besoins
de son transport dans l’UTRAN avec une garantie plus stricte pour la classe de
trafic interactif que celle de la classe de trafic d’arrière-plan.
Ces propositions de correspondance entre les classes UMTS et les classes
DiffServ ne sont pas normalisées. L’opérateur a la possibilté de transporter tout
le trafic UTRAN, y compris temps réel et non temps réel, dans la classe EF du
réseau dorsal (voir figure 5.10). La différenciation dans ce cas est nécessaire
au niveau du dernier kilomètre avec une priorité stricte pour le trafic temps
réel par rapport au trafic non temps réel. En fait, les décisions retenues par les
opérateurs seront influencées par l’expérience de ce dernier à utiliser les services
différenciés IP dans le réseau cœur de l’UMTS.

F IG . 5.9 – DiffServ dans l’UTRAN

En ce qui concerne le dernier kilomètre, les types de multiplexage cités dans


la section 2.10 peuvent assurer une utilisation efficace de la bande passante. Nous
recommandons le muliplexage de bout en bout entre le Node B et le RNC et au
niveau de la couche 3 qui présente des avantages pour les opérateurs utilisant des
réseaux DiffServ externes. Dans ce cas, sur la voie montante les trames FP voix
sont rassemblées dans des paquets IP au niveau des Nodes B où l’étiquette de
la classe EF est marquée dans le champ DSCP. Le trafic provenant de plusieurs
Nodes B est agrégé à l’entrée du domaine DiffServ dans le routeur périphérique
et transporté dans la classe EF. Idem pour la voie descendente où les trames voix
116 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

F IG . 5.10 – Transport du trafic UTRAN dans le réseau dorsal dans la classe EF

ayant le même Node B comme destination sont rassemblées dans un paquet IP


au niveau RNC et transportées dans la classe EF. Cette solution est aussi très
efficace pour le transport du trafic data sur les voies montante et descendante ;
les trames FP data ou les segments des trames sont encapsulées dans des paquets
IP marqués par l’étiquette de la classe (EF ou AF) retenue par l’opérateur, au
niveau Node B et RNC et seront transportés dans le réseau DiffServ.
Dans le cas où le multiplexage est assuré sur le dernier kilomètre seulement,
le routeur périphérique côté Node B devra supporter des fonctions de multi-
plexage et de démultiplexage. Dans ce cas, si le protocole PPP est présent entre
le Node B et le routeur périphérique, il favorise à ce stade un multiplexage par
le protocole PPPmux (voir section 3.2). Sur la voie montante, les paquets IP se-
ront décapsulés des trames PPP, et l’en-tête UDP/IP sera décompressé pour per-
mettre l’acheminement dans le domaine DiffServ. Le routeur périphérique assure
la compression des en-têtes UDP/IP et le multiplexage sur la voie descendente.
Bien entendu, cette solution est plus acceptable si le domaine Diffserv n’est pas
externe et fait partie du réseau de l’opérateur, car elle nécessite l’ajout de cer-
taines fonctions dans le routeur périphérique. Dans le routeur périphérique, une
autre session de multiplexage peut être envisagée vers le RNC, ce qui donne un
transport avec deux sessions de multiplexage. Les trames FP d’un même type
de trafic provenants de plusieurs Nodes B et décapsulées des trames PPP dans
le routeur périphérique peuvent être multiplexées dans des paquets IP qui se-
ront transportés dans la classe Diffserv correspondante. Sur la voie descendante
les trames de même type de trafic et destinées à des Nodes B connectés à un
même routeur périphérique sont muliplexées dans des paquets IP et le routeur
périphérique assure la déconcentration du trafic. La deuxième session de multi-
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 117

plexage apporte une efficacité à l’utilisation de la bande passante dans le domaine


DiffServ mais ajoute une complexité dans le routeur périphérique qui devra trai-
ter les trames.

5.5.2 Architecture MPLS dans l’UTRAN


5.5.2.1 MPLS

Autre que DiffServ, la commutation multiprotocole avec étiquetage des flux


est proposée dans l’UTRAN comme étant une technique complémentaire à IP.
L’architecture MPLS consiste à ajouter à la qualité de service IP des mécanismes
au niveau inférieur (c’est-à-dire au niveau de la couche 2, 2/3) et elle est compa-
tible avec DiffServ. Au plan conceptuel, MPLS est une technologie de routage
intermédiaire entre la couche liaison de données (couche 2) et la couche réseau
(couche 3). Elle associe la puissance de la commutation de l’une à la flexibi-
lité du routage de l’autre avec une possibilité de créer des circuits virtuels dans
les réseaux IP. Une étiquette courte, de longueur fixe, correspondant à un bref
résumé de l’en-tête IP, est attribuée à chaque flux de données. Transportée ou
encapsulée dans l’en-tête de niveau couche 2 du paquet, elle fournit des infor-
mations sur le chemin, dit chemin commuté étiqueté (LSP pour Label Switched
Path), que le paquet doit parcourir, afin qu’il puisse être commuté ou routé plus
rapidement sur des réseaux utilisant différents types de protocoles. Le chemin
LSP peut être vu comme un tunnel. Les nœuds qui participent aux mécanismes
du protocole MPLS peuvent aussi être séparés en routeur périphérique (LER,
pour Label Edge Routers) et routeur à commutation d’étiquettes (LSR pour Label
Switching Routers). Une classe de service dans MPLS est appelé classe de trans-
fert (FEC Forward Equivalence Class) et elle est la représentation d’un groupe
de paquet qui ont en commun les mêmes besoins quant à leur transport. Tous
les paquets d’un tel groupe reçoivent le même traitement au cours de leur ache-
minement. Le routeur périphérique MPLS que le paquet rencontre appose une
étiquette qui traduit la classe de service et donc le chemin LSP dans lequel le
paquet sera acheminé.

5.5.2.2 Avantages de MPLS dans l’UTRAN

Les avantages de MPLS dans les réseau IP sont résumés par une simplifi-
cation de reliage, une flexiblité d’application des règles de l’ingénierie de tra-
fic ainsi que le support de la qualité de service et le mode orienté connexion.
118 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

Un domaine MPLS traite les trames MPLS mais aussi les paquets IP. MPLS
offre aussi la possibilité du multiplexage statistique en agrégeant les chemins et
ceci indépendament de la technologie de transport. De plus elle donne la pos-
sibilité d’utiliser n’importe quel type de réseau de transport allant du simple
réseau local (LAN pour Local Area Network) comme les réseaux Ethernet aux
réseaux étendus (WAN pour Wide Area Network) comme les réseaux ATM et
les réseaux optiques (SDH pour Synchronous Digital Hierarchy). En plus des
raisons avancées précédemment, le dernier point rend MPLS très attractif pour
les solutions de transport dans l’UTRAN, tel que IP sur ATM, permettant la
migration vers IP et l’utilisation des infrastructures ATM déjà déployées dans
l’UTRAN. MPLS a un rôle promoteur à jouer dans ce contexte et ceci au fur
et à mesure que MPLS sera utilisée dans différentes technologies de couche 2
que l’on trouve traditionnellement dans les réseaux d’accès (Ethernet, Gigabit
Ethernet, etc.). De plus elle permet de créer des réseaux virtuels privés entres les
Nodes B et les RNCs correspondants.

5.5.2.3 Shémas de transport MPLS

En utilisant le multiplexage de bout en bout au niveau de la couche 3 entre


le Node B et le RNC où un chemin LSP est établi, la compression de l’en-tête
UDP/IP peut être utilisé pour maximiser l’utilisation de la bande passante. L’en-
tête compressé servira dans ce cas comme l’étiquette du chemin LSP. Utilisée
avec DiffServ et ce même mode de multiplexage, MPLS apporte des avantages
certains à la qualité de service assuré par le réseau. L’étiquette DSCP de pa-
quet IP peut être transporté dans l’information d’en-tête MPLS et permet donc
la fourniture de la qualité de service en séléctionnant les chemins qui garan-
tissent les exigences requises par les classes DiffServ. Le multiplexage dans le
réseau dorsal de l’UTRAN peut être achevé par l’agrégation des LSPs comme le
multiplexage VC/VP de l’ATM. La différenciation de service entre les différents
types de trafic peut être aussi assurée avec l’architecture MPLS. Dans [48], un
schéma de transport basé sur MPLS est simulé pour établir et gérér les chemins
LSP entre les Nodes B et le RNC. L’établissement du chemin LSP se fait sui-
vant des attributs comme la bande passante, la priorité, etc. Deux approches sont
discutées. La première consiste à utiliser un seul chemin LSP pour connecter
chaque Node B au RNC et transporter tous les types de trafic. A l’entrée du do-
maine MPLS, un routeur MPLS marque le paquet par l’étiquette de la classe de
trafic. Un traitement différencié basé sur le marquage est alors mis en œuvre.
L’ordonnanceur WFQ est utilisé pour différencier entre les classes de trafic. La
CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES 119

deuxième approche utilise plusieurs LSPs pour connecter chaque Node B au


RNC. Chaque LSP transporte une classe de trafic, donc la différenciation de ser-
vice à l’intérieur d’un LSP n’est pas nécessaire. Les résultats des simulations
montrent que la deuxième approche est plus avantageuse que la première.

5.5.2.4 Transport par des tunnels

Dans le cas où des connexions sont établies au niveau de la couche 2 offrant
une qualité de service de bout en bout entre le Node B et le RNC, le multi-
plexage par le protocole PPPmux de bout en bout est plus pratique en utilisant
des tunnels. Le protocole pour tunnel de couche 2 (L2TP pour Layer Two Tun-
neling Protocol) [101] peut être utilisé dans le réseau dorsal (voir figure 5.11).
Le protocole L2TP est une extension du protocole PPP. Il est utilisé pour des
connexions virtuelle privées (VPN pour Virtual Private Networking), créant des
liaisons point à point entre deux points distants. Ces liaisons émulent un réseau
de données privé sur l’internet public ou sur des réseaux IP privés ce qui répond
aux besoins des opérateurs d’assurer la sécurité du transport dans l’UTRAN. Les
fournisseurs de service VPN tentent d’offrir plus que le service d’accès à dis-
tance et au fur et à mesure qu’ils prennent en charge la garantie de la qualité de
service, ils peuvent vendre leurs services aux opérateurs UMTS. Dans l’UTRAN,
un tunnel par type du trafic peut être établi entre le Node B et le RNC. Ce mode
de transport bénéficie de l’expérience des fournisseurs de services Internet et de
services de réseau dans ce domaine.

F IG . 5.11 – Tranport du trafic UTRAN dans des tunnels


120 CHAPITRE 5. IMPLÉMENTATION : ARCHITECTURES ET TECHNOLOGIES

5.6 Conclusion
Dans ce chapitre, nous avons présenté une comparaison entre les perfor-
mances de la technologie AAL2/ATM et celles de la technologie IP pour le trans-
port dans l’UTRAN. L’AAL2/ATM répond mieux aux besoins du trafic voix car
la couche AAL2 a été conçu pour cet objectif. Par contre l’utilisation de la bande
passante est plus efficace par le transport basé sur IP. Pour le transport du trafic
data, l’IP est nettement plus performant en terme de délai et est plus économique
en terme de l’utilisation de la bande passante.
Dans une deuxième partie, nous avons examiné le réseau dorsal de l’UTRAN
basé sur IP à travers les architectures de qualité de service qui peuvent être uti-
lisées. Le multiplexage de bout en bout entre le Node B et le RNC au niveau de
la couche 3 est compatible avec l’architecture DiffServ dans le réseau dorsal de
l’UTRAN. La qualité de service peut être renforcée par l’utilisation des chemins
à ingénierie de trafic MPLS. Enfin, le multiplexage au niveau de la couche 2 est
très efficace pour un transport basé sur des tunnels.
Chapitre 6

Conclusion et perspectives

Le transport du trafic usager dans le réseau d’accès radio terrestre de l’UMTS


est une mission temps réel, et ce quel que soit le type du trafic usager transporté,
qui peut être lui-même temps réel ou non temps réel. Ces délais de transport
très faibles entre les éléments de l’UTRAN sont nécessaires pour l’application
des fonctions radio avancées permettant d’obtenir de meilleures performances
sur l’interface air. Dans la Release 99 des normes 3GPP concernant l’UTRAN,
le réseau de transport est basé sur l’AAL2/ATM. L’évolution du réseau vers
un système tout-IP est pronée dans les nouvelles versions des spécifications du
3GPP et les travaux de conception de ce réseau d’accès sont en cours. Avec l’IP
comme technologie de transport, l’opérateur demande des solutions de transport
exploitant l’omniprésence de l’IP avec des capacités multiservices et intégrant
la qualité de service. Un autre défi à surmonter, c’est l’utilisation efficace de
l’étroite bande passante des derniers kilomètres entre les Nodes B et le réseau de
transport IP, tout en respectant les contraintes temporelles du transport.

6.1 Contributions de la thèse


Nous avons étudié les performances de l’IP comme protocole de transport du
trafic usager dans l’UTRAN.
Tout d’abord pour le cas de la voix, nous avons examiné le multiplexage des
petites trames FP dans des paquets IP pour assurer une utilisation efficace de la
bande passante. Nous avons modélisé les piles de protocoles fondées sur IP pour
le multiplexage de trafic temps-réel tel que la voix et nous avons présenté ana-
lytiquement et empiriquement l’évaluation des performances de l’IP, en termes
de délai et d’efficacité d’utilisation de la bande passante, pour le transport de
122 CHAPITRE 6. CONCLUSION ET PERSPECTIVES

ce trafic dans l’UTRAN. Nous avons également analysé les aspects liés au pa-
ramétrage du multiplexage ; Nous proposons un temporisateur inférireur ou égal
à 2 ms et un paquet IP qui contient moins de 10 trames FP (6 à 8). La valida-
tion empirique réalisée sur une plate-forme émulant les fonctionnalités de trans-
port dans l’UTRAN a confirmé ces conclusions. Nos travaux analytiques sur
l’évaluation de performances du multiplexage, y compris remplissage et trans-
mission, peuvent être utilisés pour étudier ce même phénomène dans des contextes
différents de l’UTRAN, par exemple, le remplissage des trames optiques par des
paquets IP à l’entrée des réseaux optiques.
Ensuite, nous avons étudié le transport du trafic non temps réel qui nécessite
lui aussi un transport temps réel. Dans ce cas, la segmentation des trames de
grandes tailles est adoptée afin d’empêcher les gros paquets data de retarder
beaucoup les paquets temps réel. Puis nous avons examiné la différenciation de
service entre les flux voix et data au niveau de la couche IP en implémentant
les techniques d’ordonnancement comme WRR et PQ. Bien que les deux disci-
plines sont capables d’assurer la fonction requise, nos résultats montrent que la
discipline de service PQ est plus efficace parce qu’elle est simple à implémenter
et répond mieux aux exigeances du trafic temps réel sans trop dégrader la qualité
de service requise par le trafic non temps-réel. Ces schémas de différenciation
ont été analysé analytiquement et validé empiriquement sur notre plate-forme de
UTRAN. Pour répondre aux contraintes temporelles strictes de transport, nous
avons proposé un dimensionnement approprié des interfaces de l’UTRAN.
Dans un troisième temps, nous avons effectué une comparaison analytique
entre les performances des protocoles de transport dans l’UTRAN, IP et AAL2/ATM.
Nos résultats analytiques confirment que l’AAL2/ATM répond mieux aux be-
soins du trafic voix ce qui est prévisible car la couche AAL2 a été conçu pour cet
objectif. Les cellules ATM sont de taille plus petite que celle des paquets IP, d’où
un délai plus petit. Par contre l’utilisation de la bande passante est plus efficace
pour le transport basé sur IP. Nous notons aussi que dans un système fortement
chargé, la solution IP est plus attractive. En ce qui concerne le transport du trafic
data tel que le trafic Web, l’IP est nettement plus performant en terme du délai
et plus économique en terme de l’utilisation de la bande passante parce que les
entêtes AAL2/ATM génèrent une charge supplémentaire importante.
Comme l’IP seul n’assure pas la garantie de la qualité de service, nous avons
examiné le réseau dorsal de transport en analysant les possibles architectures à
implémenter dans l’UTRAN. L’implémentation des services différenciés suivant
les travaux de l’IETF portant sur l’architecture DiffServ est compatible avec la
CHAPITRE 6. CONCLUSION ET PERSPECTIVES 123

nature non orienté connexion de l’IP et plus pratique avec un multiplexage de


bout en bout entre les Nodes B et les RNCs. Sur le dernier kilomètre, nous re-
commandons une priorité stricte du trafic temps réel sur le trafic non temps réel.
D’autre part, l’utilisation des chemins à ingénierie de traffic MPLS est aussi en-
visageable dans le réseau dorsal de l’UTRAN pour renforcer la garantie de la
qualité de service.

6.2 Perspectives
Nos travaux sur le réseau d’accès UMTS basé sur l’IP débouchent sur de
nombreuses perspectives.
Nous avons étudié analytiquement le transport dans l’UTRAN et nous avons
mis en œuvre une plate-forme émulant ce transport. Les fonctionnalités de trans-
port de l’UTRAN ont été implémentées au niveau de la couche FP. Il serait
intéressant d’y intégrer l’interface radio par l’ajout d’un Node B recevant différents
types du trafic provenant de plusieurs terminaux mobiles. Dans ce cas de figure,
les expérimentations prennent en considération l’impact de l’interface radio et
nous permettent d’étendre notre savoir-faire en matière de tests de validation in-
dispensables au déploiement.
Nos travaux examinent la différenciation de service entre le trafic voix et
data sur le lien terrestre de l’UTRAN dans de bonnes conditions radio et sans
prendre en considération qu’une prioritisation entre ces deux types du trafic peut
être implémentée au niveau de la couche MAC de l’interface radio. Cette couche
joue un rôle central dans la garantie de la qualité de service sur le lien radio. Une
étude examinant cette couche et son impact sur l’ingénierie du trafic à ce stade
est nécessaire.
L’UTRAN basé sur IP s’inscrit dans le cadre de la convergence de l’IP et des
réseaux mobiles. La meilleure exploitation de l’IP dans des réseaux mobiles de
différents techniques d’accès (UMTS, WLAN, etc.) passe par l’assurance d’une
interconnexion entre ces réseaux répondant aux besoins du trafic usager. Ceci est
promis dans les systèmes de la quatrième génération. Par exemple, les techniques
permettant le passage d’un réseau sans fil (WiFi) à un réseau UMTS et inverse-
ment ne sont pas achevées. Elles devront être en mesure d’offrir la continuité
d’un service sans interruption à l’usager qui retrouve toutes ses caractéristiques
propres et personnelles sans avoir à les redéclarer systématiquement. La gestion
de la mobilité ainsi que les apects liés à la correspondance de la qualité de service
entres ces technologies sont des objectifs à atteindre.
124 CHAPITRE 6. CONCLUSION ET PERSPECTIVES
Bibliographie

[1] 3GPP TR 25.933 V5.4.0 (2003-12), 3rd Generation Partnership Project ;


Technical Specification Group Radio Access Network ; IP Transport in
UTRAN (Release 5).
[2] Mobile Wireless Internet Forum, IP in the RAN as a Transport Option in 3rd
Generation Mobile Systems, Technical Report MTR-006, Release v2.0.0,
Ratified June 18, 2001.
[3] 3GPP TS 25.430, Technical Specification Group Radio Access Network ;
UTRAN Iub Interface : General Aspects and Principles (Release 1999).
[4] 3GPP TS 25.427, Technical Specification Group Radio Access Network ;
UTRAN Iub/Iur Interface User Plane Protocol for DCH Data Streams (Re-
lease 1999).
[5] 3GPP TS 25.435, Technical Specification Group Radio Access Network ;
UTRAN Iub Interface User Plane Protocols for Common Transport Channel
Data Streams (Release 1999).
[6] 3GPP TS 23.107, Technical Specification Group Radio Access Network ;
QoS Concept and Architecture (Release 5).
[7] 3GPP TS 25.401, Technical Specification Group Radio Access Network ;
UTRAN Overall Description (Release 99).
[8] 3GPP TS 25.402, Technical Specification Group Radio Access Network ;
Synchronisation in UTRAN Stage 2 (Release 6).
[9] 3GPP TS 25.431, Technical Specification Group Radio Access Network ;
UTRAN Iub interface layer 1 (Release 6).
[10] 3GPP TS 26.071 V3.0.1(1999-08), Technical Specification Group Services
and System Aspects ; Mandatory Speech Codec speech processing functions
AMR Speech Codec ; General Description.
126 BIBLIOGRAPHIE

[11] 3GPP TS 26.101 V4.2.0 (2002-03), Technical Specification Group Services


and System Aspects ; Mandatory Speech Codec speech processing func-
tions ; AMR Speech Codec Frame Structure (Release 4).
[12] Mobile Wireless Internet Forum, OpenRAN Architecture in 3rd Genera-
tion Mobile Systems, Technical Report MTR-007, Release v1.0.0, Septem-
ber 2001.
[13] 3GPP TR 25.853 V3.0.0 (2000-12), Technical Specification Group Radio
Access Network ; Delay Budget within the Access Stratum (Release 1999).
[14] 3GPP TR 25.934 V4.0.0 (2001-03), Technical Specification Group Radio
Access Network ; QoS optimization for AAL type 2 connections over Iub
and Iur interfaces (Release 4).
[15] Harri Holma, Antti Toskala, WCDMA For UMTS, second edition, Jhon
Wiley and Sons, 2002.
[16] E. Dahlman et al., WCDMA-the radio interface for future mobile multime-
dia communications, IEEE Transactions on Vehicular Technology, Volume :
47 , Issue : 4 , Nov. 1998, Pages :1105 - 1118.
[17] K. Tachikawa, W-CDMA mobile communications system, Wiley and Ma-
ruzen, 2002.
[18] A. J. Huber, J. F. Huber, UMTS and Mobile Computing, Artech House,
2002.
[19] Tomi Ahonen and Joe Barrett, Services for UMTS creating killer applica-
tions in 3G, Jhon Wiley and Sons, 2002.
[20] D. Bertsekas, R. Gallager, Data Networks, second edition, Prentice-Hall,
1992.
[21] G. Pujolle, Les réseaux, Eyrolles, 2000.
[22] J. Sanchez, M. Thioune, UMTS , deuxième édition revue et augmentée,
Hermès Science, 2004.
[23] S. Tabbane, Ingénierie des réseaux cellulaires, Hermès Science, 2002.
[24] H. Saito, Performance Evaluation and Dimensioning for AAL2 CLAD,
IEEE INFOCOM’99, New-York, 1999.
[25] H. Saito, Bandwidth Management for AAL2 Traffic, IEEE Trans. on Vehi-
cular Technology, Vol. 49, No. 4, July 2000.
[26] H. Saito, Performance Evaluation of AAL2 voice multiplexer, Elseiver
Science Performance Evaluation 42 (2000), 57-83.
BIBLIOGRAPHIE 127

[27] A-F. Canton, S.Tohmé, D. Zeghlache, T. Chahed, Statistical Analysis of


Weighted Round Robin Service Differentiation at AAL2 layer in UMTS Ra-
dio Access Network, IEEE GLOBECOM, 2002.
[28] A-F. Canton, S.Tohmé, D. Zeghlache, T. Chahed, Performance analysis of
ATM/AAL2 in UMTS Radio Access Network, in press, IEEE PIMRC 2002,
Lisbonne, 2002.
[29] A-F. Canton, Modélisation et analyse des performances de l’UTRAN : Uni-
versal Terrestrial Radio Access Network, Thèse de doctorat de l’ENST, Pa-
ris, Novembre 2002.
[30] S. Nananukul et al., Some issues in performance and design of the
ATM/AAL2 transport in the UTRAN, IEEE WCNC, 2000.
[31] R. Makké, S. Tohmé, J-Y. Cochennec, S. Pautonnier , Performance of
the AAL2 Protocol within the UTRAN, Universal Multiservice Networks,
ECUMN 2002.
[32] R. Makké, Qualité de Service et Performances des protocoles de transport
dans l’UTRAN, Thèse de doctorat de l’ENST, Paris, Juillet 2003.
[33] O. Isnard, J-M. Calmel, A-L. Beylot, G. Pujolle, Handling Traffic Classes at
AAL2/ATM layer over the logical Interfaces of the UMTS Terrestrial Radio
Access Network, IEEE PIMRC 2000.
[34] A. B. Garcia et al., Simulation of Quality of Service Mechanisms in the
UMTS Terrestrial Radio Access Network, IEEE Conference on Mobile and
Wireless Communications Networks, Stockholm, September 2002.
[35] A. B. Garcia et al., A Simulation Tool for Dimensioning and Performance
Evaluation of the UMTS Terrestrial Radio Access Network, Joint Internatio-
nal Workshop on Interactive Distributed Multimedia Systems / Protocols for
Multimedia Systems IDMS/PROMS, Portugal, November 2002.
[36] S. Nananukul, S. Kekki, Simulation Studies of bandwidth Management for
the ATM/AAL2 Transport in the UTRAN. IEEE VTC, 2002.
[37] E.K. Gonen et al., Simulation analysis of impact of AAL2 multiplexing
efficiency on ATM bandwidth overbooking in UTRAN, 4th International
Workshop on Mobile and Wireless Communications Network, 2002.
[38] B. Karlander et al., AAL2 switching in the WCDMA radio access network,
published in Ericsson Review no. 03, 2002.
[39] W. Brunnbauer, G. Cichon, Bringing two worlds together : AAL2 over IP
for Radio Access Networks, IEEE GLOBECOM, 2001.
128 BIBLIOGRAPHIE

[40] J. W. Chong et al., QoS-Based AAL2/ATM Multiplexing Schemes in the


UTRAN Iub Interface, IEEE PIMRC 2003, Beijing.
[41] M. Degermark, B. Nordgren, S. Pink, IP Header Compression, IETF RFC
2507, February 1999.
[42] M. Engan et al., IP Header Compression over PPP, IETF RFC 2509, Fe-
bruary 1999.
[43] R. Pazhyannur, I. Ali, and C. Fox. PPP Multiplexing, IETF RFC 3153,
August 2001.
[44] R. S. Pazhyannur, I. Ali, and I. N. Vukovie, PPPmux-A New Protocol for
transporting Small IP Packets, IEEE International Conference on Communi-
cations ICC, 2001.
[45] K. Sklower et al., The PPP Multilink Protocol (MP), IETF RFC 1990, Au-
gust 1996.
[46] C. Bormann, The Multi-Class Extension to Multi-Link PPP, IETF RFC
2686, September 1999.
[47] C. Metz, A Pointed Look at the Point-to-Point Protocol, IEEE Internet
Computing, July-August 1999.
[48] Y. Guo et al., IP transport in 3G Radio Access Networks : an MPLS-based
Approach, IEEE WCNC, 2002.
[49] A. Samhat, T. Chahed, Performance Evaluation of IP in the UMTS Terres-
trial Radio Access Network, 18th International Teletraffic Congress (ITC),
Berlin, September 2003.
[50] A. Samhat, T. Chahed, G. Hébuterne,Transport in UMTS Radio Access
Network : IP versus AAL2/ATM, 8th International Conference on Cellular
and Intelligent Communications (CIC), Seoul, October 2003.
[51] A. Samhat, T. Chahed, IntServ sur DiffServ : Etude du rapport micro-flux/
agrégat, GRES’2003, Fortaleza, February 2003.
[52] A. Samhat, T. Chahed, G. Hébuterne, Weighted Round Robin Service Dif-
ferentiation in IP-based UTRAN, IP-Based Cellular Networks Conference
(IPCN) Paris, December 2003.
[53] A. Samhat, T. Chahed, Performance de l’IP dans le réseau d’accès UMTS
(UTRAN), Colloque Francophone sur l’Ingénierie des Protocoles (CFIP),
Paris, Octobre 2003.
BIBLIOGRAPHIE 129

[54] A. Samhat, T. Chahed, A comparison of IP to AAL2/ATM Transport in the


UTRAN : Mean Value Analysis, IEEE Third International Conference on
Networking ICN’04, Guadeloupe, March 2004.
[55] A. Samhat, T. Chahed, Modeling and Analysis of Transport of Voice and
Data in the UMTS Radio Access Network : IP versus AAL2/ATM, IEEE
WCNC, Atlanta, 2004.
[56] A. Samhat, T. Chahed, Service Differentiation Between Voice and Data
Traffic in the IP-based Radio Access Network, IEEE VTC Spring, Milan
2004.
[57] A. Samhat, T. Chahed, Transport in IP-based UMTS Radio Access Net-
work : Analytical Study and Empirical Validation, IEEE ICC, Paris, June
2004.
[58] A. Samhat, T. Chahed, G. Hébuterne, Priority Queuing for IP-based Service
Differentiation in the UMTS Radio Access Network, IFIP Networking 2004,
Athens.
[59] A. Samhat, T. Chahed, La différentiation de service basée sur la mesure,
GRES’2001 : Marrakech , Décembre 2001.
[60] S-E. Elayoubi, T. Chahed, M. Tlais and A. Samhat, Measurement-based
Admission Control in UMTS, to appear in Annals of Telecommunications.
[61] S-E. Elayoubi, T. Chahed and G. Hébuterne, Connection Admission
Control in UMTS in the Presence of Shared Channels, Computer Communi-
cations, Volume 27, issue 11, 1 June 2004.
[62] M. Chuah, Q. Zhang, O. Yue, Access priority schemes in UMTS MAC,
IEEE WCNC, September 1999.
[63] X. Hua et al., Performance analysis on the radio link control protocol of
UMTS system, IEEE VTC, September 2002.
[64] Z. Qinqing, S. Hsuan-Jung, Performance of UMTS radio link control, IEEE
ICC, April-May 2002.
[65] K. Ahmavaara et al., Interworking Architecture Between 3GPP and WLAN
Systems, IEEE Communications Magazine, November 2003.
[66] S. Malomsoky et al., Connection admission control in UMTS radio access
networks, Computer Communications, January 2003.
[67] J. Yang, I. Kriaras, Migration to all-IP based UMTS networks, International
Conference on 3G Mobile Communication Technologies, 2000.
130 BIBLIOGRAPHIE

[68] G. Clark, Y.K. Ling, Transport solutions for 3G cellular radio access net-
work, International Conference on 3G Mobile Communication Technolo-
gies, 2002.
[69] G. Toth, C. Antal, Comparaison of link-layer segmentation methods for
UMTS terrestrial radio access networks, Elsevier Computer Networks 44,
2004.
[70] G. Matefi et al., Towards Efficient Call Admission Control in IP UTRAN, in
Proc. 18th International Teletraffic Congress (ITC), Berlin, September 2003.
[71] K. Venken et al., Designing a DiffServ - Capable IP- Backbone for the
UTRAN, 3G Mobile Communication Technologies, March 2001.
[72] S. heiter et al., IP based services at the UMTS radio interface, Third Inter-
national Conference on 3G Mobile Communication Technologies, 2002.
[73] K. Venken et al., Enabling network redundancy in the Radio Access Net-
work, International Conference on 3G Mobile Communication Technolo-
gies, May 2002.
[74] M. Bauer et al., Evolution of the UTRAN Architecture, International
Conference on 3G Mobile Communication Technologies, June 2003.
[75] K. Venken et al., Analysis of the Evolution to an IP-Based UMTS Ter-
restrial Radio Access Network, IEEE Communications Magazine, October
2003.
[76] M. Menth, Carrying Wireless Traffic over IP Using Realtime Transport Pro-
tocol Multiplexing, 12th ITC Spec. Seminar (Lillehammer, Norway), pp.13
- 25, March 2000.
[77] G. Heijenk et al., DiffServ Resource Management in IP-based Radio Ac-
cess Networks, International Symposium on Wireless Personal Multimedia
Communications (WPMC’01), September 2001.
[78] T. Chahed, End-to-End Internet QoS : Mapping of QoS Between IP and
ATM, Integrated Services ans Differentiated Services, PhD thesis, UVSQ,
July 2000.
[79] J. Roberts, U. Mocci, J. Virtamo, Broadband Network teletraffic, Springer,
1996 .
[80] W.J. Stewart, Introduction to the Numerical Solution of Markov Chains,
Princeton University Press, 1994.
[81] L. Kleinrock, Queueing Systems, Volume I : Theory, John Wiley and Sons,
1975.
BIBLIOGRAPHIE 131

[82] H. Takagi, Queueing analysis : a foundation of performance evaluation.


Vol. 1 : vacation and priority systems : part 1, Amsterdam : North-Holland,
1991.
[83] O. Osterbo, IP-multiplexing for low capacity links ?, R&D Report 35/2001
Telenor, November 2001.
[84] B. Karlander et al., AAL2 switching in the WCDMA radio access network,
published in Ericsson Review no. 03, 2002.
[85] MPLS Forum, Voice over MPLS Bearer Transport Implementation Agree-
ment MPLS Forum 1.0, MPLS Forum Technical Committee, July, 2000 .
[86] S. Pedro et al., End-to-End Differentiation of IP traffic Aggregates using
Priority Queuing Models, Workshop on High Performance Switching and
Routing (HPSR 2002), JAPAN.
[87] A. Capone, M. Cesana, G. D’Onofrio and L. Fratta, Mixed Traffic in UMTS
Downlink, IEEE Microwave and Wireless Components Letters, Vol. 13, No.
8, August 2003.
[88] F. Borgonovo, A. Capone, M. Cesana, L. Fratta, Delay-throughput perfor-
mance of packet service in UMTS, IEEE VTC 2001 Fall, October 2001.
[89] H. Khedher, F. Valois, S. Tabbane, Traffic characterization for mobile net-
works, IEEE VTC 2002-Fall, September 2002.
[90] A. Klemm, C. Lindemann, M. Lohmann, Traffic modeling and characteri-
zation for UMTS networks, IEEE GLOBECOM, 2001.
[91] T. J. Kwon et al., Peformance Comparison of RAN-CN Protocol stacks in
IMT-2000 Networks, IEEE VTC, 2000.
[92] V. Vassiliou et al., A radio access network for next generation wireless net-
works based on multi-protocol label switching and hierarchical Mobile IP,
IEEE VTC, 2002.
[93] S. Leroy et al., End-to-end UMTS quality of service architecture for the
support of real-time IP multimedia services in UMTS R5, International
Conference on 3G Mobile Communication Technologies, 2002.
[94] C. Qian et al., Study of QoS in UTRAN, IEEE Canadian Conference on
Electrical and Computer Engineering 2002, p. 1605-1609.
[95] A. Szlovencsak et al., Planning Reliable UMTS Terrestrial Radio Access
Networks, IEEE Communications Magazine, January 2003.
[96] X. Xiao et al., Internet QoS : A Big Picture, IEEE Network Magazine,
March 1999.
132 BIBLIOGRAPHIE

[97] X. Xiao et al., A Practical Approach for Providing QoS in the Internet
Backbone, IEEE Communications Magazine, Dec. 2002.
[98] S.Black, D.Black, M.Carlson, E.Davies, Z.Wang, W.Weiss, An Architec-
ture for Differentiated Service, RFC 2475, December 1998.
[99] S. Shenker et al., General Characterization Parameters for Integrated Ser-
vice Network Elements, RFC 2215, September 1997.
[100] F. Le Faucheur et al., Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services, RFC 3270, May 2002.
[101] W. Townsley et al., Layer Two Tunneling Protocol L2TP, RFC 2661, Au-
gust 1999.
[102] Y. Ito, S. Tasaka, Y. Ishibashi, Variably weighted round robin queueing
for core IP routers, IEEE International Performance, Computing, and Com-
munications Conference, 2002.
[103] G. Liebl, T. Stockhammer, R. Strasser, Priority-based multiplexing of IP-
streams onto shared cellular links, IEEE VTC Spring, 2002.
[104] M. Fine, F. Tobagi, Packet Voice on a Local Area Network with Round
Robin Service, IEEE Transactions on Communications, Volume : 34 Issue :
9, Pages : 906 -915, September 1986.
[105] H.M. Chaskar, U. Madhow, Fair scheduling with tunable latency : a round
robin approach, IEEE GLOBECOM, 1999.
[106] N. Pekergin, Stochastic bounds on delays of fair queueing algorithms,
IEEE INFOCOM ’99, Eighteenth Annual Joint Conference of the IEEE
Computer and Communications Societies, 1999.
[107] H. Shimonishi, M. Yoshida, F. Ruixue, H. Suzuki, An improvement of
weighted round robin cell scheduling in ATM networks, IEEE GLOBE-
COM, 1997.
[108] W. Richard Stevens, UNIX Network Programming : Volume I, Second
Edition, Prentice Hall, N.J., 1998.
[109] Home page of ALTQ project http ://www.csl.sony.co.jp/ kjc/ projects.html
[110] L. Rizzo, Dummynet : a simple approach to the evaluation of network pro-
tocols, ACM Computer Communication Review, Volume 27, January 1997.
[111] V. Jacobson, C. Leres, and S. McCanne, tcpdump, Available from
ftp ://ftp.ee.lbl.gov/.

Vous aimerez peut-être aussi