UNIVERSIT DE BORDEAUX I

COLE DOCTORALE DE MATHMATIQUES ET

DINFORMATIQUE

THSE
Pour obtenir le grade de
DOCTEUR DE L'UNIVERSIT DE BORDEAUX
Discipline: INFORMATIQUE

Prsente et soutenue publiquement par

Alaeddine Abdallah
Le : 09/12/2010

TITRE
Mcanismes Cross-Layer pour le streaming vido dans les
rseaux WIMAX
Cross-Layer Mechanisms for video streaming in WIMAX
Networks
JURY
Toufik Ahmed

Institut Polytechnique de Bordeaux

Co-Directeur de thse

Francine Krief

Institut Polytechnique de Bordeaux

Co-Directeur de thse

Djamal Meddour

Senior Expert, France Telecom

Responsable Industriel

Andr-Luc Beylot

ENSEEIHT Toulouse

Rapporteur

Tijani Chahed

Telecom Paris Sud

Rapporteur

Sidi-Mohamed Senouci

ISAT, Universit de Bourgogne

Prsident de jury

ii

iii

Abstract

iv

Abstract

Abstract
Driven by the increasing demand for multimedia services in broadband Internet
networks, WIMAX technology has emerged as a competitive alternative to the wired
broadband access solutions. The IEEE 802.16 is a solution that provides high throughput
by ensuring a satisfactory QoS. In particular, it is suitable for multimedia applications that
have strict QoS constraints. However, the users heterogeneity and diversity in terms of
bandwidth, radio conditions and available resources, pose new deployment
challenges. Indeed, multimedia applications need to interact with their environment to
inform the access network about their QoS requirements and dynamically adapt to
changing network conditions.
In this context, we propose two solutions for video streaming over 802.16 networks
based on Cross-Layer approach. We are interested in both unicast and multicast
transmissions in uplink and downlink of one or more WIMAX cells.
First, we proposed an architecture that enables Cross-Layer adaptation and
optimization of video streaming based on available resources. We defined the entity CLO
(Cross-Layer Optimizer) that takes benefits from service flow management messages,
exchanged between BS and SS, at the MAC level, to determine the necessary adaptations /
adjustment to ensure optimal delivery of the application. Adaptations occur at two epochs,
during the admission of the video stream and during the streaming phase. The
performance analysis, performed through simulations, shows the effectiveness of the CLO
to adapt in a dynamic way, the video data rate depending on network conditions, and thus
guarantee an optimal QoS.
Second, we proposed a solution that enables IP multicast video delivery in WIMAX
network. This solution allows finding the compromise between the diversity of end-user
requirements, in terms of radio conditions, modulation schemes and available resources,
along with the SVC hierarchy video format, to offer the best video quality even for users
with low radio conditions. Indeed, we define a multicast architecture that allows each user
to get a video quality proportionally to its radio conditions and its available
bandwidth. Towards this end, several IP multicast groups are created depending on the
SVC video layers. Subsequently, our solution allows optimizing the use of radio resources
by exploiting the different modulations that can be selected by the end-users.

Key words: Cross-Layer adaptation, Quality of Service, IEEE 802.16 Wireless Networks,
video adaptation, SVC hierarchical video coding, multicast, adaptive modulation.

Abstract

vi

Rsum

Rsum
Pouss par la demande croissante de services multimdia dans les rseaux Internet
haut dbit, la technologie WIMAX a merg comme une alternative comptitive la
solution filaire daccs haut dbit. LIEEE 802.16 constitue une solution qui offre des
dbits levs en assurant une qualit de service (QoS) satisfaisante. En particulier, elle est
adapte aux applications multimdia qui ont des contraintes de QoS satisfaire. Cependant,
avec la prsence dutilisateurs htrognes qui ont des caractristiques diverses en termes
de bande passante, de conditions radio et de ressources disponibles, de nouveaux dfis
poss doivent tre rsolus. En effet, les applications multimdia doivent interagir avec leur
environnement pour informer le rseau daccs de leurs besoins en QoS et sadapter
dynamiquement aux variations des conditions du rseau.
Dans ce contexte, nous proposons deux solutions pour la transmission des flux vido
sur les rseaux 802.16 sur la base de lapproche Cross-layer. Nous nous intressons la fois
la transmission unicast et multicast sur le lien montant et descendant dune ou plusieurs
cellules WIMAX.
Premirement, nous proposons une architecture Cross-Layer qui permet ladaptation
et loptimisation du streaming vido en fonction des ressources disponibles. Nous avons
dfini une entit CLO (Cross-Layer Optimizer) qui exploite des messages de gestion des
flux de service, changs entre BS et SS, au niveau MAC, pour dterminer ladaptation
ncessaire et optimale afin dassurer le bon fonctionnement de lapplication. Les
adaptations se produisent en deux temps, lors de l'admission du flux et au cours de la
session de streaming. Lanalyse des performances, par simulations, de notre solution
montre lefficacit du CLO adapter, dune faon dynamique, le dbit vido en fonction
des conditions du rseau afin dassurer une QoS optimale.
Deuximement, nous proposons une solution de streaming multicast des flux vido
dans les rseaux WIMAX. Cette solution permet de trouver un compromis entre la
diversit des clients, en termes de conditions radio, de schmas de modulation et de
ressources disponibles, ainsi que le format de codage vido hirarchique SVC, pour offrir la
meilleure qualit vido y compris pour les clients ayant de faibles conditions radio. En effet,
cette solution permet chaque utilisateur dobtenir une qualit vido proportionnellement
ses conditions radio et sa bande passante disponible. Pour atteindre cet objectif, plusieurs
groupes multicast sont forms par couches vido SVC. Cette solution permet doptimiser
davantage les ressources radio et ainsi daugmenter la capacit globale du systme.

Mot cls: Adaptation Cross-Layer, qualit de service, rseaux sans fil 802.16, adaptation
vido, codage vido hirarchique SVC, multicast, modulation.
vii

Rsum

viii

Ddicace

Ddicace

mes chres et tendres parents Mabrouk et Mahbouba,

Votre soutien, votre amour et vos prires sont le secret de ma
russite, que Dieu vous garde pour moi et vous prte une
longue vie pleine de sant et de prosprit.

ma sur Asma et mes frres Seifeddine et Mouhamed,

merci de mavoir soutenu tout au long de cette aventure, que
Dieu vous prserve.

ma chre pouse Mouna, merci dtre l quand il fallait,

que Dieu te protge et te guide vers le droit chemin.

tous mes amis

tous ceux que jaime
tous ceux qui maiment

ix

Ddicace

Remerciements

Remerciements

Je tiens tout d'abord remercier vivement Monsieur Andr Luc Beylot et Monsieur
Tijani Chahed d'avoir accepter d'tre rapporteurs de mes travaux de thse.
Je remercie bien videmment les professeurs Francine Krief et Toufik Ahmed d'avoir
codiriger cette thse. Merci galement Djamal-Eddine Meddour d'avoir co-encadrer cette
thse. Ces annes de travail en commun m'ont beaucoup appris scientifiquement et
humainement.
Les dbuts de mes travaux sur les rseaux WIMAX remontent l'anne 2007 et ont
t possibles grce mon intgration au sein de l'quipe M2I/R2A et ensuite lquipe
TPN/FAME France Telecom R&D-Orange Labs. Merci Yvon Gourhant et Ibrahim
Houmed qui m'ont accueilli dans leurs quipes
Merci aussi Tlich pour les discussions enrichissantes que nous avons eues et tous
ceux, habitus ou occasionnels des pauses caf, pour les bons moments partags.
Je remercie galement Moez Jerbi, Mohamed Mahdi et Ahmed Ben Nacef mes
colocataires avec qui j'ai partage beaucoup durant ces trois annes de thse. Merci aussi a
tous mes amis de Lannion et d'ailleurs (Tlich, Slim, Dhafer, Abderrahman, Meftah, Med
Tounsi, Imed, Chedly, Adel, Boubakkeur et tant d'autres que je ne nommerai pas par
manque de place et de peur de ne pas tre exhaustif).
Je profite galement de ce moment privilgi pour remercier mes chres parents, ma
sur et mes frres pour leur soutien sans faille, leurs encouragements et sans qui rien
n'aurait t possible.
Enfin, je tiens remercier Mouna pour sa prsence et son soutien indfectible mme
dans les moments difficiles. Elle a su m'accompagner dans cette grande exprience
scientifique mais surtout personnelle qu'est une thse.

xi

Remerciements

xii

Table des matires

Table des matires

Abstract .......................................................................................................................................... 5
Rsum ........................................................................................................................................... 7
Ddicace ......................................................................................................................................... 9
Remerciements ............................................................................................................................11
Table des matires.......................................................................................................................13
Liste des figures ...........................................................................................................................17
Liste des tableaux ........................................................................................................................19
Liste des acronymes ....................................................................................................................21
Chapitre 1
1.1
1.2
1.3

INTRODUCTION............................................................................................. 1

Motivation ..................................................................................................................... 1
Objectifs et contributions ........................................................................................... 2
Organisation de la thse .............................................................................................. 3

Chapitre 2

ETAT DE LART ............................................................................................... 5

2.1
Evolution des systmes cellulaires ............................................................................. 5
2.2
L'IEEE 802.16-2004.................................................................................................... 7
2.2.1 Modle de rfrence ................................................................................................ 8
2.2.2 Couche MAC ............................................................................................................ 9
2.2.2.1 Le Mode PMP ................................................................................................... 9
2.2.2.2 Le Mode mesh .................................................................................................10
2.2.2.3 Adressage et connexions................................................................................12
2.2.3 Couche Physique....................................................................................................12
2.2.3.1 Modulation et codage du canal .....................................................................12
2.2.3.2 Le slot OFDMA .............................................................................................13
2.2.3.3 Structure de la trame ......................................................................................13
2.2.4 Gestion de la QoS..................................................................................................15
2.2.4.1 Ajout dun flux de service ..............................................................................16
2.2.4.2 Modification dun flux de service .................................................................17
2.2.4.3 Suppression dun flux de service ..................................................................18
xiii

Table des matires

2.2.4.4 Les classes de QoS ..........................................................................................20
2.2.4.5 Les techniques de demande de bande passante .........................................22
2.3
Lordonnancement dans les rseaux IEEE 802.16 ...............................................24
2.3.1 Les ordonnanceurs classiques utiliss dans WIMAX .......................................24
2.3.1.1 Ordonnanceurs systmatiques ......................................................................24
2.3.1.2 Ordonnanceurs prenant en compte les conditions du canal radio ..........25
2.3.2 Les ordonnanceurs spcifiquement proposs pour le WIMAX .....................26
2.3.2.1 Ordonnanceurs proposs pour une classe de service spcifique .............26
2.3.2.2 Ordonnanceurs proposs pour plusieurs classes de service QoS............26
2.4
IEEE 802.16j (Mobile Multi hop Relay) ................................................................28
2.4.1 Introduction ............................................................................................................28
2.4.2 Linitiative et la motivation de standardisation de lIEEE 802.16j .................28
2.4.3 Spcifications de lIEEE 802.16j .........................................................................28
2.4.4 Les modes de relais ................................................................................................28
2.4.5 Spcifications de la couche PHY : structure de la trame .................................30
2.4.6 Spcifications de la couche MAC ........................................................................31
2.4.6.1 Les modles de transmission.........................................................................31
2.4.6.2 Routage et gestion des routes .......................................................................31
2.4.6.3 Procdure d'entre en rseau ........................................................................32
2.5
Les applications de streaming vido........................................................................33
2.5.1 Les protocoles multimdia ...................................................................................33
2.5.2 Les standards de codage vido et le codage vido hirarchique .....................34
2.5.3 Ladaptation de la QoS pour la transmission vido ..........................................35
2.6
Les mcanismes Cross-Layer pour les rseaux WIMAX .....................................37
2.6.1 Le concept du Cross-layer ....................................................................................37
2.6.2 La communication dans les architectures Cross-Layer ....................................38
2.6.3 Les approches du Cross-Layer .............................................................................38
2.7
Conclusion ..................................................................................................................41
Chapitre 3

Optimisation Cross-Layer pour la transmission vido unicast ...................43

3.1
Introduction ................................................................................................................43
3.2
Solutions Cross-Layer pour le streaming vido dans les rseaux WIMAX. ......45
3.3
Topologies de rfrences ..........................................................................................48
3.3.1 Architecture distribue ..........................................................................................48
3.3.2 Architecture Centralise ........................................................................................48
3.4
Contexte gnrale.......................................................................................................50
3.4.1 Gestion de la QoS et des flux de services dans les rseaux WIMAX ............50
3.5
Architecture propose ...............................................................................................51
3.5.1 Proposition dune architecture Cross-Layer ......................................................51
xiv

Table des matires

3.5.2 Algorithme Cross-Layer ........................................................................................52
3.5.2.1 Collecte des indicateurs..................................................................................52
3.5.2.2 Adaptation et modification ...........................................................................52
3.5.3 Illustration de lapproche ......................................................................................53
3.5.3.1 SS envoie une requte DSA ..........................................................................53
3.5.3.2 BS envoie une requte DSC ..........................................................................54
3.5.3.3 SS envoie une requte DSC...........................................................................55
3.6
Evaluation de performances.....................................................................................56
3.6.1 Environnement de simulation .............................................................................56
3.6.2 Rsultats de simulations ........................................................................................57
3.6.2.1 Scnario 1 : conditions normales ..................................................................57
3.6.2.2 Scnario 2 : adaptation au contrle dadmission ........................................57
3.6.2.3 Scnario 3: adaptation durant le streaming vido : le dbit diminue .......59
3.6.2.4 Scnario 4: adaptation durant le streaming vido : le dbit augmente ....61
3.7
Conclusion ..................................................................................................................62
Chapitre 4

Transmission Multicast SVC Dans les Rseaux WIMAX ...........................65

4.1
Introduction ................................................................................................................65
4.2
Motivation ...................................................................................................................66
4.3
Etat de lart des solutions de vido streaming multicast ......................................67
4.4
Solutions et architectures proposes .......................................................................71
4.4.1 Cration des groupes multicast avec codage SVC ............................................71
4.4.2 Transmission multicast dans les rseaux WIMAX ...........................................74
4.5
Les architectures multicast SVC proposes ...........................................................75
4.5.1 Mode de modulation simple.................................................................................77
4.5.2 Mode de Modulation Multiple .............................................................................78
4.5.3 Mode de superposition de codage .......................................................................79
4.6
Environnement et rsultats de lvaluation de performance ...............................81
4.6.1 Environnement ......................................................................................................82
4.6.2 Rsultats dvaluation de performances .............................................................83
4.6.2.1 Mode de codage simple .................................................................................86
4.6.2.2 Mode multi-modulations ...............................................................................87
4.6.2.3 Mode de superposition de codage ................................................................88
4.7
Conclusion ..................................................................................................................89
Chapitre 5

CONCLUSION ................................................................................................91

Rfrences ....................................................................................................................................93
Liste des publications .................................................................................................................99
Annexe....................................................................................................................................... 101
xv

Table des matires

xvi

Liste des figures

Liste des figures

Figure 2-1 : Les standards IEEE 802.16 ....................................................................................... 7
Figure 2-2 : Modle de rfrence [1] .............................................................................................. 8
Figure 2-3 : Architecture PMP ........................................................................................................ 9
Figure 2-4 : Architecture MESH .................................................................................................. 11
Figure 2-5 : Structure de la trame OFDMA ................................................................................ 15
Figure 2-6 : Ajout dun flow de service (initi par une SS) ....................................................... 16
Figure 2-7 : Ajout dun flow de service (initi par une BS)....................................................... 17
Figure 2-8 : Modification dun flow de service (initi par une SS) .......................................... 19
Figure 2-9 : Modification dun flux de service (initi par une BS) ........................................... 19
Figure 2-10 : Suppression dun flux de service (initi par une SS)........................................... 20
Figure 2-11 : Suppression dun flux de service (initi par une BS) .......................................... 20
Figure 2-12 : Structure de la trame en mode relais non transparent vue par la BS [3] ......... 30
Figure 2-13 : Structure de la trame en mode relais non transparent vue par la RS [3] ......... 30
Figure 3-1 : Architecture doptimisation Cross-Layer [84] ....................................................... 46
Figure 3-2 : Architecture distribue .............................................................................................. 49
Figure 3-3 : Architecture centralise............................................................................................. 49
Figure 3-4 : Topologie dtude ...................................................................................................... 51
Figure 3-5 : Optimisateur Cross-Layer entre couches MAC et Application .......................... 52
Figure 3-6 : SS envoie le message : DSA Request ...................................................................... 54
Figure 3-7 : BS envoie le message: DSC Request....................................................................... 55
Figure 3-8 : SS envoie le message: DSC Request ....................................................................... 55
Figure 3-9 : architecture de simulation ........................................................................................ 56
Figure 3-10 : Dbits vido pour une qualit leve, Moyenne et faible .................................. 58
Figure 3-11 : Dbit vido de qualit leve rduit qualit moyenne lors de ladmission ... 59
Figure 3-12 : Dbit vido de qualit leve rduit qualit faible lors de ladmission ......... 59
Figure 3-13 : Dbit vido de qualit leve interrompue durant la transmission .................. 60
Figure 3-14 : Dbit vido de qualit leve rduit moyenne durant la transmission ......... 60
Figure 3-15 : Dbit vido de qualit leve rduit qualit faible durant la transmission ... 61
Figure 3-16 : Dbit vido de qualit faible amlior qualit leve durant la transmission
................................................................................................................................................... 62
Figure 4-1 : SVSoA : streaming vido multicast avec ALC [90] .............................................. 68
xvii

Liste des figures

Figure 4-2 : MDC : Formations des couches vido [91] ........................................................... 70
Figure 4-3 : Formations des paquets MDC [91] ......................................................................... 70
Figure 4-4 : Les niveaux Hirarchiques SVC .............................................................................. 72
Figure 4-5 : Groupes Multicast SVC ............................................................................................ 73
Figure 4-6 : Architecture WIMAX multi-cellules (Multi-BS) ................................................... 76
Figure 4-7 : Cas dune seule cellule WIMAX .............................................................................. 77
Figure 4-8 : Superposition de codage dans les rseaux cellulaires [94] ................................... 80
Figure 4-9 : Topologie avec plusieurs cellules ............................................................................ 84
Figure 4-10 : scnario : SSs identiques dans diffrentes cellules .............................................. 84
Figure 4-11 : Topologie de simulation avec une seule cellule. ................................................. 85
Figure 4-12 : Scnario: Mode Classique ....................................................................................... 86
Figure 4-13 : Scnario : Mode Multi-Modulations ..................................................................... 87
Figure 4-14 : Scenario : Superposition de codage ...................................................................... 88
Figure A-1 : Format d'un MAC PDU ........................................................................................ 101
Figure A-2 : Format d'entte gnrique ..................................................................................... 101
Figure A-3 : Format d'entte Bandwidth Request .............................................................. 102
Figure A-4 : Obtention de la synchronisation en lien descendant........................................ 106
Figure A-5 : Maintien de la synchronisation en lien descendant............................................ 107
Figure A-6 : Obtention des paramtres UL .............................................................................. 108
Figure A-7 : Maintien des paramtres UL ................................................................................. 109
Figure A-8 : Format de l'entte du Relay MAC PDU avec payload ...................................... 110
Figure A-9 : Format de l'entte du Relay MAC PDU sans payload ...................................... 111
Figure A-10 : Format de l'entte BR du Relay Station ............................................................ 111

xviii

Liste des tableaux

Liste des tableaux

Tableau 2-1. MCS selon SNR ct rcepteur (802.16 - OFDMA) [1] .................................... 13
Tableau 2-2. Comparaison entre mode de relais transparent et non transparent.................. 29
Tableau 3-1. Correspondance entre QoS IP et QoS 802.16 [83] ............................................. 45
Tableau 3-2. Qualit vido leve, moyenne et faible ............................................................... 56
Tableau 3-3. Paramtres de simulation pour la couche PHY de lIEEE 802.16 ................... 56
Tableau 3-4. Paramtres du trafic en background pour chaque scenario ............................... 58
Tableau 4-1. Paramtres de simulation pour la couche PHY de lIEEE 802.16 ................... 82
Tableau 4-2. Paramtres de la vido SVC ................................................................................... 83
Tableau 4-3. Scenario : SS identiques dans diffrentes cellules ................................................ 84
Tableau 4-4. Scenario : Diffrentes SS dans la mme cellule ................................................... 85
Tableau 4-5. Nombre de couches vido reues.......................................................................... 89

xix

Liste des acronymes

xx

Liste des acronymes

Liste des acronymes

3GPP
AD
ADSL
AF
ALC
ALM
AMC
APP
ARQ
AVC
BE
BL
BPSK
BS
BW
BWA
CAC
CBR
CDMA
CID
CLO
CPS
CS
CSI
DCD
DHCP
DIUC
DL
DLFP
DL-MAP
DRR
DSA
DSA-ACK
DSA-REQ
DSA-RSP
DSC
DSC-ACK

Third Generation Partnership Project

Active Dropping
Asymmetric Digital Subscriber Line
Assured Forwarding
Asynchronous Layered Coding
Application Level Multicast
Adaptive Modulation and Coding
Application
Automatic Repeat reQuest
Advanced Video Coding
Best Effort
Base Layer
Binary Phase-Shift Keying
Base Station
Bandwidth
Broadband Wireless Access
Call Admission Control
Constant Bit Rate
Code Division Multiple Access
Connection IDentifier
Cross-Layer Optimizer
Common Part Sub layer
Convergence Sub layer
Channel State Information
Down link Channel Descriptor
Dynamic Host Configuration Protocol
Down Link Interval Usage Channel
Down Link
Down Link Frame Prefix
Down Link MAP
Deficit Round Robin
Dynamic Service Addition
Dynamic Service Addition Acknowledgment
Dynamic Service Addition Request
Dynamic Service Addition Response
Dynamic Service Change
Dynamic Service Change Acknowledgment
xxi

Liste des acronymes

DSC-REQ
DSC-RSP
DSD
DSD-REQ
DSD-RSP
DSL
EDGE
EF
EL
ertPS
FCH
FDD
FEC
FFT
GC
GM
GPRS
GSM
HDTV
HSDPA
HSUPA
HT
HTTP
IE
IGMP
IPTV
ISDN
LOS
LTE
MAC
MAN
MCS
MDC
MIMO
MLD
MPEG
MR
MR-BS
MS
MT-CID
NLOS
nrtPS
NT_RS
O-DRR
OFDMA
P2P
PDU
xxii

Dynamic Service Change Request

Dynamic Service Change Response
Dynamic Service Delete
Dynamic Service Delete Request
Dynamic Service Delete Response
Digital Subscriber Line
Enhanced Data rates for GSM Evolution
Expedited Forwarding
Enhanced Layer
Extended Real Time Polling Service
Frame Control Header
Frequency Division Duplexing
Forward Error Correction
Fast Fourier Transform
Guarantee Service
Grant Management
General Packet Radio Service
Global System for Mobile
High-Definition Television
High-Speed Downlink Packet Access
High Speed Uplink Packet Access
Header Type
HyperText Transfer Protocol
Information Element
Internet Group Management Protocol
Internet Protocol Television
Integrated Services Digital Network
Line Of Sight
Long Term Evolution
Media Access Control
Metropolitan Area Network
Modulation and Coding Scheme
Multiple Description Coding
Multiple In Multiple Out
Multicast Listener Discovery
Moving Pictures Expert Group
Multi hop Relay
Multi hop Relay Base Station
Mobile Stations
Management Tunnel Connection Identifier
Non Line Of Sight
non-real-time Polling Service
Non Transparent Relay Station
Opportunistic Deficit Round Robin
Orthogonal Frequency Division Multiple Access
Peer To Peer
Packet Data Unit

Liste des acronymes

PER
PHY
PIM
PM
PMP
PU
QAM
QPSK
RR
RS
RTCP
RTG
RTP
rtPS
RTSP
SDP
SDU
SF
SFID
SINR
SIP
SNMP
SNR
SS
SVC
T_RS
T-CID
TCP
TDD
TTG
UCD
UEP
UGS
UIUC
UL
UL-MAP
UMTS
VCEG
VOIP
VPN
WFQ
WIFI
WIMAX
WRR

Packet Error Rate

Physical Layer
Protocol Independent Multicast
Poll Me
Point to Multi Points
Protected Unit
Quadrature Amplitude Modulation
Quadrature Phase Shift Keying
Round Robin
Relay Station
Real Time Control Protocol
Receive Transition Gap
Real Time Protocol
real-time Polling Service
Real Time Streaming Protocol
Session Description Protocol
Service Data Unit
Service Flow
Service Flow IDentifier
Signal to Interference plus Noise Ratio
Session Initiation Protocol
Simple Network Management Protocol
Signal to Noise Ratio
Subscriber Station
Scalable Video Coding
Transparent Relay Station
Tunnel Connection Identifier
Transmission Control Protocol
Time Division Duplexing
Transmit Transition Gap
Uplink Channel Descriptor
Unequal Error Protection
Unsolicited Grant Service
Up Link Interval Usage Channel
Up Link
Up Link MAP
Universal Mobile Telecommunications System
Video Compression Expert Group
Voice over Internet Protocol
Virtual Private Network
Weighted Fair Queuing
Wireless Fidelity
Worldwide Interoperability for Microwave Access
Weighted Round Robin

xxiii

xxiv

Motivation

Chapitre 1
INTRODUCTION
1.1 Motivation
Ces dernires annes ont connu un essor sans prcdent dans les nouvelles
technologies de communications et ceci notamment grce la dmocratisation de laccs
Internet. Laccs lInternet est devenu vital, aussi ncessaire que leau et llectricit. Dans
ce contexte, lutilisateur a pu bnficier de laccroissement du nombre et du type de
terminaux et exige prsent que ses services soient accessibles nimporte o et nimporte
quand. Les progrs technologiques dans le domaine des communications sans fil ont
permis de faire face l'explosion de la demande daccs au haut dbit et notamment dans
les situations de mobilit.
En effet, les instances de standardisation ont dvelopp diffrentes alternatives pour la
fourniture de l'accs au haut dbit sans fil. Le choix de la solution peut diffrer en fonction
des contraintes de dploiement et des objectifs viss. Un panorama des solutions les plus
utilises est prsent ci-dessous :
- Le WIFI (IEEE 802.11) : avec des portes de centaines de mtres, le WIFI permet
d'offrir des accs haut dbit sans fil l'chelle d'un rseau local. En effet, la problmatique
du passage l'chelle est un des critres qui ont limit le dploiement de tels rseaux
l'accs domestique et entreprise.
- Le satellite: la solution satellitaire prsente l'avantage d'offrir une connectivit
l'chelle nationale et continentale. Le satellite est largement utilis pour les applications de
diffusion de la tlvision et un degr moindre pour l'accs Internet principalement cause
du cot trs lev de la bande passante par rapport aux solutions concurrentes et du
manque dinteractivit. Les nouveaux satellites bidirectionnels oprant sur la bande Ka,
1

INTRODUCTION
promettent dapporter une solution efficace laccs au haut dbit notamment pour les
zones blanches.
- Les rseaux cellulaires : ils ont pour objectif d'offrir une connectivit haut dbit sur
plusieurs kilomtres. Deux standards concurrents se sont positionns sur ce segment: le
3GPP avec le HSDPA/LTE, et l'IEEE avec le WIMAX (802.16). Les deux technologies
prsentent plusieurs similarits notamment pour le support de la couche physique. Bien
que nous nous focalisions dans cette thse sur la technologie WIMAX, les solutions que
nous proposons peuvent tre adaptes la technologie HSDPA/LTE en considrant les
spcificits de sa couche MAC.
Les dploiements de rseaux WIMAX sont destins, dans la majorit des cas un
usage Broadband fixe ou nomade en substitution d'une infrastructure fixe comme
l'ADSL. Les dploiements actuels se situent aujourdhui en Core du Sud (KT Telecom qui
compterait 1 million d'abonns), en Russie (Yota et Comstar), au Japon (KDDI) et aux
Etats-Unis (Sprint Nextel). Les services proposs dans ces pays vont de l'accs Internet
mobile grce des puces embarques dans les PC ou des cls USB, des services de voix
intgrs dans des tlphones mobiles.
Malgr la maturit affiche dans la conception des diffrents protocoles du WIMAX,
certaines problmatiques inhrentes la couche radio et au manque d'interaction entre les
couches basses et les couches applicatives, fort requis en qualit de service, restent
rsoudre.
En effet, en dpit des efforts raliss pour traiter ces problmatiques, un des dfis
principaux reste la dfinition d'une architecture de qualit de service adapte aux
spcifications de ce type de rseaux. Cette architecture devra rpondre de manire fiable et
efficace aux besoins des applications, la fois pour les services unicast et multicast, tout en
prenant en compte l'tat du rseau et lhtrognit des terminaux.

1.2 Objectifs et contributions

Dans cette thse, nous nous sommes intresss, la transmission des flux multimdia,
notamment les flux vido, sur les rseaux WIMAX. En effet, lobjectif est de garantir une
meilleure qualit de service lutilisateur final. Pour ce faire, une optimisation est ralise
conjointement entre les paramtres de transmission vido et les conditions radio variables
des diffrents utilisateurs du rseau WIMAX. Les flux vido ont des contraintes strictes en
termes de dbit, de dlai et de pertes. Ainsi, pour atteindre cet objectif, ces paramtres
doivent tre efficacement contrls.
En effet, les conditions physiques et radio dune station WIMAX dpendent de
plusieurs paramtres tels que son emplacement par rapport la BS (Base Station), ses
2

Organisation de la thse
capacits radios, la bande passante maximale quelle peut atteindre, etc. La diversit des
profils des stations, dans une ou plusieurs cellules, prsente une forte contrainte pour un
flux de streaming vido ayant des besoins stricts en QoS (dbit de transmission, dlai de
bout-en-bout, gigue et taux de perte).
Lobjectif de notre travail de recherche consiste trouver un compromis entre les
contraintes des applications vidos et les contraintes physiques du rseau WIMAX pour
des communications de type unicast et multicast. Les mcanismes Cross-Layer sont utiliss
pour faciliter la communication entre les couches protocolaires du modle ISO/OSI en
facilitant les interactions entre les couches applicatives et les couches physiques. Ce qui
permettra dargumenter considrablement les performances des services dploys.
Notre travail s'articule autour du transport unicast et multicast des flux vido sur les
rseaux 802.16. Ainsi, nous visons mettre en uvre des solutions qui rpondront cette
problmatique en proposant des mcanismes dadaptation et doptimisation, bass sur une
architecture Cross-Layer afin de maximiser la qualit de service perue par lutilisateur final
et daugmenter la capacit globale du rseau en exploitant au mieux les ressources radio
disponibles. Deux contributions majeurs ont t proposes et valids.
Premirement, nous avons dfini une entit CLO ( Cross-Layer Optimizer ) qui
exploite des messages de gestion des flux de service, changs entre BS et SS, au niveau
MAC, pour dterminer ladaptation ncessaire et optimale afin dassurer le bon
fonctionnement de lapplication. Lanalyse des performances, par simulations, de notre
solution montre lefficacit du CLO adapter, dune faon dynamique, le dbit vido en
fonction des conditions du rseau afin dassurer une QoS optimale.
Deuximement, nous proposons une solution de streaming multicast des flux vido
dans les rseaux WIMAX. Cette solution permet chaque utilisateur dobtenir une qualit
vido proportionnelle ses conditions radio et sa bande passante disponible. Pour
atteindre cet objectif, plusieurs groupes multicast sont forms par couches vido de type
SVC. Cette solution permet doptimiser davantage les ressources radio et ainsi daugmenter
la capacit globale du systme.

1.3 Organisation de la thse

La thse est organise comme suit :
Chapitre 2 : Etat de lArt. Ce chapitre prsente une vue densemble sur larchitecture
des rseaux WIMAX. Nous prsentons les caractristiques de la couche physique (PHY),
savoir, les techniques de modulation, de codage, la structure de la trame, ainsi que les
caractristiques de la couche MAC telles que ladressage, les connexions et la gestion de la
QoS. Nous nous intressons aussi lordonnancement en prsentant les travaux raliss
3

