Académique Documents
Professionnel Documents
Culture Documents
Spécialité
Informatique
présentée par
Abed Ellatif SAMHAT
Mots clés : UMTS, UTRAN basé sur IP, transport temps réel, multiplexage,
différenciation de service.
.
Absract
1 Introduction 15
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . . 17
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
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.
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
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
Iu Réseaux
Uu UTRAN CN externes
UE Iub CS
Node B
MSC/VLR GMSC
RNC RNIS
RTCP
...
Node B
Node B
PS
Internet
Node B
RNC SGSN GGSN
(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
Iu
Iur
SRNC DRNC
Iub
Uu
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.
Couche du
réseau radio Plan de contrôle Plan usager
TNL
Signalling Bearer(s) Signalling Bearer(s) Data Bearer(s)
Couche physique
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].
Couche 3
RRC
PDCP
BMC
RLC Couche 2
Canaux
logiques
MAC
Canaux de
transport
PHY Couche 1
Canaux physiques
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)
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
Uu Iub
RLC RLC Couche du
MAC MAC réseau radio
FP FP RNL
UE Node B RNC
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
TE MT UTRAN CN Iu CN TE
Egde node Gateway
End−to−End Service
CN Bearer
RAB Service Service
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.
performance parce que le budget du délai est majoritairement consommé sur les
liaisons à bas débit.
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.
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.
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.
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.
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
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.
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
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.
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
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
TTI
! "#$" Lien
de sortie
TTI
Multiplexeur
%&'
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.
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
$'&1(
! 0 (3.1)
"#567B9C&D(E*F;G2H4 au début d’une 2H4 , un paquet IP est généré avec les trames FP
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
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
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.
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
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
.//
// 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^ +
.. .. .
.. .
.. ..
. . .
,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)
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 !*$ )
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"
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
#
!" ! %# " #& $%& ' # "() & *
"
(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).
Génération du Unité de
Trafic Voix remplissage
Trames FP (Temporisateur)
N canaux
Génération des
PC1 paquets IP
Capacité de
2 Mbps
PC2 PCr
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.
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 à !"#"#"$% . !"!#$
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
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
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
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
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
−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
15
10
0
0 10 20 30 40 50 60 70 80 90 100 110
Nombre de canaux simultanément actifs
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 ! !
1
0 10 20 30 40 50 60 70 80 90 100 110
Nombre de canaux simultanément actifs
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.
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
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
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]
4.1 Introduction
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.
&
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)
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: ' .
−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
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 !
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.
!
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]
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]
−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
−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]
Poisson.
Trames FP data
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.
"! #$%&'
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
; ;
(4.10)
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
3QR C)N'OC
descendante. Elle permet de déterminer le nombre moyen de paquets voix dans
la file en remplaçant par .
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
)78.$ C D8
,F0GCH8 ! (4.13)
Génération du
trafic voix Unité de Génération des
Trames FP remplissage paquets IP voix
Génération du
trafic donnée Unité de
Trames FP remplissage PC3
Génération des
paquets IP donnée
PC2 PCr
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]
é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.
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
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]
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
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]
90
80
70
CDF du délai total du trafic voix
60
50
40
30
20
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
!
(
!"#$ % & ' .- /012345 6 - (4.19)
)*+ ,
! !
et
(
7"8$ 9 % & ' .- /;12345 9 6 - < (4.20)
):+ ,
! !
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
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]
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
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
ρ
d
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
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
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
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]
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]
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
TTI
TTI
Multiplexeur
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
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
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
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).
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
Délai moyen [ms]
0
0 20 40 60 80 100 120
Nombre des canaux DCH actifs
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.
−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
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
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.
25
20
Délai moyen de séjour [ms]
15
10
0
0 5 10 15 20 25 30
Nombre de canaux DSCH actifs
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
RLC
MAC RNL
TNL
FP
UDP/IP AAL2
Physique Physique
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.
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.
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.
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.
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.
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
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
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
[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
[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/.