INTRODUCTION
pour loptimisation de lallocation des ressources dans les rseaux WIMAX en tenant en
compte ou non des exigences de QoS.
Dautre part, nous prsentons les applications de streaming vido, les protocoles
multimdia, les standards de codage et les diffrents travaux raliss dans la littrature pour
loptimisation de la QoS. Suite cette prsentation, nous introduisons le concept Crosslayer et nous dtaillons les travaux rcemment raliss dans ce domaine.
Chapitre 3 Optimisation Cross-Layer pour la Transmission Vido Unicast. Dans ce chapitre,
nous proposons une architecture Cross-Layer, nomme CLO, qui permet une optimisation
et une amlioration de la transmission vido unicast au sein dun rseau WIMAX. Pour
cela, nous commenons par identifier les diffrentes entits intervenant dans la solution.
Une approche Cross-Layer entre la couche application et la couche MAC est propose afin
de permettre une adaptation du dbit vido en fonction des ressources MAC/Radio
disponibles au niveau dune station SS ( Subscriber Station ). Les dtails de
fonctionnement du CLO et lvaluation de ses performances par simulation sont ensuite
fournis. Nous montrons que le CLO permet doffrir un meilleur fonctionnement du
systme et une plus grande amlioration de qualit de services pour les utilisateurs.
Chapitre 4 : Transmission Multicast SVC dans les Rseaux WIMAX. Dans ce chapitre, nous
exploitons les bnfices du codage vido hirarchique, tel que SVC, dans le cadre dune
transmission vido en multicast, vers des clients WIMAX ayant des caractristiques rseaux
diverses. Dune part, nous identifions les lacunes dune transmission multicast dans de
telles conditions. Dautre part, nous proposons une architecture multicast, base du codage
SVC, qui permet chaque client dacqurir une qualit vido quivalente aux ressources
radios dont il dispose. Nous proposons et comparons plusieurs mcanismes, prenant en
compte la diversit des clients en termes de bande passante, de modulation et de codage.
Chapitre 5 : Conclusion. Nous prsentons dans ce chapitre une conclusion gnrale pour
les travaux dcrits et nous proposons un ensemble de perspectives pour de futurs travaux
de recherche qui sinscrivent dans la continuit de cette thse.

Evolution des systmes cellulaires

Chapitre 2
ETAT DE LART
Ce chapitre dcrit notre analyse sur les travaux de recherche raliss dans le domaine
des architectures de rseaux mobiles et sans fil et leur volution actuelle.

2.1 Evolution des systmes cellulaires

Ces dernires annes ont connu une volution considrable dans le domaine des
tlcommunications et en particulier celui des communications sans fil. La premire
gnration (1G) de tlphonie mobile a t introduite dans les annes 1970. Nous pouvons
citer, titre d'exemple, Advanced Mobile Phone Service (AMPS), Total Access
Communication System (TAC), Radiocom 2000. Ces solutions permettaient les
communications de type voix et exploitaient des rseaux analogiques.
La deuxime gnration (2G) de rseaux mobiles a commenc tre dploye au
dbut des annes 1990. Le principal rseau de communications mobiles 2G est le systme
global de communications mobiles (GSM) [4]. Ce service, initialement conu pour les
communications de type voix a t enrichi avec le service SMS ( Short Message
Service ). La gnration dite de seconde et demie (2,5 G ou 2G +) tels que General
Packet Radio Service (GPRS) [5] et Enhanced Data Rates for GSM Evolution
(EDGE) [6], a ajout des services de donnes avec un dbit plus lev ddi principalement
l'accs aux services d'Internet comme le-mail et le Web. Le dbit maximal thorique dans
le systme GPRS est de 115 Kbps. Le systme EDGE offre un meilleur dbit maximal
thorique (jusqu' 384 Kbps).
la fin des annes 1990, la troisime gnration (3G) a fait voluer les solutions
2G/2G+ pour offrir d'avantage de dbit pour les services de donnes. Le systme 3G
supporte fois les services voix et donnes haut dbit en particulier pour supporter des
communications de type vido. Les principaux systmes 3G sont les Universal Mobile
Telecommunications System (UMTS) [7] et CDMA2000 [8]. Le premier dploiement de
CDMA2000 et UMTS a eu lieu entre 2000-2001. Avec le succs commercial quont connu
5

ETAT DE LART
les solutions 3G, cette technologie a russi une progression fulgurante, qui lui a permis de
dpasser les premiers dbits de l'ordre de 1 Mbps, pour atteindre des dbits plus levs sur
les deux liaisons montantes et descendantes. Ceci est d principalement l'apparition de
nouvelles amliorations de la solution de base comme le High-Speed Downlink Packet
Access (HSDPA) et le High Speed Uplink Packet Access (HSUPA) [9].
Le systme 4G est actuellement en cours de dveloppement au sein de diffrentes
instances de standardisation. L'IEEE propose le 802.16m, tandis que le 3GPP se focalise
sur le Long Term Evolution (LTE) et le LTE-Advanced . Bien que le LTE soit
pressenti pour tre la solution principale pour les services de donnes mobiles haut dbit, le
WIMAX reste tout de mme un candidat potentiel pour la quatrime gnration (4G) via sa
solution IEEE 802.16m [12].
Le nom officiel de la technologie du 3GPP est Evolved Packet System (EPS). D'un
point de vue performance du systme, et selon les diffrentes tudes menes, le rseau LTE
offre un dbit descendant de 100 Mbps avec des antennes Single In Single Out (SISO)
et 173 Mbps, dans le cas des antennes Multiple In Multiple Out (MIMO) [10].
Paralllement au 3GPP, l'IEEE 802 s'est intress aux systmes mobiles haut dbit via
son groupe IEEE 802.16 depuis 1999, qui a pour objectif de dvelopper les standards pour
Broadband Wireless Access (BWA). Pour ce faire, il tait question de traiter
conjointement la problmatique lie la fourniture du haut dbit mais avec une couverture
assez importante (ce qui reprsente un des lments de diffrenciation par rapport au
802.11). D'un point de vu commercial, le Worldwide Interoperability for Microwave
Access (WIMAX) est le nom commun pour ce standard. Le WIMAX offre un dbit
thorique de 75 Mbps et une couverture maximale de 50 km. Cette technologie vise
galement supporter plusieurs services avec des niveaux de qualit de service diffrents, le
tout un cot raisonnable. Ces services peuvent avoir des garanties strictes de QoS
(comme un tunnel VPN), des garanties de QoS moins leves (comme Voice over
Internet Protocol (VoIP), vido la demande (VOD), tlvision numrique, et les
jeux) ou Best Effort (comme HyperText Transfer Protocol (HTTP)). La dernire
version du standard est 802.16m, et elle vise offrir un dbit de 1 Gbps pour une station
fixe, et 100 Mbps pour une station mobile avec des vitesses de mobilit de lutilisateur qui
peuvent atteindre les 300km/h.
La prochaine section dcrit la norme IEEE 802.16-2004 utilise dans nos travaux de
recherche. Nous prsentons le modle de rfrence dcrivant la couche MAC (Medium
Access Control) et la couche PHY (Physical). Par la suite, les caractristiques de chaque
couche sont dtailles, savoir, les diffrents modles darchitecture, ladressage, les
connexions, les structures de trames et la gestion de la QoS.

L'IEEE 802.16-2004

2.2 L'IEEE 802.16-2004

L'IEEE 802.16 Working Group est le groupe de travail IEEE pour les rseaux
mtropolitains mobiles. Ce groupe de travail a dvelopp diffrentes versions du standard,
la version de dcembre 2001 pour les rseaux de collecte, le 802.16a/d pour l'accs fixe, et
enfin le 802.16e/m pour l'accs mobile.
L'IEEE 802.16 (version dcembre 2001) est conue pour fonctionner dans un spectre
variant entre 10 et 66 GHz. Sur ces frquences, la transmission doit tre en ligne de mire
Line-of-Sight (LOS), il sagit dune transmission directe sans prsence dobstacles. Le
standard spcifie la couche PHY et la couche MAC du systme 802.16.
Cette solution tait plutt adapte pour la mise en place de rseaux de collecte, mais
non approprie pour la majorit des applications grand public qui ncessitent des
transmissions de type non LOS (NLOS). Pour cette raison, une extension de
l'IEEE802.16, a t propose en avril 2003 afin dintgrer ce besoin de transmission
NLOS. Il s'agit de la norme IEEE 802.16a qui fonctionne dans des plages des frquences,
avec ou sans licence, variant de 2 11 GHz.
La Figure 2-1 illustre les caractristiques et les spcificits des diffrents standards du
groupe 802.16.

Figure 2-1 : Les standards IEEE 802.16

ETAT DE LART
2.2.1 Modle de rfrence
La Figure 2-2 reprsente le modle de rfrence pour les couches MAC et PHY. Nous
nous intressons dans un premier temps, la couche MAC. Elle est compose
essentiellement de 3 sous-couches : la sous-couche CS ( Convergence Sub layer )
communique avec les couches suprieures, la sous-couche CPS ( Common Part Sub
layer ) dfinit les fonctionnalits de bases dune couche MAC, ainsi que la sous-couche de
scurit ( Security Sub layer ) :

Figure 2-2 : Modle de rfrence [1]

La sous-couche CS ( Convergence Sub layer ) :

Cette sous-couche fournit la transformation de toutes les donnes externes du rseau,

reues au point daccs CS-SAP, en un MAC SDU ( Service Data Unit ), qui par la suite,
est achemin vers la sous-couche CPS via le point daccs MAC-SAP. Ceci inclut aussi la
classification des SDU provenant du rseau externe, et leurs associations selon leur propre
SFID ( Service Flow IDentifier ) et leur CID ( Connection IDentifier ). Cette couche
implmente aussi d'autres fonctionnalits telles que la suppression d'enttes (PHS :
Payload Header Suppression ).
Plusieurs spcifications de la sous-couche CS sont dfinies pour garantir l'interfaage
avec divers protocoles. Le format interne du payload CS lui est propre, ce qui veut dire que
la CPS n'a besoin ni de connatre le format, ni d'extraire une information du payload CS.
8

L'IEEE 802.16-2004

La sous-couche CPS ( Common Part Sub layer ) :

Cette couche fournit les fonctionnalits de base de la couche MAC, savoir l'allocation
de bande passante, l'tablissement et la maintenance des connexions.

La sous-couche scurit ( Security Sub layer )

Cette sous-couche fournit les fonctionnalits d'authentification, d'change de cls et de

cryptage.
Dans la prochaine section, nous dcrivons avec plus de dtails les diffrentes
spcifications de la couche MAC, plus prcisment la sous-couche CPS. Pour le reste de ce
chapitre, nous sous-entendons par MAC la sous-couche CPS de la couche MAC.
2.2.2 Couche MAC
Le 802.16 dfinit deux modes de topologie possible: Le mode PMP (Point to Multi
Point), et le mode MESH. Nous dtaillons ces deux modes dans ce qui suit
2.2.2.1

Le Mode PMP

Il s'agit du mode de communication de base pour le 802.16. Comme son nom l'indique,
il s'agit dune transmission dun point central vers plusieurs points dans le rseau, ce
concept est prsent dans la Figure 2-3. Dans cette configuration, le lien descendant DL
( Down Link ), depuis la BS ( Base Station ) vers lutilisateur SS ( Subscriber Station )
fonctionne en mode PMP : la BS est l'lment qui contrle les transmissions dans sa zone
de couverture sans coordination avec les autres stations (BS ou SS).

Figure 2-3 : Architecture PMP

ETAT DE LART
Dans le cas d'un duplexage temporel TDD ( Time Division Duplexing ), la BS doit
diviser la priode de transmission en priodes DL et UL ( Up Link ). Dans le cas d'un
duplexage frquentiel FDD ( Frequency Division Duplexing ), deux frquences
diffrentes sont alloues par la BS pour le DL et UL.
Gnralement la transmission en DL est effectue en broadcast depuis la BS, la trame
en DL est divise en plusieurs parties, chacune tant ddie une ou plusieurs SS. Chaque
SS est en consquence capable de lire uniquement la partie de la trame qui lui est destine.
Sur le lien montant, les SS partagent le lien la demande pour pouvoir transmettre. En
fonction de la classe de service utilise, une SS peut avoir le droit de transmettre.
Lobtention du droit de transmission peut tre dcide par la BS suite une requte
provenant de lutilisateur. En plus de la transmission unicast, les donnes peuvent tre aussi
transmises en multicast tel que la diffusion de contenu vido ou encore en broadcast
toutes les stations.
Dans le mode PMP, les utilisateurs adhrent un protocole de communication qui va,
par la suite, grer l'accs, activer les services ncessaires et assurer les besoins en dlai et
bande passante pour ses nouvelles applications. Ce processus est assur par des
mcanismes d'ordonnancement, tels que les mcanismes unsolicited bandwidth grants ,
polling et contention .
La couche MAC est oriente connexion, c.--d. que toutes les communications se font
dans un contexte de connexions: l'analyse des services d'une nouvelle SS, l'association d'un
niveau de QoS un service, etc. Lors de l'entre d'une SS dans le systme, plusieurs flux de
service doivent tre disponibles. Aprs l'enregistrement d'une SS dans le rseau, diffrentes
connexions sont associes aux flux de services (une connexion par flux), et c'est avec la
rfrence une connexion qu'une demande de bande passante par exemple pourra avoir
lieu.
Une connexion dfinit la fois le flux de service et la relation entre les processus de
convergence et ce flux. Ce dernier dfinit les besoins en termes de QoS des paquets qui
vont tre changs au cours de cette connexion. Le concept de flux de service est
primordial pour le fonctionnement du protocole MAC, notamment pour la gestion des
ressources rseaux. En effet, il assure la gestion de la QoS sur le lien montant et descendant
(UL/DL) d'une SS ce qui est essentiel pour le processus d'allocation de bande passante.
2.2.2.2 Le Mode mesh
La diffrence majeure entre le mode PMP et le mode Mesh (Figure 2-4) est dtaille
dans ce qui suit. En mode PMP, le trafic se fait uniquement depuis ou vers la BS, alors que
dans le cas du Mesh, les SS peuvent communiquer directement entre elles sans passer par la
BS. Pour assurer le bon fonctionnement de ces deux types de communications, un
10

L'IEEE 802.16-2004
mcanisme d'ordonnancement est ncessaire. L'ordonnancement peut tre distribu ou
centralis au niveau de la BS, on parle dans ce dernier cas de topologie Mesh BS, ou bien
tre une combinaison des deux.

SS

SS

SS

SS

BS

Trafic entre BS et SS
Trafic entre BSs
Trafic entre SSs
SS
BS

Figure 2-4 : Architecture MESH

Contrairement au mode PMP, o la BS tait la seule entit qui contrle et initie les
transmissions, dans le mode Mesh, le processus est gr de faon coordonne entre les
Mesh SS et la Mesh BS. En effet, les Mesh SS peuvent galement transmettre au mme titre
que la Mesh BS.
En utilisant un ordonnancement distribu, les nuds peuvent prendre des dcisions
d'ordonnancement partir des informations de scheduling du voisinage deux sauts et
diffuser leur tour leurs propres informations au voisinage.
Dans le cas d'un ordonnancement centralis, les ressources sont distribues d'une
manire centralise. En effet, la Mesh BS doit grer toutes les requtes de ressources
provenant des Mesh SS saut-par-saut, i.e., la Mesh BS gre les requtes du premier saut et
puis du second, etc. La Mesh BS dtermine les ressources requises pour chaque lien, en up
Link ou en down Link. Elle transmet ensuite l'information tous les nuds. Le message en
question ne contient pas une dcision d'ordonnancement, c'est chaque nud de calculer
lordonnancement l'aide d'un algorithme prdtermin avec les paramtres donns.
Le mode MESH na pas t retenu par le groupe de travail 802.16 dans sa rvision
2009. Son retrait est d ses spcifications incompltes, qui avaient peu de chances d'tre
acheves, et galement son manque de compatibilit avec le mode PMP.
Pour le mode MMR (Mobile Multi hop Relay), plus de dtails sont prsents dans la
section 2.4.
11

ETAT DE LART
2.2.2.3 Adressage et connexions
Dans le mode PMP, chaque SS possde une adresse MAC universelle de 48 bits, cette
adresse est unique, elle est ncessaire pour l'tape d'initialisation ou "initial ranging" afin
d'tablir les connexions requises. Cette adresse est galement utilise dans le processus
d'authentification.
Les connexions sont identifies par le CID (16bits). Lors de l'initialisation d'un SS, deux
paires de connexions de management (UL et DL) sont tablies entre la BS et le SS. Ensuite,
une troisime paire de connexion peut tre tablie de manire optionnelle. La prsence de
trois paires de connexions reflte la prsence de trois niveaux de qualit de service pour le
trafic de management. La connexion de base est destine aux changes de messages de
management courts et urgents entre les couches MAC. La connexion primaire est utilise
par les couches MAC afin de transporter les messages de management plus longs et plus
tolrants aux dlais. La connexion secondaire est utilise pour les changes de messages
plus tolrants aux dlais de type DHCP, TFTP, SNMP, etc.
Pour le mode Mesh, l'adresse MAC est toujours utilise. Une fois autoris entrer dans
le rseau, une SS doit recevoir un Node ID (16 bits). Cela reprsente l'identit de base pour
les oprations normales et il est transfr dans le sous-entte Mesh. Par ailleurs, pour
pouvoir communiquer avec les nuds dans un contexte de voisinage local, lidentifiant du
lien ou le LINK ID (8 bits) est utilis. Chaque nud doit associer un identificateur pour
chaque lien entre lui et un de ses voisins. Le LINK ID est une partie du CID dans l'entte
gnrique de la MAC PDU.
2.2.3 Couche Physique
Dans le cadre de notre tude, nous nous sommes intresss principalement la couche
physique OFDMA. En effet, la couche Wireless MAN-OFDMA PHY est dsigne pour
supporter des transmissions NLOS oprants dans des frquences en dessous de 11GHz.
2.2.3.1

Modulation et codage du canal

La modulation et le codage adaptatifs AMC ( Adaptive Modulation and Coding ) est

une technique puissante utilise par la technologie WIMAX pour renforcer la robustesse de
la communication dans des conditions radio trs variables. Ceci est ralis en utilisant un
schma de modulation et de codage MCS ( Modulation and Coding Scheme ) robuste,
cest dire en transmettant des dbits faibles lorsque le canal est de mauvaise qualit et en
augmentant le dbit de donnes en utilisant une MCS plus efficace lorsque le canal est bon.
Les techniques de modulation utilises par la technologie WIMAX sont: BPSK, QPSK,
16-QAM et 64-QAM. Pour le codage du canal, plusieurs types de FEC ( Forward Error
Correction ) sont utiliss dans les rseaux WIMAX : Convolutional Codes , Turbo
12

L'IEEE 802.16-2004
Codes , et Block Codes .
Ces techniques de codage de canal sont utilises pour ajouter, aux bits d'information,
des bits redondants qui sont destins augmenter le gain de codage et corriger les erreurs
sur les bits lors de la transmission. Avec la combinaison des modulations, les diffrents
taux de codages proposs par la norme IEEE 802.16, et les trois types de FEC, il existe 52
configurations possibles, nommes burst profiles .
Le mcanisme utilis pour choisir le MCS le plus appropri pour chaque trame et pour
chaque utilisateur, et grer les diffrents burst profiles en DL et en UL de chaque SS,
n'est pas entirement dfini par la norme 802.16.
Nanmoins, l'ide de base consiste adapter le choix le plus appropri du burst
profile , identifi par un DIUC / UIUC ( DL / UL Interval Usage Channel ), au rapport
signal / bruit SNR ( Signal to Noise Ratio ) du canal mesur au niveau du rcepteur.
Le Tableau 2-1ci-dessous fournit les MCS recommands par la norme IEEE 802.16 [1]
selon la valeur du SNR ct rcepteur pour une couche physique 802.16 OFDMA (les
valeurs des SNR ne sont que des ordres de grandeur obtenus pour des besoins spcifiques)

Tableau 2-1. MCS selon SNR ct rcepteur (802.16 - OFDMA) [1]

2.2.3.2 Le slot OFDMA

Un slot OFDMA possde deux dimensions, une dimension temporelle et une
dimension frquentielle. Le canal physique est divis en plusieurs porteuses ( sub
carriers ), un sous-ensemble de porteuses forme un sous-canal. En DL, un sous-canal peut
tre utilis par plusieurs utilisateurs. En UL, un transmetteur peut utiliser plusieurs souscanaux. Les porteuses, formant un sous-canal, pourraient mais ne devraient pas tre
adjacents pour des raisons de scalabilit et d'accs multiples.
2.2.3.3 Structure de la trame
Concernant le mode de duplexage, il existe le TDD ( Time Division Dulexing ) et le
FDD ( Frequency Division Duplexing ) ou encore le H-FDD ( Half FDD ). Pour le
duplexage frquentiel, les canaux en DL et UL sont spars en frquences diffrentes et la
13

ETAT DE LART
taille de la trame est fixe pour le DL et lUL. Pour le duplexage temporel, les transmissions
en DL et en UL se font lune aprs lautre, et utilisent la mme frquence et la dure de la
trame est fixe. Dans cette partie, nous nous intressons essentiellement au mode TDD qui
offre une meilleure utilisation de la frquence et permet ladaptation de lallocation de
bande passante entre le DL et lUL, i.e., la dure de la trame en DL et en UL nest pas
forcment la mme.
La structure de la trame est construite partir des transmissions de la BS et des SS. En
effet, une trame en lien descendant commence par un prambule qui sert la
synchronisation physique, suivi d'une priode de transmission en DL, puis d'une priode de
transmission en UL. Dans chaque trame, de petites priodes TTG et RTG ( Receive /
Transmit Transition Gap ) doivent tre insres respectivement entre le DL et l'UL et la
fin de la trame pour permettre la BS et aux SS d'avoir des slots pour changer entre les
modes de transmission ou de rception.
La structure de la trame OFDMA est illustre dans la Figure 2-5. Les deux premiers
sous-canaux transmis dans le symbole de donne en DL, juste aprs le prambule, est
appel le FCH ( Frame Control Header ). Le FCH contient le DLFP ( DL Frame
Prefix ) qui donne entre autres la longueur du message DL-MAP. Le DL-MAP, s'il est
transmis, est le premier burst qui suit le FCH. Si les messages DCD et UCD sont transmis
dans la trame, ils doivent l'tre immdiatement aprs le DL-MAP et l'UL-MAP. Tous ces
messages, que nous venons de citer, sont des messages de contrle de la couche MAC
envoys par la BS vers toutes les SS en mode broadcast.
Comme dj cit, les messages DL-MAP et UL-MAP donnent des informations de
contrle qui renseignent chaque SS sur les coordonnes et la taille du DL burst qui lui sont
destines ainsi que les coordonnes et la taille de l'UL burst qui lui sont alloues pour
transmettre vers la BS. La sous-trame en UL, contient un premier burst appel ranging
subchannel , il s'agit d'un burst base de contention, utile pour raliser linitial ranging ,
le periodic ranging ainsi que pour des Bandwidth Request base de contention. C'est
une priode pendant laquelle n'importe quelle station peut transmettre en procdant une
technique ou algorithme d'lection.
Nous avons prsent, jusqu maintenant, les caractristiques gnrales de la couche
PHY et MAC. Nous avons dcrit les diffrentes structures et mcanismes dfinis dans
chacune de ces couches. Dans la prochaine section, nous mettons laccent sur la gestion de
la qualit de service au niveau de la couche MAC 802.16. Cette tude est primordiale pour
la suite de nos travaux.

14

L'IEEE 802.16-2004

Figure 2-5 : Structure de la trame OFDMA

2.2.4 Gestion de la QoS

Un flux est un service de transport MAC qui fournit un transport unidirectionnel de
paquets soit en lien montant ou en lien descendant. La liaison montante et les paquets en
liaison descendante sont transmis par les SS et de la BS, respectivement.
Un flux de service (SF) est rfrenc par son identifiant de flux de service
(SFID). Lorsque le flux de service est admis, une nouvelle connexion est
associe. L'identifiant de connexion (CID) est ajout aux paramtres du flux de service.
Les principaux paramtres de QoS d'un flux de service sont les suivants:

Traffic priority : reprsente la priorit accorde au flux de service.

Maximum sustained traffic rate : reprsente le dbit maximal autoris.

Minimum reserved traffic rate : reprsente le dbit minimum rserv.

Tolerated jitter : reprsente la variation du dlai maximum de la connexion.

Maximum latency : reprsente le temps de latence maximal entre la rception d'un

paquet et sa transmission.

La gestion dynamique des services est utilise pour ajouter un nouveau flux de
service. Un utilisateur peut avoir de nombreux flux de service simultanment. Une fois
quun flux de service est cr, l'utilisateur peut demander modifier es paramtres ou
supprimer le flux.

15

ETAT DE LART
2.2.4.1

Ajout dun flux de service

Le mcanisme d'ajout de services dynamiques (DSA) est utilis afin de crer un

nouveau SF entre une SS et une BS, (voir Figure 2-6 et Figure 2-7). Il existe trois types de
messages DSA: Dynamic Service Addition Request (DSA-REQ), Dynamic Service
Addition Response (DSA-RSP) et Dynamic Service Addition Acknowledgment (DSAACK).

Dynamic Service Addition Request : Un message DSA-REQ est envoy par une
SS ou une BS pour demander la cration d'un nouveau SF entre une SS et une BS (ou
inversement). Quand une SS initialise le mcanisme DSA, le message DSA-REQ ne fournit
pas de SFID. La SS peut utiliser une rfrence d'une configuration de service prdfinie par
la BS, nomm classe de service, au lieu dun ou de plusieurs paramtres de QoS. Lorsque la
BS initialise le mcanisme DSA, le message DSA-REQ contient un SFID, un CID si la
connexion est admise, et un ensemble de paramtres de QoS si la classe de service existe.
Tous les messages DSA-REQ contiennent les paramtres suivants:

CID: c'est lidentifiant principal de management de connexion de la SS. La connexion

de management principale est utilise par la BS et les SS dans le but d'changer des
messages plus longs et des messages de management plus tolrants au dlai.

Transaction ID : reprsente l'identifiant unique pour cette transaction attribu par

l'expditeur.

Service Flow Parameters : spcifie les caractristiques du trafic SF et les besoins de

lordonnancement ( Scheduling ).

Figure 2-6 : Ajout dun flow de service (initi par une SS)

Dynamic Service Addition Response : Un message DSA-RSP est gnr en

rponse un message DSA-REQ reu. Un message DSA-RSP contient un CID, un ID de
16

L'IEEE 802.16-2004
transaction, qui reprsente l'identifiant du message DSA-REQ, et une confirmation qui
reprsente le code de confirmation approprie (CC) pour l'intgralit du message DSAREQ.
Quand les SS initialisent un mcanisme d'addition de flux de service, le message DSARSP contient un SFID si l'opration est russie. Sinon, la BS utilise la rfrence dorigine du
flux de service pour identifier les paramtres qui n'ont pas t retenu dans le message DSARSP.
Si une transaction, initialise par la BS, choue, la SS doit utiliser un SFID pour
identifier les paramtres qui ont caus lchec dans le message DSA-RSP.

Figure 2-7 : Ajout dun flow de service (initi par une BS)

Dynamic Service Addition Acknowledgment : Un message DSA-ACK contient

un CID, une transaction ID, qui reprsente l'identifiant du message DSA-RSP
correspondant, un code de confirmation qui reprsente l'intgralit du message DSA-RSP
correspondant, et un ensemble derreur du flux de service. L'ensemble des erreurs doit tre
inclus pour tous les flux de services qui ont chou dans le message DSA-RSP
correspondant. Ce paramtre est obligatoire uniquement si la transaction choue.
Les dtails du comportement d'une SS et une BS pour ajouter un nouveau flux de
service sont indiqus dans la Figure 2-6 et Figure 2-7, quand les SS ou la BS initialise le
processus, respectivement.
2.2.4.2 Modification dun flux de service
Les messages de changement de service (DSC) sont utiliss pour modifier les
paramtres d'un flux de service existant. Il existe trois types de messages DSC : Dynamic
17

ETAT DE LART
Service Change Request (DSC-REQ), Dynamic Service Change Response (DSC-RSP),
et Dynamic Service Change Acknowledgment (DSC-ACK).

Dynamic Service Change Request : Un message DSC-REQ est envoy par une
SS ou une BS pour demander la modification certains paramtres d'un flux de service
existant. Un message DSC-REQ contient un CID, un ID de transaction, qui reprsente
l'identifiant unique pour cette transaction attribu par lexpditeur, et un paramtre du SF
indiquant les nouvelles caractristiques du trafic et les nouvelles contraintes
dordonnancement.

Dynamic Service Change Response : Un message DSC-RSP est gnr en

rponse au message reu DSC-REQ. Un message DSC-RSP contient un CID, un ID de
transaction, qui reprsente l'identifiant du message DSC-REQ correspondant, et un code
de confirmation qui reprsente l'intgralit du message DSC-REQ correspondant.
Lorsque le mcanisme DSC russit, un paramtre appel Service Flow Parameter
doit tre ajout au message DSC-RSP. Ce paramtre spcifie les caractristiques du flux de
service et les exigences dordonnancement. Sinon, lorsque le mcanisme DSC choue, un
paramtre appel Service Error doit tre ajout au message DSC-RSP. Ce paramtre
doit tre inclus pour tous les flux de service pour lesquels le message DSC-REQ
correspondant a chou.

Dynamic Service Change Acknowledgment : Un message DSC-ACK est gnr

en rponse un message reu DSC-RSP. Un message DSC-ACK contient un CID, un ID
de transaction, qui reprsente l'identifiant du message correspondant DSC-RSP, un code de
confirmation de lintgrit du message DSC-RSP correspondant.
L'ensemble des erreurs doit tre inclus pour chaque flux de service qui a chou dans le
message DSC-RSP correspondant. Ce paramtre est obligatoire uniquement si la
transaction a chou.
Les dtails du comportement d'une SS et dune BS pour changer les paramtres d'un
flux de service existant sont indiqus la Figure 2-8 et la Figure 2-9 lorsque la SS ou la BS
initialise le processus, respectivement.
2.2.4.3 Suppression dun flux de service
Le message Dynamic Service Delete (DSD) est utilis pour supprimer un flux de
service existant. Il existe 2 types de messages DSD : Dynamic Service Delete Request
(DSD-REQ) et Dynamic Service Delete Response (DSD-RSP).

Dynamic Service Delete Request : un message DSD-REQ est envoy par une SS
ou une BS pour la suppression dun flux de service existant. Le message DSD-REQ
contient un CID et un ID de transaction.
18

L'IEEE 802.16-2004

Dynamic Service Delete Response : un message DSD-RSP est gnr en rponse

un message DSD-REQ. Le message DSD-RSP contient un CID, un SFID, qui reprsente
le SFID provenant du message DCD-REQ correspondant, une transaction ID qui
reprsente lidentifiant du message DSD-REQ correspondant, et un code de confirmation.
Les dtails du comportement dune SS et dune BS pour la suppression dun flux de
service existant sont indiqus dans la Figure 2-10 et la Figure 2-11.

Figure 2-8 : Modification dun flow de service (initi par une SS)

Figure 2-9 : Modification dun flux de service (initi par une BS)

La gestion des flux de service dcrite dans cette section nous donne une ide sur les
diffrents messages de signalisation changs entre les stations dune cellule WIMAX, ainsi
que sur les informations contenues dans ces messages. Ce type dinformations savre assez
intressant pour pouvoir lexploiter et effectuer des amliorations et des optimisations de la
capacit globale du systme. En effet, le Chapitre 3 illustre une de nos propositions o
19

ETAT DE LART
nous exploitons le mcanisme de gestion des flux de service en faveur d'une application de
streaming vido.

Figure 2-10 : Suppression dun flux de service (initi par une SS)

Figure 2-11 : Suppression dun flux de service (initi par une BS)

Dans la prochaine section, nous dcrivons les diffrentes classes de services afin
didentifier la classe de service qui correspond aux applications de streaming vido
auxquelles nous nous sommes intresss.
2.2.4.4 Les classes de QoS
Le standard IEEE 802.16-2004 dfinit quatre classes de QoS: Unsolicited Grant
Service (UGS), real-time Polling Service (rtPS), non-real-time Polling Service
(nrtPS), et Best Effort (BE).
Lamendement IEEE 802.16e a ajout une cinquime classe de QoS au standard
802.16e, nomme Extended Real Time Polling Service (ertPS). Les diffrentes
caractristiques de ces cinq classes QoS sont rsumes ci-dessous.

Caractristiques de la classe BE : La classe de service BE est utilis pour les trafics

Best Effort, o il ny a de garantie ni de dbit, ni de dlai. Une SS pourra utiliser des
20

L'IEEE 802.16-2004
opportunits de requtes unicast, ou bien, les zones de concurrences pour envoyer leur
requtes. Il nexiste pas de paramtres de QoS obligatoires pour la classe BE.
Un exemple dapplication BE et le Email.

Caractristiques de la classe nrtPS : La classe de service rtPS a t conue pour les

flux de service non temps rel, qui ont une taille de paquet de donnes variable et un
intervalle inter-paquets variable. Le dbit maximum support, le dbit minimum rserv, et
la priorit sont les paramtres de QoS obligatoires pour cette classe.
Un exemple dapplications nrtPS est le File Transfer Protocol (FTP).

Caractristiques de la classe UGS : La classe UGS prsente les flux de service temps
rel ayant une taille de paquets de donnes fixe. Le dbit maximum support, la latence
maximale tolre et la gigue sont les paramtres de QoS obligatoires de cette classe.
Le dbit des services d'une classe UGS tant constant pendant toute la connexion, la
BS peut faire des allocations de bande passante de manire spontane. Pour chaque
utilisateur UGS, la BS doit allouer un dbit gal au dbit maximum de cet utilisateur.

Caractristiques de la classe rtPS : La classe rtPS inclut les flux de service temps rel
qui ont une taille de paquet de donnes variable. Le dbit maximum, le dbit minimum
rserv et la latence maximum tolre sont des paramtres obligatoires pour la classe de
service rtPS.
Les demandes en bande passante sont mises via des requtes unicast priodiques par
les SS destination de la BS. Pour chaque utilisateur rtPS, la BS doit allouer un dbit
suprieur ou gal au dbit minimum rserv
Un exemple dapplications rtPS est le transfert de flux vido.

Caractristiques de la classe ertPS : La classe ertPS inclut les flux de service temps
rel. Le dbit maximum, le dbit minimum rserv et la latence maximale tolre sont des
paramtres de QoS obligatoires pour cete classe.
La classe ertPS combine les avantages de deux classes de service, savoir lUGS et la
rtPS. Contrairement lUGS, o les allocations sont fixes, les allocations avec ertPS sont
dynamiques. Par la suite, la SS peut demander de changer la taille des allocations par l'envoi
d'une demande de changement de bande passante. Un exemple d'applications ertPS est la
VoIP.
Dans nos travaux, notre intrt se porte particulirement sur la classe de service rtPS.
En effet, nous nous intressons aux applications temps rel de type streaming vido et la
classe rtPS est la plus adquate pour ce type dapplications.
Une fois que les flux de service dune SS sont classs parmi les 5 classes de services que
nous venons de citer, la SS doit acqurir des ressources sur le canal pour pouvoir mettre
21

ETAT DE LART
ses donnes. Ceci seffectue laide de mcanismes de demande de bande passante,
envoys la BS.
2.2.4.5 Les techniques de demande de bande passante
Le standard dfinit plusieurs techniques pour l'tablissement des demandes en bande
passante de la SS vers la BS. On verra nanmoins, que la majorit de ces techniques
s'appuie largement sur la premire technique cite ci-dessous :

REQUESTS : Il s'agit de la requte classique BW-REQ pour demander de la bande

passante. En effet, une SS, ayant une allocation de ressources en UL disponible, peut
envoyer cette requte en indiquant la taille en octets de ressources dont elle a besoin et son
identit CID. Cette demande peut se faire de deux faons, la premire consiste envoyer
un en-tte PDU sans payload, il s'agit du Bandwidth Request Header . Dans le second
cas, on enverra un paquet PDU avec un en-tte gnrique, il y aura, ici, un sous-entte au
niveau du payload qui indiquera la demande de bande passante, il s'agit d'une demande
piggypacked .

GRANTS : Les GRANTS reprsentent les rponses aux requtes de bande

passante. Normalement une allocation est attribue une connexion particulire, mais les
GRANTS sont destins la connexion de base de la station. Dans le cas o la SS ne reoit
pas de rponse, ou que la donne est errone ou qu'il est trop tard pour l'appliquer, la SS va
dcider de relancer la requte ou d'annuler la transmission. Pour insrer sa demande, une
SS peut utiliser les "Request IE" en broadcast ou multicast si elle fait partie d'un groupe de
polling multicast. La SS peut utiliser les "Request IE" mme si la BS pourrait lui fournir un
meilleur Burst Profile.

PM-bit ( Poll Me ) : Les SS ayant au moins une connexion UGS active peuvent
utiliser le bit PM du sous-entte GM, dans un PDU MAC de la connexion UGS, pour
informer la BS quun polling est ncessaire pour des connexions non-UGS. En rponse
cette demande, la BS lance un processus de polling unicast.
Cette technique ne devrait tre utilise par les SS que lorsqu'il est impossible deffectuer
une demande de bande passante par les techniques de piggybacking ou de stealing .

POLLING : Le Polling est le processus travers lequel la BS alloue de la bande

passante la SS pour qu'elle puisse demander de la bande passante. Le polling n'est pas un
message explicite, il est reprsent sous la forme de plusieurs IE au niveau de l'UL-MAP.
Le polling peut tre ralis en broadcast, en multicast ou en unicast. Notons que le polling
se fait par station, alors qu'une demande de bande passante se fait par connexion. Le
polling unicast est envoy vers une SS via son basic CID, celle-ci va utiliser cette allocation
pour envoyer sa demande de BW pour n'importe quel CID. Dans le cas unicast, le polling
est exprim l'aide d'un Data Grant IE. Le polling multicast ou broadcast est un peu
22

L'IEEE 802.16-2004
diffrent. En effet, le polling est envoy pour un CID broadcast (0000) ou bien un CID
multicast.

Contention-based Bandwidth Request : L'OFDMA supporte deux techniques

base de contention. La premire utilise le format classique d'une BW REQ dfinit cidessous et la seconde utilise le mcanisme des codes CDMA. En effet, la couche PHY
OFDMA spcifie un sous-canal pour le ranging et un ensemble de codes ranging qui
devrait tre utilis pour la Contention based BW Request . Ainsi, une SS voulant faire sa
demande de BW, va choisir d'une faon quiprobable un code ranging, ce code sera
modul en un sous-canal ranging, puis transmis via l'allocation correspondante. Par
consquent, la BS alloue les ressources ncessaires la SS en indiquant non pas son basic
CID, mais plutt le broadcast CID en combinaison avec un CDMA_Allocation_IE
contenant l'allocation et le mme code ranging qui a t utilis.

Piggybacking : Pour demander de la bande passante, la SS peut envoyer un entte de demande de bande passante (6 octets), ou simplement intgrer la demande au sein
dun PDU en utilisant le sous-entte GM (Grant Management : 2 octets). Le mcanisme de
piggybacking est facultatif et ne peut tre utilis que pour demander de la bande
passante pour les connexions qui appartient le PDU contenant le champ GM.

Bandwidth stealing : Ce mcanisme fait rfrence l'utilisation, par les SS, d'une
partie de la bande passante dj alloue pour les donnes, pour transmettre une demande
de bande passante la place. Il est noter que puisque la SS reoit lallocation de bande
passante dans son ensemble en rponse aux demandes par connexion, la SS ne peut pas
savoir quelle demande sera accepte. La SS peut utiliser lallocation, soit pour envoyer des
donnes, soit pour envoyer la demande de bande passante pour une de ses connexions, ou
mme pour envoyer des messages de management.
Notre intrt dans cette thse se porte sur les applications de streaming vido qui sont
classes dans la classe de service rtPS. Par la suite, la technique de demande de bande
passante PM ddie la classe de service UGS, sera exclue ou non utilise dans notre cas.
En outre, la majorit des techniques et mcanismes que nous venons de voir sont les
techniques dfinis dans la standard 802.16, mais ils ne sont pas toujours implments. En
gnral, uniquement les techniques de base telle que les REQUEST, GRANT et
POLLING sont considres. En particulier, la plateforme de simulation (QualNet) que
nous avons utilise pour lanalyse de performance de nos solutions, intgre uniquement les
techniques essentielles de demande de bande passante. Dans le Chapitre 3, ces techniques
seront utilises par les SS WIMAX afin dacqurir des ressources en lien montant (UL)
pour envoyer les messages de gestion des flux de service relatifs aux applications vido.
Le standard IEEE 802.16 a dfini les couches MAC et PHY, les types de classes de
service (ou classes de QoS), les paramtres de QoS requis ainsi que les messages de
23

ETAT DE LART
management. Par contre, lalgorithme dordonnancement a t laiss comme un sujet
ouvert. Il appartient aux constructeur des quipements et aux oprateurs de choisir
lalgorithme dordonnancement le plus appropri. Nous dfinissons dans la prochaine
section lordonnancement dans les rseaux WIMAX en mode PMP.

2.3 Lordonnancement dans les rseaux IEEE 802.16

Lordonnanceur au niveau de la BS est responsable de l'ensemble du contrle d'accs
des diffrentes SS en lien descendant et en lien montant. Pour indiquer laffectation des
intervalles de transmission (ou Burst ) en lien descendant et montant, dans chaque trame,
la BS transmet les messages de signalisation DL-MAP et UL-MAP. Ces messages sont mis
au dbut de la sous-trame en lien descendant. Quand la SS reoit un message de gestion
UL-MAP, elle dtermine si elle peut accder au lien montant au cours de la trame courante.
Lordonnanceur utilis dans le systme WIMAX peut tre issu du monde du rseau
fixe ou spcifiquement conu pour un rseau WIMAX. Diffrentes stratgies peuvent en
effet tre employes, variant d'un simple Round Robin (RR) [13] qui ne considre pas les
conditions de la partie radio, au maximum Signal-to-Noise Ratio (mSIR), Temporary
Removal Scheduler (TRS) et le Earliest Deadline First (EDF) [14] qui tiennent compte
de certains paramtres de QoS comme la qualit du signal radio et le temps de latence.
Un ordonnanceur peut tre spcifiquement propos pour une classe de QoS telles que
[15] pour la classe BE ou [20] pour la classe rtPS. Un ordonnanceur peut tre galement
propos pour plusieurs classes de QoS [16].
2.3.1 Les ordonnanceurs classiques utiliss dans WIMAX
2.3.1.1

Ordonnanceurs systmatiques

Dans cette section, nous prsentons quelques ordonnanceurs qui servent

systmatiquement tous les abonns, sans tenir compte de leurs caractristiques de QoS ni
des conditions du canal radio.

Round Robin (RR) : Lordonnanceur RR, galement appele ordonnanceur

cyclique, distribue quitablement les ressources du canal aux demandes des paquets de
donnes multiplexs ou aux sessions. Cette technique est approprie si les abonns ont le
mme type de trafic et les mmes conditions radio. Nanmoins, tant donnes que ces
conditions varient d'un utilisateur un autre dans le contexte d'un rseau mobile, ce type de
scheduling n'est pas efficace dans ce contexte.

Weighted Round Robin (WRR): Lordonnanceur WRR [13] est une extension
de lordonnanceur RR. Il pondre les ressources alloues chaque SS en fonction de leur
demande de ressources. L'utilisation de WRR peut tre adapte un rseau WIMAX tout
24

Lordonnancement dans les rseaux IEEE 802.16

en faisant attention ce que l'algorithme d'attribution de poids/priorit reflte au mieux
l'tat conjointe du trafic/ressources.

Deficit Round Robin (DRR): Lordonnanceur DRR [17] fait de l'allocation par
paquet. En effet, DRR alloue virtuellement un certain montant de ressources chaque
connexion. Lordonnanceur DRR a besoin comme information d'entre du taux minimal
qui sera rserv chaque flux. Cette caractristique peut tre utile dans un rseau WIMAX,
car certaines classes de QoS ont besoin d'un dbit minimal rserv.
2.3.1.2

Ordonnanceurs prenant en compte les conditions du canal radio

Dans cette section, nous prsentons les ordonnanceurs capables de tenir compte des
conditions radio du canal.

Maximum Signal-to-Interference (mSIR): Lordonnanceur mSIR alloue les

ressources radio proportionnellement au rapport signal sur bruit ( Signal to Noise Ratio
SNR ) des SS. Par consquent, mSIR offre une meilleure gestion du spectre. Nanmoins,
les SS ayant un faible SIR risquent de ne jamais tre servi.

Temporary Removal Scheduler (TRS): TRS [18] permet de dterminer

l'ensemble des SS qui peuvent tre satisfaits. Cet ensemble est appel la liste
dordonnancement. Les SS ayant de mauvaises conditions radio sont temporairement
bloques. Le TRS fonctionne comme suit : il identifie les paquets ayant un SNR infrieur
un seuil dfini. Ces paquets sont temporairement retirs de la liste dordonnancement pour
une certaine priode de temps Tr puis rinsrs. Ce processus est rpt jusqu' ce que les
conditions radio soit meilleurs.
Le TRS se comporte particulirement bien lorsque les conditions radio du canal sont
fluctuantes. Il doit tre cependant combin avec un autre ordonnanceur afin de dterminer
les ressources attribuer chaque SS appartenant la liste de scheduling.

Opportunistic Deficit Round Robin (O-DRR): Dans [19], O-DRR est utilis au
niveau de la BS sur le lien montant. O-DRR opre comme suit : La BS envoie
priodiquement des allocations toutes les SS tous les k trames. Aprs chaque priode,
appele priode dordonnancement, la BS dtermine l'ensemble des SS qui peuvent
transmettre ainsi que leurs besoins en bande passante. En effet, une SS peut transmettre si
elle dispose d'une file d'attente non vide, et que le rapport signal sur interfrence et bruit
(SINR) se trouve au-dessus d'un seuil minimal.
La liste des SS est modifie dynamiquement en fonction des changements de l'tat de
la liaison radio de chaque SS. Au dbut d'une nouvelle priode de scheduling, la BS
rinitialise cette liste et excute le mme processus nouveau.

25

ETAT DE LART
2.3.2 Les ordonnanceurs spcifiquement proposs pour le WIMAX
Dans cette section, nous prsentons quelques ordonnanceurs tenant compte,
partiellement ou intgralement, de la qualit de service du WIMAX. Ces ordonnanceurs
sont proposs spcifiquement pour les systmes WIMAX et prennent en compte les
caractristiques des classes de QoS.
2.3.2.1

Ordonnanceurs proposs pour une classe de service spcifique

Adaptive rtPS Scheduler : Cet ordonnanceur [20] est utilis uniquement pour la
classe rtPS sur la prvision de l'arrive de paquets. Pour la classe rtPS, les paquets qui
arrivent aprs une allocation satisfaite par la BS doivent attendre la prochaine allocation
pour tre envoys car les allocations ne peuvent s'effectuer qu' la demande. Ceci introduit
par consquent un dlai supplmentaire pour ces paquets.
Pour pallier ce problme, lordonnanceur rtPS adaptatif propose un algorithme de
prdiction stochastique pour estimer l'arrive des donnes rtPS afin d'anticiper les
allocations futures pour ce type de trafic.

Adaptive Bandwidth Allocation Scheme (ABAS) : Le schma dallocation

ABAS propos dans [15] vise dterminer dynamiquement le meilleur rapport entre la
bande passante en lien descendant et montant. La BS dtermine tout d'abord les diffrentes
informations des connexions telles que les demandes de bande passante le nombre de slots
attribus aux sous-trames sur les liens descendant / montant, respectivement. La BS ajuste
sur la base de ces informations la rpartition entre les deux parties de la trame. La dcision
dordonnancement est par la suite transmise au diffrentes SS en utilisant les messages
MAC de gestion DL-MAP et UL-MAP. Le mcanisme est rpt au dbut de chaque
trame. ABAS est propos pour la classe BE en supposant que toutes les connexions ont les
mmes conditions du canal.
2.3.2.2 Ordonnanceurs proposs pour plusieurs classes de service QoS

Uplink packet scheduler with a Token Bucket Call Admission Control (CAC)
mechanism : Dans [21], un ordonnanceur en lien montant avec contrle dadmission est
propos. Le mcanisme CAC est bas sur le principe du Token Bucket .
L'algorithme dordonnancement fonctionne comme suit: toutes les connexions UGS
sont accordes. Par la suite, le CAC est appliqu aux paquets rtPS. Afin de servir les
paquets les plus prioritaires, lordonnanceur EDF ( Earliest Deadline First ) attribue les
priorits aux diffrents paquets en fonction de leurs temps de validit. Aprs avoir servi les
connexions UGS et rtPS, la BS attribue TnrtPS symboles aux connexions nrtPS, ensuite,
TBE symboles aux connexions BE. La bande passante rsiduelle est alloue quitablement
entre les connexions nrtPS et BE.
26

Lordonnancement dans les rseaux IEEE 802.16

Cross-layer Scheduling Algorithm with QoS Support : Dans [22], un nouvel

algorithme dordonnancement Cross-Layer est propos. L'ide principale de
lordonnanceur Cross-Layer est laffectation des priorits pour les diffrentes
connexions. Ces priorits dpendent des contraintes de QoS de chaque connexion.
Pour les connexions UGS, lordonnanceur doit garantir un nombre constant de slots
au cours de toute la priode de service. Pour les connexions rtPS et nrtPS, lordonnanceur
doit garantir le temps de latence et le dbit minimal rserv respectivement. Pour les
connexions BE, il n'y a aucune garantie de qualit de service mais un taux derreur des
paquets(PER) devrait tre maintenu.

Hybrid Scheduling Algorithm : L'algorithme hybride propos dans [23] utilise

deux ordonnanceurs diffrents. Lordonnanceur EDD est utilis pour les services temps
rel tandis que lordonnanceur WFQ est utilis pour les services non-temps rel. EDD est
bas sur la priorit dynamique. Dans une file d'attente EDD, les paquets sont classs par
ordre de leurs temps de validit. WFQ alloue les ressources radio en fonction des
diffrentes connexions. Puis, lordonnanceur WFQ peut fournir le dbit ncessaire pour
chaque connexion en attribuant des valeurs proportionnelles aux diffrents poids.
Nous avons vu dans cette section que lordonnancement, peut tre classique, peut
tenir compte des conditions radio et peut tenir compte dune classe de service quelconque.
Par contre, ces ordonnanceurs ne peuvent pas prendre en compte les paramtres dune
application temps rel telle que le streaming vido pour une meilleure allocation de
ressources.
En effet, le but principal de nos travaux est de permettre une certaine adaptabilit et
scalabilit des applications vido en fonction des conditions rseaux, notamment en termes
de ressources radios. Les ordonnanceurs prsent ci-dessus ne rpondent pas toutes les
contraintes. En premier lieu, les ordonnanceurs classiques traitent toute les classes de
service de la mme faon, ainsi, la classe rtPS naura pas de traitement spcial. Ensuite, les
ordonnanceurs ddis aux rseaux WIMAX mais qui sont une solution pour plusieurs
classes de service, ne font que dfinir un ordre de priorit entre les classes.
Finalement, lordonnanceur ddi la classe rtPS dfini plus haut est une approche de
prdiction pour estimer les prochaines allocations pour ce type de trafic, mais cet
ordonnanceur na aucune ide de la nature de lapplication relative au flux rtPS concern.
En particulier, les applications de streaming vido que nous considrons dans cette thse,
sont dotes dune lasticit et dune capacit dadaptation afin de changer de dbit vido
mis depuis le serveur. Ainsi, dans nos approches, nous ajoutons des fonctionnalits au
niveau de lordonnanceur pour la prise en compte dune telle proprit. Dans le cas de
pnurie de ressources par exemple, lordonnanceur dtecte les flux rtPS (type vido)
lastique ou scalable et leur demandera de rduire leur dbit vido.
27

ETAT DE LART

2.4 IEEE 802.16j (Mobile Multi hop Relay)

2.4.1 Introduction
Les systmes base de relais comprennent gnralement des relais qui sont associs
des stations de base spcifiques. Ils peuvent tre utiliss pour tendre la zone de couverture
d'une BS et/ou augmenter la capacit d'un systme d'accs mobile [80] [81]. En rgle
gnrale, ils sont intgrs dans la conception des solutions ds les premires phases de
dploiement du rseau afin d'amliorer la zone de couverture d'une solution mono BS
moindre cot, ils peuvent aussi tre utiliss pour augmenter la capacit de rseaux dj
dploys typiquement dans les zones denses.
LIEEE 802.16j est un groupe de travail au sein du 802.16 dont l'objectif est de
dvelopper une extension des standards 802.16 et 802.16d afin de supporter la
fonctionnalit de relais fixe et mobile. Dans cette section nous prsentons un aperu des
aspects les plus importants de la version actuelle de la norme 802.16j.
2.4.2 Linitiative et la motivation de standardisation de lIEEE 802.16j
Le standard 802.16j est dvelopp pour intgrer le mode relai dans les rseaux 802.16
afin de rduire les cots oprationnels et dinvestissement (OPEX/CAPEX) et en
consquence faciliter les dploiements. Pour ce faire, le groupe de travail 802.16j vise
dfinir des stations de relais RS avec une complexit nettement infrieure celle dune BS
802.16e-2005. Les deux principaux cas d'utilisation du 802.16j consistent en laugmentation
de la couverture et lamlioration de la capacit. La premire utilisation peut tre divise en
deux sous-cas lgrement diffrents: l'extension de la zone de couverture d'une BS en
utilisant des techniques multi-sauts et le traitement des problmes de saut de couverture
(par exemple, les ombres des btiments). Le deuxime cas d'usage est laugmentation de la
capacit du systme qui peut tre ralise grce l'utilisation des liens multiples avec une
plus grande efficacit. De plus, la solution multi-sauts permet la rutilisation spatiale de
frquences, ce qui rsulte en l'augmentation de la capacit du systme global.
2.4.3 Spcifications de lIEEE 802.16j
2.4.4 Les modes de relais
La norme dfinit deux modes de fonctionnement pour les relais : le mode transparent
et le mode non transparent. La principale diffrence entre ces deux modes de
fonctionnement du relais est de savoir comment les trames d'information sont transmises :
en mode transparent, le relais ne transmet pas les informations dentte de la trame, alors
quen mode non-transparent, ils sont transmis. Lentte de la trame contient des
28

IEEE 802.16j (Mobile Multi hop Relay)

informations dordonnancement essentielles pour les nuds afin de dterminer quel
moment ils peuvent transmettre et recevoir des informations. Cette diffrence donne lieu
des caractristiques trs diffrentes entre les deux modes de fonctionnement.
En association avec le mode de relais, il existe deux options diffrentes pour
lordonnancement: centralises et distribues. Dans le premier cas, lordonnancement pour
tous les nuds dans le systme est effectu par la BS, alors que dans le second cas, les RS
(Relay Station) ont une certaine autonomie et peuvent prendre des dcisions
d'ordonnancement pour les nuds avec lesquels ils communiquent.

Le mode transparent : Dans ce mode, les RS ne transmettent pas dinformations

den-tte sur la trame, et ainsi ne permettent pas daugmenter la zone de couverture. Par
consquent, le cas d'utilisation principale des relais en mode transparent est l'augmentation
des capacits au sein de la zone de couverture de la BS. Ce type de relais est dot dune
complexit rduite, et fonctionne uniquement dans un mode dordonnancement centralis
dans le cadre d'une topologie deux sauts maximum.

Le mode non-transparent : Les RS gnrent leurs propres informations den-tte

dans la trame, ou transmettent celles prvues par la BS selon l'approche d'ordonnancement
(distribue ou centralise). Ils sont principalement utiliss pour augmenter la
couverture. D'autre part, la transmission des informations den-tte de la trame peut
provoquer un niveau d'interfrence lev entre les RS voisines, par consquent, sans
conception efficace, le renforcement des capacits, qui peut tre obtenu en utilisant ces
relais est limit. Les relais non-transparents peuvent fonctionner dans des topologies de
plus de deux sauts en mode dordonnancement centralis ou distribu, conduisant
diffrents niveaux de complexit de la RS.
Puisque les relais transparents (T_RS) et les relais non-transparents (NT_RS) ont des
avantages diffrents, il peut y avoir certains scnarios dans lesquels il est logique d'associer
les deux modes avec une BS unique. Cependant, la norme donne peu de dtails sur la faon
de raliser cela. Le Tableau 2-2 illustre la diffrence entre les deux modes de relais.

Extension de la couverture
Nombre de sauts
Interfrence entre RS
Performance

Cot de la RS
Ordonnancement

RS transparente

RS non Transparente

Non

Oui

2 ou plus

Aucune

importante

Dans la zone de la BS : lev

Dans la zone de la BS : comme en 802.16e

Hors de la zone de la BS : ___

hors de la zone de la BS : moyenne

faible

lev

Uniquement centralis

Centralis ou distribu

Tableau 2-2. Comparaison entre mode de relais transparent et non transparent

29

ETAT DE LART
2.4.5 Spcifications de la couche PHY : structure de la trame
Comme la structure de trame, dfinie dans les prcdentes normes 802.16, a t conue
pour oprer dans un systme un seul saut, des modifications ont t ncessaires pour
supporter le relai. Comme pour l'ancienne structure de trame 802.16, la trame est divise en
deux sous-trames : une en liaison descendante (DL) et une autre en liaison montante
(UL). Toutefois, contrairement la structure de trame prcdente, ces sous-trames sont
divises en zones pour les communications RS-BS et RS-SS : la diffrence de zones facilite
les communications entre les diffrentes parties du systme.
Dans les deux modes transparents et non transparents, les zones d'accs ( Access
Zone ) sont dfinies pour supporter la communication entre BS ou NT_RS et SS ou
T_RS. Dans le mode transparent une zone dite zone transparente ( Transparent Zone )
est dfinie pour les communications entre T_RS et SS. Dans le mode non transparent, les
zones de relais sont dfinies pour les communications entre BS ou NT_RS et NT_RS. Les
Figure 2-12 et Figure 2-13 illustrent la structure de la trame pour le mode non transparent
du ct de la BS et de la RS respectivement.

Figure 2-12 : Structure de la trame en mode relais non transparent vue par la BS [3]

Figure 2-13 : Structure de la trame en mode relais non transparent vue par la RS [3]

30

IEEE 802.16j (Mobile Multi hop Relay)

2.4.6 Spcifications de la couche MAC
Trois diffrents aspects de la couche MAC sont prsents ci-dessous : le modle de
transmission ( Forwarding Scheme ), le routage et les mcanismes de gestion des chemins
( Path Management ), et les mcanismes d'entre en rseau ( Network Entry ).
2.4.6.1

Les modles de transmission

Deux modles de transmission diffrents sont dfinis, les deux tant destins
maximiser la capacit du systme par l'agrgation de trafic lorsque cela est possible : le
mode de transmission base de tunnel et le mode de transmission base de connexion
CID. Cette agrgation de trafic a deux principaux avantages: il peut en rsulter des gains en
efficacit du systme puisque moins d'information de signalisation est envoye, et il en
rsulte une gestion plus simple puisque plusieurs groupes de flux peuvent tre traits
ensemble.
La transmission base de tunnel fournit un support pour les tunnels explicite
caractris par : un CID unique, deux points dextrmit spcifiques, et un besoin en qualit
de service. Le modle base de CID n'a pas de tels tunnels et ne supporte pas
explicitement l'agrgation de trafic, mais ncessite moins de complexit. Dans l'approche
base de tunnel, les tunnels sont utiliss pour agrger le trafic des MS sur la connexion entre
RS et BS pour des connexions de gestion ou de transport avec des exigences de qualit de
service similaires. Lapproche base de CID, d'autre part, ne supporte que les connexions
de gestion et de transport tels que dfinis dans la norme 802.16e. Ces deux modles
peuvent tre diffrencis en termes de gestion de la QoS, de gestion des erreurs, et de la
charge ajoute.
2.4.6.2 Routage et gestion des routes
Comme les rseaux 802.16j comportent des routes multi-sauts entre la BS et la MS, la
question du routage et de la gestion des routes se pose. Bien que le routage dans de tels
systmes est base de structure darbre, il peut y avoir des dcisions prendre concernant
lassociation dune RS et dune MS. La gestion de routes renvoie des questions relatives
l'tablissement dune route, l'entretien, et la libration pour laquelle diffrentes techniques
de gestion de routes ont t proposes.

Routage et slection de route : La norme prvoit des dcisions de routage en

fonction des paramtres tels que la disponibilit des ressources radio, la qualit du lien
radio, et la charge de trafic vers les RS, mais la norme n'indique pas la faon dont la
dcision doit tre prise, les dtails de la dcision de slection de route sont laisss aux
fournisseurs. La norme dfinit deux approches de gestion des routes : une approche
intgre et une approche explicite. La principale diffrence entre ces deux approches rside

31

ETAT DE LART
dans la faon dont les informations de signalisation pour grer la route sont distribues
dans le systme.
2.4.6.3 Procdure d'entre en rseau
Il y a deux aspects diffrents pour lentre en rseau dans 802.16j ; les procdures
d'entre en rseau pour les MS et les procdures d'entre en rseau pour les RS. Comme la
norme 802.16j doit maintenir la compatibilit avec les terminaux WIMAX existants, la
procdure d'entre en rseau vue par le terminal doit rester inchange. Toutefois, il existe
des diffrences sur la faon dont la BS et les RS utilisent cette procdure venant du fait que
le rseau a besoin de dterminer quel nud doit tre le nud d'accs pour la MS. Le
processus dinitialisation ( initial ranging ) dans les systmes 802.16j varie en fonction du
mode dordonnancement et du mode de relais: les diffrents processus dinitialisation
peuvent tre distingus comme suit:

Initialisation dune MS dans le mode de relais transparent : Les RS coutent le

canal dinitialisation de la zone d'accs en UL et transmettre les codes dinitialisation qu'ils
reoivent vers la BS. La BS attend un dlai dtermin pour recevoir dautres messages avec
le mme code dinitialisation, partir dautres RS et dtermine en consquence la route la
plus approprie pour la station ( savoir, directement ou via une interface RS). Si la route
d'accs direct est choisie, la BS envoie une rponse directement la MS. Sinon, la rponse
est envoye la RS qui la transmet, ensuite, la MS.

Initialisation dune MS dans le mode de relais non transparent : En raison des

contraintes existantes, la MS choisit la BS ou le NT_RS avec le plus fort prambule
dtect. Cela signifie qu'il n'y a pratiquement aucune dcision de routage faire dans ce cas.
Comme cest la BS qui rend la dcision finale d'entre en rseau, la RS doit communiquer
avec la BS pour s'assurer que la MS est autorise entrer dans le rseau. Dans le cas
centralis cela implique la communication de toutes les informations dinitialisation la BS,
mais dans le cas distribu la RS gre les fonctions dinitialisation et fait simplement une
requte d'entre au rseau la BS.
Le processus d'entre en rseau pour les RS comprend des tapes supplmentaires et
dfinit un processus dinitialisation spcifique. Plus prcisment, l'entre en rseau est
complte par une dcouverte de voisinage et le processus d'valuation suivi par un
algorithme de slection de route afin de dterminer la station daccs la plus approprie
pour la RS.
Dans la prochaine section, nous dcrivons la nature des applications de type streaming
vido. Nous prsentons les diffrents protocoles multimdia et les diffrents codages vido
afin didentifier les caractristiques et les contraintes de ce type dapplication, notamment,
dans le cadre dune transmission au sein dun rseau sans fil tel que leWIMAX.
32

Les applications de streaming vido

2.5 Les applications de streaming vido

Dans le cadre de notre tude, nous nous sommes intresss aux applications de
streaming vido qui, loppos du tlchargement vido, permettent la visualisation dun
flux vido au fur et mesure de sa rception. Les applications de streaming permettent la
diffusion de flux vido temps rel. Le streaming sur les rseaux IP se base principalement
sur deux modes de transmission : lunicast et le multicast. Le premier mode ncessite la
duplication dun flux vido pour chaque rcepteur et dans le deuxime mode, un flux est
transmis pour un groupe de rcepteurs (vidoconfrence).
Actuellement, les applications de streaming vido souffrent du manque de QoS dans
les rseaux IP qui affecte la transmission des paquets et dgrade, par la mme, la qualit de
la vido perue par le rcepteur. De plus, lhtrognit grandissante dans les rseaux IP
oblige ces applications sadapter plusieurs paramtres, comme le dbit du rseau daccs,
les capacits du terminal rcepteur, etc.
2.5.1 Les protocoles multimdia
Le rle principal des protocoles multimdia et de fournir des fonctionnalits de base
aux applications pour le contrle, la description et la transmission de flux multimdia. Une
brve description de chaque protocole est prsente ci-dessous :

H.323 [24] [25] : Il dfinit un ensemble de protocoles et darchitectures pour la

communication audio/vido/donnes sur les rseaux IP en mode centralis.

SIP ( Session Initiation Protocol ) [26] : Il permet ltablissement, la

modification et la libration de sessions multimdia. Une session multimdia peut
reprsenter un appel tlphonique sur IP, une confrence multimdia ou une
distribution de contenus multimdia.

RTSP ( Real Time Streaming Protocol ) [27] : RTSP est un protocole de

niveau applicatif qui permet ltablissement et le contrle dune session multimdia
entre un client et un serveur afin de transmettre un, ou plusieurs, flux audio/vido
en unicast ou en multicast.

SDP ( Session Description Protocol ) [28] : SDP dfinit un format pour la

description dune session multimdia. La description inclut plusieurs informations,
comme le nom de la session, sa dure, les flux multimdia quelle contient et les
informations ncessaires la rception de ces flux.

SAP ( Session Announce Protocol ) [29] : SAP est utilis pour annoncer une
session multimdia multicast et transmettre la description de cette session aux futurs
participants.
33

ETAT DE LART

RTP/RTCP ( Real Time Protocol / Real Time Control Protocol ) [30] :

RTP est un protocole de niveau applicatif qui offre des fonctions de transport de
bout-en-bout pour les flux multimdia.

2.5.2 Les standards de codage vido et le codage vido hirarchique

La majorit des standards de codage vido ont t dvelopps par deux organismes de
standardisation : MPEG ( Moving Pictures Expert Group ) de ISO/IEC et VCEG
( Video Compression Expert Group ) de lITU-T ( International Telecommunication
Union Telecommunications ). Une brve description de ces standards est donne cidessous :

H.261 [31] : Dfini en 1990 par le groupe VCEG, il a t utilis principalement pour la
vidoconfrence sur les rseaux ISDN ( Integrated Services Digital Network ).

H.263 [32] : Dfini en 1996 par le groupe VCEG, il se base sur larchitecture H.261
avec de nouveaux algorithmes pour amliorer les performances du codage.

MPEG-1 [33] : Publi par le groupe MPEG en 1991, il a t dvelopp principalement

pour le stockage des vidos sur des supports numriques (CD-ROM) avec un dbit
vido de 1.5 Mbits/s

MPEG-2 / H.262 [34] : Publi en 1994, il permet une trs grande flexibilit de formats
et des dbits vido levs pour la HDTV ( High-Definition Television ) et la SDTV
( Standard-Definition Television ).

MPEG-4 Part-2 [35] : Publi en 2000 par le groupe MPEG, il reprsente le premier
codec vido orient objet dvelopp principalement pour les applications multimdia
interactives.

H.264 AVC ( Advanced Video Coding ) / MPEG-4 part-10 [36] : Publi en 2003,
il offre une plus grande performance de codage compar au MPEG-2 et MPEG-4 et il
vise diverses applications : la diffusion TV, le HD-DVD, le stockage numrique, et la
TV mobile.

Actuellement, les efforts sont orients vers le codage vido hirarchique SVC
( Scalable Video Coding ) [37] afin de rpondre aux besoins des nouvelles applications
multimdia qui doivent transmettre des flux vido sur des rseaux htrognes.
Contrairement aux codecs prcdents, qui gnrent un seul flux vido avec une seule
couche, le SVC gnrent plusieurs flux correspondant plusieurs couches hirarchiques,
une couche de base (BL : Base Layer ) et une ou plusieurs couches damlioration (EL :
Enhanced Layer ). La couche de base se suffit elle-mme pour le dcodage, mais le
34

Les applications de streaming vido

dcodage des couches suprieures ncessite le dcodage de la couche de base. La dfinition
du nouveau standard SVC se base sur larchitecture H.264/AVC. Les couches
hirarchiques peuvent tre construites sur trois dimensions :

La hirarchie temporelle : Correspond diffrents nombres dimages par seconde (frame

rate). La couche de base est constitue des images I ( Intra-coded frame ) et P
( Predicatively coded frame ) et les couches damlioration sont constitues dimages
B ( Bi-directionally predicted frame ) insres entre les images I et P.

La hirarchie spatiale : Correspond diffrentes dimensions dimage. Les couches

suprieures fournissent une plus grande taille dimage.

La hirarchie en qualit (SNR) : Correspond diffrentes qualits dimages. Les couches

suprieures permettent dobtenir une qualit plus fine de limage avec plus de prcision.

En tronquant les couches suprieures, les applications multimdia peuvent mieux

sadapter diffrents paramtres. Par exemple, le dbit disponible dans le rseau en
utilisant la hirarchie en qualit ou la capacit daffichage dun terminal en utilisant la
hirarchie spatiale.
2.5.3 Ladaptation de la QoS pour la transmission vido
La transmission des paquets vido doit considrer les paramtres principaux qui
caractrisent les rseaux IP, savoir le dbit, les pertes de paquets, le dlai de bout-en-bout
et la gigue. Durant ces dernires annes, plusieurs techniques ont t utilises par les
applications multimdia afin de palier aux variations de ces facteurs et de minimiser leurs
effets sur la qualit de la vido perue par le rcepteur. Nous dtaillons dans ce qui suit
quelques travaux qui permettent principalement dadapter le dbit de la vido en fonction
du dbit disponible dans le rseau:

Simulstore [38] : La solution Simulstore propose de stocker sur un serveur plusieurs

flux dun mme contenu avec diffrentes caractristiques spatiales, temporelles et de
qualit (SNR). Le bon flux est choisi et transmis en fonction du dbit de lutilisateur.
Cependant, cette solution est statique et ne peut pas sadapter au changement
dynamique du dbit durant la transmission.

Transcoding [39] [40] [41] : Le transcoding permet de transformer une vido dun
format vers un autre en changeant la taille de limage, le nombre dimages par seconde,
la qualit de la vido ou le dbit. Cette solution ne ncessite pas un grand espace de
stockage, par contre, elle consomme normment de ressource de calcul pour excuter
le transcodage. De plus, elle introduit une latence supplmentaire qui peut tre
contraignante pour les services multimdia interactifs.
35

ETAT DE LART

SVC Sclable Video Coding [37] : Le codage hirarchique, dcrit plus haut,
permet le codage de la vido en plusieurs couches hirarchiques, une couche de base et
plusieurs couches damlioration. Ladaptation seffectue simplement en supprimant
une ou plusieurs couches damlioration. Plusieurs travaux se sont intresss ce type
dadaptation qui peut supporter la monte en charge [42] [43] [44]. Linconvnient du
codage hirarchique est la dpendance des couches suprieures de la couche de base
lors du dcodage, ce qui ncessite la bonne rception de la couche de base.

MDC Multiple Description Coding : Avec le codage MDC, une vido est
code en plusieurs descriptions, ou flux, indpendants. Le MDC possde deux
proprits importantes : (1) Chaque flux peut tre dcod indpendamment des autres
en donnant une certaine qualit de vido, (2) les informations des flux sont
complmentaires ce qui permet daugmenter la qualit de la vido en augmentant le
nombre de flux dcods simultanment. Plusieurs algorithmes de codage MDC ont t
proposs dans plusieurs travaux [45] [46] [47]. Dautres travaux [49] [50] [51] [52] se
sont intresss lexploitation de ce type de codage dans des architectures de
transmission vido.

En plus de limpact du dbit du rseau, les pertes de paquets vido affectent

considrablement la qualit de la vido. La dgradation de la qualit est accentue par leffet
de la propagation des erreurs [53] due la dpendance du dcodage des images I, P et B.
Ci-dessous, nous prsentons quelques mcanismes qui ont t dvelopps afin de faire face
aux pertes de paquets et de minimiser leur impact sur la qualit de la vido.

ARQ ( Automatic Repeat reQuest ) [54] [55] : La retransmission des paquets

vido perdus est considre comme un mcanisme simple. Lutilisation dARQ suppose
la prsence dune voie de retour entre lmetteur et le rcepteur. Cependant, la
retransmission introduit une latence supplmentaire. De plus, la mise en place dun
mcanisme ARQ pour les transmissions multicast est complexe et sa mise lchelle est
limite cause du nombre dacquittements que peut recevoir le serveur.

FEC ( Forward Error Correction ) : Le mcanisme FEC ajoute des paquets de

redondance aux flux de paquets original, au niveau de lmetteur, afin de permettre au
rcepteur de reconstruire les paquets perdus [56] [57]. Les paquets redondants sont
gnrs par des codes correcteurs traditionnels (Reed Solomon, etc.) en considrant un
paquet comme tant un symbole. Le principal inconvnient de la FEC est la
consommation additionnelle du dbit due lajout de donnes redondantes.

UEP ( Unequal Error Protection ) [59] [60] : Le UEP offre une protection
diffrente des paquets vidos. Il se base principalement sur le codage hirarchique o la

36

Les mcanismes Cross-Layer pour les rseaux WIMAX

couche de base doit tre mieux protge contre les pertes, compare aux couches
damlioration.

Errors concealment [61] : Cette technique opre au niveau image en essayant

destimer les informations, ou pixels, perdues partir dinformations correctement
reues. Pour cela, elle se base sur la forte corrlation spatiale et temporelle qui existe
dans les images vido et qui est exploite par les algorithmes de codage.

Dans cette section, nous avons vu les diffrentes caractristiques des applications de
type streaming vido ainsi que les diffrents travaux raliss pour ladaptation du dbit de
ces applications en fonction du dbit du rseau et pour palier aux problmes causs par les
pertes des paquets vido.
Pour une meilleur adaptation et optimisation des applications de streaming vido au
sein dun rseau, ces applications devraient avoir une ide sur les caractristiques du rseau
concern. La connaissance de ltat et de la qualit du rseau, spcialement dans le cas de
rseaux sans fil, permettrait ces applications dadapter leur comportement.
Cela peut tre ralis laide de nouveaux mcanismes qui permettent une meilleure
communication entre les diffrentes couches du rseau dans le but damliorer la
performance globale du systme. Dans la prochaine section, nous dcrivons ce type de
mcanismes que sont les Cross-Layers.

2.6 Les mcanismes Cross-Layer pour les rseaux WIMAX

2.6.1 Le concept du Cross-layer
Le modle OSI dfinit une architecture en couches avec une hirarchie de services.
Cependant, cette mthode ne conduit pas ncessairement une solution optimale,
notamment pour les rseaux sans fil. La recherche sur les mcanismes Cross-Layer dans les
rseaux sans fil a t stimule par le fait que l'tat du canal sans fil varie au cours du temps
et que les ressources limites sont partages par plusieurs utilisateurs.
Le concept de Cross-layer permet la dfinition de protocoles ou de mcanismes qui
violent lisolation des couches du modle OSI. Ainsi, il autorise la communication entre
deux, ou plusieurs couches dans le but damliorer les performances globales du systme.
Ceci peut tre ralis par la dfinition de nouvelles interfaces au niveau des couches
qui permettent de rcuprer leurs paramtres de performances. Ces paramtres peuvent
tre utiliss par les mcanismes dadaptation pour amliorer la performance globale de la
communication en se basant sur des politiques dadaptation.

37

ETAT DE LART
2.6.2 La communication dans les architectures Cross-Layer
Le principe de base du concept Cross-layer est de permettre lchange dinformations
entre les couches adjacentes et non adjacentes afin damliorer les performances de
transmission. Parmi toutes les architectures Cross-layer proposes dans la littrature, deux
modles de communication peuvent tre distingus [62] [63] : La communication directe
entre les couches ou la communication via une base de donnes partage entre les couches.

Communication directe entre les couches

La communication directe entre les couches est le modle le plus utilis par les
architectures Cross-layer. Il permet une couche daccder directement aux paramtres et
aux variables dune autre couche sans passer par un intermdiaire.
Cette communication peut tre in-band en utilisant les en-ttes des protocoles
existants, ou out-of-band en utilisant un nouveau protocole de signalisation tel que
CLASS (Cross-layer signaling shortcuts) [64]. La communication out-of-band peut
seffectuer aussi en dfinissant de nouvelles interfaces qui seront utiliss directement pour
rcuprer et configurer des paramtres de fonctionnement [65].

Communication via une base de donnes partage

Plusieurs architectures Cross-layer [66] [67] proposent lutilisation dune base de

donnes partage afin de stocker et de rcuprer des paramtres. Cette base est accessible
par toutes les couches qui peuvent, ainsi, sinformer de ltat des autres couches ou
rcuprer des paramtres de configuration ncessaires leur fonctionnement interne
2.6.3 Les approches du Cross-Layer
Dans la littrature, plusieurs techniques Cross-layer ont t proposes pour amliorer
les performances des transmissions sans fil. Au dbut, ces mcanismes taient limits
linteraction entre la couche physique et la couche liaison de donnes. Par la suite, nous
avons assist lapparition de plusieurs travaux proposant des interactions avec les couches
suprieures, prenant en charge plusieurs paramtres, pour une optimisation globale. Ces
travaux peuvent tre classs en trois approches identifies dans [62] [68]: Lapproche
ascendante (Bottom-up) o les couches suprieures optimisent leurs mcanismes en
fonctions des paramtres des couches infrieures, lapproche descendante (Top-down) o
les couches infrieures considrent certaines spcificits de niveau applicatif pour excuter
leurs traitements, et lapproche mixte (Integrated) qui exploite les deux approches
prcdentes dans une mme architecture afin de trouver la meilleure configuration intercouches pour un fonctionnement optimal du systme.

38

Les mcanismes Cross-Layer pour les rseaux WIMAX

Les approches ascendantes (Bottom-up)

Dans [69] les auteurs proposent un algorithme pour lallocation de ressources dans les
rseaux 3G. En effet, la variation du canal de transmission et la diversit multiutilisateur est
sont exploites pour fournir des services en continu uniquement aux MS dont la qualit du
canal de transmission est leve. La MS, dont ltat instantan du canal est faible, reporte
ses transmissions jusqu' ce que son canal change dtat afin de ne pas pnaliser les autres
MS.
Un algorithme dordonnancement se basant sur ltat du canal (CSI : Channel State
Information) a galement t propos pour les rseaux satellitaires dans [70]. Lalgorithme
est implment au niveau liaison de donnes est exploite ltat du canal satellitaire pour
dcider de lenvoi dun paquet. Le canal est aussi modlis par deux tats : bon tat et
mauvais tat.
Les auteurs dans [71] explorent une architecture Cross-layer pour la transmission des
flux vido sur des rseaux sans fil. Larchitecture Cross-layer propose maintient la
structure en couche et identifie les principaux paramtres qui peuvent tre changs entre
ces couches. Ainsi, une technique dadaptation est propose au niveau liaison de donnes
qui dtermine la taille optimale dun paquet en fonction de la modulation et du codage qui
sont leur tour adapts en fonction du SINR (Signal-to-Interference-plus-Noise Ratio).

Les approches descendantes (Top-down)

Lordonnancement optimal pour minimiser la congestion et la distorsion (CoDiO :

Congestion-Distortion Optimized) est lune des principales techniques dans les approches
descendantes tudies dans plusieurs travaux [71] [72] [73]. La distorsion correspond la
diffrence de qualit entre la vido encode, ct metteur, et la vido dcode, ct
rcepteur. Le CoDiO vise minimiser cette distorsion suivant les contraintes du dbit
disponible dans le rseau.
Dans [74], les auteurs proposent une optimisation des performances du protocole TCP
sur les rseaux sans fil 3G. Cette optimisation propose une variation de plusieurs
paramtres au niveau de laccs rseau afin de les faire correspondre au dbit calcul au
niveau TCP.
Dans [75], les auteurs soulvent le problme de la retransmission (ARQ) qui peut tre
prsent au niveau liaison de donnes et au niveau transport. En effet, la prsence de ce
mcanisme au niveau liaison de donnes introduit un dlai de transmission dsagrable
pour les flux temps rel. Pour y faire face, les auteurs proposent un systme ARQ adaptatif
qui permet de fournir un ARQ personnalis en fonction des besoins des applications.
39

ETAT DE LART

Les approches mixtes (Integrated)

Dans [76], les auteurs prsentent une architecture Cross-layer pour analyser,
slectionner et adapter les diffrentes stratgies prsentes sur les couches du modle OSI.
Ceci dans le but daugmenter la qualit des flux multimdia, de prserver la consommation
dnergie des terminaux et doptimiser lutilisation spectrale des canaux de transmission.
Loptimisation Cross-layer a pour but de slectionner la meilleure stratgie qui offre la
meilleure qualit de service pour les flux multimdia sous les contraintes des transmissions
sans fil ainsi que les contraintes du systme.
Dans [66], CrossTalk est propose pour les rseaux ad hoc. Son objectif est de
prserver la structure en couches tout en permettant des amliorations de performance. Le
concept fournit une vue globale de ltat du rseau en utilisant plusieurs mtriques
prsentes sur diffrentes couches. Cette vue globale permettra chaque nud rseau de
comparer son tat local avec ltat global du rseau afin dappliquer les adaptations
ncessaires.
Dans [77], les auteurs proposent un nouveau mcanisme de protection Cross-layer qui
fournit une QoS adaptative en exploitant conjointement le codage en couches des vidos,
les files dattente prioritaires au niveau de la couche rseau et ladaptation de la
retransmission au niveau liaison de donnes des rseaux sans fil. Le mcanisme Cross-layer
propos a pour but de trouver un compromis entre le nombre de retransmissions (ARQ),
et la taille des files dattente au niveau de la couche rseau.
Dans [67] [78] [79], une stratgie doptimisation Cross-layer est propose. Cette
stratgie permet doptimiser conjointement le fonctionnement des couches application,
liaison de donnes et physique. Loptimisation Cross-layer dans cette nouvelle stratgie est
pilote par la couche applicative puisque lobjectif principal est de maximiser la satisfaction
de lutilisateur en relation directe avec lapplication.
Dans les approches ascendantes, nous avons vu que le Cross-Layer intervient pour
prendre une dcision de transmettre un flux de donnes multimdia par exemple
uniquement aux clients qui possdent de bonnes conditions radios, ou encore exclure ou
modifier la taille de certains paquets du flux en question. Par consquent, les flux vido
auxquels nous nous intressons et qui sont trs sensibles la perte, ne peuvent pas tre
traits convenablement par ces mcanismes. De plus, le but de nos travaux est de satisfaire
le maximum de clients, mme dans les mauvaises conditions radio.
Dans les approches descendantes, les solutions Cross-Layer proposes se focalisent sur
la couche 3 en optimisant les techniques de transport et de contrle de congestion afin
dviter les pertes de paquets de type temps rel ou de dcider quel paquets doivent tres
40

Conclusion
supprims, retransmis, etc. selon les besoins de lapplication. Ces solutions supposent que
les couches basses sont capables de sadapter aux besoins des applications, alors que dans le
cas de mauvaises conditions radio ou dun trafic trs charg, la congestion est trs
fortement probable et les pertes sont normes. Par consquent, les adaptations sont
limites et les rsultats sont insuffisants pour satisfaire les applications.
Dans les approches mixtes, certaines solutions proposent des amliorations gnrales
du rseau en faisant profiter toutes les couches du modle OSI en tenant compte de tous
les paramtres. Ces modles sont assez complexes, il faut dfinir tous les paramtres de
chaque couche qui entrent en jeu, dfinir ceux qui sont dpendants les uns des autres, ceux
qui sont modifiables et ceux qui ne sont pas contrlables.
Dans les approches Cross-Layer que nous proposons dans cette thse, nous optons
pour des approches ascendantes puisque nous nous intressons ladaptation des flux
multimdia en fonction de ltat du rseau. Dans la solution dcrite dans le Chapitre 3, la
couche liaison de donnes et la couche Radio fournissent les informations ncessaires la
couche applicative, ct serveur, afin dadapter son dbit vido. Dans la solution prsente
dans le Chapitre 4, la couche liaison de donns et la couche Radio dfinissent la meilleur
distribution des flux vidos en fonction de la modulation et des ressources radio
disponibles et permet, par la suite, lapplication vido, ct client, dadapter la qualit
vido demande au serveur.

2.7 Conclusion
Dans ce chapitre, nous avons prsent ltat de lart de la technologie WIMAX, nous
avons dfini les diffrents aspects des couches PHY et MAC du standard 802.16 qui se
relatent nos travaux. Nous avons discut de la gestion de la QoS dans la couche MAC
802.16 et les contraintes et limitations des ressources de la couche PHY 802.16. En outre,
nous avons prsent la nature et les contraintes des applications de streaming vido.
Ceci nous a amen prsenter le concept Cross-Layer qui permet de palier ces
limitations en autorisant un change dinformation entre les couches. Ce nouveau
paradigme suscite un grand intrt pour amliorer les performances des rseaux WIMAX
pour lesquels les conditions du canal radio varient considrablement compares celles
dun rseau de type filaire. En effet, le partage de ltat du canal avec les couches
suprieures permettra ces dernires de rpondre efficacement ces changements.
Dans le chapitre suivant, nous allons voir comment le concept Cross-Layer peut tre
exploit pour garantir la QoS pour des services multimdia transmis sur les rseaux 802.16.

41

ETAT DE LART

42

Introduction

Chapitre 3
Optimisation Cross-Layer
pour la transmission vido
unicast
3.1 Introduction
Actuellement, nous assistons une recrudescence des efforts de dveloppement des
technologies sans fil et mobile pour la transmission des services multimdia de type voix et
vido. Le but est de fournir une plus grande bande passante et une couverture optimale
avec la meilleure qualit de service et dexprience (QoS/QoE) possible pour lutilisateur
final.
La norme IEEE 802.16 [1] [2] constitue une solution pour lInternet haut dbit mobile
qui offre des dbits levs tout en assurant une qualit de service satisfaisante. Cette norme
est particulirement adapte au contexte des applications multimdia temps rel telles que
la transmission en continu des flux vido ( streaming ), la tlphonie sur IP ou encore la
tlvision sur IP. Cependant, diffrentes contraintes doivent tre leves pour assurer un
bon fonctionnement des services envisags, notamment en termes de garantie de la bande
passante requise, de contrle de dlai, de la gigue et de taux de pertes tolrs. Pour ce faire,
plusieurs mcanismes ont t proposs diffrents niveaux des couches protocolaires et
notamment au niveau de la couche MAC. En effet, la couche MAC joue un rle important
pour garantir les paramtres de qualit de service. Nanmoins, cette couche seule ne
rpond pas la problmatique complexe de la QoS.
43

Optimisation Cross-Layer pour la transmission vido unicast

Toutefois, la satisfaction de ces paramtres ncessite loptimisation et le contrle
dimportantes ressources, qui sont parfois indisponibles selon ltat du rseau, notamment
au niveau de la couche physique (PHY) et de la couche MAC. En consquence, si les
ressources disponibles dans le rseau ne sont pas suffisantes pour assurer un
fonctionnement correct de lapplication de streaming vido, cette dernire est tout
simplement interrompue. Actuellement, aucune solution efficace nest propose dans les
diffrents standards 802.16. Pour pallier la problmatique de la pnurie de ressources et
anticiper tout disfonctionnement, les applications de streaming vido devraient, idalement,
adapter leurs dbits de donnes en fonction de la variation observe des conditions rseau
et principalement au niveau des couches PHY et MAC. Ce processus est utilis dans de
nombreux mcanismes d'optimisation et est appel Cross-Layering . Le concept CrossLayer est un sujet de recherche dactualit qui vise accrotre la qualit de service en
ralisant des actions coordonnes entre les diffrentes couches du modle protocolaire
rseau.
Notre objectif principal consiste trouver des solutions efficaces en se basant sur le
modle Cross-Layer qui permet de mettre en place des interactions coordonnes entres les
couches hautes reprsentant lapplication de streaming vido et les couches basses
reprsentant la couche MAC/PHY de la norme IEEE 802.16. Lchange dinformations
entre ces couches conduira une optimisation du fonctionnement de lapplication en
fonction des changements observs sur le canal radio. Ainsi, cette solution doptimisation
permettrait de limiter les probabilits de disfonctionnement ou dinterruption de la
transmission vido et de garantir, par la mme, les contraintes de QoS.
Nous proposons dans ce chapitre une solution base sur les mcanismes Cross-Layer
nomme CLO (pour Cross-Layer Optimizer ). Ce chapitre se focalise sur les
transmissions vido sur le lien montant. Ainsi, loptimisation apporte par lentit CLO sera
applique aux diffrentes stations SS qui transmettent leur flux sur le rseau WIMAX.
Lentit CLO sera installe entre la couche applicative et la couche MAC/PHY de la SS.
Lide principale du CLO est dexploiter les messages MAC de signalisation et de
management changs au sein dune cellule WIMAX, de les interprter dans le but
doptimiser et dadapter le flux vido pour garantir une continuit de service.
Ce chapitre est organis comme suit ; dans un premier temps, nous prsentons
quelques solutions Cross-Layer proposes dans la littrature qui ont des lments en
commun avec notre problmatique. Dans la deuxime partie, nous exposons le contexte
44

Solutions Cross-Layer pour le streaming vido dans les rseaux WIMAX.

gnral de notre approche savoir les architectures rseaux compatibles avec notre
solution, en particulier, pour la gestion de la QoS dans les rseaux WIMAX. Dans la
troisime partie, nous prsentons larchitecture et lalgorithme Cross-Layer que nous
proposons. Finalement, nous dcrirons dans la dernire partie, lenvironnement et les
rsultats de nos simulations.

3.2 Solutions Cross-Layer pour le streaming vido dans les rseaux

WIMAX.
La plupart des travaux existants sur les optimisations Cross-Layer dans les rseaux
WIMAX se concentrent sur les interactions de la couche PHY avec la couche MAC et ne
considrent pas les performances de la couche application (APP).
Les auteurs de [82] et [83] proposent un mcanisme Cross-Layer pour intgrer la QoS
de la couche 3 avec la QoS de la couche 2. Leurs propositions sont dcrites en quatre
tapes. Dans la premire tape, ils proposent une correspondance ( mapping ) entre la
QoS au niveau IP et la QoS au niveau MAC 802.16. Ils dcrivent des rgles de
correspondance entre les classes de service dfinies par IntServ et DiffServ et les
classes de services dfinies dans la norme 802.16, savoir, lUGS, rtPS, nrtPS et BE
comme indiqu dans le Tableau 3-1

Tableau 3-1. Correspondance entre QoS IP et QoS 802.16 [83]

La seconde partie concerne le contrle dadmission, les auteurs proposent un nouvel

algorithme qui met en uvre des restrictions dallocation de bande passante. Cette
restriction vise prendre en compte laspect de variation des caractristiques de chaque
flux. Ensuite, un schma de fragmentation est propos comme troisime tape ; ils
introduisent un mcanisme de contrle de fragments qui sassure que les fragments dun
mme paquet IP sont mis dans la mme file d'attente MAC. Ceci permettra, par la suite,
une meilleure reconstruction des paquets. Par ailleurs, en cas de perte ou de congestion,
tous les fragments dun mme paquet seront limins, ce qui empche toute transmission
inutile de certains fragments. La quatrime et la dernire tape concerne la gestion des
buffers des files dattentes rtPS et nrtPS. Cela consiste une rorganisation conditionne et
45

Optimisation Cross-Layer pour la transmission vido unicast

temporelle, permettant ainsi aux classes de service CL et EF dutiliser le buffer nrtPS
lorsque le buffer rtPS arrive saturation. Ceci est bas sur le fait quil est probable que le
buffer rtPS soit satur avant celui de la classe nrtPS. Lvaluation de la solution, faite par
simulation, confirme que les mcanismes proposs offre une meilleure performance,
notamment en terme de dbit de donnes.
Dans [84], les auteurs proposent une optimisation Cross-Layer entre la couche MAC
et la couche PHY. Leur solution collecte des paramtres tels que des indications sur l'tat
du canal radio, les demandes de bande passante et la longueur des files dattente des deux
couches. Pour ce faire, lentit Cross-Layer doit avoir les informations sur les conditions du
canal radio depuis la couche PHY et les autres paramtres depuis la couche MAC. Par la
suite, les paramtres sont optimiss et retourns aux deux couches respectives (Figure 3-1).
Par exemple, lentit Cross-Layer peut informer la couche PHY quelle devrait changer le
schma de modulation et de codage en fonction des informations SNR reues. De mme,
la couche MAC reoit des paramtres optimiss tels que la taille idale de paquets,
lallocation idale des slots. Lobjectif de la solution est de permettre un meilleur
ordonnancement des ressources pour satisfaire les besoins en QoS des flux de donnes.
Les auteurs ont dmontr, travers les simulations, lintrt du mcanisme Cross-Layer, en
particulier en cas de dgradation des conditions radio.

Figure 3-1 : Architecture doptimisation Cross-Layer [84]

Jusquici, ces deux approches proposent des solutions gnriques pour tous les flux de
donnes. De plus, les caractristiques de la couche applicative ne sont pas considres. Par
consquent, dans le cas dune transmission vido en temps rel par exemple, lapplication
na aucune connaissance des conditions du rseau et ainsi aucune adaptation ou
optimisation nest prise en compte.
Dans [85] et [86], la couche APP est incluse dans le mcanisme Cross-Layer en plus
des couches MAC et PHY. Dans le cadre de ces tudes, l'optimisation est effectue au
niveau de la BS qui achemine le trafic vido la SS.
Les auteurs de [85] utilisent les informations fournies par les couches PHY, MAC et
APP pour amliorer les performances du systme. L'ide principale est d'adapter et
d'ajuster la modulation de la couche PHY et le dbit de donnes de lapplication vido
46

Solutions Cross-Layer pour le streaming vido dans les rseaux WIMAX.

streaming en fonction des informations sur le trafic, de l'tat du canal et les paramtres de
QoS des connexions actives. De nouveaux messages de gestion sont introduits pour
informer les SS du nouveau dbit de donnes vido. Par consquent, la SS doit tre capable
daccepter ces requtes de changement de dbit et de communiquer ces dcisions la
couche applicative. Par simulation, les auteurs notent une amlioration de la capacit
globale du systme et la rduction des pertes. Nanmoins, la dfinition de nouveaux
messages de signalisation, pour que la BS et les SSs changent les informations
dadaptation, peut conduire une charge ajoute trs importante. Cette charge est
proportionnelle la frquence de changement de ltat du canal et la variation des
diffrents paramtres de QoS des connexions actives.
Dans [86], les auteurs mnent une tude d'valuation des performances d'une
approche Cross-Layer pour la transmission vido H.264 multiutilisateurs dans les rseaux
sans fil. Trois tapes sont dfinies: l'abstraction des paramtres de la couche APP et
Liaison/Radio, la slection des paramtres optimiss et leur distribution aux couches
correspondantes. La couche APP contribue au design Cross-Layer puisquelle a
connaissance des pertes des paquets vido et des rpercutions sur la qualit vido perue
par lutilisateur. La couche MAC et PHY contribuent leur tour puisquils fournissent les
informations de variation des tats dallocation et du canal radio. Lalgorithme Cross-Layer
est appliqu pour chaque trame pour tous les utilisateurs simultanment afin de fournir une
optimisation de la QoS de bout en bout.
Un autre mcanisme Cross-Layer est propos dans [87] ; les auteurs prsentent une
solution de gestion des buffers afin damliorer le fonctionnement dune application de
type streaming vido. En effet, lide de base de cette approche rside dans le fait que les
MAC PDUs dun flux vido peuvent tre volontairement supprims au niveau de la BS si
cette dernire juge que le dlai de transmission de la trame correspondante est suprieur au
dlai maximum support par lapplication vido. Le mcanisme AD ( Active Dropping )
propos permet, dans ce cas, une optimisation des ressources disponibles avec la
rallocation des ressources libres aux trames suivantes du flux vido ou aux trames dun
autre flux de donnes.
Nous proposons une solution Cross-Layer qui prend en compte la couche Application
et la couche MAC 802.16. Lexclusion de la couche PHY de notre approche est justifie,
dune part, par un souci de compatibilit avec le standard (rappelons que toute modification
de la couche PHY casse la comptabilit car cela implique une modification du matriel), et
dautre part, par notre conviction de lefficacit des mcanismes existants (Modulation
OFDMA adaptative, ) qui sont exploitables directement partir de la couche MAC.
Notre solution vise amliorer la transmission vido sur le lien montant pour les
stations contributrices. En consquence, les traitements sont proposs au niveau de la SS et
non pas au niveau de la BS. En outre, nous utilisons les messages existants de la couche
47

Optimisation Cross-Layer pour la transmission vido unicast

MAC pour la signalisation et le management, aucun nouveau message de gestion na t
ajout la diffrence de [85] et [86]. Dans une optique de rduction de la surcharge de
calcul, notre approche d'optimisation est effectue uniquement au dbut d'une session de
streaming vido ou pendant la dure de vie d'une session des instants ponctuels, si
l'volution des conditions de la couche MAC o de la couche PHY est notablement
dtecte.
Dans le reste de ce chapitre, nous dveloppons le contexte gnral de notre
problmatique, nous exposons, par la suite, notre approche ainsi que lvaluation de
performance afin de confirmer lintrt de notre solution.

3.3 Topologies de rfrences

Dans cette partie, nous tudions les diffrentes architectures et topologies auxquelles
nous nous sommes intresss et qui conviendraient le plus notre problmatique.
3.3.1 Architecture distribue
Dans ce paragraphe nous dcrivons les architectures de rfrence que nous jugeons
pertinentes pour notre proposition. Tout d'abord, nous considrons une architecture Point
Point (ou Peer-to-Peer) comme indiqu dans la Figure 3-2 o chaque client demande le
flux vido partir dune source. Selon la demande, la source vido initie une session de
streaming vido correspondante. Cela est en relation directe avec la bande passante
disponible pour chaque utilisateur. Cette architecture est plus approprie pour les services
de streaming P2P. En effet, un client P2P pourrait rcuprer le contenu vido
paralllement partir de plusieurs sessions de streaming vido depuis plusieurs pairs.
L'inconvnient de cette architecture est la correspondance 1-1 entre le nombre de client et
les sessions vido initier par le serveur vido. Cette architecture est appele diffusion
simultane ou Simulcast , et conduit une surcharge importante sur les liens de
transmission.
3.3.2 Architecture Centralise
La seconde architecture dcrite dans la Figure 3-3 est une architecture centralise.
Contrairement la premire architecture, les clients n'ont pas un accs direct au serveur de
streaming vido, ils doivent plutt envoyer leur demande un routeur ou une passerelle
centralise. Ce dernier devrait, en premier lieu, faire une slection des demandes puis envoi
au serveur vido. Ensuite, le serveur envoie le flux de streaming vido appropri tous les
utilisateurs. Par rapport larchitecture distribue, larchitecture centralise rduit le
nombre de connexions 1-N dans le cas le plus favorable (tous les utilisateurs ont le mme
profil), et dans le cas le plus dfavorable (les clients ont des profils htrognes), nous nous
48

Topologies de rfrences
retrouvons dans le cas 1-1. Le serveur vido doit envoyer de multiples sessions vido en
mme temps. Pour viter ce problme, la passerelle devrait choisir un nombre fini de
profils utilisateurs afin de limiter le nombre de sessions de streaming vido.

d
Vi

eo

eq
R

ue

s
st

Vid
e
req o
ues
t

Figure 3-2 : Architecture distribue

t
es
qu
Re

eo
vid

er
rv
se

Figure 3-3 : Architecture centralise

Indpendamment de larchitecture utilise, que ce soit distribue ou centralis, notre

but est de trouver une solution dadaptation et doptimisation de lapplication streaming

49

Optimisation Cross-Layer pour la transmission vido unicast

vido qui prenne en compte le changement des conditions du rseaux et la diversit des
clients vido.

3.4 Contexte gnrale

Comme mentionn ci-dessus, nous avons dvelopp notre solution CLO pour un
rseau WIMAX. Dans le paragraphe suivant, nous rappelons brivement le
fonctionnement de la gestion de la QoS dans un rseau WIMAX, ainsi que la gestion des
flux de service dans la couche MAC 802.16 afin de mieux comprendre lapproche
propose.
3.4.1 Gestion de la QoS et des flux de services dans les rseaux WIMAX
La gestion de la QoS dans la norme IEEE 802.16 [1] est articule autour de la gestion
dun flux de service ( Service Flow ou SF). On dfinit un SF comme tant un flux
unidirectionnel de paquets fournissant une certaine garantie de QoS sous la forme d'un
ensemble de paramtres de QoS tels que la latence, la gigue et le dbit. Un SF peut tre
cre, modifi ou supprim l'aide des messages de gestion au niveau de la couche MAC qui
sont dcrits dans le paragraphe suivant.
La cration d'un SF pourrait tre faite soit depuis une SS ou une BS. Quand il sagit
dune SS, le message DSA_REQ inclut le nom de la classe de service ou lensemble des
paramtres de QoS du flux de service demand. La BS rpond par un message DSA_RSP
avec l'acceptation ou le rejet de la requte. Le message de rejet peut contenir des
informations supplmentaires telles que les paramtres non pris en charge ou les
paramtres ayant de mauvaises valeurs. Lorsque la BS est l'initiatrice de la requte, le
message DSA_REQ contient le SFID, le CID et lensemble des paramtres de QoS actifs
et/ou admis. La mme rponse que dans le premier cas est renvoye la BS.
Aprs sa cration, un SF peut tre modifi au moyen du message DSC_REQ. La
modification comprend les paramtres de QoS admis ou actifs. Si les nouveaux paramtres
de QoS sont accepts par la BS, les changements prennent effet au niveau du SF, sinon, le
SF reste inchang et continue de fonctionner avec les paramtres dj existants.
Finalement, la suppression d'un SF pourrait tre engage par la BS ou une SS, via le
message DSD_REQ. En outre, un SF peut tre supprime implicitement lorsque des
erreurs se produisent.
Les messages de gestion des SF vont servir au CLO pour fixer les paramtres
optimiss pour lapplication de streaming vido et par consquent, offrir une meilleure
qualit du service. Les dtails de notre approche sont dcrits dans la prochaine section.

50

Architecture propose

3.5 Architecture propose

Nous nous concentrons sur des scnarios o des SS partagent leurs vidos en temps
rel. Notre solution vise optimiser la session de streaming vido initie par une SS dans le
lien montant. Les cas d'utilisation les plus applicables de notre solution sont la vido
confrence, la vido surveillance et la livraison P2P de vido. Toutefois, notre approche
reste applicable pour les deux architectures de rfrence prsentes dans la Figure 3-2 et la
Figure 3-3.
Nous supposons un trafic de streaming vido entre une SS WIMAX et nimporte quel
autre type de client. En particulier, un trafic de streaming vido entre une SS WIMAX vers
une autre SS WIMAX pas forcment situes dans la mme cellule comme indiqu dans la
Figure 3-4.

Figure 3-4 : Topologie dtude

3.5.1 Proposition dune architecture Cross-Layer

Comme signal prcdemment, notre solution consiste en un mcanisme d'adaptation
de lapplication de streaming vido conjointement avec un mcanisme doptimisation
Cross-Layer entre la couche MAC et la couche applicative. L'adaptation est effectue du
ct serveur, c'est dire, le propritaire du contenu vido qui contribue la session sur le
lien montant. La pile protocolaire propose ainsi que les messages utiliss sont illustrs
dans la Figure 3-5.
Dans cette figure, les modles de rfrence pour les couches MAC et PHY, tel que
dfini dans la norme IEEE 802.16d, et le CLO sont clairement indiqus. Les messages de
gestion des SF (DSA, DSC, et DSD) sont intercepts par le module CLO et mis la
disposition de lapplication de streaming vido du ct serveur. Le serveur, de son ct,
met les paramtres de transmission la disposition du module CLO depuis le dbut de la
session de streaming.
Il est noter que la sous-couche CPS ( Common Part Sub layer ) offre les
fonctionnalits de base dune couche MAC savoir, l'accs au rseau, lallocation de bande
passante et ltablissement de la connexion. En particulier, la gestion des SF est sous la
responsabilit de la sous-couche CPS. Ainsi, le CLO interagit avec la sous-couche CPS et la
couche application de streaming vido ct serveur.
51

Optimisation Cross-Layer pour la transmission vido unicast

Figure 3-5 : Optimisateur Cross-Layer entre couches MAC et Application

3.5.2 Algorithme Cross-Layer

L'algorithme doptimisation Cross-Layer propos est dfini en trois tapes. Dans un
premier temps, nous recueillons des indicateurs depuis la sous-couche CPS. Durant la
seconde tape, ces indicateurs sont analyss et une dcision est prise au niveau du module
CLO. Enfin, les adaptations sont appliques en affectant les nouveaux paramtres vido au
serveur de streaming vido.
Lalgorithme Cross-Layer que nous proposons dans cette approche a fait lobjet dun
brevet publi en 2009 [A].
3.5.2.1

Collecte des indicateurs

Comme mentionn au paragraphe 3.4.1, les SF sont grs (initis, modifis et

supprims) via les messages DSA, DSC et DSD. De nombreux messages sont changs
entre les SS et la BS, et nous nous sommes intresss, en particulier, aux messages
DSA_RSP, DSC_REQ et DSC_RSP. L'ide principale consiste utiliser des messages de
gestion existants et dj dfinis par la norme IEEE 802.16 plutt que d'ajouter de
nouveaux messages de signalisation. Ensuite, tous les messages (une copie) de gestion des
SF initis par la SS mettrice ou reus depuis la BS seront collects par le module CLO
puisque notre dmarche est implmente au sein du serveur de streaming vido.
3.5.2.2 Adaptation et modification
Les messages de gestion de SF collects sont tout d'abord analyss. Ces messages
renvoient une rponse positive si la requte est accepte, ou une rponse ngative si la
requte n'est pas totalement accepte ou tout simplement rejete. Dans ce cas, si la requte
52

Architecture propose
n'est pas accepte, le message de rponse indique l'indisponibilit des ressources ncessaires
pour le flux vido correspondant. Par consquent, lapplication de streaming vido devrait
adapter son dbit en vue d'obtenir une rponse positive lors de la prochaine tentative. Pour
ce faire, les paramtres de diffusion sont modifis de faon ajuster le dbit de donnes
vido. Cette procdure peut se poursuivre jusqu' ce que le flux vido soit accept ou que la
qualit vido minimale prise en charge soit atteinte et quil y ait toujours un rejet.
Ds l'acceptation de la requte, les paramtres et le temps de l'acceptation sont
stocks. Plus tard, le module CLO va augmenter le dbit de donnes vido si le streaming
vido fonctionne correctement pendant une certaine priode, en supposant que davantage
de ressources sont maintenant disponibles. Si la demande est rejete, le flux vido continue
d'utiliser ses paramtres actuels. Si par contre, elle est accepte, le mme processus est
rpt jusqu' atteindre la qualit vido maximale.
Le paragraphe qui suit dcrit les diagrammes de squence qui fournissent plus de
dtails sur les oprations d'optimisation Cross-Layer et les messages changs entre les
entits impliques dans le processus d'optimisation.
3.5.3 Illustration de lapproche
Quand un flux vido est demand, le CLO identifie les paramtres vido appropris
permettant de garantir l'acceptation du SF au niveau de lentit de contrle dadmission de
la couche MAC. Au cours de la session de streaming vido, des changements de conditions
de la couche MAC, et par consquent du dbit vido, peuvent forcer le SF correspondant
tre interrompu ou finalement rejet. Si le mcanisme de CLO n'est pas utilis, le flux vido
est abandonn si les paramtres du SF ne rpondent plus ses contraintes de QoS. Le
mcanisme CLO permet l'adaptation du dbit de donnes du flux de streaming vido en
fonction de la fluctuation des conditions du rseau et permet dviter ainsi le rejet des
SF. De plus, notre approche peut tre applique au niveau du contrle dadmission suite
une requte de flux vido, ainsi que durant une session de streaming vido dj existante.
Nous illustrons l'approche CLO travers quelques exemples. La topologie prsente
dans la Figure 3-4 est utilise, avec la mise en uvre dun serveur de streaming vido
implmentant les fonctionnalits CLO au niveau de la station SS1.
3.5.3.1

SS envoie une requte DSA

Si la couche MAC de la SS1 reoit un flux vido des couches suprieures, un message
DSA_REQ est envoy avec les paramtres de QoS souhaits la station de base
BS1. Ensuite, en fonction de l'acceptation ou du rejet des paramtres de QoS, BS1 envoie
le message DSA_RSP avec un code de succs ou un code de rejet. Le diagramme de
squences de la Figure 3-6 montre les diffrentes actions du CLO, avec lajout dun
53

Optimisation Cross-Layer pour la transmission vido unicast

nouveau SF (tape 1) qui est rejet lors de la premire tentative puis, accept lors de la
seconde tentative.

SS 1

APP

CLO

BS 1

MAC

MAC
DSA_REQ (1)

Add Video traffic

Adaptation
And
Optimization
(5)

DSA_RSP(reject) (3)
DSA_RSP (reject) (4)

Service flow
QoS
not supported
(2)

DSA_ACK (6)
Affect NEW Parameters (7)
Add New Video traffic

DSA_RSP(success) (11)
No
Adaptation
(12)

DSA_REQ (new) (8)

Service flow
QoS
supported OK
(9)

DSA_RSP(success) (10)
DSA_ACK (13)

Video Data

Video Data

Figure 3-6 : SS envoie le message : DSA Request

Une fois que la SS reoit un message de rejet DSA_RSP (tape 2 et 3), elle le transmet
au CLO (tape 4). Le message est intercept par le module CLO qui informe lapplication
de streaming vido dadapter ses paramtres de QoS en rduisant son dbit vido (tape 5
et 7). Ensuite, une nouvelle requte dajout de vido est lance (tape 8), suivie par la mme
procdure entre BS1 et SS1. La demande est accepte (tape 10 et 11) et le streaming vido
est lanc. Une fois le flux vido accept, la disponibilit des ressources et les conditions du
canal radio peuvent varier. Dans ce cas, un message de requte DSC doit tre envoy par la
BS ou la SS afin de changer les paramtres de QoS.
3.5.3.2 BS envoie une requte DSC
La Figure 3-7 montre le diagramme de squence avec la BS1 qui envoie un message de
requte DSC. Ce message est envoy une fois que la BS1 est incapable de rpondre aux
nouvelles contraintes de QoS des SF (tape 1). Cette situation peut se produire dans deux
cas, premirement, lorsque les ressources ncessaires du ct de la BS1 ne sont pas
disponibles, deuximement, quand les contraintes de QoS ne peuvent pas tre satisfaites
par le lien entre la BS et la station rceptrice du flux vido. La BS1 envoie un message de
demande de changement du SF DSC_REQ SS1 (tape 2), afin que cette dernire adapte
les paramtres du SF en consquence. SS1 reoit la requte et effectue les changements
requis (tape 3). Lentit CLO reoit le mme message (tape 4), calcule ladaptation
ncessaire (tape 6) et affecte les nouveaux paramtres la couche applicative (tape 8).
54

Architecture propose

Figure 3-7 : BS envoie le message: DSC Request

3.5.3.3 SS envoie une requte DSC

Un message DSC_REQ est initi par la SS1 si un changement de conditions du canal
radio est dtect (tape 1). La SS1 demande la BS1 de mettre jour les paramtres de
QoS du SF correspondant en faisant varier le dbit de donnes du flux vido. Une fois que
le message DSC_REQ est reue par BS1 (tape 2), celle-ci vrifie si les nouveaux
paramtres de QoS peuvent tre appliqus et envoie un message DSC_RSP (tape 4) SS1
avec une rponse de rejet ou dacceptation. Dans le cas o la requte est rejete, SS1
poursuivra sa transmission vido avec les paramtres actuels. Si la demande est accepte
comme mentionn dans l'tape 4 de la Figure 3-8, SS1 met en place les nouveaux
paramtres du SF. On peut voir clairement dans ce cas lavantage de l'approche CLO. Cette
dernire en effet vite le rejet dun nouveau flux de service SF vido en adaptant les
paramtres du streaming vido en consquence (tape 5, 6 et 8 de la Figure 3-8).

Figure 3-8 : SS envoie le message: DSC Request

55

Optimisation Cross-Layer pour la transmission vido unicast

3.6 Evaluation de performances

3.6.1 Environnement de simulation
Nous avons utilis le simulateur QualNet [88] pour mettre en uvre notre solution de
Cross-Layer sur le rseau WIMAX. Nous considrons la topologie dcrite dans la Figure
3-9, et le lien entre BS1 et BS2 est suppos tre un lien filaire fiable, tant donn que nous
nous sommes concentrs essentiellement sur les performances du module CLO.

Figure 3-9 : architecture de simulation

Le trafic streaming vido de la SS1 vers la SS2 est simul dans diffrents scnarios en
utilisant un gnrateur de trafic vido bas sur des traces pr-encodes de type MPEG-4
[89]. Ces traces fournissent trois qualits vido : vido de qualit leve, moyenne et faible
(voir Tableau 3-2 pour plus de dtails). Pour ce faire, un nouveau gnrateur de streaming
vido scalable est dvelopp sur la base des traces MPEG. Il est capable de faire varier la
qualit vido en basculant dune qualit une autre et par consquent faire varier le dbit
de donnes en temps rel. Les paramtres de la couche PHY de lIEEE 802.16 sont fixs
comme indiqu dans le Tableau 3-3.
Video quality

Frame rate
Mean data rate

High

Medium

25 frames / sec

25 frames / sec

766 Kbps

267 Kbps

Low

25 frames / sec
153 Kbps

Tableau 3-2. Qualit vido leve, moyenne et faible

Propagation channel frequency

2.4 GHz

Channel bandwidth

20 MHz

FFT size

2048

Antenna gain

12 dB

Transmission Power

20 dB

Frame size

20 ms

Tableau 3-3. Paramtres de simulation pour la couche PHY de lIEEE 802.16

56

Evaluation de performances
Dans le paragraphe suivant, nous dcrivons quatre scnarios de simulation et nous
discutons les rsultats obtenus.
3.6.2 Rsultats de simulations
Pour valuer les performances de notre solution dans diffrentes situations, nous
dfinissons quatre scnarios :
Le Scnario 1 prsente les conditions normales. Le CLO nintervient pas. Ce scenario
nous sert de rfrence pour connatre lallure du dbit instantan de chaque qualit
vido obtenue dans une situation normale.
Le Scnario 2 simule le comportement du dbit vido au contrle dadmission grce
CLO, ds que le flux streaming vido est initi. Deux cas de figures sont illustrs, le
dbit vido est rduit chaque fois selon la bande passante disponible.
Le Scnario 3 illustre le comportement de lapplication de streaming vido en cours de
transmission, suite une diminution brusque de la capacit du rseau.
Le Scnario 4 est leffet inverse du scnario 3, il montre lintervention de CLO pour
augmenter la qualit vido dans le cas o la capacit du rseau est amliore.
3.6.2.1

Scnario 1 : conditions normales

Nous valuons le dbit des flux vido dans des conditions normales en supposant qu'il
y a assez de ressources disponibles dans le rseau. Les rsultats des simulations des vidos
avec qualit leve, moyenne et faible sont prsents dans la Figure 3-10. Ces rsultats
servent de base pour mieux comprendre les scnarios suivants.
3.6.2.2 Scnario 2 : adaptation au contrle dadmission
Dans ce scnario, les performances de notre solution CLO sont values en prsence
d'un mcanisme de contrle d'admission. En plus du trafic de streaming vido entre SS1 et
SS2, un trafic en background avec une priorit plus leve est ajout. Son rle est de
perturber le trafic vido et de voir la raction du module CLO. Un trafic CBR en temps
rel avec un dbit lev est choisi pour charger le rseau afin que la BS1 n'ait plus de
ressources suffisantes pour satisfaire le trafic vido de qualit leve ce qui va forcer le
serveur de streaming vido rduire son dbit de donnes, comme expliqu dans la Figure
3-6.
Le trafic en background est prsent durant tout le temps de la simulation, et le trafic de
streaming vido commence t = 10 sec pour une dure d'une minute. Le dbit du trafic en
background pour chaque scnario est indiqu dans le Tableau 3-4. Le serveur vido
commence, par dfaut, la diffusion dune vido de qualit leve et laisse le module CLO
adapter le dbit de la vido en fonction des ractions de la BS.
57

Optimisation Cross-Layer pour la transmission vido unicast

Figure 3-10 : Dbits vido pour une qualit leve, Moyenne et faible

Scnario 2

Scnario 3

Scnario 4

Description

Dbit du trafic CBR

en Background

Qualit leve rduite qualit

moyenne
lors
du
contrle
dadmission.

30.6 Mbps

Qualit leve rduite qualit faible

lors du contrle dadmission

30.75 Mbps

Qualit leve rduite qualit

moyenne durant la session de
streaming

30.6 Mbps

Qualit leve rduite qualit faible

durant la session de streaming

31 Mbps

Qualit faible amlior qualit

leve durant la sesssion de
streaming

30.75 Mbps
Se termine 40sec

Figures

Figure 3-11

Figure 3-12

Figure 3-14

Figure 3-15

Figure 3-16

Tableau 3-4. Paramtres du trafic en background pour chaque scenario

Le comportement de l'application de streaming vido peut tre observ dans la Figure

3-11 et la Figure 3-12. Dans la premire figure, nous remarquons que le dbit vido passe
immdiatement du dbit de la vido de qualit leve au dbit de la vido de qualit
moyenne. Seulement, quelques paquets appartenant la vido de qualit leve sont tout
dabord transmis, ensuite, la vido de qualit moyenne (Figure 3-11) est transmise. Dans la
deuxime figure, nous observons le mme comportement, cette fois, le CLO rduit la
qualit vido jusqu atteindre la qualit la plus faible (Figure 3-12). Le dbit du trafic CBR
est suffisamment lev (30,75 Mbit/s) au point que la BS1 n'a plus de ressources
58

Evaluation de performances
disponibles pour satisfaire la qualit leve ou moyenne de la vido.

Figure 3-11 : Dbit vido de qualit leve rduit qualit moyenne lors de ladmission

Figure 3-12 : Dbit vido de qualit leve rduit qualit faible lors de ladmission

3.6.2.3 Scnario 3: adaptation durant le streaming vido : le dbit diminue

Ce scnario illustre le fonctionnement du CLO durant une session de streaming vido;
nous simulons la mme configuration que dans le scnario prcdant.
Le dbit du trafic CBR est choisi au dpart, de manire donner la chance la vido de
qualit leve d'tre accepte ds le dbut de la session. Puis, l'instant t = 30sec, un autre
trafic CBR, avec une plus grande priorit, est initie. Le dbit de ce trafic CBR est choisi de
telle sorte que la BS n'aura plus assez de ressources pour le trafic vido dj existant (Voir
Tableau 3-4 pour le dbit du trafic en background pour chaque scnario).
Nous commenons, dans un premier temps, par simuler ce scnario sans lintervention
de lentit CLO, les rsultats sont prsents dans la Figure 3-13. Sans optimisation CrossLayer, quand BS1 ne peut pas satisfaire le dbit de la vido de qualit leve, un message de
rejet est envoy SS1, la connexion du SF est abandonne et le trafic de streaming vido
est tout simplement interrompu. Ensuite, nous simulons le mme scnario, mais en tenant
compte de loptimisation CLO. Cette fois, les rsultats sont diffrents. En effet, grce
notre optimisation au niveau de lalgorithme de scheduling, la BS connat parfaitement les
59

Optimisation Cross-Layer pour la transmission vido unicast

flux de service SF correspondants aux applications de streaming vido. Par consquent,
comme le montre la Figure 3-7, le module CLO forcera l'application de streaming vido du
ct serveur s'adapter et rduire son dbit de donnes. Les rsultats de simulation qui
illustrent le basculement vers un dbit rduit sont illustrs dans la Figure 3-14 (basculement
vers une qualit vido moyenne) et Figure 3-15 (basculement vers une qualit vido
moyenne et puis faible).

Figure 3-13 : Dbit vido de qualit leve interrompue durant la transmission

Figure 3-14 : Dbit vido de qualit leve rduit moyenne durant la transmission

60

Evaluation de performances

Figure 3-15 : Dbit vido de qualit leve rduit qualit faible durant la transmission

3.6.2.4 Scnario 4: adaptation durant le streaming vido : le dbit augmente

Dans ce scnario, nous rutilisons les mmes paramtres de simulation que dans le
scnario 2, avec un trafic de background de 30,75 Mbit/s. Le trafic CBR commence ds le
dbut de la simulation, mais se termine t = 40 sec au lieu de toute la dure de la
simulation.
Comme mentionn ci-dessus, le dbit vido va diminuer, grce au module CLO ds
ladmission du flux vido, jusqu' ce que le dbit atteigne le dbit de la qualit vido la plus
faible. Puis, t = 40 sec, le trafic en background est interrompu et les ressources qu'il
utilisait auparavant deviennent disponibles.
Lorsque la disponibilit est dtecte par l'entit CLO, celle-ci informe le serveur de
streaming vido en vue d'accrotre son dbit de donnes vido. Un premier message
DSC_REQ est envoy partir de la SS la BS pour atteindre une qualit vido moyenne,
comme indiqu dans la Figure 3-16, puis une deuxime requte DSC_REQ est envoye
pour atteindre une qualit vido optimale.

61

Optimisation Cross-Layer pour la transmission vido unicast

Figure 3-16 : Dbit vido de qualit faible amlior qualit leve durant la transmission

3.7 Conclusion
Dans ce chapitre, nous avons prsent une solution Cross-Layer pour loptimisation
des applications de streaming vido au sein des rseaux WIMAX. La problmatique tudie
consiste trouver un compromis entre, dune part, les besoins dune application temps rel
en ressources rseau telles que la bande passante minimum requise et le dlai maximum
tolr et dautre part, la diversit des utilisateurs dune telle application ainsi que la variation
des conditions du rseau au cours du temps.
Dans ce chapitre, nous nous sommes focaliss sur les transmissions vido depuis une
station SS WIMAX. Notre optimisation a t bnfique pour les transmissions en lien
montant depuis une SS vers la BS, puis vers le rseau Internet. Cette approche est
approprie pour les applications de streaming vido tels que la vido surveillance, la vido
confrence ou encore le partage de vido en direct dans le cadre dune communication
point point ou point multipoints.
Notre solution a apport les claircissements et les rponses ncessaires la
problmatique pose. Nous avons propos une architecture Cross-Layer qui sadapte
efficacement aux changements de conditions rseau en ajustant le dbit des flux vido en
fonction des ressources disponibles. La nouvelle technique dadaptation du dbit vido
pouvait intervenir ds le dbut dune transmission vido grce une entit de contrle
dadmission enrichie par des algorithmes doptimisation. Cette adaptation pouvait, aussi,
avoir lieu en cours de transmission suite une volution ou une dgradation des capacits
62

Conclusion
du rseau.
Lvaluation de performance de notre solution a t effectue par un ensemble de
simulations de scnarios qui couvraient les architectures vises. Nous avons, en effet, pu
dmontrer lefficacit de ladaptation et de loptimisation Cross-Layer menant un meilleur
fonctionnement de lapplication de streaming vido.
Les rsultats de la contribution, prsente dans ce chapitre, ont t publis dans [B] et
[C].
Dans le chapitre suivant nous nous intressons la transmission vido en lien
descendant, depuis un serveur vido quelconque vers diffrents utilisateurs. En particulier
nous nous focalisons sur la transmission vido vers des clients ayant un accs Internet via
un rseau de collecte tel que WIMAX. De plus, nous considrons les transmissions
multicast afin doptimiser lutilisation des capacits du rseau en prsence de clients divers
et multiples. Le but de ce chapitre est de trouver une solution doptimisation qui tienne
compte la fois de la diversit des profils rseau des clients vido, et galement, des
caractristiques adaptatives des codeurs vido hirarchiques.

63

Transmission Multicast SVC Dans les Rseaux WIMAX

64

Introduction

Chapitre 4
Transmission Multicast SVC
Dans les Rseaux WIMAX
4.1 Introduction
Quelque soit la technologie de communication utilise, l'accs et la demande simultan
du mme contenu/ressource constitue un usage trs rpondu. Dans les architectures
classiques, les donnes sont envoyes aux divers clients demandeurs du mme contenu par
simple duplication. Ceci peut gnrer rapidement un problme de congestion dans le
rseau. Cette approche de communication de groupe est appele multicast applicatif (ou
ALM pour Application Level Multicast ). Pour remdier au problme de la redondance
du trafic dans le rseau, la solution du Multicast IP savre trs utile. Cependant, pour tirer
profit de cette solution, il est ncessaire que le rseau soit capable de vhiculer du trafic
multicast IP, ncessitant ainsi le dploiement du protocole de gestion de groupe (IGMP/
MLD) et de routage multicast (par exemple PIM).
Si nous considrons la transmission de flux vido temps rel, lapproche multicast IP
est priori dune efficacit ingale vue le besoin important en termes de bande passante des
flux vido. Dailleurs, certains ISP exploitent le multicast IP pour offrir des services IPTV
largement utiliss de nos jours.
Dans ce chapitre, nous nous intressons particulirement au streaming vido multicast
sur les rseaux WIMAX. Dans ce contexte, plusieurs contraintes, auxquelles nous devons
trouver des solutions, rendent lapproche classique multicast IP peu efficace. Ceci est
d'autant plus vrai cause de la diversit des profils des stations, en termes de conditions
rseaux et de ressources disponibles. Lapproche Multicast IP classique ne prend, en effet,
en considration ni ltat en cours du rseau, ni la disponibilit des ressources radio dans le
cadre dun rseau daccs tel que le WIMAX.

65

Transmission Multicast SVC Dans les Rseaux WIMAX

Lobjectif de cette tude est deffectuer du streaming vido au format SVC vers des
clients divers appartenant en particulier des rseaux WIMAX, et ce sachant que chaque
client WIMAX possde ses propres caractristiques physiques, en termes de bande
passante et de ressources disponibles. Nous proposons une solution base sur le multicast
IP qui permet de trouver le meilleur compromis entre la diversit des clients et le codage
vido hirarchique SVC. Nous dmontrons que cette solution offre la meilleure qualit
vido mme pour les clients ayant de faibles conditions radio.

4.2 Motivation
Comme soulign prcdemment, la transmission des flux vido en multicast IP savre
trs efficace si tous les clients (SS) sont homognes et synchrones. Cependant, dans notre
cas, les clients qui sont attachs une BS WIMAX ne peuvent pas tre homognes, cause
des caractristiques inhrentes au mdium radio au sein de la cellule. En effet, les SS les
plus proches de la BS possdent une meilleure bande passante et peuvent recevoir le flux
vido avec la qualit de service demande, tandis que les SSs les plus loignes nont pas
assez de ressources pour recevoir ce flux. Dans ce cas, et afin de grer de faon efficace les
ressources rseau et doffrir la meilleure qualit de service, il est possible de mettre en place,
au niveau du serveur de streaming vido, des mcanismes permettant dadapter le flux aux
ressources utilisateurs. Dans ce cas, lapproche multicast ne peut pas tre applique cause
de l'htrognit des profils utilisateurs prsents dans la cellule. Ci-dessous, sont dtailles
les limitations du multicast IP pour diffrents cas possibles de transmission:
Cas1 : Transmission dun flux vido avec la qualit la plus leve afin de satisfaire les
abonns les plus favoriss, ayant assez de ressources et assez de bande passante pour
acheminer le flux vido de qualit leve de bout en bout. Dans ce cas, tous les autres
utilisateurs ne rpondant pas aux critres du flux vido en termes de bande passante, ne
peuvent recevoir ce flux vido. Si le flux est reu, il le sera avec une qualit trs
dgrade (due par exemple lattnuation du signal).
Cas 2 : Transmission dun flux vido avec la qualit la plus faible afin de satisfaire le
maximum dutilisateurs. Dans ce cas de figure, les utilisateurs ayant une plus grande
bande passante sont pnaliss et doivent recevoir une vido de moindre qualit.
Cas 3 : Transmission dun flux vido dune qualit moyenne afin de satisfaire une bonne
partie des utilisateurs et offrir une qualit plus acceptable pour les utilisateurs les plus
favoriss. Cette solution augmente le nombre de personnes satisfaites par la qualit
vido perue mais ne rsout pas l'intgralit des problmes. Certains utilisateurs
excellentes ressources ne reoivent pas la qualit adquate, dautres ne reoivent aucun
flux vido.
66

Etat de lart des solutions de vido streaming multicast

Cas 4 : Transmission dun flux vido plusieurs fois avec un niveau de qualit diffrent.
Le serveur vido pourra, en fonction des profils de ses utilisateurs, diffuser plusieurs
flux vido avec diffrentes qualits (qualit minimale, moyenne et maximale). Cette
solution pourra satisfaire un plus grand nombre dutilisateurs. Si les profils des
diffrents utilisateurs vido sont trs proches, le nombre de flux vido transmettre
sera rduit. A la diffrence, si la diversit des profils est importante, le nombre de flux
vido ne pourra rsoudre le problme. Linconvnient de cette solution est
laugmentation de la bande passante requise ainsi que les ressources ncessaires pour
acheminer toutes les qualits du mme flux vido. Si plusieurs profils sont prsents au
sein dune mme cellule WIMAX, la BS doit trouver les ressources ncessaires pour
acheminer toutes les qualits. De plus, dans cette solution, il restera toujours des
utilisateurs non satisfaits qui recevront une qualit vido insuffisante par rapport la
bande passante disponible pour chacun.
Comme on le voit clairement, aucune solution ne permet de remdier au problme de
la diversit des conditions rseau des utilisateurs. Dans tous les cas, certains utilisateurs ne
seront pas satisfaits (dgradation de la qualit dexprience QoE), des ressources seront
gres de faon non efficace ou des utilisateurs seront non ligibles au service.
Idalement, chaque utilisateur devrait recevoir une qualit vido proportionnelle ou
quivalente ces capacits et ses ressources disponibles.
Pour trouver une solution qui tienne compte de toutes ces contraintes, nous nous
sommes intresss aux dveloppements rcents dans le codage vido supportant
lhtrognit des profils utilisateurs. Pour ce faire, nous avons opt pour le codage
hirarchique SVC ( Scalable Video Coding ). En effet, le SVC nous parait la solution de
codage vido la plus adquate et qui rpond aux exigences voques prcdemment.
Dans le prochain paragraphe, nous dcrivons tout dabord, quelques exemples de
solution vido multicast qui se basent sur le codage vido hirarchique. Ensuite, nous
prsentons notre solution et nous dtaillions notre architecture ainsi que son valuation de
performance.

4.3 Etat de lart des solutions de vido streaming multicast

Plusieurs travaux se sont intresss l'utilisation des techniques de codage hirarchique
pour la transmission vido en multicast, nous dcrivons ci-dessous deux principales
propositions utilisant un codage vido hirarchique.
Lapproche SVSoA est dfinie dans [90]. Les auteurs de ce papier prsentent une
solution de streaming de vido hirarchique utilisant le multicast IP. Grce lutilisation du
protocole ALC ( Asynchronous Layered Coding [97]), SVSoA garantie la scalabilit vis67

Transmission Multicast SVC Dans les Rseaux WIMAX

-vis de lhtrognit des utilisateurs ainsi que la fiabilit. Le protocole ALC [RFC 3450]
est considr comme un protocole de transport multicast fiable et il nest pas conu la
base pour des transmissions temps rel.
Les auteurs combinent lutilisation des codeurs vido hirarchiques avec le protocole
ALC. En effet, le serveur vido commence par dcouper la vido en plusieurs segments de
dures gales. Chaque segment est compos de plusieurs blocs de telle faon que chaque
bloc reprsente une couche vido de base ou damlioration. La dcomposition en
segments et blocs est illustre dans la Figure 4-1. La transmission de chaque bloc est
effectue dune faon indpendante dans une session ALC part entire. Ainsi, chaque
couche vido sera transmise dans un groupe multicast diffrent. La taille de donnes de
chaque bloc reprsente la taille des donnes utiles plus la taille des paquets de corrections
derreur base de FEC ( Forwarding Error Correction ) utilis en natif par le protocole
ALC pour assurer la fiabilit. A la rception, chaque client commence par acqurir les
donnes de la premire session ALC qui correspond la couche de base de la vido.
Ensuite, avant que la dure du segment ne se termine, le client commute vers la session
ALC qui correspond la couche vido damlioration. Ce processus est rpt pour toutes
les couches damlioration. Dans ce papier, les auteurs ont considr une session pour la
couche de base et une autre pour une seule couche damlioration.

Figure 4-1 : SVSoA : streaming vido multicast avec ALC [90]

Linconvnient de cette solution rside dans laugmentation du nombre de sessions

ALC actives. En effet, le serveur doit envoyer toutes les couches vido et crer ainsi un
nombre important de sessions ALC mme si lutilisateur ne recevra que la couche vido de
base. La deuxime problmatique non traite dans cette approche concerne lhtrognit
des rcepteurs si le rseau et de type WIMAX. Enfin, il faut sassurer que la dure du
segment vido permettra lutilisateur de recevoir le maximum de couches damlioration
en plus de la couche de base. Une seule couche damlioration a t considre dans ce
68

Etat de lart des solutions de vido streaming multicast

papier, ce qui ne correspond pas aux codeurs vido existants, comme le SVC qui fourni un
nombre important de couches. Au mme titre, la dure du segment est considre comme
un paramtre cl pour cette solution.
La dure du segment doit prendre en compte laspect temps rel de lapplication de
vido streaming. SVSoA fixe la dure dun segment 60 secs et, comme la rception des
couches est squentielle, la lecture ne pourra commencer avant lacquisition totale du
segment. Ainsi, une latence plus importante est observe par rapport une architecture
classique o la taille dun segment correspond la taille dune image (1/25 s).
Selon les auteurs, la solution SVSoA est valable pour tous les codeurs vido
hirarchiques. Dautres travaux ont propos des solutions spcifiquement pour le codage
MDC ( Multiple Description Coding ).
Les auteurs de [91] et [93] proposent une architecture Cross-Layer pour la
transmission vido IPTV dans un rseau WIMAX. En effet, la solution propose cherche
trouver un compromis entre une application vido hirarchique tels que le codage MDC et
la diversit des utilisateurs du canal radio dans les rseaux WIMAX. Une approche de type
Cross-Layer est alors adopte. Cette solution prend en considration laspect multi
rsolutions de lapplication vido et propose un schma de modulation et un plan
dallocation de ressources optimal afin de maximiser la qualit vido mme dans les
conditions radio les plus dfavorables.
Pour bien comprendre cette approche, nous rappelons le fonctionnement du codeur
MDC. Une squence vido est forme par plusieurs groupes dimages (GOP : Group Of
Pictures ou GOF : Group Of Frames ), chaque GOP est dcompos en plusieurs
couches, savoir la couche de base (layer 1 : Figure 4-2) et les couches damlioration (layer
2, ). Chaque couche est divise en plusieurs blocs de taille gale K octets. Le paramtre
K dpend de la couche en question et de certains autres paramtres. Ensuite, chaque bloc
est encod et tendu jusqu atteindre une certaine taille N, en utilisant des codes ReedSolomon [95] ou Digital Fountain [96] ou autres afin de former des PU ( Protected
Units ). Le choix du paramtre K pour chaque couche vido est effectu selon
limportance de la couche. Ainsi, le paramtre K pour la couche 1, qui est la couche de
base, est plus petite que celui de la couche 2 et ainsi de suite. Le but de ce choix est de
protger davantage les couches infrieures qui sont plus prioritaires pour dcoder les
couches suprieures (voir les dtails dans la Figure 4-3).
Aprs la formation des PU de taille N, les paquets MDC sont forms de telle faon
que chaque paquet contienne une partie de chaque PU, i.e., le premier paquet MDC
contient le premier octet de chaque PU et ainsi jusquau Nime paquet qui contient les Nime
octets de chaque PU. Ainsi, chaque paquet MDC contient une description de chaque PU et
par consquent de chaque couche vido, do le nom du codeur MDC. Aprs rception des
69

Transmission Multicast SVC Dans les Rseaux WIMAX

paquets MDC, mme en cas de perte, les codes correcteurs derreurs, prcdemment
utiliss, permettent la reconstruction des blocs et ainsi de la squence vido.

Figure 4-2 : MDC : Formations des couches vido [91]

Figure 4-3 : Formations des paquets MDC [91]

Les mmes auteurs de [91] proposent dans [92] un nouveau schma de modulation
pour les rseaux WIMAX, permettant une meilleure transmission multicast. Au lieu
dutiliser un seul schma de modulation pour une transmission multicast, chaque signal
multicast est gnr au niveau du canal en superposant des couches de qualit faible du flux
vido modul en BPSK ainsi que certaines couches damlioration modules par un ordre
suprieur de modulation tel que 16QAM. Ainsi, un rcepteur peut obtenir la qualit vido
de base en dcodant partiellement les paquets multicast des flux moduls en BPSK lorsque
le canal radio n'est pas de bonne qualit, ou obtenir la qualit complte de la vido de tous
70

Solutions et architectures proposes

les flux moduls en BPSK et en 16QAM aprs le dcodage des paquets multicast
superposs lorsque le canal radio est de bonne qualit.
Une modification au codeur MDC est introduite par les auteurs en appliquant une
protection plus importante aux couches suprieures de MDC plutt quaux couches
infrieures. Cette modification est essentielle afin dutiliser la technique de codage
superpos. En effet, leur solution consiste transmettre la description des couches
infrieures avec la modulation et le codage les plus robustes et transmettre la description
des couches suprieures avec le codage et la modulation les moins robustes. Il est clair que
la modulation BPSK est robuste et efficace par rapport au 64QAM, ainsi, il nest pas
intressant dappliquer une protection supplmentaire au niveau du codage MDC.
Cependant, pour la modulation 64QAM, beaucoup de pertes peuvent avoir lieu, ainsi une
protection supplmentaire au niveau du codage MDC apportera une fiabilisation de la
transmission.
Nous avons vu dans ce paragraphe quelques solutions pour la transmission vido
multicast prenant en compte le codage hirarchique du flux vido ainsi que la diversit des
utilisateurs et du canal radio daccs. Ces propositions nous ont permis de dfinir notre
architecture multicast laide du codage SVC. Nous dtaillons dans le prochain paragraphe
cette architecture et nous prsentons les diffrents lments techniques qui la composent.

4.4 Solutions et architectures proposes

4.4.1 Cration des groupes multicast avec codage SVC
Contrairement plusieurs codecs qui gnrent un flux vido unique avec une seule
couche, le SVC gnre de multiples flux pour de multiples niveaux hirarchiques, une
couche de base (BL : Base layer ) et une ou plusieurs couches damlioration (EL :
Enhanced layer ). La couche de base est suffisante en soi pour le dcodage, mais le
dcodage des couches damlioration ncessitent le dcodage des couches infrieures (la
couche de base dans ce cas). Les niveaux hirarchiques peuvent tre construits sur trois
dimensions, voir la Figure 4-4.

La dimension temporelle fait rfrence au nombre de trames par seconde ( frame

rate ). La couche de base se compose des trames I et P et les couches damlioration
sont composes de trames B insres entre les images I et P.

La dimension spatiale dsigne les diffrentes tailles d'image. Les couches suprieures
fournissent une image plus grande.

La dimension qualit SNR correspond la qualit d'image. Les couches suprieures

permettent une qualit plus fine de l'image avec plus de prcision.
71

Transmission Multicast SVC Dans les Rseaux WIMAX

Avec le codage hirarchique, chaque utilisateur recevra au moins la couche de base
SVC, et puis, selon sa bande passante disponible, il recevra un certain nombre de couches
damlioration. Avec cette distribution, on garantit que chaque utilisateur aura la meilleure
qualit vido quil pourra avoir selon ses ressources.
La question qui se pose maintenant est comment le serveur vido organisera la
transmission des diffrentes couches SVC selon les besoins de chaque utilisateur dans une
architecture htrogne. Pour ce faire, nous avons opt pour une solution qui combine les
caractristiques hirarchiques du SVC, de la transmission multicast IP et des
caractristiques physiques du support de communication WIMAX. Notre architecture est
de type cross-layer car elle prend en considration plusieurs aspects et paramtres se
trouvant dans des couches diffrentes.

Figure 4-4 : Les niveaux Hirarchiques SVC

Transmettre un flux vido SVC en multicast ncessite une connaissance pralable des
ressources disponibles dans le rseau afin doptimiser la diffusion. Or, cette connaissance
dpend fortement de la nature du trafic envoy et du nombre dutilisateurs prsents dans la
cellule. Plusieurs combinaisons de transmission peuvent tre possibles :

Associer un groupe multicast pour chaque couche vido, une pour la couche de base et
une pour chaque couche damlioration. Dans ce cas, le nombre de sessions multicast
est proportionnel au nombre de couches. Une session multicast est dfinie par une
adresse multicast de classe D. Cette solution savre peut efficace.

Associer un groupe multicast pour plusieurs couches vido. On pourra associer un

groupe multicast pour la couche de base toute seule puis grouper ensemble un certain
nombre de couches damlioration dans un mme groupe multicast. Cette solution
savre intressante et elle prsente plusieurs alternatives de mise en place. En effet, le
choix des couches vido regrouper ensemble peut se faire selon plusieurs critres :

72

Solutions et architectures proposes

o Le type damlioration temporelle, spatiale ou SNR : un groupe multicast ne peut
contenir que des couches damlioration de mme genre.
o Le degr damlioration : le deuxime groupe multicast, aprs le groupe de base,
comprend une premire amlioration temporelle, spatiale et SNR la fois. Ensuite,
le troisime groupe contient une deuxime amlioration gnrale, etc.
o En Zigzag, lordre des groupes multicast peut tre fait dune faon cyclique afin de
permettre des amliorations progressives selon les trois axes.
Dans la suite de ce chapitre, nous optons pour la gnration des groupes multicast
selon laxe temporelle qui correspond au nombre dimages par seconde. Il faut noter que
les autres possibilits resteront valides dans notre approche. Chaque groupe multicast
contiendra la meilleure qualit spatiale et SNR. Cette supposition est faite principalement
pour la simplification de ltude de simulation. Un exemple de dcomposition en plusieurs
groupes multicast est dcrit dans la Figure 4-5.

Group
Multicast 1

Group
Multicast 2

Group
Multicast 3

Figure 4-5 : Groupes Multicast SVC

Comme consquence directe au fonctionnement du codeur vido hirarchique SVC,

les groupes multicast ainsi crs sont complmentaires. En effet, selon la bande passante
disponible, une SS cliente devrait adhrer au premier groupe multicast, qui reprsente ou
englobe la couche vido de base ncessaire pour dcoder les couches damlioration.
Ensuite, en fonction de sa bande passante disponible, la SS adhre au second groupe
multicast et ainsi de suite. Pour recevoir la qualit vido la plus leve, une SS cliente
devrait recevoir les donnes de tous les groupes multicast sans exception. Ainsi, lordre
dimportance des groupes multicast est quivalent limportance des couches vido quils
contiennent.
Nous avons expliqu jusqu maintenant, le ct applicatif en utilisant le codage vido
hirarchique; le ct transport en utilisant le multicast et la cration des groupes multicast
partir de lapplication vido. Le paragraphe suivant dcrit les aspects relatifs la couche
73

Transmission Multicast SVC Dans les Rseaux WIMAX

MAC et Physique utiliss dans notre solution. Dans un premier temps, nous expliquons le
fonctionnement normal dune telle architecture multicast au sein dun rseau WIMAX.
Ensuite, nous dcrivons les amliorations proposes, notamment du ct radio, afin
doptimiser lutilisation des ressources radio et de maximiser la qualit vido pour tous les
utilisateurs.
4.4.2 Transmission multicast dans les rseaux WIMAX
Afin de transmettre un flux de donnes, une requte dajout de flux de service doit tre
envoye la station de base mme si cest la BS qui doit initier le trafic. Cest alors, la
fonction de contrle dadmission qui intervient.
Il est important de noter que cette procdure est valable la fois pour les flux unicast
et multicast.

Contrle dadmission dans les rseaux WIMAX

Nous rappelons que le contrle dadmission est une fonction qui dpend du
constructeur, la norme IEEE 802.16 ne prcise pas lalgorithme dordonnancement
(scheduling), elle dfinit seulement les diffrents outils ncessaires tels que les messages de
signalisation ainsi que le fonctionnement de base.
En effet, le calcul des ressources disponibles dpend de la taille de la trame au niveau
PHY, la bande frquentielle et la modulation et codage utiliss. Ainsi, aprs fixation de tous
ces paramtres, on arrive calculer le nombre de slots physiques dont dispose une station
WIMAX (BS, ou SS). Rappelons quun slot physique est une allocation rectangulaire qui
consiste en un symbole OFDM en temps et en frquence.
Supposons que la BS veuille envoyer un flux de donnes vers une des SS de sa cellule,
elle commence par calculer le nombre de slots physiques ncessaires pour ce flux (aprs
consultation de tous les paramtres PHY correspondant la fois la BS et la SS
concerne). Ensuite, la BS vrifie la disponibilit de ce nombre de slots et accepte ou refuse
laccs de ce flux.
Bien videment, la SS sera informe de cette dcision via un des messages de
signalisation et de gestion des flux de service. En particulier, chaque SS reoit les
allocations de ressources dans le champ MAP au dbut de chaque trame juste aprs le
prambule :

Le message DL_MAP

Au dbut de chaque trame, la BS inclut les messages DL_MAP et UL_MAP qui sont
envoys en broadcast toutes les SS de la cellule. Le DL_MAP contient la description des
allocations de ressources pour chaque SS et pour chaque flux de donnes. Le DL_MAP
74

Les architectures multicast SVC proposes

permet la SS de localiser le burst de donnes qui lui est ddi. Le burst tant une partie de
la trame identifie par une plage temporelle et frquentielle. Chaque burst est dcrit dans le
DL_MAP sous forme dun DL_MAP_IE. Ce dernier fournit lemplacement exact au sein
de la trame
Selon la norme IEEE 802.16, le champ DL_MAP ne contient aucune indication pour
dcrire le schma de modulation et codage utilis. En effet, suite une ngociation entre la
BS et la SS, le schma de modulation et codage est fix. Il peut tre mis jour en cas de
changement des conditions radio, la BS informant de ces changements via les champs
UCD et DCD qui sont envoys priodiquement par la BS en dbut de la trame. La valeur
de la modulation et codage est utilise pour tous les flux envoys la mme SS. Ainsi, une
SS ne peut utiliser deux modulations diffrentes dans la mme trame par exemple.
Une SS, qui peut recevoir des donnes codes en 64QAM, est tout fait capable de
recevoir des donnes avec des modulations plus robuste telles que 16QAM ou BPSK, en
particulier car les champs UCD et DCD, DL_MAP et UL_MAP sont tous cods en
modulation BPSK afin que toutes les SS les reoivent sans perte. La mme chose est
observe pour la zone de contention ddie la demande de bande passante par contention
entre toutes les SS. Par la suite, il est tout fait possible dindiquer la SS de recevoir des
donnes avec des modulations diffrentes qui ne dpassent pas le maximum ngoci avec la
BS.
Linformation contenant le schma de modulation et de codage utilis pour un burst
quelconque sera incluse dans le DLMAP_IE correspondant. Ce dtail est ncessaire pour la
ralisation et la comparaison des deux approches que nous allons dcrire dans le
paragraphe ci-dessous.

4.5 Les architectures multicast SVC proposes

Dans ce paragraphe, nous tudions les diffrentes topologies possibles dans le cadre
des rseaux WIMAX. En effet, il existe plusieurs scenarios possibles.
Dans un premier temps, nous considrons la topologie prsente dans la Figure 4-6.
Nous disposons dun serveur vido dot dun codeur vido SVC capable de transmettre le
flux sous forme de plusieurs sessions multicast comme cela a t prsent au paragraphe
prcdant. Nous supposons que le flux SVC est compos dune couche de base et de deux
couches damlioration. Les groupes multicast relatifs aux trois couches vido, sont
reprsents par les petites flches voir Figure 4-6. Nous supposons aussi quil existe trois
cellules WIMAX raccordes au rseau Internet. Une SS, de chaque cellule, se connecte au
serveur et demande le flux vido en temps rel. En fonction de leurs bandes passantes
respectives de bout en bout, chaque SS sera membre dun ou plusieurs groupes multicast.
La SS1, par exemple, sera capable de recevoir uniquement la session multicast qui
75

Transmission Multicast SVC Dans les Rseaux WIMAX

reprsente la couche vido de base du flux SVC, ceci peut tre d la non disponibilit des
ressources radio au sein de sa cellule. La SS3, par contre, sera capable de recevoir les trois
couches vido et aura, en consquence, la qualit vido maximale disponible.
Dans ce cas de figure, nous remarquons que les groupes multicast sont transports
depuis le serveur vido et via le rseau Internet jusqu atteindre les stations de base de
chaque cellule. Notons que le troisime groupe reprsentant la deuxime couche
damlioration na pas t transmis ni la BS1, ni la BS2, alors que le premier groupe de
base arrive toutes les BS. Nous constatons ainsi que la dcomposition du flux SVC en
plusieurs groupes multicast est suffisant en partie pour rsoudre le problme, en particulier
dans ce cas de topologie. Chaque SS dune cellule diffrente recevra uniquement le flux
multicast ncessaire qui correspond ses capacits rseaux. Ceci reste aussi valable si des
SS font partie de la mme cellule condition quelles aient les mmes caractristiques
radios. Dans ce cas, aucune ressource supplmentaire nest requise.

Figure 4-6 : Architecture WIMAX multi-cellules (Multi-BS)

Nous nous intressons, maintenant, au fonctionnement de notre approche au sein

dune mme cellule. La Figure 4-7 reprsente le mme serveur vido SVC et une cellule
WIMAX dont BS1 est la station de base et SS1, SS2 et SS3 sont des stations clientes avec
des caractristiques radios diffrentes. Toute les SS sont connectes au serveur vido SVC
et dsirent recevoir la meilleure qualit vido possible.
Nous supposons que les trois SS se trouvent des distances diffrentes de la BS, de
telle sorte que la BS affecte chaque SS un schma de modulation et codage diffrent ; par
exemple, SS1 en 64QAM, SS2 en 16QAM et SS3 en QPSK.
76

Les architectures multicast SVC proposes

Figure 4-7 : Cas dune seule cellule WIMAX

4.5.1 Mode de modulation simple

Pour que chaque SS puisse recevoir la meilleure qualit vido, elle doit adhrer aux
trois groupes multicast et rcuprer toutes les couches vido. Une fois les flux multicast
arrivs la BS, une demande de cration dun nouveau flux de service pour chaque groupe
et pour chaque SS est gnre. La BS doit dupliquer chaque flux multicast puisque les SS
ont des schmas de modulation diffrents. Ainsi la couche vido de base sera transmise
trois fois au sein de la mme cellule, une fois en QPSK, une fois en 16QAM et une fois en
64QAM. La mme chose est ralise pour les deux autres couches vido. La BS devra
allouer les ressources ncessaires pour chacun des neufs flux de services. Bien videmment,
en cas de manque de ressources radios, la BS devra prioriser la transmission de la couche
de base puis les couches damlioration. De mme, les SS les plus favorises, les plus
proches de la BS en gnral, seront traites en premier lieu. Le mcanisme
dordonnancement de la BS devra prendre en compte ces deux critres.

A part sa simplicit, ce mode prsente plusieurs inconvnients :

La gestion des ressources est loin d'tre efficace. En effet, les mmes donnes sont
codes plusieurs fois, cette redondance nuit considrablement au principe mme de la
transmission multicast, il sagit ici dune transmission simultane de la mme vido avec
des modulations diffrentes et le cas chant avec des qualits diffrentes.
77

Transmission Multicast SVC Dans les Rseaux WIMAX

La BS possde un nombre limit de slots physiques allouer. Avec ce nombre, la BS ne

pourra peut-tre pas satisfaire toutes les demandes. Chaque SS doit rduire la qualit de
sa vido chaque fois quil y a une nouvelle SS non compatible ou ayant des
caractristiques radios diffrentes.

Les SS avec la meilleure qualit de rception sont celles qui sont les plus proches de la
BS. Le schma de modulation et codage utilis est moins gourmand en ressources
radio, alors que les SS les plus loignes risquent de renoncer au flux vido suite une
carence en ressources.

Les SS, supportant une modulation moins robuste, sont tout fait capables de dcoder
une modulation plus robuste. Ainsi, ces SS peuvent dcoder le mme flux vido autant
de fois quil y a de schmas de modulation utiliss.

Pour remdier ces limitations, nous proposons dans un premier temps, un nouveau
systme dallocation de ressources permettant de distribuer les flux multicast selon les
diffrentes modulations.
4.5.2 Mode de Modulation Multiple
Lide consiste bnficier du fait quune SS, capable de fonctionner avec une
modulation moins robuste, peut aussi bien fonctionner avec une modulation plus robuste.
En effet, en reprenant la topologie dcrite dans la Figure 4-7, le mode multi-modulation
sera comme suit :

La couche de base est module en QPSK, le burst de donnes contenant ce premier

flux de service est visible pour toutes les SS sans exception. Ainsi, la qualit vido
minimale est dj acquise pour toutes les SS dans le champ de couverture de la BS.

La premire couche damlioration est code en 16QAM, le burst de donnes

correspondant sera visible par SS1 et SS2 uniquement. (i.e., seulement par les stations
qui peuvent dcoder cette modulation)

La deuxime couche damlioration est code en 64QAM, le burst de donnes

correspondant sera visible par SS1 uniquement.

Dans cet exemple, nous remarquons que chaque SS reoit une qualit vido diffrente,
les couches vido sont codes avec des modulations dans lordre dcroissant de robustesse.
De plus, la redondance est omise et les ressources utilises sont beaucoup moindres. Les
ressources libres pourront servir amliorer la qualit vido pour toutes les SS. Par
exemple, le codage de la couche de base et de la premire couche damlioration pourra
tre fait en QPSK et on pourra donner la possibilit SS3 de recevoir la qualit vido
amliore.
Plus prcisment, nous modifions la fonction de contrle dadmission au niveau de la
78

Les architectures multicast SVC proposes

BS afin dtablir la distribution optimale entre les groupes multicast et les diffrentes
modulations utilises au sein de la cellule. Il sagit de maximiser la qualit vido reue par
chaque SS en fonction des ressources disponibles dans le canal radio. Lalgorithme
dallocation des ressources au diffrents flux vido est dcrit comme suit :

effectuer la liste des SS dsirant recevoir le flux vido.

tablir respectivement le schma de modulation des SS dans lordre dcroissant de

robustesse.

tablir la liste des flux de service relatifs aux groupes multicast en fonction de
limportance de la couche vido quil transporte.

Calculer le nombre de slots physiques ncessaires chaque flux de service avec chaque
modulation.

Pour sassurer quun maximum de SS reoivent les flux vido, la BS a tendance

affecter la modulation la plus robuste possible tous les flux de service dans la limite
des ressources disponibles.

Si les ressources sont puises et quil y a encore une autre couche vido damlioration
non encore transmise, la BS doit changer la modulation dune ou plusieurs couches
prcdentes vers une modulation moins robuste afin de librer des ressources pour le
nouveau flux. Le nouveau flux sera cod avec la modulation la moins robuste dj
utilise. Notons que ce changement na pas dincidence sur le multicast IP

Dans le meilleur des cas, toutes les couches vido sont codes avec la modulation la
plus robuste et ainsi toutes les SS reoivent la mme vido avec la meilleure qualit. Le pire
des cas est que les ressources disponibles ne permettent pas la transmission des flux vido
quavec la modulation la moins robuste et ainsi, uniquement un petit nombre de SS aura
accs la vido.
Le mode multi-modulations profite de la diversit des schmas de modulation des SS,
faisant partie de la mme cellule, et de la diversit des groupes multicast reprsentant les
couches vido SVC. La combinaison parfaite entre ces deux paramtres, en tenant compte
des ressources disponibles, permet la BS de distribuer les flux vido aux diffrentes SS
dune faon quitable et optimale.
Dans le paragraphe suivant nous introduisons une autre technique qui permet une
conomie de ressources considrable. Contrairement au mode multi-modulations, cette
technique permet chaque SS dutiliser un seul schma de modulation pr-ngoci entre la
SS et la BS.
4.5.3 Mode de superposition de codage
Selon la norme IEEE 802.16, le rsultat de lordonnancement au niveau de la BS
consiste allouer des ressources pour chaque flux de service et pour chaque SS.
79

Transmission Multicast SVC Dans les Rseaux WIMAX

Linformation dallocation est transmise via le message DL_MAP toutes les SS. Chaque
SS dispose de lemplacement de son burst de donnes dans la trame. Le burst de donnes
qui lui est allou est cod avec la modulation la plus adquate selon ses conditions radios.
Le reste des burst ne lui est pas destin et peut tre cod avec une modulation diffrente de
la sienne.
Considrons la topologie dfinie dans la Figure 4-7, avec le serveur SVC multicast et
les SS avec diffrentes modulations. Dans le mode classique, plusieurs burst de donnes
seront crs et chacun avec une modulation diffrente selon la SS de destination. Chaque
SS reoit ses donnes dans le burst qui lui est destin, et reste en mode inactif au cours des
autres burst transportant les autres flux vido /donnes pour les autres SS.
Si plusieurs SS avec des modulations diffrentes pouvaient utiliser le mme burst de
donnes, un gain considrable de ressources radio serait ralis. En effet, si la BS arrive
coder les symboles OFDM avec deux ou plusieurs modulations en mme temps, chaque SS
dcode ces symboles OFDM avec sa propre modulation et rcuprerait ses donnes. Cette
technique sappelle la superposition de codage ou Superposition Coding , elle a t
introduite dans plusieurs travaux [93] [94] afin damliorer la capacit utilisateur dans les
rseaux sans fil.
Un exemple est illustr dans la Figure 4-8. Les nuds sont indexs dans un ordre
croissant en fonction de leur distance la BS.

Figure 4-8 : Superposition de codage dans les rseaux cellulaires [94]

Comme le montre cette figure, lorsque la BS transmet un signal M3 avec un certain

niveau SNR, le SNR ressenti la fois par M1 et M2 est beaucoup plus grand que leur
niveau de SNR attendu ou suffisant. De mme, lorsque le BS transmet un signal M2, M1
reoit de la puissance supplmentaire au-dessus de son niveau SNR. Cela implique que M1
a un SNR suffisant pour dcoder les messages destins la fois M2 et M3, et M2 a un
SNR suffisant pour dcoder les messages destins M3. Ainsi, linformation destine pour
M1 peut tre incluse dans la transmission M2 ou M3 par lutilisation de la superposition
80

Environnement et rsultats de lvaluation de performance

de codage. De mme, linformation destine M2 peut tre incluse dans la transmission
M3.
Lutilisation de la superposition de codage dans le cadre de la transmission multicast
SVC est comme suit :

effectuer la liste des SS dsirant recevoir le flux vido SVC.

tablir respectivement les diffrentes modulations des SS dans lordre dcroissant de

robustesse.

tablir la liste des flux de service relatifs aux groupes multicast en fonction de
limportance de la couche vido quil transporte.

Calculer le nombre de slots physiques ncessaires pour chaque flux de service avec
chaque modulation.

En fonction du nombre de slots physiques disponibles, calculer pour chaque

modulation, le nombre maximum de flux de service en commenant par le plus
important.

Utilisation de la superposition de codage en superposant les donnes des diffrentes

modulations.

Cet algorithme est inclus dans la fonction de contrle dadmission au niveau de la BS,
de faon similaire la solution prcdente. Pour limiter le nombre de modulations
superposer, la BS doit choisir deux ou trois modulations les plus convenables pour
satisfaire le maximum des SS de sa cellule.
Remarquons que, contrairement au mode multi-modulations, la redondance est
toujours prsente dans la technique de superposition. En effet, la couche de base, par
exemple, est code autant de fois quil y a de modulations superposer. Ceci est du au fait
quune SS ne peut dcoder plusieurs modulations en mme temps. Malgr cette
redondance, le montant de ressources utilis reste infrieur toute autre proposition.
Dans le prochain paragraphe, nous valuons, par simulation, les performances des
deux solutions proposes, nous comparons les rsultats avec le mode classique et nous
montrons le gain rsultant chaque fois.

4.6 Environnement et rsultats de lvaluation de performance

Nous dfinissons dans ce paragraphe, trois cas de figures. Tout dabord, nous
valuons, par simulation, le cas classique de la transmission multicast SVC au sein des
rseaux WIMAX sans aucune modification. Ensuite, une premire approche est mise en
uvre, il sagit de mapper les groupes multicast sur les diffrents schmas de modulations.
Enfin, dans la troisime approche, nous valuons la transmission multicast SVC dans le
cadre dun codage superpos.
81

Transmission Multicast SVC Dans les Rseaux WIMAX

4.6.1 Environnement
Nous avons utilis le simulateur QualNet [88] pour raliser les simulations des
diffrents mcanismes proposs. La ralisation est divise en deux parties :

Le serveur SVC multicast : Nous avons adapt un gnrateur de trafic dj dfini sur
QualNet afin de gnrer plusieurs flux correspondant chacun une couche vido SVC
partir dun fichier de traces. Ces traces reprsentent les tailles des images ainsi que le
temps de transmission de chaque image. A laide dun programme utilisant loutil
JSVM, nous obtenons des fichiers de traces partir dune vido relle code en SVC.
Ces traces contiennent, en particulier, la taille des images et leur appartenance la
couche de base ou aux couches damlioration. Chaque trafic est transmis en multicast
et correspond une des couches vido SVC.

Contrle dadmission : nous avons modifi les algorithmes dallocation de ressources au

niveau du contrle dadmission la BS. De nouvelles fonctionnalits sont ajoutes pour
supporter les trafics vido SVC multicast. Deux versions ont t implmentes : la
premire pour le mode multi-modulations qui permet dobtenir la meilleure distribution
entre les modulations et les groupes multicast ; et la seconde pour la superposition de
codage afin de dterminer le nombre de couches vido ncessaires pour chaque
modulation. Pour les deux mcanismes, la signalisation entre la BS et les SS est assure
par les champs DL_MAP_IE du MAP envoys au dbut de chaque trame.

Les paramtres de la couche physique IEEE 802.16, communs toutes les BS de

toutes les simulations, sont fournis dans le Tableau 4-1. Les paramtres de la vido SVC
utiliss sont fournis dans le Tableau 4-2. La squence vido de 60 secondes est partitionne
en plusieurs couches vido, nous notons une couche de base L0 et 4 couches
damlioration L1, L2, L3 et L4.

Propagation channel frequency

2.4 GHz

Channel bandwidth

20 MHz

FFT size

2048

Antenna gain

12 dB

Transmission Power

20 dB

Frame size

20 ms

Tableau 4-1. Paramtres de simulation pour la couche PHY de lIEEE 802.16

.
82

Environnement et rsultats de lvaluation de performance

Squence de Football amricain

Description
Dure

60 secondes

Dbit total moyen

~ 160 Kbps

Taille dun GOP

16 images par GOP

Nombre de couches vido

5 (not L0, , L4)

Dbit moyen pour L0

L1
L2
L3
L4

~ 37 Kbps
~ 17 Kbps
~ 28 Kbps
~ 38 Kbps
~ 40 Kbps

Tableau 4-2. Paramtres de la vido SVC

4.6.2 Rsultats dvaluation de performances

Nous effectuons une premire srie de simulation en utilisant une topologie avec trois
cellules WIMAX connectes, via le rseau internet, au serveur vido SVC (Figure 4-9). Une
SS de chaque cellule doit recevoir la qualit vido maximale. Dans ce premier scenario,
aucune modification au niveau de la BS nest applique. La BS opre dans le mode
classique comme cela est dfini par dfaut dans le simulateur QualNet.
Nous ne considrons pas de diffrence entre les SS en termes de caractristiques radio
lors de lordonnancement. Pour ce faire, les trois SS sont places la mme distance de
leurs BS, comme indiqu dans le Tableau 4-3. Nanmoins, une diffrence entre les SS
existe ; les trafics prsents dans chaque cellule ne sont pas les mmes. Un trafic CBR est
ajout en arrire plan pour surcharger la cellule. Nous modifions le dbit de ce trafic dans
chaque cellule afin dobserver son influence sur le trafic vido multicast SVC.

Il faut noter que le flux CBR ajout est dot dune priorit plus importante que le flux
SVC, le but est de limiter la bande passante au sein de chaque cellule pour forcer une SS
choisir une qualit vido moins importante. Les rsultats de cette simulation sont illustrs
par la Figure 4-10.

83

Transmission Multicast SVC Dans les Rseaux WIMAX

Figure 4-9 : Topologie avec plusieurs cellules

SS 1

SS 2

SS 3

Distance la BS (m)

350

350

350

Flux CBR (Mbps)

19.97

19.90

Tableau 4-3. Scenario : SS identiques dans diffrentes cellules

Figure 4-10 : scnario : SSs identiques dans diffrentes cellules

Nous remarquons que les trois SS nont pas reu la mme qualit vido. SS1 a eu la
qualit la plus faible en recevant la couche de base L0 uniquement, toutes les ressources
tant puises, la BS tait incapable dallouer plus de bande passante SS1. La qualit vido
84

Environnement et rsultats de lvaluation de performance

la plus leve a t atteinte chez SS3 en recevant les cinq couches vido, nayant aucun
trafic perturbateur, toutes les ressources de la BS taient la disposition de SS3.
Finalement, SS2 a eu droit une qualit moyenne contenant la couche de base L0 et deux
couches damlioration L1 et L2. Cette simulation nous permet de valider lintrt de la
dcomposition du flux SVC en plusieurs groupes multicast. Chaque SS, en fonction de la
bande passante disponible acquiert une qualit vido diffrente. De plus, les groupes
multicast, contenant des couches damlioration non ncessaires, ne sont pas transmises
jusqu la BS, leurs flux sarrte au dernier routeur en commun avec dautres BS.
Le reste des simulations dcrit dans cette partie sont ralises avec la topologie illustre
dans la Figure 4-11. On y retrouve une seule cellule WIMAX et trois SS places des
distances diffrentes de la BS. La distance des SS est choisie de telle faon que les
modulations affectes aux SS soit diffrentes lune de lautre, comme indiqu dans le
Tableau 4-4.
SS 1

SS 2

SS 3

Distance la BS (m)

100

350

580

Flux CBR (Mbps)

19.80

19.80

19.80

Modulation / Coding Rate

64QAM

16QAM

QPSK

Tableau 4-4. Scenario : Diffrentes SS dans la mme cellule

Figure 4-11 : Topologie de simulation avec une seule cellule.

Trois scnarios sont dfinis. Premirement, nous effectuons une simulation dans le
mode classique sans aucune modification. Ensuite, nous simulons le mode multimodulations et enfin, nous terminons en simulant le mode de superposition de codage.
Dans les trois cas de simulation, nous gardons les mmes paramtres de la couche Physique
802.16, ainsi que les mmes paramtres de simulation telle que la distance des SS leurs BS.
85

Transmission Multicast SVC Dans les Rseaux WIMAX

De plus, un traffic CBR en background de priorit leve est inclus dans toutes les
simulations. Par consquent, dans chaque cas de simulation, la BS possde les mmes
ressources radio pour statisfaire les SS. La diffrence entre les rsultats de simulation sera
une consquence directe du choix de la technique utilise.
4.6.2.1

Mode de codage simple

Dans le mode de codage simple, chaque SS reoit ses donnes avec la modulation qui
lui est attribue par la BS. Ainsi, pour que toutes les SS soient entirement satisfaites, il faut
que les couches L0, 1, 2, 3 et 4 soient codes avec les trois modulations. Pour cela, la BS
doit allouer les ressources ncessaires pour 15 bursts de donnes. Justement, nous avons
choisi le dbit du trafic CBR (19.8 M bps) afin dempcher que cela narrive. En effet, la BS
est incapable de satisfaire toutes les SS. Les rsultats de cette simulation sont dcrits dans la
Figure 4-12.
Nous remarquons quaucune des SS na pu atteindre la qualit vido optimale. En
effet, SS1 a atteint un dbit moyen de lordre de 80 Kbps, ce qui correspond au dbit
moyen des couches L0, L1 et L2 runies. SS2 et SS3 nont eu droit qu L0 et L1. En
analysant les fichiers de traces de cette simulation, nous avons pu voir que les ressources
mises la disposition de la BS ont t utilises ainsi :

La couche L0 cod en QPSK pour SS3, en 16QAM pour SS2 et en 64QAM pour SS1

La couche L1 cod en QPSK pour SS3, en 16QAM pour SS2 et en 64QAM pour SS1

La couche L2 cod en 64QAM pour SS1

Figure 4-12 : Scnario: Mode Classique

A travers ces rsultats de simulation, nous constatons que la transmission multicast na

pas t bnfique pour les trois stations htrognes puisque il y a eu redondance des
86

Environnement et rsultats de lvaluation de performance

couches L0 et L1. Dans le prochain scnario, nous apportons des modifications pour
optimiser lutilisation des ressources disponibles.
4.6.2.2 Mode multi-modulations
Dans ce scnario, nous effectuons la simulation avec les mmes paramtres que dans
le scnario prcdant. Les rsultats sont illustrs dans la Figure 4-13. Avec lutilisation
optimise des modulations, les SS arrivent amliorer la qualit de leurs vidos. En effet,
SS3 atteint un dbit vido moyen quivalent trois couches vido au lieu duniquement
deux couches dans le mode classique. SS2 acquiert deux couches damlioration
supplmentaires et SS1 russit avoir la qualit vido maximale. La qualit vido minimale
dans ce scnario correspond la meilleure qualit vido atteinte dans le mode classique,
ceci reprsente un gain considrable.
Les traces des simulations concernant la couche Physique de la BS nous fournissent les
dtails suivants : la couche L0, L1 et L2 ont t cods en QPSK, L3 en 16QAM et L4 en
64QAM. Ainsi trois bursts avec trois modulations sont insrs dans la trame. Par
consquent, chaque SS est capable de dcoder le burst avec la modulation qui lui est
attribue par dfaut, ainsi que les bursts avec une modulation plus robuste que la
modulation par dfaut. Cest le rle de la BS dinformer les SS de la prsence de ces bursts.
En outre, aucune redondance nest observ, chaque couche vido est code une seule
fois et avec une seule modulation. Les ressources devenues disponibles, par rapport au
mode classique, ont permis lajout dautres couches vido et par consquent lamlioration
de la qualit vido dans chaque SS.

Figure 4-13 : Scnario : Mode Multi-Modulations

87

Transmission Multicast SVC Dans les Rseaux WIMAX

4.6.2.3 Mode de superposition de codage
Dans ce scnario, nous utilisons les mmes paramtres que dans les autres scnarios.
Les rsultats de simulation du codage superpos sont fournis par la Figure 4-14. Nous
pouvons constater quune amlioration importante est ralise. Le dbit moyen du flux
vido total observ dans chaque cellule est nettement plus lev que dans les autres
scnarios. En effet, SS1 et SS2 atteignent la qualit maximale de la vido (toutes les
couches) et SS3 arrive recevoir quatre couches vido, une seule couche damlioration lui
manque.

Figure 4-14 : Scenario : Superposition de codage

A niveau de la couche physique, voici comment lallocation des ressources a t

ralise. Pour chaque SS, la BS alloue un burst de donnes, cod avec la modulation
attribue par dfaut la SS. Trois bursts au total sont allous, la taille de chaque burst ne
doit pas dpasser le nombre de slots physiques disponibles dans la trame en cours quelque
soit la modulation utilise. Dans notre cas de simulation, il est clair que le nombre de slots
physiques disponible est infrieur au nombre de slots ncessaire pour un burst cod en
QPSK contenant toutes les couches vido SVC. Cest pour cette raison que SS3 na reu
que quatre couches. Tandis que les bursts cods en 16QAM et en 64QAM ont occup un
nombre moindre de slots quil y en a de disponibles.
Nous rcapitulons les rsultats des trois scnarios dans le Tableau 4-5. Le tableau
indique le nombre de couches vido reu par chaque SS dans chaque scnario. Nous
remarquons que le mode classique ne russit satisfaire aucune SS avec une qualit vido
maximale alors que la BS a puis toutes les ressources dont elle disposait. Le mode multimodulations apporte un gain considrable et lutilisation optimise des schmas de
modulation de chaque SS apporte ses fruits. Ce mode offre la SS la meilleure qualit
88

Conclusion
observe par rapport au mode classique. Enfin, la superposition de codage reprsente
loptimisation maximale des ressources radio par rapport tous les scenarios.

SS1

SS2

SS3

Mode de Superposition de Codage

Mode Multi Modulations

Mode Classique

Tableau 4-5. Nombre de couches vido reues

Les deux modes que nous avons prsents dans ce chapitre, sont convenables pour les
SS les moins favoriss, i.e., ceux qui sont loin de la BS. En effet, nous remarquons que SS2
et SS3 sont les stations qui ont le plus profit de cette optimisation puisquelles passent
dune qualit vido trs moyenne une qualit presque maximale.

4.7 Conclusion
Dans ce chapitre, nous avons propos plusieurs mcanismes permettant la
transmission multicast de flux vido en streaming au sein des rseaux WIMAX. La
problmatique tudie consiste trouver un meilleur compromis entre, dune part, la
diversit des stations clientes en termes de bande passante, de ressources disponibles et de
conditions radio et dautre part, la structure hirarchique du codage vido SVC adapte
lhtrognit des rcepteurs. Nous avons pu tudier le fonctionnement de ce type
dapplication dans un rseau WIMAX classique, nous avons identifi ses problmes et nous
avons propos des solutions pour y remdier.
Deux techniques ont t introduites. En premier lieu, lutilisation intelligente des
diffrentes modulations des SS a permis un gain en ressources et par consquent en dbit
vido ralis. Cette technique met en vidence la compatibilit de certaines stations avec
des modulations plus robustes par rapport la modulation par dfaut qui lui est attribue
par la BS. La redondance de certaines couches vido est alors omise. Ensuite, le codage en
superposant plusieurs modulations permet une utilisation optimale des ressources
disponibles dans la cellule. Le principe de cette technique rside dans le fait que le support
radio, permettant denvoyer des donnes une station loigne de la BS, permet en mme
temps lintgration des donnes envoyes une station proche.
Loptimisation de lutilisation des ressources reste toujours un sujet dactualit, les
mcanismes dcrits dans ce chapitre sont adapts la couche physique IEEE 802.16
OFDMA. En fait, la dcomposition de la trame en plusieurs symboles OFDM ou en slots
physiques permet un accs multiple aux utilisateurs du canal et offre, par consquent, une
manipulation plus facile pour les algorithmes dordonnancement et dallocation de
ressources.
89

Transmission Multicast SVC Dans les Rseaux WIMAX

90

Conclusion

Chapitre 5
CONCLUSION

La technologie WIMAX a merg comme une alternative comptitive aux solutions

d'accs filaires pour la fourniture de l'accs haut dbit. Sa conception efficace lui permet de
supporter des classes de trafic htrognes avec des contraintes de qualit de service
diffrentes. En effet, les nombreux avantages quoffre cette technologie (haut dbit,
couverture plus large, support de la QoS, etc.) lui ont permis de simposer rapidement
comme une alternative technique intressante aux rseaux cellulaires existants. Cependant,
la mise en place de services IP multimdia, qui ncessitent des garanties de QoS, dmontre
la ncessit de concevoir de nouveaux mcanismes mettant en place des interactions
coordonnes entre le rseau et l'application afin de pallier aux limitations observes.
Si la problmatique relative la QoS dans le cur du rseau IP a t largement traite
durant ces dernires annes, la QoS dans les rseaux daccs tel que le WIMAX reste un
domaine de recherche dactualit. Les contraintes dapplications en termes de paramtres
de QoS doivent tre garanties travers l'ensemble des couches de larchitecture rseau.
Pour cela, les interactions entre les couches protocolaires sont devenues ncessaires pour
permettre dchanger des mtriques de performances indispensables ladaptation de leur
fonctionnement. Ce nouveau paradigme dinteraction est appel mcanisme Cross-Layer.
La conception de nouveaux mcanismes doit, ainsi, prendre en compte cet aspect
dadaptation. Ces mcanismes doivent tre plus flexibles et doivent, en mme temps,
interagir avec leur environnement caractris par une htrognit grandissante.
Dans cette thse, nous nous sommes intresss aux performances des rseaux
WIMAX dans le cadre du streaming vido. Pour ce faire, nous avons explor les
mcanismes Cross-Layer pour ladaptation et loptimisation de la transmission des services
vido en fonction des contraintes des rseaux daccs 802.16.
91

CONCLUSION
Lobjectif principal des solutions proposes est de permettre aux utilisateurs dacqurir
un service vido avec contrle de qualit de service, et ce en instaurant une collaboration
efficace et utile entre la couche MAC/Radio et la couche application.
Dans ce qui suit, nous rsumons les principales contributions qui ont t dtailles
dans cette thse. Enfin, nous prsenterons un ensemble de perspectives pouvant tre
explores dans de futurs travaux.
Dans lapproche CLO (Cross-Layer Optimizer), nous avons propos une solution
base sur les mcanismes Cross-Layer pour ladaptation des applications de streaming
vido sur le lien montant. Loptimisation apporte par CLO est applique au niveau des
stations SS qui transmettent leur contenu en unicast dans le rseau WIMAX. Lide de
CLO consiste exploiter les messages de gestion de la couche MAC afin de dtecter, au
pralable, les changements de conditions MAC/Radio. Ds lors, lentit CLO informe
lapplication de streaming vido de ces changements qui seront pris en compte par des
adaptations. Pour valider le fonctionnement de ce mcanisme, nous avons analys les
performances par simulations. Les rsultats obtenus ont montr que lentit CLO a pu
garantir une meilleure QoS et ceci ladmission du flux vido et au cours de la
transmission.
La deuxime approche propose dans cette thse concerne la transmission IP
multicast des flux vido au format SVC vers des terminaux WIMAX htrognes. Il sagit
dune solution dadaptation des flux vido multicast en fonction des utilisateurs prsents
dans la cellule WIMAX. La solution prend en compte laspect dhtrognit des
utilisateurs en termes de conditions rseaux et de ressources radio disponibles. La nature
hirarchique du codage vido SVC a t un avantage prpondrant pour larchitecture
multicast propose. En effet, pour pallier la diversit radio et lhtrognit des
ressources utilisateurs, plusieurs groupes multicast ont t crs. Ces groupes sont
complmentaires et contiennent chacun une ou plusieurs couches vido SVC. Selon la
bande passante disponible, une SS sabonne un certain nombre de groupes (couches
vido) et ralise ainsi une qualit vido maximale possible. Cette architecture multicast est
value tout dabord dans le cadre dune modulation simple : la BS diffuse les flux multicast
conventionnellement au sein de sa cellule.
Dans le cadre de la mme approche, nous avons ensuite propos un nouveau systme
dallocation des ressources au sein dune mme cellule. Pour cela, nous avons exploit la
diversit des utilisateurs selon le schma de modulation utilis. En effet, la BS distribue les
flux vido multicast selon les diffrentes modulations des utilisateurs. Par consquent, un
gain considrable de ressources est ralis en liminant les redondances. De plus, chaque SS
peut fonctionner en mode de modulations multiples. Elle est, en effet, capable de dcoder
les modulations gales ou plus robustes sa modulation en cours et obtient ainsi, une
92

Conclusion
qualit vido encore meilleure. Au mme titre, nous avons exploit la technique de
superposition de codage qui permet une BS de coder simultanment des donnes avec
plusieurs modulations dans le mme canal. Chaque SS nutilise, dans ce cas, que sa propre
modulation pour dcoder les donnes. Avec cette technique, les prcieuses ressources
conomises ont permis par la suite daugmenter la qualit vido perue par les utilisateurs.
Lanalyse et la comparaison des rsultats de simulation des trois modes (modulation simple,
modulations multiples et modulations superposes) ont montr lefficacit de la solution
garantir la qualit vido aux utilisateurs. Le mode de modulations par superposition a
permis doffrir la meilleure QoS.
Les travaux exposs dans cette thse ont t raliss dans le cadre dune architecture
PMP en mode centralis en UL pour la premire solution et en DL pour la deuxime
solution. Plusieurs perspectives peuvent tre exposes pour amliorer les solutions
dadaptation proposes pour dautres cas dutilisation et dautres architectures. Nous
dtaillons ci-dessous ces perspectives.
Extension en DL pour le CLO : Lapproche CLO propose une solution dadaptation
Cross-Layer pour les transmissions vido sur le lien montant, cest--dire, depuis une SS
vers la BS puis vers nimporte quel client. Lentit CLO exploite les changes de messages
de gestion entre BS et SS pour en faire bnficier la couche application. Pour une
projection de notre solution pour loptimisation dune transmission en DL, des
modifications sont ncessaires. En effet, lentit CLO pourrait tre implante au niveau de
la BS, sauf que les dcisions dadaptation du service de transmission vido ne remontent
pas la couche application, mais sont plutt envoyes au serveur vido distant. Par
consquent, un protocole de communication pour transmettre ces dcisions entre lentit
CLO et la couche application ct serveur, doit tre dfini. De plus, il faut considrer le
dlai supplmentaire en termes de temps de raction du systme caus par cet change
entre BS et serveur vido.
Optimisation des communications dans les rseaux multi-sauts: le CLO a t test dans le cadre
dun ordonnancement centralis la BS en mode PMP. Dans le mode multi-sauts relais,
la solution CLO reste applicable si un ordonnancement centralis la BS est utilis. En
effet, puisque les informations sur ltat du canal sont fournies par la BS, lentit CLO peut
prendre une dcision qui tient compte du lien montant de bout-en-bout en passant par la
station relais RS. Par contre, dans le cas dun ordonnancement distribu, linformation
utilise par le CLO provient du relai daccs et ne donne pas une ide complte sur le lien
montant vers la BS. Dans ce contexte, il est ncessaire que la station relais RS participe la
prise de dcision de lentit CLO puisquelle a accs aux informations concernant le lien
vers la BS. Ainsi, si le relayage coopratif est utilis, un algorithme supplmentaire au
niveau du CLO permettra une adaptation plus efficace selon le(s) relais utilis(s). Au final,
93

CONCLUSION
lentit CLO reste une solution de base pour une architecture ddie aux rseaux multisauts.
Cas des rseaux multi-sauts pour le multicast SVC : la dcomposition de la transmission du
flux SVC en plusieurs flux multicast ne peut tre que bnfique dans le cadre du rseau
WIMAX multi-sauts. En effet, en prsence de clients avec des conditions diffrentes,
certains flux multicast ne seront pas transfrs par les relais et ceci ne peut tre que
bnfique pour prserver les ressources au niveau du lien entre un relais et les SS.
Concernant le mode de modulation, cela dpend du type de relais et du mode
dordonnancement utiliss. En effet, dans le cas dun relais transparent (ordonnancement
centralis par dfaut) ou dun relais non transparent en mode centralis, tous les trois
modes de modulation sont possibles puisque toutes dcisions prises par la BS seront
ralises par les relais. Cependant, pour le mode distribu, nous devons ajouter des
fonctionnalits au niveau de la RS pour choisir la technique de modulation la plus adquate
et la distribution des flux multicast selon ces modulations.

94

Rfrences

Rfrences
[1] IEEE Std 802.16, IEEE Standard for Local and metropolitan area networks. Part 16: Air Interface for Fixed
Broadband Wireless Access Systems, October 2004.

[2] IEEE Std 802.16e, IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and
Mobile Broadband Wireless Access Systems. Amendment 2: Physical and Medium Access Control Layers for
Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1, February 2006.

[3] IEEE Draft Standard P802.16j/D5, Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access
Systems Multihop Relay Specification, May 2008.

[4] Xavier Lagrange, Philippe Godlewski, and Sami Tabbane, "Rseaux GSM", 5ime dition, September 2000.
[5] Emmanuel Seurre, Patrick Savelli, and Pierre-Jean Pietri, "GPRS for Mobile Internet", December 2002.
[6] Timo Halonen, Javier Romero, and Juan Melero, "GSM, GPRS and EDGE Performance: Evolution Towards
3G/UMTS", second edition, October 2003.

[7] Josef Franz Huber and Alexander Joseph Huber, "UMTS and Mobile Computing", March 2002.
[8] Aleksandar Damnjanovic, Branimir Vojcic, and Vieri Vanghi, "The CDMA2000 System for Mobile
Communications: 3G Wireless Evolution", July 2004.

[9] Harri Holma and Antti Toskala, "HSDPA/HSUPA for UMTS: High Speed Radio Access for Mobile
Communications", April 2006.

[10] Stphane Jacquelin, "Evolution of the wireless network to LTE", Technical report, Alcatel-Lucent, February 2008.
[11] Institute of Electrical and Electronics Engineers, "Part 11: Wireless LAN medium access control (MAC) and
physical layer (PHY) specifications - amendment 4: Further higher-speed physical layer extension in the 2.4 ghz
band", June 2003.

[12] IEEE 802.16 Broadband Wireless AccessWorking Group, "IEEE 802.16m requirements", January 2007.
[13] Jorg Liebeherr, "Packet scheduling", Technical report, Lab 3, February 2007.
[14] Khaled M. F. Elsayed, "Enhancing the end-to-end schedulability condition of EDF scheduling for real-time
applications", ATM Workshop Proceedings, 1998 IEEE, pages 75 _ 79, May 1998.

[15] Chih-He Chiang, Wanjiun Liao, and Tehuang Liu, "Adaptive downlink/uplink bandwidth allocation in IEEE
802.16 (WIMAX) wireless networks: A cross-layer approach", Global Telecommunications Conference, 2007,
GLOBECOM '07, pages 4775_4779, November 2007.

[16] Alexander Sayenko, Olli Alanen, Juha Karhula, and Timo Hmlinen, "Ensuring the QoS requirements in 802.16
scheduling", the 9th ACM international symposium on Modeling analysis and simulation of wireless and mobile
systems, MSWiM '06, pages 108 _ 117, October 2006.

[17] Teck Peow Lee and Guven Mercankosk, "Deficit round robin favors longer documents", TENCON 2006, IEEE
Region 10 Conference, November 2006.

[18] Carstin Ball, Franz Treml, Xavier Gaube, and Anja Klein, "Performance analysis of temporary removal scheduling
applied to mobile wimax scenarios in tight frequency reuse", European Transactions on Telecommunications,
2(16):888_894, September 2005.

[19] Hemant Kr Rath, Abhijeet Bhorkar, and Vishal Sharma, "An opportunistic DRR (O-DRR) uplink scheduling
scheme for IEEE 802.16-based broadband wireless networks", International Conference on Next Generation
Networks, February 2006.

93

Rfrences
[20] Reetesh Mukul, Pradyumna Singh, D. Jayaram, Debabrata Das, N. Sreenivasulu, Karnati Vinay, and Anoop
Ramamoorthly, "An adaptive bandwidth request mechanism for QoS enhancement in WIMAX real time
communication", Wireless and Optical Communications Networks, April 2006.

[21] Tzu-Chieh Tsai, Chi-Hong Jiang, and Chuang-Yin Wang, "CAC and packet scheduling using token bucket for
IEEE 802.16 networks", Journal of communications, 1(2) :30_37, May 2006.

[22] Qingwen Liu, Xin Wang, and Georgios B. Giannakis, "A cross-layer scheduling algorithm with QoS support in
wireless networks", IEEE Transactions on Vehicular Technology, 55(3) :839_847, May 2006.

[23] Kalyan Vinay, N. Sreenivasulu, D. Jayaram, and Debabrata Das, "Performance evaluation of end-to-end delay by
hybrid scheduling algorithm for QoS in IEEE 802.16 network", Wireless and Optical Communications Networks,
2006 IFIP International Conference on, April 2006.

[24] IUT-T Recommendation H.323 (11/96), "Visual telephone systems and equipment for local area networks which
provide a non guaranteed quality of service", Nov. 1996.

[25] IUT-T Recommendation H.323 Draft v4 (11/2000), "Packet-based multimedia communications systems", Nov.
2000.

[26] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, "RFC
3261: SIP : Session Initiation Protocol", Request for Comments, IETF, June 2002.

[27] H. Schulzrinne, A. Rao, R. Lanphier, "RFC 2326: Real Time Streaming Protocol (RTSP)", Request for Comments,
IETF, April 1998.

[28] M. Handley, V. Jacobson, C. Perkins, "RFC 4566: SDP: Session Description Protocol", Request for Comments,
IETF, July 2006.

[29] M. Handley, C. Perkins, E. Whelan, "RFC: 2974 Session Announcement Protocol", Request for Comments, IETF,
Oct. 2000.

[30] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RFC 3550: RTP: A Transport Protocol for Real-Time
Applications", Request for Comments, IETF, July. 2003.

[31] ITU-T Recommendation H.261: "Video codec for audiovisual services at p x 64 kbit/s", March 1993.
[32] ITU-T Recommendation H.263: "Video coding for low bitrate communication", March 1996.
[33] ISO/IEC JTC1 IS 11172 (MPEG-1), "Coding of moving picture and coding of continuous audio for digital storage
media up to 1.5 Mbps", 1992.

[34] ISO/IEC JTC1 IS 13818 (MPEG-2), "Generic coding of moving pictures and associated audio", 1994.
[35] ISO/IEC JTC1 IS 14386 (MPEG-4), "Generic Coding of Moving Pictures and Associated Audio", 2000.
[36] ISO/IEC 14496-10 AVC or ITU-T Rec. H.264, September 2003.
[37] ISO/IEC JTC 1/SC 29/WG 11, Joint Draft 5: Scalable Video Coding", Bangkok, Jan. 2006.
[38] P. Amon and J.Pandel, "Evaluation of adaptive and reliable video transmission technologies", In Proc. of the 13th
Packet Video Workshop, Nantes France, 2003.

[39] A. Vetro, C. Christopoulos, Huifang Sun, "Video transcoding architectures and techniques: an overview", IEEE
Signal Processing Magazine, Volume 20, Issue 2, Page(s):18 - 29, March 2003.

[40] J. Xin, C.-W. Lin, M.-T. Sun, "Digital Video Transcoding", Proceedings of the IEEE, Volume: 93 , Issue: 1, On
page(s): 84 - 97, Jan. 2005.

[41] I. Ahmad, Xiaohui Wei, Yu Sun, Ya-Qin Zhang,"Video transcoding: an overview of various techniques and
research issues", IEEE Transactions on Multimedia, Volume 7, Issue 5, Page(s):793 - 804, Oct. 2005.

[42] Peng Chen; Jeongyeon Lim; Bumshik Lee; Munchurl Kim; Sangjin Hahm; Byungsun Kim; Keunsik Lee; Keunsoo
Park, "A network-adaptive SVC Streaming Architecture", The 9th International Conference on Advanced
Communication Technology, Volume 2, Page(s):955 - 960, Feb. 2007.

[43] Avramova, Z.; De Vleeschauwer, D.; Spaey, K.; Wittevrongel, S.; Bruneel, H.; Blondia, C., "Comparison of
simulcast and scalable video coding in terms of the required capacity in an IPTV network", Packet Video 2007,
Page(s):113 - 122, Nov. 2007.

[44] Wien, M.; Cazoulat, R.; Graffunder, A.; Hutter, A.; Amon, P, "Real-Time System for Adaptive Video Streaming
Based on SVC", IEEE Transactions on Circuits and Systems for Video Technology, Volume 17,
Page(s):1227 - 1237, Sept. 2007.

94

Issue 9,

Rfrences
[45] M. van der Schaar, D.S. Turaga, "Multiple description scalable coding using wavelet-based motion compensated
temporal filtering", Proc on International Conference on Image Processing (ICIP 2003), Volume 3, Page(s):III - 48992, Sept 2003.

[46] Zhe Wei, Canhui Cai, Kai-Kuang Ma, "A Novel H.264-based Multiple Description Video Coding Via Polyphase
Transform and Partial Prediction", International Symposium on Intelligent Signal Processing and Communications
(ISPACS '06), Page(s):151 - 154, Dec. 2006.

[47] Zhe Wei, Canhui Cai, Kai-Kuang Ma, "H.264-based Multiple Description Video Coder and Its DSP
Implementation", IEEE International Conference on Image Processing, Page(s):3253 - 3256, Oct. 2006.

[48]
[49] J. Apostolopoulos, T. Wong, Wai-tian Tan, S. Wee, "On multiple description streaming with content delivery
networks", Proceedings in IEEE INFOCOM 2002, Twenty-First Annual Joint Conference of the IEEE Computer
and Communications Societies, Volume 3, Page(s):1736 - 1745, June 2002.

[50] M. Pereira, M. Antonini, and M. Barlaud, Multiple description coding for internet video streaming, Proceeding,
IEEE International Conference Image Processing, Sept. 2003.

[51] Wang, Y.; Reibman, A.R.; Lin, S.; "Multiple Description Coding for Video Delivery", Proceedings of the IEEE,
Volume 93, Issue 1, Page(s):57 - 70, Jan. 2005.

[52] Joohee Kim; Mersereau, R.M.; Altunbasak, Y.; "Distributed video streaming using multiple description coding and
unequal error protection", IEEE Transactions on Image Processing, Volume 14, Issue 7, Page(s):849 - 861, July
2005.

[53] Jong-Tzy Wang, Pao-Chi Chang, "Error-propagation prevention technique for real-time video transmission over
ATM networks", IEEE Transactions on Circuits and Systems for Video Technology, Volume 9, Issue 3, Pages: 513
- 523, Apr. 1999.

[54] C. Papadopoulos and G. M. Parulkar, "Retransmission-based Error Control for Continuous Media Applications",
Proc. 6th International Workshop on Network and Operating Systems Support for Digital Audio and Video
(NOSSDAV), April 1996.

[55] D.Loguinov, H.Radha, "On retransmission schemes for real-time streaming in the Internet", Proceedings In IEEE
INFOCOM 2001, Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies,
Volume 3, Page(s):1310 - 1319, 2001.

[56] Injong Rhee, Srinath R. Joshi, "FEC-based Loss Recovery for Interactive Video Transmission," icmcs, p. 9250,
1999 IEEE International Conference on Multimedia Computing and Systems (ICMCS'99) - Volume 1, 1999

[57] Cai, J.; Qian Zhang; Wenwu Zhu; Chen, C.W., "An FEC-based error control scheme for wireless MPEG-4
videotransmission", Proc In IEEE Wireless Communications and Networking Conference (WCNC 2000), Volume
3, Page(s):1243 - 1247, 2000.

[58] J. Rosenberg, and H. Schulzrinne, "RFC 2733: RTP payload format for generic forward error correction", Request
for Comments, IETF, December 1999.

[59] Wai-Tian Tan, A.Zakhor, "Video multicast using layered FEC and scalable compression", IEEE Transactions on
Circuits and Systems for Video Technology, Volume: 11, Issue: 3, on page(s): 373-386, Mar 2001.

[60] I.Bouazizi, M.Gunes, "Distortion-optimized FEC for unequal error protection in MPEG-4 video delivery", Proc in
Ninth International Symposium on Computers and Communications (ISCC 2004), Volume 2, Page(s): 615 - 620,
June-July 2004.

[61] Trista Pei-chun Chen, Tsuhan Chen, "Second-generation error concealment for video transport over error prone
channels", Proc in International Conference on Image Processing, Volume: 1, on page(s): I-25- I-28, 2002.

[62] V. Srivastava and M. Motani, "Cross-layer design: a survey and the road ahead", IEEE Communications Magazine,
vol.43, no.12, pp.112-119, December 2005.

[63] Nasser Sedaghati-Mokhtari, Mahdi Nazm Bojnordi, Nasser Yazdani, "Cross-Layer Design: A New Paradigm", Proc
in International Symposium on Communications and Information Technologies (ISCIT '06), On page(s): 183-188,
Bangkok, Sept 2006.

[64] Q. Wang, M. A. Abu-Rgheff, "Cross-Layer Signalling for Next-Generation Wireless Systems", Proc In IEEE
Wireless Communication and Networking, New Orleans, Mar. 2003.

[65] V.T.Raisinghani, S.Iyer, "Cross-layer feedback architecture for mobile device protocol stacks", IEEE
Communications Magazine, Volume 44, Issue 1, Page(s): 85 - 92, Jan 2006.

95

Rfrences
[66] R.Winter, J.H.Schiller, N.Nikaein, C.Bonnet, "CrossTalk: cross-layer decision support based on global knowledge",
in IEEE Communications Magazine, ISSN: 0163-6804, pages 93- 99, Volume: 44, Issue: 1, Jan 2006.

[67] S.Khan, Y.Peng, E.Steinbach, M.Sgroi, W.Kellerer, "Application-driven cross-layer optimization for video streaming
over wireless networks", In IEEE Communications Magazine, ISSN: 0163-6804, pages 122- 130, Volume: 44, Issue:
1, Jan 2006.

[68] M. Van Der Schaar, et al., "Cross-layer wireless multimedia transmission: challenges, principles, and new
paradigms", IEEE Wireless Communications Magazine, vol. 12, no. 4, pp. 50-58, August 2005.

[69] Hai Jiang; Weihua Zhuang; Xuemin Shen,"Cross-layer design for resource allocation in 3G wireless networks and
beyond", IEEE Communications Magazine, Volume 43, Issue 12, Page(s): 120 - 126, Dec 2005.

[70] A.Sali, A.Widiawan, S.Thilakawardana, R.Tafazolli, B.G.Evans, "Cross-Layer Design Approach for Multicast
Scheduling over Satellite Networks", 2nd International Symposium on Wireless Communication Systems, ISBN: 07803-9206-X, page(s): 701- 705, Sept 2005.

[71] E.Setton, Taesang Yoo, Xiaoqing Zhu, A.Goldsmith, B.Girod, "Cross-layer design of ad hoc networks for real-time
video streaming", IEEE Communications Magazine, Volume 12, Issue 4, Page(s): 59 - 65, Aug 2005.

[72] P. A. Chou and Z. Miao, "Rate-Distortion Optimized Streaming of Packetized Media", Microsoft Research tech rep
MSR-TR-2001-35, Feb 2001.

[73] E. Setton, X. Zhu, and B. Girod, "Congestion-Optimized Scheduling of Video over Wireless Ad Hoc Networks",
IEEE International Symposium on Volume 4, Page(s): 3531-3534, May 2005.

[74] Hai Jiang; Weihua Zhuang; Xuemin Shen,"Cross-layer design for resource allocation in 3G wireless networks and
beyond", IEEE Communications Magazine, Volume 43, Issue 12, Page(s): 120 - 126, Dec 2005.

[75] Q. Zhang, F.Yang, W.Zhu, "Cross-Layer QoS Support for Multimedia Delivery over Wireless Internet", EURASIP
Journal on Applied Signal Processing, vol: 2005:2, pp. 207-219, 2005.

[76] M. Van Der Schaar, et al., "Cross-layer wireless multimedia transmission: challenges, principles, and new
paradigms", IEEE Wireless Communications Magazine, vol. 12, no. 4, pp. 50-58, August 2005.

[77] Qiong Li, M.van der Schaar, "Providing adaptive QoS to layered video over wireless local area networks through
real-time retry limit adaptation", IEEE Transactions on Multimedia, Volume 6, Issue 2, Page(s): 278 - 290, Digital
Object Identifier 10.1109/TMM.2003.822792, April 2004.

[78] Lai-U Choi, W.Kellerer, E.Steinbach, "Cross-Layer optimization for wireless multi-user video streaming",
International Conference on Image Processing 2004 (ICIP'04), Volume: 3, pages: 2047- 2050, October 2004.

[79] Lai-U Choi, Wolfgang Kellerer, Eckehard Steinbach, "On Cross-Layer Design for Streaming Video Delivery in
Multiuser Wireless Environments", EURASIP Journal on Wireless Communications and Networking, Volume 2006,
Article ID 60349, pages 1-10, May 2006.

[80] R. Pabst, B. Walke, and D. Schultz, Relay-Based Deployment Concepts for Wireless and Mobile Broadband
Radio, IEEE Commun. Mag., Sept. 2005.

[81] N. Esseling, B. Walke, and R. Pabst, Fixed Relays For Next Generation Wireless Systems, Ch. 5, Emerging
Location Aware Broadband Wireless Ad Hoc Networks, R. Ganesh, S. Kota, and K. Pahlavan, Eds., Springer
Science and Business Media, 2005, pp. 71-91.

[82] Yi-Ting Mai; Chun-Chuan Yang; Yu-Hsuan Lin, "Cross-Layer QoS Framework in the IEEE 802.16
Network," Advanced Communication Technology, The 9th International Conference on , vol.3, no., pp.2090-2095,
12-14 Feb. 2007

[83] Y. T. Mai, C. C. Yang, and Y. H. Lin, Design of the Cross-Layer QoS Framework for the IEEE 802.16 PMP
Networks, IEICE Transactions on Communications, vol. E91-B, no. 5, pp. 1360-1369, May 2008.

[84] Noordin, K.A.; Markarian, G., "Cross-Layer Optimization Architecture for WiMAX Systems," Personal, Indoor
and Mobile Radio Communications, 2007. PIMRC 2007. IEEE 18th International Symposium on , vol., no., pp.1-4,
3-7 Sept. 2007

[85] D.-K. Triantafyllopoulou, N. Passas, and A. Kaloxylos, "A Cross-Layer Optimization Mechanism for Multimedia
Traffic over IEEE 802.16 Networks", European Wireless 2007, Paris, France, Apr. 2007.

[86] Fan Li, G. Liu, L. He, "Application-driven cross-layer design of multiuser H.264 video transmission over wireless
networks", Proceedings of the 2009 International Conference on Wireless Communications and Mobile Computing:
Connecting the World Wirelessly, pp. 176-180, 21-24 Juin 2009.

[87] J. She, F. Hou, and P.-H. Ho, An Application-Driven MAC-layer Buffer Management with Active Dropping for

96

Rfrences
Real-time Video Streaming in 802.16 Networks, Proc. of IEEE 21st International Conference on Advanced
Networking and Applications, pp.451-458, Niagara Falls, Canada, 2007.

[88] Scalable Network Technologies (SNT). QualNet. . [Online]. Available: http://www.qualnet.com/

[89] MPEG-4 and H.263 Video Traces for Network Performance Evaluation.[Online].Available:http://www.tkn.tuberlin.de/research/trace/trace.html

[90] Ch. Neumann and V. Roca, Scalable Video Streaming over ALC (SVSoA): a Solution for the Large Scale Multicast
Distribution of Videos, Research Report, INRIA Rh.one-Alpes, Plan_ete project, March 2003.

[91] J. She, X. Yu, P. Ho, and E. Yang. A cross-layer design framework for robust IPTV services over IEEE 802.16
networks. IEEE JSAC, 27(2):235245, Feb. 2009.

[92] J. She et al., IPTV over WiMAX: Key Success Factors, Challenges, and Solutions, IEEE Communications
Magazine, vol. 45, no 8, Aug. 2007, pp.87-93

[93] James She, Xiang Yu, Fen Hou, Pin-Han Ho, and En-Hui Yang, A Framework of Cross-Layer Superposition
Coded Multicast for Robust IPTV Services over WiMAX, IEEE Wireless Communications and Networking
Conference, 2008., pp. 3139-3144, 2008

[94] S. Bopping and J. M. Shea, Superposition Coding in the Downlink of CDMA Cellular Systems, IEEE Wireless
Commun and Networking Conf., vol. 4, Apr. 36, 2006, pp. 197883.

[95] I. S. Reed and G. Solomon, "Polynomial Codes over Certain Finite Fields," J. SIAM 8, 300 (1960).
[96] D. J. C. MacKay, Fountain codes, IEE Proc. - Comm., vol. 152, pp. 10621068, 2005.
[97] M. Luby, et. al., Asynchronous Layered Coding (ALC) Protocol Instantiation, IETF Internet RFC 3450,
December 2002.

97

Rfrences

98

Liste des publications

Liste des publications

Brevet
[A] A. ABDALLAH, DE. MEDDOUR, T. AHMED, "Optimisation dune communication de donnes, notamment
pour des applications de transmission en continu de donnes vido dans un rseau WIMAX ", 11/06/2009, INPI
FR #0953911

Articles
[B] Alaeddine Abdallah, Djamal Eddine Meddour, Toufik Ahmed, Raouf Boutaba, Cross Layer Optimization
Architecture for Video Streaming in WIMAX Networks, IEEE Symposium on Computers and Communications,
ISCC 2010.

[C] Alaeddine Abdallah, Djamal Eddine Meddour, Toufik Ahmed, Tinku Rasheed, Cross Layer Design for Optimized
Video Streaming Over Heterogeneous Networks, Proceedings of the 6th International Wireless Communications
and Mobile Computing Conference IWCMC 2010.

99

Annexe

100

Annexe

Annexe
A.1 Dtails de la couche MAC 802.16
A.1.1 Format du MAC PDU
Un MAC PDU est l'unit de donne change entre les couches MAC de la BS et des
SS. Un MAC PDU (Figure A-1) est constitu d'un entte gnrique de longueur fixe, d'un
payload optionnel et de taille variable et d'un champ CRC ( Cyclic Redanduncy
Cheksum ) optionnel. Le payload comprend zro ou plusieurs sous-enttes, zro ou
plusieurs MAC SDU et/ou fragments de MAC SDU.

Figure A-1 : Format d'un MAC PDU

Il ya deux formats d'en-ttes MAC, le premier est gnrique (Figure A-2) valable pour
tous les MAC PDU contenant des donnes de gestion de la couche MAC ou des donnes
de la couche CS. Le deuxime est le Bandwith Request (Figure A-3) utilis dans le cas de
demande de bande passante. Le champ HT permet d'indiquer s'il s'agit d'un entte
gnrique (HT=0) ou bien d'un entte BR (HT=1).

Figure A-2 : Format d'entte gnrique

101

Annexe

Figure A-3 : Format d'entte Bandwidth Request

Pour plus d'informations, voici la description des champs de l'entte MAC:

HT

: Header Type : type de l'entte

EC

: Encryptions Control

Type

: Type de sous-enttes prsentes dans le payload

CI

: CRC Indicator

EKS

: Encryptions Key Sequence

LEN

: LENgth

BR

: Bandwith Request

CID

: Connection Identifier

HCS

: Header Check Sequence

A.1.2 Les messages de gestion de la couche MAC

Le standard IEEE 802.16d dfinit un ensemble de messages de management. Ces
messages doivent tre inclus dans le payload du MAC PDU. Chaque message commence
par un champ type du message.
A.1.2.1 DCD ( Down link Channel Descriptor )
Ce message est transmis en diffusion par la BS d'une manire priodique dans le but de
dfinir les caractristiques du canal physique en DL, ce message est envoy chaque fois qu'il
y a un changement, l'intervalle entre deux messages DCD ne doit pas dpasser la valeur du
DCD Interval (10 secs).

102

Annexe
Ce message contient :
lidentifiant du canal du DL ainsi que sa frquence
un champ Configuration Change Count, permettant de savoir si les informations
sont rcentes ou pas.
la dure dune trame en termes de Slots Physiques (PS).
la puissance maximale que peut recevoir la BS au cours de la phase dinitial ranging.
la dure des gaps TTG et RTG correspondant respectivement au temps ncessaire
pour que la BS passe du mode transmission au mode rception et vice-versa.
la liste des DL burst profile.
A.1.2.2 UCD ( Uplink Channel Descriptor )
Tout comme le DCD, lUCD est un message de management envoy par la BS dune
manire priodique dans le but de dfinir les caractristiques du canal physique en Up Link.
Lintervalle qui spare lenvoi de deux UCD successifs ne doit en aucun cas dpasser la
valeur de l' UCD Interval (10 secs).
Ce message contient :
lidentifiant du canal en UL ainsi que sa frquence
un champ Configuration Change Count quivalent celui du DCD
la taille en termes de slots physiques ou PS d'une opportunit de ranging. En fait,
l'intervalle durant lequel une SS pourrait envoyer un RNG REQ doit tre un multiple
de cette valeur.
La taille d'une opportunit de demande de BP. En fait, l'intervalle durant lequel une
SS pourrait envoyer une BR doit tre un multiple de cette dure.
liste des UL burst profile.
A.1.2.3 DL-MAP ( Down Link MAP )
Le message DL-MAP, gnr par la BS, dfinit les informations daccs au DL. Ce
message doit contenir notamment :
Un champ de synchronisation de niveau physique (PHY Synchronisation) qui prcise
le type du rseau (point point, point multipoint, etc.).
Le numro de la trame.

103

Annexe
Un champ DCD Count correspondant la valeur du Configuration Change
Count du DCD appliqu ce DL-MAP.
Lidentifiant de la BS.
La liste des IE ( Information Elements ) du DL-MAP.
A.1.2.4 UL-MAP ( UpLink MAP )
Le message UL-MAP alloue laccs lUL Channel. La BS doit inclure dans l'UL-MAP
les informations suivantes :
Lidentifiant de l'UL Channel auquel ce message fait rfrence.
Un champ UCD Count (quivalent celui dcrit pour le DL-MAP mais
correspondant dans ce cas la valeur du Configuration Change Count de l'UCD).
L Allocation Start Time : le champ indiquant linstant effectif o dbute
lallocation de l'UL dfinie au niveau de l'UL-MAP.
La liste des IE de l'UL-MAP.

Chaque IE doit contenir :

Le CID de la connexion concerne par cet IE. Il peut sagir aussi bien dun CID
multicast, broadcast ou unicast.
Le Start Time qui indique linstant de dbut relativement lAllocation Start Time
spcifi dans l'UL-MAP.
La Duration qui indique la dure de lallocation.

Il ya plusieurs types de IE, tel que les Data Grant IE qui donnent l'opportunit aux SS
de transmettre des donnes, les Request IE qui donnent l'opportunit aux SS de
transmettre des demandes de BP, etc.
A.1.3 Entre en rseau et initialisation
Dans ce paragraphe, nous allons voir comment s'effectue l'entre d'une nouvelle
station dans le rseau depuis son apparition jusqu' ce qu'elle commence mettre des
donnes.
Cette procdure se dcompose en plusieurs phases que voici:
Balayer le lien descendant et tablir la synchronisation avec la BS.
104

Annexe
Obtenir les paramtres de transmission.
Effectuer le ranging.
Ngocier les possibilits de base.
Autoriser la SS et effectuer l'change de cls.
Effectuer l'enregistrement de la SS auprs de la BS.
Etablir la connectivit IP.
Etablir l'heure du jour
Transfrer les paramtres oprationnels.
Etablir les connexions.
Toutes ces phases ne sont pas toutes obligatoires, nous allons expliciter dans ce qui
suit, les phases les plus importantes.
A.1.3.1 Balayage et synchronisation
A l'initialisation ou lors de la perte de signal, une SS doit se procurer un canal en lien
descendant. Si elle a gard les derniers paramtres oprationnels en stock, elle essayera de
rtablir le signal, sinon, elle balayera tous les canaux possibles de la bande de frquence en
lien descendant jusqu' trouver un signal en DL valide.
Une fois que la PHY a russi la synchronisation, c'est au tour de la MAC d'acqurir les
paramtres du DL, ensuite de lUL.
A.1.3.2 Obtention des paramtres DL
Pour cela, la couche MAC cherche les messages de management DL-MAP. Une SS
achve la synchronisation niveau MAC une fois qu'elle a reu au moins un DL-MAP. Cette
phase continue tant que la SS n'a pas russi avoir des messages DL-MAP et DCD de son
canal. Au bout d'un certain temps, si la SS n'a pas russi en avoir, elle revient la phase
prcdente de recherche d'un nouveau canal descendant.
Pour plus de dtails, voir Figure A-4.
A.1.3.3 Obtentions des paramtres UL
Aprs la synchronisation, la SS va attendre la rception d'un message UCD de la part
de la BS qui contiendra des paramtres de transmission pour des canaux en UL. Ces
messages sont transmis priodiquement par la BS. Si la SS choue au bout d'un TO ( time
out ), elle doit retrouver un autre canal DL.

105

Annexe

Figure A-4 : Obtention de la synchronisation en lien descendant

A partir des paramtres de description du canal, la SS va voir la possibilit d'utilisation

de l'UL. Si le canal n'est pas appropri, la SS doit trouver un autre canal en DL. Dans le cas
contraire, la SS sauvegarde les paramtres relatifs au canal. Ensuite, elle attendra le prochain
DL-MAP pour en extraire le temps de synchronisation. Puis, elle attendra le plan
d'allocation de bande passante. A partir de ce moment, la SS pourra transmettre en UL en
tenant compte des oprations de la MAC et du mcanisme d'allocation de BP.
La SS continue considrer les paramtres UL tant qu'elle continue recevoir les ULMAP et UCD. Si elle ne reoit plus ces messages au bout d'un TO, la SS n'utilisera plus ce
canal. Pour plus de dtail, voir Figure A-5.

106

Annexe

Figure A-5 : Maintien de la synchronisation en lien descendant

A.1.3.4 Initial ranging et ajustement automatique

Le processus du ranging sert acqurir l'instant de dbut ou timing offset et
ajuster la puissance de transmission. Ceci permettra la SS de s'aligner avec le dbut de la
trame envoy par la BS. La SS est dite co-localise avec la BS.
Au dbut, une SS synchronise avec un lien descendant et acquiert les caractristiques
du lien montant partir du message UCD. Ensuite, la SS va analyser le message UL-MAP
pour en extraire des informations utiles pour le processus d'initial ranging. En effet, dans le
cas de PHY OFDMA, un sous-canal, dit ranging Channel , et un ensemble de codes
CDMA sont disponibles pour permettre la SS de raliser le processus d'initial ranging.
Pour qu'une SS puisse effectuer l'initial ranging, elle passe par les tapes suivantes : la
SS choisit au hasard un ranging code (le CDMA code ) parmi une liste initiale ( initial
ranging list ) et l'envoie vers la BS. La BS, ne pouvant pas connatre la SS qui a envoy le
code CDMA, rpond par un RNG-RSP en diffusion, contenant le ranging slot utilis par la
SS pour que celle-ci puisse reconnatre que le message lui est destin. De plus, ce message
contient des donnes d'ajustement et une variable tat qui indiquent la SS si elle doit
effectuer des ajustements ou pas. Si la BS reoit un ranging code suite un RNG-RSP avec
tat succs, la BS doit allouer de la bande passante la SS pour qu'elle puisse envoyer des
RNG-REQ. Si l'tat est continue, la SS rpte le processus d'entre et choisit un autre
ranging code parmi une liste de codes ( periodic ranging list ).

107

Annexe

Figure A-6 : Obtention des paramtres UL

108

Annexe

Figure A-7 : Maintien des paramtres UL

A.1.3.5 Ngociation des capacits de base

Juste aprs le ranging, une SS informe la BS de ses capacits en lui transmettant un
SBC-REQ ( SS Basic Capabilities ), la BS rpond par un SBC-RSP en indiquant l o ses
capacits concident avec celles de la SS.
A.1.3.6 Autorisation et change de cls
Cette partie ne nous intresse pas pour le moment. Pour plus de dtail, voir le
paragraphe 7.2 dans le standard 802.16-2004.
A.1.3.7 Enregistrement
L'enregistrement est le processus qui permettra une SS l'entre en rseau, et une SS
administre ( Managed SS ) d'acqurir le secondary management CID . La SS transmet
un REG-REQ et attend un REG-RSP de la part de la BS.

A.2 Couche MAC 802.16j

A.2.1 Adressage et connexions
Tous ce qui a t dfini en mode PMP reste valable dans le cas de rseaux MR ( Multi
hop Relay ). Dans un rseau MR, une connexion peut exister le long de plusieurs sauts, et
puisquun CID est unique dans une cellule MR, le mme CID sera attribu la connexion
mme en passant par plusieurs RS. Ceci est valable pour tous les types de connexion,
savoir les connexions basiques, primaires ou secondaires.

109

Annexe
Un autre type de connexion existe dans le cas de rseaux MR, il s'agit de tunnel. Le
tunnel transporte des Mac PDU faisant parties de plusieurs connexions, en direction de la
MR-BS et passant par la RS. Un MPDU n'appartient pas forcment un tunnel.
Il existe deux types de tunnel. Le premier est le tunnel de management transportant des
Mac PDU de management, il est identifi par le MT-CID ( Management Tunnel CID ).
Le second est le tunnel de transport transportant des Mac PDU de transport, il est identifi
par le T-CID (Tunnel CID).
A.2.2 Format du MAC PDU
Concernant le MAC PDU, il garde toujours sa forme standard, on aura l'entte de taille
fixe suivi, ou pas, par le payload et finissant optionnellement par le CRC.
Maintenant concernant l'entte, c'est l qu'on trouve des spcificits.
Dans la Figure A-8, ci-dessous, nous observons le format du Relay MAC header. Nous
remarquons la prsence d'un champ RMI ( Relay Mode Indication ), il permet de savoir si
le mode Relay est utilis ou pas. Ensuite, le champ Priority indique la priorit entre les
Mac PDU lorsqu'un tunnel est utilis.

Figure A-8 : Format de l'entte du Relay MAC PDU avec payload

Un autre type de MAC header est utilis. Il s'agit des PDU sans payload, conu pour les
PDU de signalisation en UL (voir Figure A-9).

110

Annexe

Figure A-9 : Format de l'entte du Relay MAC PDU sans payload

Un autre type d'entte existe, il s'agit de l'entte de demande de bande passante pour la
station de relais. En effet, la RS envoie cet entte comme Bandwith Request la MRBS, pour pouvoir envoyer des messages de RNG-RSP. Cet entte est dcrit dans la Figure
A-10.

Figure A-10 : Format de l'entte BR du Relay Station

Plusieurs types d'enttes existent aussi selon l'utilisation

d'acquittement. Pour plus de dtail, voir le standard 802.16j.

comme

l'entte

A.2.3 Network Entry & Initialisation

La procdure d'entr en rseau pour une SS ou bien une RS est similaire au mode PMP.
Il y aura quelques dtails en plus concernant les RS et SS qui ne sont pas dans la porte de
la MR-BS qui seront dtaills plus tard. Durant l'entre en rseau, une RS se comporte de la
mme faon qu'une SS.
111

Annexe
Il y a deux types d'opration pour les systmes multi hop: le mode transparent et le
mode non transparent. La diffrence rside dans le fait que dans le mode non transparent,
une RS pourra transmettre des donnes de contrle et particulirement, transmettre son
prambule et son MAP afin que des SS puissent se synchroniser avec elle au lieu de se
synchroniser avec la BS, alors que pour le mode transparent, la RS n'effectue rien de cela,
elle fait du simple relais.
A.2.3.1 Network entry & initialisation dans le mode transparent
La procdure se fait selon l'ordre des vnements suivants:

Une MS dsirant entrer dans le rseau, va scanner le canal DL pour tablir la

synchronisation avec la MR-BS. Elle obtient les paramtres DL depuis le message
UCD.

Le processus d' Initial Ranging commence par l'envoi des codes CDMA via le canal
ddi pour la ranging, ce canal est gr par une RS qui est affect par la MR-BS.

lorsque la MS envoie le code CDMA, la MR-BS ainsi que quelques RS reoivent le

code. Aussitt, chacune de ces RS va transmettre un message RNG-REQ vers la MRBS. Ce message contient le mme code ainsi que des informations d'ajustements.

La MR-BS, ayant reu le code CDMA, va attendre un ou plusieurs messages REGREQ des RS ayant le mme code du ranging. Ensuite, elle dcide du meilleur chemin
emprunter. La RS choisi est dsormais appele lAccess RS. La MR-BS pourra dcider
de faire de la transmission directe vers la MS.

Si l'tat du ranging n'est pas encore russi pour le chemin choisi, la MR-BS envoie un
message RNG-RSP directement la MS via l'initial ranging CID. Ce message contient
les informations d'ajustements mesures par l'Access RS correspondante.

Remarque: Le chemin entre la MR-BS et l'Access RS est dj au point, reste adapter

le lien entre la MS et l'Access RS.

Si l'tat du ranging est russi pour le chemin choisi, la RS va recevoir depuis la MS et

relayer vers la MR-BS, un message RNG-REQ, contenant l'adresse MAC de MS,
transmis dans un burst spcifi par la CDMA_allocation_IE.

La MR-BS pourra assigner la MS le basic CID et le CID primaire.

A.2.3.2 Network entry & initialisation dans le mode non transparent dans le cas de
scheduling centralis
Dans le cas du mode non transparent et pour le cas de scheduling centralis, le
processus d'entre en rseau se fait selon les tapes suivantes:
112

Annexe

La MS scanne le canal DL pour se synchroniser avec la RS non transparente et obtient

les paramtres de transmission partir du message UCD.

Le processus d'initial ranging commence toujours par l'envoie des codes CDMA.

Lorsqu'une RS reoit un code CDMA avec un tat continu, la RS doit envoyer

localement un RNG-RSP. Pour cela, elle va envoyer la MR-BS l'entte RS-BR pour
lui demander des ressources afin de pouvoir envoyer ce message.

Une fois que l'tat du code CDMA a t envoy avec succs, la RS peut envoyer le
message RNG-REQ vers la MR-BS.

La MR-BS, de son ct, va lui envoyer un RS UL-MAP contenant des allocations de

ressources spcifies par le CDMA_Allocation-IE, et bien sre, elle va lui rpondre par
un RNG-RSP avec un tat succs.

La RS va relayer le message vers la MS aprs quelques modifications. En effet, il y a un

champ Ranging Indicator qui informe s'il s'agit d'un ranging classique ou bien d'un
ranging avec relais.

La MS envoie ensuite un RNG REQ via UL selon l'allocation ci-dessus.

De mme, la RS reoit le message par l'initial ranging CID et le transmet la MR-BS

via le RS basic CID.

Une fois ce message reu, contenant l'adresse MAC de MS, la MR-BS peut assigner un
basic CID et un CID primaire pour la MS, en la lui communiquant via un message
RNG-RSP.

Aprs que la RS relaye le message la MS, cette dernire met jours ses paramtres de
CID et termine ensuite la procdure d'entre en rseau avec la MR-BS.
Pour plus de dtail, consulter le diagramme page 84

A.2.3.3 Network entry & initialisation dans le mode non transparent dans le cas de
scheduling distribu
Toujours dans le cas non transparent, mais cette fois dans un cas de scheduling
distribu :

La procdure est la mme concernant le scanning du canal, l'obtention des paramtres

de transmission, et le processus d'initial ranging entre la MS et la RS jusqu' ce que la
RS reoive un code CDMA rsultant d'un tat de succs.

A ce moment, la RS envoie un RNG-RSP avec tat succs. En mme temps, la RS lui

alloue de la bande passante avec le CDMA_Allocation-IE pour qu'elle puisse envoyer
un RNG-REQ contenant son adresse MAC avec l'initial ranging CID.
113

Annexe

Ce RNG-REQ reu par la RS, va tre analys pour voir s'il y a quelque chose que la RS
peut assurer, le message est ensuite modifi et envoy vers la MR-BS avec le RS basic
CID.

La MR-BS reoit le message qui contient l'adresse MAC de MS, et associe le basic CID
et le CID primaire au MS et envoie le tout dans le message RNG-RSP.

La RS met jour le message, en y insrant les rponses aux traitements qu'elle a pu

assurer, et envoie le rsultat la MS avec l'initial ranging CID de MS.

La MS met jour ces paramtres de connexion et continue la procdure d'entre en

rseau avec la MR-BS.

A.2.4 Les techniques de demande de bande passante dans le cadre de multi hop
relay (IEEE 802.16j)
Dans le cas des rseaux WIMAX multi-sauts, les techniques de demande de bande
passante restent les mmes, il faut juste tenir compte du fait que les SS ne sont plus
directement connectes la BS.
Dans cette partie, nous allons expliquer les diffrents ajustements et modifications du
fonctionnement de ces techniques pour assurer les allocations de ressources tout au long
du chemin entre une BS et une SS.
A.2.4.1 Rgles gnrales
Dans dtaillons dans cette partie les mcanismes dans le cas dun ordonnancement
centralis la BS, ainsi,

La MR-BS doit connatre les besoins de tous les liens, que ce soit le lien d'accs ou le
lien de Relay.

Si une SS dsire transmettre un paquet, une demande de BW doit atteindre la BS qui va

allouer les ressources tout au long du lien entre la BS et la SS.

Une TRS (Transparent RS) ne transmet pas de MAP, mais une NTRS (Non TRS) en
transmet. Dans notre cas centralis, c'est la BS qui doit effectuer le calcul.

A.2.4.2 Bandwidth Request dans la mode centralis

Les stations de relais devraient transfrer toute demande de BW (sous forme d'entte
ou de code CDMA) vers les stations plus hautes jusqu' la MR-BS. Ainsi, une RS ne peut
pas combiner toutes ces demandes en une seule puisque la MR-BS doit savoir tous les
besoins de tous les liens.
Une station de relais aura besoin de demander de la BW pour ces propres trafics et
114

Annexe
pour acheminer les trafics ascendants ou descendants. Sachant qu'une RS ayant dj une
allocation disponible, n'a pas besoin de demander de la BW.
Nous rappelons que la demande de BW se formule en le nombre d'octets ncessaires
pour le transfert des enttes et payload sans compter l'overhead de la couche physique. Une
demande peut tre transmise en n'importe quelle allocation en UL sauf en priode d'initial
ranging.
A.2.4.3 CDMA BW Request en mode centralis
Lorsqu'une NTRS reoit plusieurs codes CDMA de la part des SS qui lui sont associ
(c'est le relais d'accs), elle devrait regrouper ces codes et envoyer un entte MR_CodeREP qui indiquera la MR-BS le nombre de codes CDMA que la RS a reu. Par la suite, la
MR-BS va envoyer des CDMA_Allocation_IE dont les champs sont mis zro. Une fois
que la RS a reu ces IE, elle remplit ces champs et les envoie au SS correspondant.
Lorsqu'une TRS reoit plusieurs codes CDMA de la part des SS qui lui sont associes,
elle envoie autant de codes que de MR_Code-REP, si elle a assez de BW pour les envoyer.
Sinon, elle envoie le maximum et indique le nombre de codes non encore transfrs. Ainsi,
la BS saura lui allouer de la BW pour qu'elle puisse les transfrer.
A.2.4.4 GRANTS en mode centralis
Lorsqu'une MR-BS doit allouer de la BW pour permettre le transfert d'un paquet
montant ou descendant, la MR-BS doit faire les allocations ncessaires tout au long du
chemin en tenant compte de la qualit des liens et de leurs disponibilits ainsi que des dlais
de traitement au niveau des nuds intermdiaires. Par exemple, l'allocation au niveau du
deuxime lien est la premire opportunit aprs l'allocation du premier lien, plus le temps
de traitement au niveau du relais intermdiaire.
Maintenant, il y a deux mthodes qui existent pour garantir des allocations de BW aux
RS, le polling et l'UL_DCH.
Le POLLING en mode centralis

La MR-BS peut allouer de la BW aux RS pour qu'elles puissent formuler leurs

demandes, il s'agit d'un polling priodique.
Dans le cas centralis, si la MR-BS dsire envoyer un pool vers une RS, elle va faire de
telle sorte que les stations intermdiaires aient aussi un pool chacune pour que les
demandes puissent remonter jusqu' la MR-BS. Dans le meilleur des cas, la demande atteint
la MR-BS en un minimum de temps.

115

Annexe
Relay UL DCH en mode centralis

C'est une deuxime mthode pour garantir des allocations priodiques une RS. En
effet, aprs l'entre en rseau et l'initialisation, une RS peut avoir un canal ddi en UL
assign par la MR-BS. Si la RS n'est pas directement lie la MR-BS, cette dernire doit
allouer un canal ddi pour chacune des RS intermdiaires ou ajuster leurs tailles s'ils
existent dj. La taille d'un canal ddi doit tre suffisante pour transfrer des messages de
management. La taille peut aussi changer en fonction du trafic.
En mode centralis, seule la MR-BS peut assigner ces canaux. L'attribution se fait par
un RS_UL_DCH IE au niveau du R-MAP et il est disponible juste la trame suivante.
Si une SS change les besoins de ses flux de service, il y aura impact sur les besoins en
BW au niveau des canaux UL_DCH tout au long du chemin vers la MR-BS. Ainsi, la MRBS se basera sur les informations de trafic au niveau des messages DSA, DSC, DCD.

116