Tao PDF

THSE
En vue de l'obtention du
DOCTORAT DE LUNIVERSIT DE TOULOUSE

Dlivr par L'Institut National Polytechnique de Toulouse (INPT)
Discipline ou spcialit : Aronautique et Astronautique
Prsente et soutenue par
Na TAO
Le 10 Juillet 2009
Titre : Etude des Performances et Optimisation d'un Rseau

d'Accs par Satellite pour les Communications
Aronautiques
JURY
Prof. Francine KRIEF
Prof. Pascal LORENZ
Prof. Gilles ROUSSEL
Dr. Christophe MACABIAU
Dr. Alain PIROVANO
Dr. Jos RADZIK
Ecole doctorale : Ecole Doctorale Aronautique Astronautique (EDAA)

Unit de recherche : Ecole Nationale de l'Aviation Civile (ENAC), Laboratoire d'Etude et
d'Optimisation des Architectures des Rseaux de Tlcommunication (LEOPART)
Directeurs de Thse : Christophe MACABIAU, Jos RADZIK
Encadrement : Alain PIROVANO, Jos RADZIK
Abstract
The rapid growth of air traffic needs a new communication infrastructure with increased bandwidth, high
speed services and applications to satisfy expected air-ground communication requirements. Satellite
communication systems play a significant role in this context, not only as a complement to terrestrial
systems for Air Traffic Management (ATM) by offering global coverage but also as a promising solution to
enrich In-Flight Entertainment (IFE) for passengers. DVB-S2/RCS technology is an attractive proposition to
provide the cost-effective broadband services for both ATM and IFE, mainly because a large radio
bandwidth is primarily allocated to aeronautical mobile communications in Ka-band, where the open
standards DVB are implemented.
However, such system design with convergence of heterogeneous traffics involves two main challenges.
Firstly, using Ka-band means the implementation of Fade Mitigation Techniques (FMT) in order to cope with
deep fades caused by atmospheric attenuation. Otherwise, the waste of capacity would be excessively high
in a constant link margin design. FMT adapt in real time the link budget to the propagation conditions, this
adaptivity has an impact not only on physical layer but also on upper layers. An efficient resource
management strategy with dynamic bandwidth allocation is required in this case, especially in DVB-RCS
return link where FMT are not natives. Secondly, the proposed system must be able to multiplex the traffic
flows with highly different characteristics and Quality of Service (QoS) expectations into a single link, the
corresponding capacity management and QoS support seem with higher complexity.
In this paper, we present an adaptive system design using a single DVB-S2/RCS based satellite link to
provide Internet access and mobile telephony (GSM/UMTS) for passengers and a high-reliability channel for
ATM. Concerning the airborne terminal architecture, two approaches are investigated. The first one is in
compliance with ETSI Broadband Satellite Multimedia (BSM) architecture and based on a layering paradigm.
The conducted simulation experiments highlight the need of dynamic interactions and adaptations among
the layers to achieve an overall performance optimization. We propose then an enhanced approach with
the concentration of both resource allocation and QoS management at the same interface - adaptation
layer. The idea comes from the success of the recent Generic Stream Encapsulation (GSE) protocol, which
carries the network protocol packets over DVB-S2 forward link in a simple, flexible and efficient way,
especially when used with Adaptive Coding and Modulation (ACM). Furthermore, GSE can be easily
extended to use in our design for DVB-RCS return link thanks to a proper design of MF-TDMA structure in
which the suitable FMT (ACM and Dynamic Rate Adaptation) are context-aware configured. With the
combined use of GSE, service policy and the interactions between adaptation and access layers, incoming
heterogeneous traffics can be dynamically scheduled, segmented and encapsulated at the same adaptation
layer. Performance evaluation of two proposed approaches is derived by a network-level simulation model
I
developed using OPNET. Results prove the enhanced approach outperforms the first one leading to better
resource utilization and satisfactory performance.
II
Rsum
La croissance rapide du trafic arien et les besoins en nouveaux services notamment pour les
passagers imposent lintroduction de nouveaux moyens de communication pour les avions avec
une bande passante globale fortement accrue. Les satellites sont appels jouer un rle
important dans ce contexte, non seulement en complment des systmes terrestres pour les
services cockpit (services ATM, Air Traffic Management) mais aussi pour les services cabine
(In-Flight Entertainment). Lobjectif de la thse est dtudier larchitecture dun systme satellite
supportant lensemble de ces services, en se focalisant sur larchitecture du terminal embarqu
bord des aronefs.
Larchitecture retenue repose sur des liaisons DVB-S2/DVB-RCS normalises par lETSI. Cette
option permet dutiliser efficacement limportante bande passante disponible en bande Ka pour
les services mobiles aronautiques (allocation primaire) ou en bande Ku (allocation secondaire).
Ces normes ont t conues pour les applications multimdia (Broadband Satellite Multimedia).
Le dfi est alors dutiliser de telles liaisons satellite pour des services aux caractristiques et
besoins fortement htrognes. Par ailleurs, lutilisation de la bande Ka nest pas concevable sans
lactivation de techniques de lutte contre les affaiblissements (FMT Fade Mitigation Techniques).
Lutilisation dune marge statique conduit une perte importante de capacit. Les techniques
FMT reposent sur une valuation dynamique du bilan de liaison et permettent une modification
de la forme donde. Le systme utilise ainsi la forme donde la plus efficace spectralement pour
chaque terminal et maximise la capacit globale du systme. Par contre, chaque terminal observe
une modification de la ressource alloue au fil du temps.
Lobjectif de la thse est de concevoir une architecture au niveau terminal qui permette
dexploiter les liaisons DVB-S2/RCS afin de fournir les services passagers (Internet et tlphonie
mobile de type GSM/UMTS) et un canal haute fiabilit pour les services aronautiques. Deux
approches ont t retenues. La premire repose sur une application du modle ETSI BSM
(Broadband Satellite Multimedia) en couches sparant strictement les couches dpendantes
satellite et les couches indpendantes satellite. Les simulations de cette architecture montrent
que les liaisons ne peuvent tre utilises de faon efficace sans une interaction entre couches afin
de tenir compte de lvolution de la capacit disponible. La seconde approche consiste en la
concentration de la gestion de la ressource et la gestion de la qualit de service dans la mme
III
couche protocolaire. Lide de dpart est dutiliser la mthode dencapsulation gnrique Generic
Stream Encapsulation (GSE). GSE a t conu pour la projection des paquets de couches
suprieures lintrieur des trames DVB-S2. GSE tient compte de la taille variable des trames
DVB-S2 et introduit une capacit de multiplexage entre diffrents flux (identification de
fragments). Sur cette base, une gestion de laccs est introduite pour grer la liaison DVB-RCS au
format MF-TDMA. Nous introduisons ainsi une utilisation conjointe de GSE, dune politique de
service diffrentie et de flux de signalisation inter-couches ( cross-layer ).
Les performances des deux approches sont tudies laide dun modle de simulation
dvelopp laide du logiciel OPNET Modeler (simulations vnements discrets). Les rsultats
obtenus dmontrent le meilleur comportement de la seconde architecture avec une meilleure
utilisation de la ressource et des performances de transmission satisfaisant les objectifs.
IV
Remerciements
Les travaux prsents dans ce mmoire ont t effectus au Laboratoire d'Etude et d'OPtimisation
des Architectures des Rseaux de Tlcommunication(LEOPART) de lENAC (Ecole Nationale de lAviation
Civile). Je tiens tout bord remercier Farid ZIZI, directeur des tudes et de la recherche, de m'avoir
accueillie avec beaucoup de gentillesse dans son tablissement.
Je tiens dire toute ma connaissance Madame Francine KRIEF, professeur lENSEIRB de Bordeaux, Pascal
LORENZ, professeur lUniversit de Haute Alsace, pour avoir accept dtre rapporteurs de cette thse.
Je remercie Gilles ROUSSEL, professeur lUniversit de Marne-La-Valle, davoir accept de prsider ce

jury de thse.
Merci galement Christophe MACABIAU, directeur du laboratoire de traitement du signal de lENAC, davoir
accept dtre directeur de cette thse.
Je tiens exprimer mes plus sincres remerciements et ma profonde gratitude mes deux directeurs et
encadrants de thse : Alain PIROVANO, directeur du LEOPART de lENAC et Jos RADZIK, professeur adjoint
lISAE, pour mavoir propos cette thse et mavoir accompagne tout au long de ces trois annes. Leurs
aides, leurs encouragements et leurs disponibilits ont t dterminants pour la ralisation de cette thse.
Je remercie lensemble du dpartement EL de lENAC avec qui jai pass de merveilleux moments. Mes
remerciements vont galement toutes les personnes qui, un moment ou un autre, mont apport leur
aide et contribu rendre mon sjour lENAC trs agrable.
Je ddie cette thse mes parents et wentao.
V
Table des matires
I. INTRODUCTION............................................................................................................... 1
I.1 Datalink.............................................................................................................................. 2
I.2 Services aux passagers et premires exprimentations.................................................... 3
I.3 Convergence des communications aronautiques sur un lien unique par satellite ......... 4
I.4 Plan du mmoire................................................................................................................ 5
II. SERVICE A BORD.............................................................................................................. 7

II.1 Services pour lATM ........................................................................................................... 7
II.1.1 Historique......................................................................................................................... 7
II.1.2 Dfinitions ........................................................................................................................ 8
II.1.3 Diffrents types de services de communication .............................................................. 9
II.1.4 Une tude prospective : le COCR ................................................................................... 11
II.1.5 Performances requises................................................................................................... 12
II.1.6 Service mobile aronautique par satellite ..................................................................... 15
II.2 Services aux passagers..................................................................................................... 17
II.2.1 Services pour tlphonie mobile ................................................................................... 17
II.2.2 Services daccs Internet............................................................................................. 18
II.2.3 Qualit de service requise.............................................................................................. 18
II.3 Modlisation des sources de trafic.................................................................................. 19
II.3.1 Source de trafic cockpit.................................................................................................. 20
II.3.2 Source de trafic tlphonie mobile................................................................................ 25
II.3.3 Source de trafic Internet embarqu............................................................................... 31
III. RESEAU DACCES PAR SATELLITE.................................................................................. 35

III.1 Ressources radiolectriques............................................................................................ 35
III.1.1 Justification de lutilisation de la bande Ka.................................................................... 35
III.1.2 Propagation en bande Ka............................................................................................... 38
III.1.3 Techniques de compensation des affaiblissements....................................................... 40
III.1.3.1 Contrle de puissance................................................................................... 41
III.1.3.2 Adaptation de la forme donde..................................................................... 41
III.1.3.3 Diversit ........................................................................................................ 42
III.2 Accs satellite : DVB-S2/DVB-RCS.................................................................................... 43
III.2.1 Normes pour les accs satellite haut dbit ................................................................. 43
III.2.2 Systme de rfrence .................................................................................................... 47
III.2.2.1 Lien aller DVB-S2 ........................................................................................... 49
III.2.2.2 Lien retour DVB-RCS...................................................................................... 49
VII
III.2.3 Couche physique DVB-RCS .............................................................................................51
III.2.4 Qualit de service et DVB-RCS ........................................................................................58
III.2.5 Mise en uvre de lalgorithme DAMA ...........................................................................60
IV. ARCHITECTURE SYSTEME ............................................................................................. 63

IV.1 Modle OSI de lISO ......................................................................................................... 63
IV.2 Services aronautiques.................................................................................................... 64
IV.2.1 Architecture protocolaire dans lATN .............................................................................64
IV.2.2 Introduction du satellite dans larchitecture ATN ..........................................................66
IV.3 Services aux passagers..................................................................................................... 68
IV.3.1 Services de tlphonie mobile........................................................................................68
IV.3.1.1 Rseau GSM...................................................................................................68
IV.3.1.2 Rseau UMTS.................................................................................................69
IV.3.1.3 Choix dun point de coupure pour lintroduction de la liaison satellite ........70
IV.3.2 Services daccs Internet ................................................................................................73
IV.4 Convergence des trafics sur la liaison satellite ................................................................ 76
IV.4.1 Format de donnes DVB .................................................................................................76
IV.4.1.1 Lien aller DVB-S2............................................................................................76
IV.4.1.2 Lien retour DVB-RCS ......................................................................................78
IV.4.2 Mthode dencapsulation...............................................................................................78
IV.4.2.1 Mthode dencapsulation sur le flux de transport MPEG .............................78
IV.4.2.2 Mthode dencapsulation sur le flux gnrique............................................80
V. ARCHITECTURE DU TERMINAL AVION : APPROCHE CLASSIQUE ET APPROCHE

DYNAMIQUE ....................................................................................................................... 85
V.1 Approche classique .......................................................................................................... 85
V.1.1 Architecture BSM par ETSI..............................................................................................85
V.1.2 Projection de larchitecture BSM dans le cas du terminal avion ....................................87
V.1.3 Mise en uvre dtaille .................................................................................................89
V.1.3.1 Rseau ATN....................................................................................................89
V.1.3.2 Rseau GSM/UMTS........................................................................................90
V.1.3.3 Rseau TCP/IP................................................................................................90
V.1.4 Etude prliminaire de lapproche classique....................................................................93
V.1.5 Contrle dynamique du flux IP .......................................................................................97
V.2 Etat de lart des techniques Cross-Layer .................................................................. 102
V.2.1 Diffrentes catgories de Cross-Layer ....................................................................103
V.2.2 Les architectures Cross-Layer .................................................................................105
V.2.3 Techniques Cross-Layer dans les systmes de communication par satellite..........107
V.2.3.1 Cross-Layer pour loptimisation de la gestion de ressources ................107
V.2.3.2 Cross-Layer pour loptimisation de performances.................................108
VIII
VI. ARCHITECTURE DU TERMINAL AVION : APPROCHE DYNAMIQUE AVEC
ENCAPSULATION GENERIQUE .......................................................................................... 111
VI.1 Architecture retenue pour le terminal avion................................................................. 111
VI.1.1 Choix des techniques Cross-Layer .......................................................................... 111
VI.1.2 Les flux de signalisation Cross-Layer ...................................................................... 113
VI.1.3 Mcanismes mis en uvre la couche dadaptation.................................................. 114
VI.1.4 Dimensionnement des files dattente du Terminal Satellite........................................ 115
VI.2 Etude des performances................................................................................................ 118
VI.2.1 Simulation avec un seul terminal et conditions de propagations fixes........................ 118
VI.2.2 Simulation avec plusieurs terminaux et conditions de propagations fixes.................. 122
VI.2.2.1 Configuration du scnario et trafic exogne............................................... 122
VI.2.2.2 Etude des performances en fonction de la charge ..................................... 124
VI.2.2.3 Etude du fonctionnement du rseau charg .............................................. 127
VI.2.2.4 Performances daccs pour un avion avec le seul trafic ATC/AOC ............. 130
VI.2.3 Simulation avec plusieurs terminaux et conditions de propagations variables........... 132
CONCLUSION ..................................................................................................................... 137
REFERENCE ........................................................................................................................ 143
PUBLICATIONS................................................................................................................... 149
ANNEXES ........................................................................................................................... 151

Annexe A Recommandation COCR ....................................................................................... 151
Annexe B Performances de codage et de modulation du DVB-S2/RCS................................ 157
Annexe C Bilan de liaison ciel clair........................................................................................ 159
Annexe D Le logiciel de simulation OPNET ........................................................................... 163
Annexe E Sources de trafic ................................................................................................... 167
Annexe E.1 Source de trafic cockpit ATS/AOC........................................................................ 167
Annexe E.2 Source de trafic tlphonies mobile bord ........................................................ 170
Annexe E.2.1 Modle N-sources ON/OFF................................................................ 170
Annexe E.2.2 Modle agrg................................................................................... 171
Annexe E.3 Modle de source Internet embarqu ................................................................ 173
Annexe F Modles de simulation ......................................................................................... 177
Annexe F.1 Terminal avion (ST) .............................................................................................. 178
Annexe F.2 Gateway (NCC intgr) ........................................................................................ 182
IX
Liste des acronymes
3GPP 3rd Generation Partnership Project
ACARS Aircraft Communication Addressing and Reporting System

ACM Adaptive Coding and Modulation
ACQ ACQuisition
ADS-A Automatic Dependent Surveillance - Addressed
ADS-B Automatic Dependent Surveillance - Broadcasted
ADS-C Automatic Dependent Surveillance - Contract
AES Airborne Earth Station
AF Assured Forwarding
AMSS Aeronautical Mobile Satellite Service
AOA Autonomous Operations Area
AOC Aeronautical Operational Control
APC Aeronautical Passenger Communications
APT AirPorT
ATC Air Traffic Control
ATM Air Traffic Management
ATM Asynchronous Transfer Mode
ATN Aeronautical Telecommunication Network
ATS Air Traffic Services
AVBDC Absolute Volume Based Dynamic Capacity
BER Bit Error Rate

BGAN Broadband Global Area Network
BoD Bandwidth on Demand
bps bits per second
BPSK Binary Phase Shift Keying
BSC Base Station Controller
BSM Broadband Satellite Multimedia
BSS Broadcasting Satellite Service
BSS Base Station Sub-system
BTS Base Transceiver Station
CBB Connexion By Boeing

CCM Constant Coding and Modulation
CDMA Code Division Multiple Access
CLNP ConnectionLess Network Protocol
CNI Carrier to Noise and Interference ratio
CNS Communication, Navigation, Surveillance
COCR Communications Operating Concepts and Requirements
COS Class of Service
CPDLC Controller Pilot Data Link Communications
CR Capacity Requests
XI
CRA Constant Rate Allocation
CSC Common Signalling Channel
DRA Dynamic Rate Adaptation

DAMA Demand Assigned Multiple Access
DVB-S2 Digital Video Broadcast - Satellite 2nd generation
DVB-RCS Digital Video Broadcast - Return Channel Satellite
DOCSIS Data Over Cable Service Interface Specification
DOCSIS-S Data Over Cable Service Interface Specification - Satellite
EIRP Equivalent Isotropic Radiated Power

ENR EN Route
Es/N0 Energy per symbol per Noise power spectral density
ETSI European Telecommunications Standards Institute
EUROCONTROL European Organization for the Safety of Air Navigation
EWMA Exponentially Weighted Moving Average
FAA Federal Aviation Administration

FCA Free Capacity Assignment
FEC Forward Error Correction
FL Flight Level (1 FL = 100 pieds)
FMT Fade Mitigation Techniques
FRS Future Radio System
FSS Fixed Satellite Service
GEO GEOstationary
GES Ground Earth Station
GSE Generic Stream Encapsulation
GSM Global System for Mobile communications
HF High Frequency (3MHz ~ 30MHz)
ICAO International Civil Aviation Organization

IFE In-Flight Entertainment
IP Internet Protocol
IPoS Internet Protocol over Satellite
ITU International Telecommunication Union
JT Jitter Tolerant
Kbps kilo bits per second

Km kilomtre
Ksps kilo symbols per second
LAN Local Area Network
MAC Media Access Control
XII
TCP Transmission Control Protocol
TCT Timeslot Composition Table
TDMA Time Division Multiple Access
TIA Telecommunications Industry Association
TMA Terminal Maneuvering Area
TRAU Transcoder and Rate Adaptation Unit
TRF TRaFfic
TRX Transmission/Reception
ULE Unidirectional Lightweight Encapsulation

ULPC UpLink Power Control
UMTS Universal Mobile Telecommunications System
VBDC Volume Based Dynamic Capacity

VDL mode 2 VHF Digital Link mode 2
VHF Very High Frequency (30MHZ ~ 300MHz)
VPN Virtual Private Network
VR Variable Rate
W-CDMA Wideband - Code Division Multiple Access

WWW World Wide Web
XIV
Liste des figures
Figure II-1 : Relation entre le service et lapplication. ....................................................................................... 9

Figure II-2 : Interface graphique de lapplication CPDLC. ................................................................................ 10
Figure II-3 : Dfinition des phases dans le COCR. ............................................................................................ 12
Figure II-4 : Dfinition du FRS (Futur Systme Radio) dans le COCR. .............................................................. 14
Figure II-5 : Diffrents canaux du system AMSS.............................................................................................. 15
Figure II-6 : Vue globale de la modlisation de source trafic cockpit.............................................................. 21
Figure II-7 : Profil de trafic cockpit (domaine TMA/ENR). ............................................................................... 23
Figure II-8 : Profil de trafic cockpit (domaine ORP). ........................................................................................ 24
Figure II-9 : Modle ON/OFF. .......................................................................................................................... 26
Figure II-10 : Modle N-sources ON/OFF. ....................................................................................................... 27
Figure II-11 : Trafic gnr - N-sources ON/OFF............................................................................................. 28
Figure II-12 : Processus de Poisson Modul par une chane de Markov (MMPP). .......................................... 29
Figure II-13 : Exemple de la matrice des probabilits de transition. ............................................................... 30
Figure II-14 : Trafic gnr - source MMPP. .................................................................................................... 31
Figure II-15 : Comportement TCP Reno - source TCP greedy. ......................................................................... 34
Figure III-1 : Scnario de rfrence (cas gnral). ........................................................................................... 36
Figure III-2 : Exemple de srie temporelle dattnuation par la pluie en bande Ka. ....................................... 38
Figure III-3 : Scnario de rfrence (rseau daccs DVB-S2/DVB-RCS). ......................................................... 47
Figure III-4 : Mthode daccs pour le lien retour DVB-RCS : MF-TDMA. ....................................................... 50
Figure III-5 : Exemple de la rpartition MF-TDMA........................................................................................... 57
Figure IV-1 : Modle OSI.................................................................................................................................. 64
Figure IV-2 : Pile protocolaire du systme ATN (Exemple : VDL mode 2). ...................................................... 66
Figure IV-3 : Introduction de la liaison DVB dans larchitecture ATN. ............................................................. 67
Figure IV-4 : Structure du rseau GSM simplifie. .......................................................................................... 68
Figure IV-5 : Structure du rseau UMTS simplifie. ........................................................................................ 69
Figure IV-6 : Topologie GSM/UMTS par satellite............................................................................................. 71
Figure IV-7 : Transmission sur linterface Abis. ............................................................................................... 72
Figure IV-8 : Structure de la trame TRAU (Transcoder/Rate Adaptor Unit). ................................................... 72
Figure IV-9 : Modle TCP/IP. ........................................................................................................................... 74
Figure IV-10 : Pile protocolaire du systme IP via satellite. ............................................................................ 76
Figure IV-11 : Structure de flux de transport MPEG-TS................................................................................... 77
Figure IV-12 : Encapsulation MPE.................................................................................................................... 79
Figure IV-13 : Structure de SNDU de lencapsulation ULE (sans extension).................................................... 80
Figure IV-14 : Encapsulation GSE..................................................................................................................... 81
Figure IV-15 : Exemple de format de paquet GSE. .......................................................................................... 82
Figure V-1 : Architecture protocolaire BSM. ................................................................................................... 86
XV
MMS Multimedia Messaging Service
MMPP Markov Modulated Poisson Process
MF-TDMA Multi Frequency - Time Division Multiple Access
MPE Multi Protocol Encapsulation
MPEG Moving Picture Experts Group
MPEG-TS MPEG - Transport Stream
MSC Mobile Switching Center
MSS Mobile Satellite Service
MTU Maximum Transmission Unit
NCC Network Control Center
OPA Operational Performance Assessment

ORP Oceanic, Remote, Polar
OSI Open Systems Interconnection
PC Power Control
PEP Performance Enhancing Proxy
PER Packet Error Rate
PIAC Peak Instantaneous Aircraft Count
PID Packet Identifier
PSTN Public Switched Telephone Network
PDU Protocol Data Unit
QoS Quality of Service

QPSK Quadrature Phase Shift Keying
RBDC Rate Based Dynamic Capacity

RCP Required Communication Performance
RCTP Required Communication Technical Performance
RNC Radio Network Controller
RT Real Time
RTT Round Trip Time
SAC Satellite Access Control

SARPs Standards and Recommended Practices
SATCOM Satellite Communication
SESAR Single European Sky ATM Research
SMS Short Message Service
SNAcP SubNetwork Access Protocol
SNDCF SubNetwork Dependent Convergence Function
SNR Signal to Noise Ratio
SOHO Small Office/Home Office
ST Satellite Terminal
SYNC SYNChronization
TBTP Terminal Burst Time Plan
XIII
Figure V-2 : Cur du systme : Approche classique........................................................................................88
Figure V-3 : Architecture du terminal avion (Approche classique). .................................................................89
Figure V-4 : Format de paquet PDU CLNP........................................................................................................90
Figure V-5 : Mcanisme RED (Random Early Detection)..................................................................................91
Figure V-6 : Mise en uvre dtaille de larchitecture de lapproche classique.............................................93
Figure V-7 : Taux dutilisation moyen de la ressource alloue - Approche classique. .....................................95
Figure V-8 : Courbes CDF des dlais (ATS/AOC, GSM/UMTS, IP) - Approche classique...................................97
Figure V-9 : Mise en uvre dtaille de larchitecture de lapproche dynamique. ........................................98
Figure V-10 : dbit/dbit moyen du seau perc - Approche dynamique.........................................................99
Figure V-11 : Comparaison de lapproche classique et dynamique - Taux moyen dutilisation de la ressource
alloue............................................................................................................................................................100
Figure V-12 : Comparaison de lapproche classique et dynamique - Courbes CDF de dlai IP......................101
Figure V-13 : Courbes CDF des dlais (ATS/AOC, GSM/UMTS, IP) - Approche dynamique. ..........................101
Figure V-14 : Diffrentes conceptions de Cross-Layer - Type 1................................................................104
Figure V-15 : Diffrentes conceptions de Cross-Layer - Type 2, 3 et 4.....................................................105
Figure V-16 : Implmentations dinteractions Cross-Layer . .....................................................................107
Figure VI-1 : Architecture retenue pour le terminal avion.............................................................................113
Figure VI-2 : Encapsulation GSE sur le lien retour DVB-RCS...........................................................................114
Figure VI-3 : Modle bande quivalente pour la source GSM. ................................................................117
Figure VI-4 : Modle bande quivalente GSM, taux de perte vs dbit (taille de file en paramtre). ......117
Figure VI-5 : Courbes CDF des dlais (ATS/AOC, GSM/UMTS, IP) - Approche dynamique avec GSE. ............119
Figure VI-6 : Comparaison des dlais du trafic IP (IP-IP) entre les trois approches tudies. .......................120
Figure VI-7 : Comparaison des RTT mesurs (TCP-TCP) entre les trois approches tudies. ........................120
Figure VI-8 : Modle de simulation N avions. ................................................................................................123
Figure VI-9 : Modle de simulation N avions, gnrations des requtes de capacit. ..................................124
Figure VI-10 : Simulation N avions - Dlais par services. ...............................................................................126
Figure VI-11 : Simulation N avions - Dbit moyen IP. ....................................................................................127
Figure VI-12 : Simulation 60 avions - CDFs des dlais par services. ...............................................................128
Figure VI-13 : Simulation 60 avions - CDFs du nombre de crneaux allous. ................................................128
Figure VI-14 : Simulation 60 avions - Gnration des requtes de capacit en dbit pour le service GSM. .129
Figure VI-15 : Simulation 60 avions - CDF du dlai dans le cas dun trafic GSM seul.....................................130
Figure VI-16 : Squence dchange DVB-RCS dans le cas dun message ATC/AOC isol. ..............................131
Figure VI-17 : Simulation 60 avions - Distribution (CDF) des dlais pour trafic ATC/AOC seul. .....................131
Figure VI-18 : Simulation 60 avions - Requtes de capacit cumules en entre du NCC.............................132
Figure VI-19 : Exemple de fichier dentre du modle de simulation............................................................133
Figure VI-20 : Profil FMT pour la simulation. .................................................................................................134
Figure VI-21 : Dlais ATC/AOC et GSM avec modes FMT variables. ..............................................................135
Figure VI-22 : Dlais IP avec modes FMT variables. .......................................................................................135
XVI
Figure A- 1 : Modlisation hirarchique dans lenvironnement OPNET........................................................ 164
Figure A- 2 : Vue globale du modle de source de trafic cockpit. ................................................................. 167
Figure A- 3 : Modle de source : trafic cockpit (domaine TMA&ENR). ......................................................... 168
Figure A- 4 : Modle de source : trafic cockpit (domaine ORP)..................................................................... 169
Figure A- 5 : Modle de source : trafic GSM (N-sources ON/OFF). ............................................................... 170
Figure A- 6 : Modle de source : trafic GSM (MMPP). .................................................................................. 172
Figure A- 7 : Module TCP_greedy_client. .................................................................................................... 173
Figure A- 8 : Module TCP_greedy_server. ................................................................................................... 176
Figure A- 9 : Modle du rseau. .................................................................................................................... 177
Figure A- 10 : Nud terminal satellite davion (ST). ..................................................................................... 178
Figure A- 11 : Module GSE_server............................................................................................................... 179
Figure A- 12 : Module MAC_serveur. .......................................................................................................... 180
Figure A- 13 : Nud Gateway (NCC intgr)................................................................................................. 182
Figure A- 14 : Module DAMA_controller..................................................................................................... 183
XVII
Liste des tableaux
Tableau II-1 : Dfinition des domaines despace arien dans le COCR. .......................................................... 12
Tableau II-2 : Paramtres et leurs dfinitions du RCP. .................................................................................... 13
Tableau II-3 : Exigences de performances les plus contraignantes dfinies dans le COCR. ............................ 14
Tableau II-4 : Exigences de performances pour les services aux passagers. ................................................... 19
Tableau II-5 : Tableau rcapitulatif des caractristiques services cockpit (Domaine TMA/ENR).................... 25
Tableau II-6 : Tableau rcapitulatif des caractristiques des services cockpit (Domaine ORP). ..................... 25
Tableau III-1 : Bandes de frquence disponibles pour les services AMSS (Zone europenne). ...................... 37
Tableau III-2 : Calcul de lattnuation par la pluie selon lITU-R P.618 (bande Ka). ........................................ 39
Tableau III-3 : Comparaison des normes DVB-S2, DVB-RCS, IPoS et DOCSIS-S. .............................................. 46
Tableau III-4 : Eb/N0 obtenus et les marges maximum offertes..................................................................... 52
Tableau III-5 : Marges offertes par les techniques FMT. ................................................................................. 52
Tableau III-6 : Modes FMT retenues................................................................................................................ 53
Tableau III-7 : Dimensionnement de la super-trame MF-TDMA. .................................................................... 55
Tableau III-8 : Divers classes de requte de capacit. ..................................................................................... 59
Tableau III-9 : Mise en uvre des requtes de capacit................................................................................. 61
Tableau IV-1 : Comparaison rcapitulative des interfaces/composants des rseaux UMTS et GSM.............. 70
Tableau IV-2 : Caractristiques dune liaison voix sur linterface Abis. ........................................................... 73
Tableau IV-3 : Types de paquets pendant lencapsulation.............................................................................. 78
Tableau IV-4 : Fragmentation/Rassemblage Indicateurs de GSE. ................................................................. 82
Tableau V-1 : Volumes reus en 1 heure - Approche classique....................................................................... 94
Tableau V-2 : Taille moyenne des files dattente dans le terminal avion - Approche classique. .................... 96
Tableau V-3 : Comparaison de lapproche classique et dynamique - Volumes reus en 1 heure................... 99
Tableau V-4 : Taille moyenne des files dattente dans le terminal avion - Approche dynamique. ............... 100
Tableau VI-1 : Comparaison des trois approches - Volumes reus en 1 heure. ............................................ 119
Tableau VI-2 : Comparaison des trois approches - Volumes reus en 1 heure (GSM/UMTS en veille)......... 121
Tableau VI-3 : Comparaison des trois approches - Taille moyenne des files dattente................................. 122
Tableau VI-4 : Rpartition de la ressource radiolectrique dans la simulation............................................. 134
Tableau A- 1 : Performances requises des services ATS pour le FRS............................................................. 152

Tableau A- 2 : Performances requises des services AOC pour le FRS............................................................ 153
Tableau A- 3 : Hypothse sur les paramtres de vol. .................................................................................... 153
Tableau A- 4 : Caractristiques des services ATS........................................................................................... 154
Tableau A- 5 : Caractristiques des services AOC.......................................................................................... 155
Tableau A- 6 : Performances de codage et de modulation du DVB-S2. [ETSI 302 307] ................................ 157
XIX
Tableau A- 7 : Performances de codage et de modulation du DVB-RCS. [BOL 04] ........................................158
Tableau A- 8 : Bilan de liaison sur le lien retour DVB-RCS..............................................................................162
Tableau A- 9 : Initialisation des paramtres TCP............................................................................................174
XX
Chapitre I
I. INTRODUCTION
Les communications aronautiques connaissent actuellement une profonde mutation. Dune part,
la croissance continue du trafic arien impose lintroduction de moyens nouveaux pour la
navigation arienne. LOACI (Organisation de l'Aviation Civile Internationale) dans le cadre du
comit spcial FANS (Future Air Navigation System) a dfini le concept CNS/ATM
(Communications, Navigation et Surveillance/Air Traffic Management). Pour la partie
communications, CNS/ATM non seulement utilise de nouveaux moyens de communications
(formes donde et techniques daccs adaptes aux transmissions de donnes numriques,
interconnexion par protocoles OSI) mais dveloppe galement de nouveaux services bass sur les
liaisons de donnes. Dautre part, les compagnies ariennes souhaitent proposer leurs
passagers de nouveaux services lis la connectivit aux rseaux terrestres : accs Internet,
services de tlphonie mobile Dans ce contexte, les liaisons par satellite sont appeles jouer
un rle majeur. Ces liaisons sont traditionnellement utilises pour le contrle arien dans les
domaines de vol o les liaisons terrestres ne sont pas disponibles (zones ocaniques par exemple).
Pour lensemble des nouveaux services aronautiques, le satellite est un moyen efficace pour
assurer la connectivit dans tous les domaines de vol.
Lobjectif de la thse prsente dans ce mmoire est didentifier ces nouveaux besoins en matire
de communication par satellite, de les quantifier en proposant notamment une modlisation des
sources de trafic puis de proposer et de dfinir une architecture du systme. Cette architecture
vise principalement fournir diffrents services la fois pour le CNS/ATM et pour les passagers
sur la base dune liaison satellite unique en bande Ka (20/30 GHz). Une attention particulire a t
porte sur la conception du terminal avion afin dassurer la convergence des diffrents flux de
trafic tout en satisfaisant les contraintes en matire de qualit de service.
1
Chapitre I - Introduction
I.1 Datalink
Dans le concept du CNS/ATM, la liaison de donnes, appele datalink, est une notion trs
importante car les services quelle offre permettent lvolution rapide des communications
aronautiques. Le datalink modifie le contrle de la circulation arienne (ATC : Air Traffic Control)
en introduisant un moyen complmentaire aux communications vocales qui sont essentiellement
utilises pour lATC. Par rapport aux communications vocales, les avantages du datalink sont :
allger la charge du travail de contrle
aider la localisation et la surveillance des avions
amliorer le contrle despace
viter les erreurs de procdure (malentendu, etc.).
Le concept du datalink a t introduit avec le systme de communications entre avion et sol

ACARS (Aircraft Communication Addressing and Reporting System, premier dploiement par
ARINC en 1978). Ce systme permet l'change de messages entre l'avion et le sol par une liaison
radio de trs haute frquence (VHF : Very High Frquence) ou une liaison satellite. Dans les
annes 1980, lOACI a dfini un concept darchitecture de rseau de tlcommunications
aronautiques plus robuste pour remplacer lACARS : ATN (Aeronautical Telecommunications
Network). LATN est une partie essentielle dans le systme CNS/ATM et fournit plusieurs services
de liaison de donnes pour les communications aronautiques [ANNEXE 10]. Les dtails de
larchitecture ATN seront introduits dans le chapitre IV.
Parmi plusieurs liaisons de donnes introduites dans lATN, SATCOM (SATellite COMmunication)
reprsente un moyen de communication important. Une solution oprationnelle propose par
lOACI pour le SATCOM est lutilisation des satellites INMARSAT (INternational MARitime SATellite
organization) et ses supports pour le service mobile aronautique par satellite (AMSS :
Aeronautical Mobile Satellite Service) avec pour principal atout une couverture quasi-mondiale.
Des systmes rgionaux peuvent augmenter la capacit du systme AMSS. Un exemple est donn
par les deux satellites MTSAT (Multifonctional Transport Satellite) 1R et 2 au dessus de la zone
Asie. Dautres systmes devront tre utiliss dans le futur afin de disposer dune capacit globale
suffisante.
2
I.2 Services aux passagers et premires exprimentations

Les compagnies ariennes sont particulirement intresses par le dveloppement des
communications aronautiques passagers (APC : Aeronautical Passenger Communications). Avec
lvolution rapide des technologies de communications terrestres, les divertissements classiques
bord (IFE : In-Flight Entertainment), principalement bass sur les audio/vido statiques, ne
permettent plus de satisfaire la demande des passagers en services multimdia. Au cours de ces
dernires annes, plusieurs projets ont dj montr lintrt et la faisabilit technique de laccs
Internet et du service tlphonie mobile bord des avions. Les solutions proposes sont
principalement bases sur les communications par satellite.
Le premier systme commercial par satellite pour les services APC est CCB (Connexion By Boeing)
[CCB-1]. Ce systme a t dvelopp par Boeing pour fournir laccs Internet haut dbit aux
passagers en cabine. Le dbit propos est de 5 Mbps en rception (lien aller) et 1 Mbps en
mission (lien retour). Le systme CCB opre en bande Ku (14,0-14,5 GHz pour le lien montant et
11,2-12,75 GHz pour le lien descendant). Le 17 aot 2006, Boeing a annonc l'abandon de ce
service de communication haut dbit bord [CCB-2]. Les raisons de cet chec relvent
principalement de l'exploitation commerciale plutt que de la technique. Connexion By Boeing a
dmontr que lutilisation de systmes commerciaux par satellite pour les services APC est
ralisable mais le cot dutilisation final doit tre matris. De plus en plus de projets continuent
davancer sur les communications embarques [AirCell] [OnAir] [MOWGLY].
LOACI a autoris le 19 juin 2007 lintroduction de systmes de tlphonie mobile bord des
avions [ICAO 07]. Un certain nombre de projets se sont mis en place pour fournir les services
correspondants [ONAIR] [AeroMobile]. Airbus est le premier constructeur aronautique qui a
reu l'autorisation de l'Agence Europenne de Scurit Arienne (AESA) pour le GSM bord afin
de permettre denvoyer/recevoir les appels/donns/mails durant le vol. La socit OnAir a t
cre dans ce contexte ; OnAir est une filiale du constructeur aronautique Airbus et du leader
mondial dapplications pour le transport arien SITA. Elle est aussi membre de lassociation GSM
et partenaire distribution dINMARSAT pour les services SwiftBroadband. En gnral, les
tlphones mobiles oprent avec une puissance leve quand ils recherchent un rseau partir
de lavion. Ceci augmente galement les risques d'interfrence avec les frquences des systmes
embarqus et les rseaux tlphoniques terrestres. Pour rsoudre ce problme, OnAir propose
dutiliser une station de base sur chaque avion qui permet dmettre et de recevoir des appels et
3
les connecter au rseau GSM via un lien satellite. Cette configuration permet aux tlphones
mobiles de fonctionner une puissance plus faible (de lordre du milliwatt).
I.3 Convergence des communications aronautiques sur un lien

unique par satellite
Pour chacun des services de communication bord de lavion, il existe diffrents systmes
disponibles ou en cours dtude. Jusqu prsent, ces systmes fonctionnent dune manire
indpendante avec des infrastructures propres installes bord et au sol. Cependant, il est
avantageux davoir un seul systme qui permette dintgrer les diffrents systmes de
communication et de rpondre toutes les exigences des services ATM [SESAR] [NEWSKY]. Dune
part, la capacit et la disponibilit du systme pour lATM peuvent tre augmentes par la
convergence de plusieurs moyens de communication ; dautre part, en partageant entre
diffrents agents, les cots de certaines applications (ex : APC) peuvent tre diminus pour les
utilisateurs. Nanmoins, ce principe dintgration implique que des applications scurises (ex :
ATC, AOC) et non scurises (APC) soient transmisses dans un mme rseau.
Les systmes de communication par satellite sont un lment trs important dans ce concept
dintgration. Ils reprsentent non seulement un moyen complmentaire aux systmes terrestres
pour la gestion du trafic arien en offrant une couverture globale, mais aussi une solution
prometteuse pour enrichir les services IFE (APC) grce la capacit significative quils peuvent
offrir. Jusqu prsent, lOACI ne permet pas encore dutiliser des systmes APC pour la
communication ATM en raison de la scurit et de la diversit des exigences des services en
termes de performances. Pourtant, plusieurs activits rcentes ont dj montr lintrt et la
faisabilit prliminaire dutiliser les systmes commerciaux qui sont consacrs aux services APC
pour les communications ATM [ANASTASIA] [RAD 06]. Cependant, le dveloppement et
limplmentation du rseau global ddi lATM et lAPC restent une perspective long terme.
Lobjectif des travaux mens lors de la thse est de proposer un systme de communication par
satellite qui permette de fournir la fois de nouveaux services pour les passagers (accs
Internet, tlphonie mobile) et un canal fiable pour les services aronautiques CNS/ATM. Lenjeu
principal de cette approche est la convergence de diffrents flux de trafic avec des
caractristiques et les exigences de performances htrognes dans un lien unique par satellite.
4
I.4 Plan du mmoire

Le mmoire est organis en six chapitres, dont cette introduction gnrale est le premier.
Le deuxime chapitre est ddi ltude des services proposs bord de lavion. Lobjectif est
didentifier les diffrents flux de trafic et de les caractriser. Une premire partie prsente un
historique rapide des liaisons de donnes pour les services aronautiques puis expose la
dfinition des performances requises par les services ATS (Air Traffic Service) et AOC (Airline
Operational Control) utiliss pour la navigation arienne. Une seconde partie dcrit les services de
tlphonie mobile et daccs Internet pour les passagers. Concernant les flux htrognes
gnrs par les diffrents services, nous proposons la modlisation des sources de trafic et sa
validation avec logiciel de simulation de rseaux OPNET Modeler.
Le troisime chapitre est consacr ltude des caractristiques du rseau daccs par satellite.
Lutilisation dune ressource radiolectrique de bande Ka (20/30GHz) est dabord propose.
Compte tenu des contraintes de propagation imposes, un panorama des techniques FMT (Fade
Mitigation Technique) qui permettent de compenser les affaiblissements est prsent. Une
architecture daccs satellite, dit de rfrence, base sur les normes DVB-S2/DVB-RCS de lETSI est
ensuite propose et les proprits des couches physique et daccs sont analyses.
Le quatrime chapitre aborde la conception de larchitecture du systme satellite devant assurer

la convergence des diffrents rseaux. Pour ce faire, une tude de larchitecture protocolaire de
chaque rseau (ATN, GSM/UMTS et TCP/IP) est dabord prsente. Base sur cette tude,
ladquation des formats de donnes et des mthodes dencapsulation spcifiques la liaison
satellite est analyse.
Le cinquime chapitre est consacr la dfinition de larchitecture du terminal avion. Deux

approches sont proposes et analyses. La premire approche est base sur larchitecture de
rfrence BSM (Broadband Satellite Multimedia) faisant lobjet de plusieurs documents de lETSI.
Le terminal avion et le rseau daccs satellite DVB-S2/RCS sont modliss laide du logiciel
OPNET Modeler. Ltude des performances met en vidence la ncessit dune amlioration de
lutilisation de la ressource et de la gestion de son partage entre flux de trafic par la mise en
uvre dune signalisation entre couches protocolaires (interaction de type Cross-Layer ). Une
premire solution est propose et analyse. Un tat de lart du concept et des techniques Cross-
5
Layer est ensuite prsent afin de nous permettre de dfinir une architecture finale pour le
terminal avion.
Cette architecture finale pour le terminal avion est prsente et sa mise en uvre est dtaille
dans le sixime chapitre. Ainsi, une valuation des performances de cette troisime version
darchitecture est tudie et permet de comparer cette version finale avec les deux approches
prcdentes. Un modle de simulation plus complexe est utilis pour tudier les performances du
rseau avec une charge variable (nombre davions partageant la mme ressource satellite). Ce
modle permet galement dobserver le comportement du terminal avion dans le cas dune
volution dynamique du bilan de liaison. Les performances obtenues rpondent aux objectifs
fixs : convergence des diffrents flux de trafic sur la mme liaison avec un respect des exigences
de qualit de service, adaptation aux variations de capacit sur la liaison satellite.
6
Chapitre II
II. SERVICE A BORD
Lobjectif de ce chapitre est double : il est tout dabord de dfinir dune manire formelle les
performances requises pour les services bord, y compris les services ATS/AOC pour la gestion du
trafic arien (ATM) ainsi que les services IFE pour les passagers (APC) ; il est ensuite de
caractriser les trafics associs aux services proposs et de modliser les sources de trafic
correspondantes avec le logiciel de simulation OPNET.
II.1 Services pour lATM
II.1.1 Historique
Le contrle arien utilise des changes de type phonie pour lensemble des procdures. Les
compagnies ariennes ont cependant prouv le besoin dchanges de donnes entre les avions
et le sol afin dautomatiser certaines tches de gestion (par exemple le suivi des phases de vol par
la compagnie) et dintroduire de nouveaux services (principalement lis aux services
mtorologiques et la maintenance avion). La socit ARINC a dfini la fin des annes 1970 le
systme ACARS (Aircraft Communication Addressing and Reporting System). La couverture du
systme a t rapidement augmente par un accord entre ARINC et SITA permettant lchange de
messages par les stations sol des deux socits. Le systme ACARS permet l'change de messages
entre l'avion et le sol par une liaison radio de trs haute frquence (VHF : Very High Frquence)
ou par satellite. Les messages sont de type telex, cest--dire que linformation est code sous
forme dune suite de caractres (dlimitation par octets).
Le systme ACARS sest impos comme un standard de fait pour la liaison de donnes. Cependant,
le rseau ACARS prsente plusieurs inconvnients : une capacit faible, une conception ne
7
Chapitre II - Services Bord
permettant pas une interconnexion simple, des limitations dans les formats dchange, une
absence de procdures dauthentification et de scurit. Dans les annes 1980, lOACI a dfini un
concept darchitecture de rseau de tlcommunication robuste pour remplacer lACARS. Il sagit
du rseau de tlcommunications aronautiques ATN (Aeronautical Telecommunications
Network). LATN est une partie essentielle dans le systme CNS/ATM et destin fournir plusieurs
services de liaison de donnes pour les communications aronautiques [ANNEXE 10]. Les dtails
de larchitecture ATN seront introduits dans le chapitre IV. La principale caractristique de lATN
est de reposer sur une architecture de type OSI (Open Systems Interconnection, norme ISO et ITU-
T) ce qui permet daugmenter de faon importante le domaine dapplication. En particulier, lATN
doit tre utilis pour le contrle arien ATC (Air Traffic Control).
LATN permet une intgration de tous types de liaisons de donnes : HF (High Frequency), VHF,
radar secondaire Mode-S, satellite. SATCOM (SATellite COMmunication) reprsente un moyen de
communication long terme. Il permet une couverture globale des services et une meilleure
performance de transmission grce sa capacit disponible. La solution oprationnelle propose
lheure actuelle par lOACI pour le SATCOM est lutilisation des satellites INMARSAT
(INternational MARitime SATellite organization) et ses supports pour le service mobile
aronautique par satellite (AMSS : Aeronautical Mobile Satellite Service). INMARSAT [INMARSAT-
1] a t cr en 1979 comme une organisation internationale pour fournir les communications
mobiles dans la rgion maritime. Aujourdhui, INMARSAT est devenu le fournisseur principal de
communications mobile par satellite la fois pour les rseaux terrestres et maritimes mais
galement pour lATN. Six types de terminaux aronautiques associs des classes de service sont
proposs : Aro-H, Aro H+, Aro-I, Aro-L, Mini M Aero et Aero-C, collectivement appels
services aronautiques classiques . Ces systmes aronautiques classiques appliquent les
normes et pratiques recommandes par lICAO (SARPs : Standards and Recommended Practices)
[ATN SARPs] et permettent des communications phonie ainsi que des changes de donnes
fiables et scurises. Cependant, le dbit de donnes fournies par ces services classiques demeure
faible (10,5 Kbps maximum). La capacit des satellites INMARSAT peut tre augmente
localement par lutilisation dautres satellites (ex. MTSAT : Multifunctional Transport Satellites).
II.1.2 Dfinitions
Avant de prsenter les diffrents types de services dans cette partie, il est ncessaire de
distinguer deux termes de base : le service et lapplication.
8
Le service correspond aux transactions qui sappuient sur une ou plusieurs applications avec
une mission oprationnelle spcifiquement dfinie. Par exemple : ATIS (Automatic Terminal
Information Service) est un service automatique de diffusion qui permet aux pilotes de
recevoir en continu des informations sur les aroports les plus frquents.
Lapplication correspond lensemble des fonctions qui permettent et grent les transactions
de communication ncessaires afin dassurer les services. Par exemple : lapplication CPDLC
(Controller Pilot Data Link Communications) qui permet les changes d'informations entre
pilotes et contrleurs.
Plus prcisment, comme montr par la Figure II-1, le service reprsente une des ralisations des
applications ; dans les applications, un certain nombre de messages sont retrouvs et permettent
aux services doprer dans le domaine dapplication [DTI 00].
Application 1
Service A
Application 2
Service B Application 3
Figure II-1 : Relation entre le service et lapplication.
II.1.3 Diffrents types de services de communication
Les services de communication ATM se composent principalement de deux grandes catgories :
Les services ATS (Air Traffic Services) [ANNEXE 10] sont des services qui servent au contrle
de la circulation arienne (ATC : Air Traffic Control). Ils sont utiliss pour empcher les
abordages entre avions, viter les collisions entre les avions sur laire de manuvre de
laroport et les obstacles, etc. Le service ATIS que nous avons mentionn prcdemment est
un exemple de ce type de service.
Les services ATS peuvent tre supports par plusieurs applications. Les deux types
dapplication datalink introduits dans le systme FANS qui permettent les services ATS
sont :
9
ADS-A, galement connu sous le nom de ADS-C (Automatic Dependant Surveillance -

Addressed/Contract) est une application utilise pour surveiller automatiquement la
position relle de l'avion par des communications point point. Suite des requtes
envoyes par les contrleurs appeles les contrats , plusieurs informations comme la
position avion, les intentions de vol, etc. sont rcupres depuis les calculateurs bord et
sont envoyes intervalles rguliers vers le sol. Par contre, cause des dures de mises
jour pour les informations, lADS-C est gnralement utilis dans le cas o le radar
classique nest pas disponible (ex : rgions ocaniques).
CPDLC est une application qui permet les communications entre les pilotes et les
contrleurs par un systme de messagerie (voir la Figure II-2). Ces messages sont bass sur
des textes courts, instantans avec certaines de commandes (ex : monter ou descendre
tel niveau). Les messages sont codifis et envoys avec des procdures de bouclage qui
assure lenvoie et rception des messages. Lutilisation du CPDLC permet de dsencombrer
les frquences actuelles (ex : HF, VHF) pour les communications vocales.
Figure II-2 : Interface graphique de lapplication CPDLC.
10
Les services AOC (Aeronautical Operational Control) [ANNEXE 10] sont ddis aux
compagnies ariennes et sont ncessaires lexercice de lautorit sur le commencement, la
continuation, le droutement ou lachvement du vol pour des raisons de scurit, de
rgularit et defficacit. Par exemple : le service WXGRAPH (Graphical Weather Information)
permet denvoyer des informations de mto lavion, ces informations sont affiches sous
forme de graphique.
II.1.4 Une tude prospective : le COCR
La dfinition et la normalisation des services oprationnels devant tre assurs par lATN ne sont
pas immdiates. En effet, dune part, les services doivent tre rendus de faon homogne au
niveau rgional ainsi que mondial. Dautre part, la tendance reproduire les services vocaux par
le datalink va conduire une divergence entre les systmes impliqus, ce qui entrane une
htrognit dans limplmentation. Rcemment, lorganisation europenne pour la scurit de
la navigation arienne (EUROCONTROL) et l'administration de l'aviation civile aux Etats-Unis (FAA)
ont propos conjointement un guide appel COCR (Communications Operating Concept and
Requirements for the Future Radio System) [COCR 2.0]. Ce guide est une rfrence technique qui
identifie les services oprationnels et leurs exigences et sera applique pour valuer les
performances du futur systme radio FRS (Future Radio System).
Dans le COCR, la dfinition des services oprationnels et leurs exigences de performances sont
exprimes sur deux phases principales (voir Figure II-3). Dans la premire phase (Phase 1), les
communications vocales sont essentielles pour lATM et les communications des donnes
sappuient sur les services datalink existants ou mergents. A partir de 2020, la deuxime phase
(Phase 2) reprsente une nouvelle faon d'utiliser les communications datalink : les transmissions
de donnes seront le moyen principal pour lATM et un ensemble de nouveaux services datalink
seront introduits pour remplacer ou complter ceux de la Phase 1. Dans notre tude, nous nous
concentrons sur les services datalink moyen terme, cest--dire la Phase 1.
11
Phase 2
Communications essentielles : donnes
Phase 1
Communications essentielles : vocales
2005 2010 2015 2020 2025 2030 2035
Figure II-3 : Dfinition des phases dans le COCR.
Les services oprationnels introduits dans le COCR sont particulirement concentrs sur les
communications de donnes. Pour chaque priode (Phase 1 ou 2), un certain nombre de services
ATC/AOC sont dfinis et activs par phase de vol. Cinq domaines despace arien qui
correspondent aux phases de vol sont spcifis et rsums dans le Tableau II-1 :
Domaine oprationnel Dfinition dans le COCR
Zone cylindrique de 10 miles de diamtre et dune hauteur ~5000

APT (AirPorT)
pieds dont la base est laroport
Zone de rayon 50 nautiques (Nm) dont le centre est laroport, et
sur une hauteur comprise entre 5000 pieds et FL245. Les zones
TMA (Terminal Manoeuvring Area)
de dpart et darrive sont considres identiques dans le COCR
(sauf pour le sens du vol)
Espace continental ou national qui entoure le domaine TMA sur
ENR (EN Route)
une altitude de FL245 jusqu FL600.
Espace comme le domaine ENR mais pour des rgions non
ORP (Oceanic, Remote, Polar)
habites (ocans, ples, etc.)
Nouveau domaine (Phase 2) associ des oprations autonomes
AOA (Autonomous Operations Area)
pour les arodromes pouvant oprer sans ATC
Tableau II-1 : Dfinition des domaines despace arien dans le COCR.
II.1.5 Performances requises
Dans le domaine aronautique, les procdures et les mthodes pour dterminer les exigences de
performances dun systme ou dun service sont appeles lOPA (Operational Performance
Assessment). Conforme aux [RTCA-189] et [EUROCAE ED-78A], dans le COCR, lOPA dtermine les
exigences de performances partir du concept de type RCP (Required Communication
Performance). Le type RCP est exprim sous forme dun ensemble de paramtres comme la
disponibilit, l'intgrit, etc. pour qualifier les performances. Bas sur ce type, le RCP permet de
dterminer le cadre oprationnel des performances de communication. Le RCP est dfini
12
conformment aux besoins oprationnels et aux exigences de scurit, il est indpendant de la

technologie utilise. Deux composants essentiels sont spcifis concernant les exigences de
performance : Performance Humaine et Performance Techniques de Communication Requise
(RCTP: Required Communication Technical Performance). Dans cette thse, nous ne considrons
que la partie technique.
Comme mentionn prcdemment, le type RCP est exprim sous la forme dun ensemble de
paramtres pour qualifier les performances des transactions des communications, ces diffrents
paramtres et leurs dfinitions sont montrs dans le Tableau II-2 [EUROCAE ED-78A] :
Paramtre Dfinition
Dure maximale La dure maximale dune transaction aprs laquelle les parties
ETRCP
de la transaction homologues doivent passer une autre procdure.
Dure de 95%
TT95 Dure avant laquelle 95% des transactions sont termines
des transactions
La probabilit que la transaction soit termine avant sa dure maximale
Continuit CRCP en supposant que le systme de communication est disponible au dbut
de la transaction
La probabilit que le systme de communication entre les deux parties
Disponibilit ARCP
soit en service lorsquil est sollicit
La probabilit que des communications avec tous les avions de la zone
Disponibilit Aprovision
soient disponibles
Intgrit IRCP Le pourcentage de transactions ralises sans erreur non dtecte
Tableau II-2 : Paramtres et leurs dfinitions du RCP.
Dans [EUROCAE ED-78A], au lieu de dfinir un type de RC(T)P pour chaque transaction, la
procdure est simplifie par le regroupement des transactions en grandes catgories (ex :
Planification, Stratgique, Tactique). Le type RC(T)P pour chaque catgorie reprsente un type
global de RCP pour un espace arien partir de la transaction la plus contraignante assurer.
Par contre, dans le COCR, pour avoir le type de RCTP plus prcis, les performances requises sont
dfinies par service pour un espace arien spcifi. Cette dfinition est base sur les exigences
bout en bout du RCTP en tenant compte tous les segments du rseau global (ex : le rseau
terrestre, le systme terminal embarqu, etc.). Par ailleurs, en ce qui concerne le futur systme
radio (FRS), une frontire est introduite pour distinguer la partie FRS dans tous les composants du
rseau global. En dautres mots, cette borne introduite dans la pile de protocole de
13
communication est considre comme une interface logique sparant le sous rseau radio FRS du
reste du rseau. D'un point de vue physique, ces points de frontire sont situs dans le routeur sol
et le routeur bord. Une illustration de cette frontire FRS dans les diffrentes architectures de
rseaux est montre dans la Figure II-4. Les dtails darchitectures seront prsents dans le
chapitre IV.
Modle OSI Modle TCP/IP ATN
Application
Application
(CPDLC, ADS, etc.)
Application
Prsentation Prsentation
(HTTP, FTP, etc.)
Session Session
Transport
Transport TP4
(TCP, UDP)
Rseau
Inter CLNP
Rseau (IP)
Frontire FRS
Intra SNDCF Mobile
Accs rseau
Liaison de donnes Liaison de donnes Partie FRS
(Ethernet, X.25, etc.)
Physique Physique
Figure II-4 : Dfinition du FRS (Futur Systme Radio) dans le COCR.
Les performances requises pour les services ATS et AOC (partie FRS) sont dfinies selon une
hypothse du pourcentage de rpartition du RCTP global. Les valeurs sont listes dans les Tableau
A- 1 et Tableau A- 2 de lannexe A et les exigences les plus contraignantes pour les
communications air-sol point point sont montres dans le Tableau II-3 :
TT95 one way (seconde)

Type de service Phase Intgrit Disponibilit
TMA ENR ORP
1 3.8 3.8 26.5 5.0E-6 0.9995
ATS
2 0.74 0.74 5.9 5.0E-10 0.9999999995
AOC 1+2 13.6 13.6 26.5 5.0E-10 0.9995
Tableau II-3 : Exigences de performances les plus contraignantes dfinies dans le COCR.
14
A lvidence, les exigences de disponibilit ne peuvent tre satisfaites avec un seul type de liaison
(par exemple satellite), une combinaison de plusieurs liaisons est ncessaire (par exemple satellite
et HF).
II.1.6 Service mobile aronautique par satellite
Au niveau oprationnel, lOACI a produit des documents normatifs prsentant les standards et
pratiques recommandes (SARP : Standards and Recommended Practices) qui concernent tous les
aspects techniques et oprationnels dans le domaine de laviation civile. En ce qui concerne les
systmes AMSS (Aeronautical Mobile Satellite Service) pour les communications aronautiques
par satellite (SATCOM), celles-ci sont prsentes dans le volume III de lannexe 10 du SARP
[ANNEXE 10].
Le systme AMSS comprend la station terrienne davion (AES : Airborne Earth Station), la station
terrienne au sol (GES : Ground Earth Station) et le satellite gostationnaire. Dans la
recommandation de lannexe 10, plusieurs canaux physiques sont dfinis comme montrs dans la
Figure II-5. Les canaux P, T et R sont ddis aux donnes et la signalisation, les canaux C sont des
canaux de type circuits utiliss pour la phonie.
Canal P : GES AES

Canal T : AES GES
Canal R : AES GES
P Canal C : Bidirectionnel
T P
R T
C R
C
AES
GES
Figure II-5 : Diffrents canaux du system AMSS.
15
Canal P : canal utilis pour la liaison du sol vers lavion entre le GES et tous les AES
correspondants, servant transmettre continuellement des donnes de signalisation et les
donnes dutilisateurs. Il est aussi utilis pour fournir des informations aux autres canaux.
Canal R : canal accs alatoire (Aloha discrtis) utilis pour la liaison du bord au sol et aussi
pour les demandes du canal T.
Canal T : canal accs multiple par rpartition dans le temps (TDMA : Time Division Multiple
Access) en mode rservation, utilis partir de lavion seulement pour transmettre du bord
au sol les messages plus longs. La GES rceptrice rserve des crneaux de temps pour les
transmissions demandes par les AES, selon la longueur du message. LAES mettrice met le
message dans les crneaux de temps rservs, selon sa priorit.
Canal C : canal bidirectionnel, gnralement utilis pour les communications vocales.
Bas sur ces diffrents canaux, les AES peuvent tre classes en plusieurs niveaux selon les
services fournis. Cette dfinition du niveau de lAES est ensuite utilise pour caractriser un
systme AMSS.
Niveau 1 : est capable de supporter les canaux uniques P, T et le canal R aux dbits de 0,6 et
1,2 Kbps.
Niveau 2 : est capable de supporter les canaux uniques P, T, et le canal R aux dbits de 0,6 et
10,5 Kbps.
Niveau 3 : est capable de supporter les services de niveau 2 plus un mode circuit du canal C
un dbit de canal de 8,4 ou 21,0 Kbps.
Niveau 4 : est capable de supporter les services de niveau 3 plus lexploitation doprations
simultanes entre le canal C et les canaux R et T.
Normalement, mme si les canaux de niveau 3 et 4 peuvent tre employs pour la transmission
de donnes, ils sont principalement utiliss pour les communications vocales.
Les normes SARP de lOACI pour le service AMSS correspondent ltat actuel des protocoles
daccs utiliss pour les satellites INMARSAT. La ncessit de pouvoir prendre en compte dautres
protocoles daccs a conduit la formation dun groupe de travail NGSS (Next Generation Satellite
Systems). Il est noter que le systme Iridium utilisant des satellites en orbites basses fait partie
des alternatives prises en compte par lOACI.
16
II.2 Services aux passagers

Dans cette partie, nous nous intressons aux services qui peuvent tre fournis aux passagers
pendant leur voyage. Conformment ce qui est prsent dans le chapitre I, le choix repose sur
les deux types de services qui sont les plus souvent demands : la tlphonie mobile et laccs
Internet.
II.2.1 Services pour tlphonie mobile
La tlphonie mobile a t introduite dans les annes 80 pour sa premire gnration. Cette
technique est base sur la transmission radiolectrique dans une zone de quelques dizaines de
kilomtres de rayon au maximum qui est gre par un site cellulaire. Jusqu prsent, lvolution
de la technologie des communications radio mobiles nous permet non seulement la
communication vocale mais aussi des services supplmentaires, par exemple : la messagerie SMS
(Short Message Service) pour le transfert des messages textuels courts ; la transmission des
donnes par Internet ; la messagerie multimdia (MMS) pour lchange des photos, daudio et de
vido ; etc.
La premire gnration de la tlphonie mobile est en mode analogique. Elle a t compltement

remplace en 1990 par la seconde gnration (2G par la suite) qui est actuellement largement
dploye au niveau mondial. En Europe, la norme 2G est connue sous le nom de GSM (Global
System for Mobile Communications). Le GSM utilise une technologie TDMA (mthode daccs par
multiplexage rpartition temporelle). En dautres mots, le TDMA permet diffrents utilisateurs
de partager une bande de frquence des moments diffrents. Par rapport la premire
gnration, les avantages de la 2G sont : le terminal est plus petit, la capacit est augmente, la
qualit de la voix est amliore, la scurit est mieux assure. En gnral, la 2G est ddie
essentiellement aux services de base, cest--dire le service vocal, des messages courts et la
transmission de donnes avec un dbit faible (9,6 Kbps maximum).
Pour rpondre aux besoins de la transmission haut dbit afin de permettre les services
multimdia ainsi que laccs Internet, la troisime gnration (3G par la suite) a t propose.
En Europe, la norme 3G utilise s'appelle UMTS (Universal Mobile Telecommunications System).
Elle est base sur l'accs multiple de type W-CDMA (Wideband - Code Division Multiple Access)
qui permet plusieurs liaisons numriques de partager simultanment la mme frquence
17
porteuse. Grce cette technologie, le dbit offert peut atteindre jusqu 2 Mbps (dbit maximal,
mais 384 Kbps en gnral) ce qui donne la possibilit denrichir les services offerts (MMS, Internet,
etc.).
Dans le cas dapplication qui nous intresse, il parait appropri de considrer les systmes GSM
(2G) et optionnellement les systmes UMTS (3G). En effet, mme si de nouvelles techniques avec
des dbits encore amliors sont adoptes pour les futures gnrations de tlphonie mobile
(exemple : LTE, Long Term Evolution), les utilisateurs GSM (UMTS inclus) seront majoritaires dans
le monde au cours des dix prochaines annes [3G Americas]. Sachant que jusquen 2008, la
famille GSM compte environs trois milliards d'utilisateurs repartis dans 220 pays du monde (soit
88% des utilisateurs de tlphones portable), nous nous intressons aux standards et services qui
sont bass sur cette technique (2G et 3G) et les appelons la tlphonie mobile GSM/UMTS par la
suite.
II.2.2 Services daccs Internet
Aujourdhui, lInternet permet au public de communiquer sur un rseau informatique mondial et

il est devenu un lment important pour la vie professionnelle et quotidienne. De plus, pour les
compagnies ariennes, lInternet haut dbit bord reprsente un march la croissance
prometteuse la condition que les tarifs soient abordables. Aussi, les services envisags
dpendent fortement des besoins de passagers et des cots lis aux techniques proposes. Dans
cette thse, nous considrons deux principaux services qui sont les plus utiliss par les
internautes : le courrier lectronique (Email) et le World Wide Web (WWW).
II.2.3 Qualit de service requise
Les exigences de performance des services multimdia sont dfinies par les diffrents groupes de
normalisation comme ITU, ETSI et 3GPP. Dans ces recommandations, les paramtres utiliss pour
valuer les performances sont prciss. Les limites de ces critres sont exprimes dune manire
gnrique et indpendamment de la technique retenue.
Trois paramtres principaux sont gnralement utiliss pour caractriser la qualit des services
multimdia:
18
Dlai : reprsente le temps coul pour un service donn, entre l'envoi des informations par
un metteur et la rception par le(s) destinataire(s). Ce dlai correspond au dlai de
transmission plus le dlai de propagation le long du rseau et les dlais introduits par les files
d'attente dans les lments intermdiaires (ex : Routeurs/Switches).
Gigue : dsigne la variation du dlai de transfert de l'information. Elle est principalement due
lacheminement des paquets dans les nuds intermdiaires du rseau. Ce paramtre est
souvent utilis pour vrifier la synchronisation entre lmetteur et le rcepteur. Pour les
services trs exigeants en termes de gigue, on utilise parfois un buffer pour re-synchroniser
les donnes.
Taux de perte : correspond au pourcentage des paquets perdus durant leurs transmissions
par rapport au nombre total des paquets envoys par lmetteur. Ces pertes sont le plus
souvent causes par les congestions dans le rseau.
Les exigences de performance des services multimdia ainsi que la tlphonie mobile GSM/UMTS
en fonction des trois critres mentionns ci-dessus sont exposes dans le Tableau II-4 [ITU
G.1010] :
Performance Requise
Application
Dlai unilatral Gigue Taux de perte
Tlphonie < 150ms (prfrable) < 3%
Communication vocale < 1ms
Mobile GSM < 400ms (limite) (taux de perte de paquets)
Email < 4s / 0
Internet
WWW < 4s/page / 0
Tableau II-4 : Exigences de performances pour les services aux passagers.
II.3 Modlisation des sources de trafic

La modlisation des sources de trafic est une tape fondamentale pour valuer la performance du
systme. Ces sources doivent permettre de gnrer des flux de paquets rpondant des
caractristiques prcises. Dans cette partie, trois sources de trafic sont proposes. Concernant le
trafic cockpit des services ATS/AOC, la modlisation repose sur les hypothses introduites dans le
COCR, il sagit dans ce cas de modliser une source par avion. Par contre pour les services
GSM/UMTS et Internet cabine, les deux flux sont considrs comme des flux agrgs par avion :
19
effectivement pour lun comme pour lautre il est ncessaire de considrer que compte-tenu du
nombre dutilisateurs, plusieurs connexions sont ouvertes simultanment. Plusieurs paramtres
de ces 3 modles de source (par exemple : taille de message, nombre dutilisateurs, etc.) pourront
ensuite servir de paramtres dentre des simulations afin dvaluer les performances globales du
systme dans diffrentes conditions.
II.3.1 Source de trafic cockpit
Pour modliser le flux de paquets ATS/AOC, nous adoptons le mme principe que le COCR, qui est
bas sur deux ensembles dhypothses :
Hypothses sur lenvironnement et le mode dopration : ils dcrivent le mode dutilisation

des services dans le contexte oprationnel. Ces hypothses sont : la frquence dutilisation de
service, les caractristiques moyennes des vols, etc. Par exemple, pour le service ACL (ATC
clearance) qui permet lenvoi de la clairance par le contrleur vers le pilote et de la requte
par le pilote vers le contrleur, dans le domaine oprationnel ENR, sa frquence dutilisation
est 5 fois par domaine pour chaque avion.
Hypothses sur limplmentation de service : il sagit des hypothses sur le mode de

communication pour chaque service et de leurs caractristiques dimplmentation. Ces
hypothses sont : le mode de communication (en point point ou en diffusion), la quantit et
la taille des messages, etc. Nous restons toujours sur lexemple de service ACL qui fonctionne
en point point, en lien du bord au sol, 2 messages de 93 octets sont envoys chaque
utilisation du service.
Les dtails de ces hypothses sont donns dans la rfrence COCR. Un travail danalyse est
ncessaire afin dextraire les informations pertinentes pour notre systme. Ainsi, en ce qui
concerne la communication par satellite, certaines adaptations et simplifications doivent tre
prises en compte (voir Annexe A). Le trafic cockpit concerne principalement les services qui sont
les plus appropris pour les transmissions par satellite. Ceci signifie que les communications AIR-
AIR (par exemple : les changes dinformations de navigation entre les avions en utilisant lADS-B)
sont exclus dans cette tude. Le domaine APT nest pas pris en compte car les services qui
relvent de ce domaine sont gnralement plutt supports par une infrastructure terrestre (par
ex : VHF, IEEE 802.16, etc.) pour des raisons conomiques. Par ailleurs, le domaine AOA nest pas
non plus considr car il nest applicable que pour la Phase 2 (Figure II-3). Conformment la
20
mthodologie recommande dans le COCR, pour modliser un fonctionnement trs forte charge,
nous prenons lhypothse que le trafic cockpit (ATS/AOC) de donnes, par opposition la voix,
remplit pleinement sa capacit.
La source de trafic cockpit est ensuite modlise sous forme de processus stochastiques, laide
du logiciel de simulation OPNET Modeler (Annexe D). Les paramtres dentres sont des extraits
des hypothses du COCR en tenant compte des simplifications mentionnes prcdemment. Le
trafic modlis concerne au flux de communications point point pour les services ATS/AOC dans
les domaines TMA, ENR et ORP. Les services du domaine ORP et des domaines continentaux
TMA/ENR sont tudis sparment car leurs rpartitions gographiques et les performances
requises sont trs diffrentes. De plus, cette source de trafic (montre dans lAnnexe E.1) permet
dtudier collectivement ou individuellement les comportements des services ATS et AOC. La
Figure II-6 illustre le processus de conception qui nous permet dobtenir le modle retenu.
Trafic cockpit (par avion)
Hypothses Modle de source Rsultats
Domaine TMA/ENR/ORP
Entres de simulation (ref. COCR) Sorties de simulation
ATS
Caractristique de vol Taux moyen darriv des messages
Services oprationnels Taille moyenne des messages
Frquence dutilisation AOC
Caractristique de messages
Classes de service
Figure II-6 : Vue globale de la modlisation de source trafic cockpit.
Deux profils de trafic cockpit sont capturs partir de la simulation (sur le lien AIR-SOL : du bord
au sol) et montrs dans les Figure II-7 et Figure II-8. Il sagit des trafics correspondants
respectivement aux domaines TMA/ENR et ORP. Dans les domaines TMA/ENR, nous dfinissons
trois classes de service selon leurs TT95 demand (COS0 : 3,8s, COS1 : 13,6s ; COS2 : 26,5s).
Cependant, le choix reste trs souple dans cette tude, ces trois classes peuvent tre regroupes
ou raffines selon les besoins. Pour le trafic montr dans la Figure II-8, une seule classe (TT95 :
26,5 s) de service est associe la fois des services ATS et AOC dans le domaine ORP.
21
(a) : Profil de trafic (ATS/AOC). (b) : Densit de probabilit cumule (ATS+AOC).
(c) : Densit de probabilit cumule (ATS). (d) : Densit de probabilit cumule (AOC).
22
(e) : Profil de trafic (COS0/COS1/COS2). (f) : Densit de probabilit cumule (COS0).
(g) : Densit de probabilit cumule (COS1). (h) : Densit de probabilit cumule (COS2).
Figure II-7 : Profil de trafic cockpit (domaine TMA/ENR).
23
(a) : Profil de trafic (ATS/AOC). (b) : Densit de probabilit cumule (ATS+AOC).
(c) : Densit de probabilit cumule (ATS). (d) : Densit de probabilit cumule (AOC).
Figure II-8 : Profil de trafic cockpit (domaine ORP).
Selon les rsultats montrs ci-dessus, nous pouvons remarquer que le trafic cockpit est un trafic
faible et sporadique (les paquets sont gnrs avec un rythme irrgulier). Ces proprits rendent
la conception du systme plus difficile: dune part, le systme doit tre capable de fournir des
dbits suffisamment levs (dbit crte) pour rpondre aux besoins de tous les services
oprationnels ; dautre part ce mme dbit na pas besoin dtre garanti en continu compte-tenu
de la sporadicit observe.
24
Les tableaux rcapitulatifs (Tableau II-5, Tableau II-6) prsents ci-dessous donnent les valeurs
caractristiques obtenues par simulation avec notre modle pour le trafic cockpit.
Lien aller
Global
ATS AOC COS0 COS1 COS2
Caractristiques (ATS+AOC)
(COS0/1/2) (COS0/1/2) (ATS+AOC) (ATS+AOC) (ATS+AOC)
(COS0/1/2)
Taille des paquets
93 88 103 88 103 268
(min) (octets)
Taille des paquets
2763 2763 1530 387 2763 727
(max) (octets)
Taille des paquets
306 487 209 188 337 418
(moyenne) (octets)
Dbit demand
/ / / 5.4 3.9 0.8
(crte) (Kbps)
Tableau II-5 : Tableau rcapitulatif des caractristiques services cockpit (Domaine TMA/ENR).
Lien retour
Global
ATS AOC COS0 COS1 COS2
Caractristiques (ATS+AOC)
(COS0/1/2) (COS0/1/2) (ATS+AOC) (ATS+AOC) (ATS+AOC)
(COS0/1/2)
Taille des paquets
88 88 103 / / 88
(min)
Taille des paquets
2763 2763 1530 / / 2763
(max)
Taille des paquets
715 1968 198 / / 715
(moyenne)
Dbit demand
/ / / / / 3.2
(crte) (Kbps)
Tableau II-6 : Tableau rcapitulatif des caractristiques des services cockpit (Domaine ORP).
II.3.2 Source de trafic tlphonie mobile
Le trafic des services GSM/UMTS que nous considrons dans cette tude est principalement bas
sur la transmission vocale. Dans cette section, deux approches pour modliser la source de trafic
tlphonie mobile sont tudies : le modle des sources individuelles et le modle agrg. Ces
deux approches sont bases sur le modle le plus populaire pour la modlisation de services
orients voix le modle ON/OFF [BRA 69].
25
Le modle ON/OFF est le modle de trafic le plus largement utilis pour caractriser une source
de voix. Il utilise un processus stochastique dune chane de Markov tat discret qui permet de
dcrire la source sens unique pour un appel. Cette chane de Markov est base sur deux tats
(ou priodes) : ltat ON, reprsentant les temps de parole et ltat OFF correspondant aux
silences. Les temps passs dans les tats ON et OFF suivent une loi exponentielle dcroissante de
moyenne respective 1 / et 1 / . Les cellules ou les paquets sont gnrs un dbit constant
gal R uniquement pendant les priodes ON.
1/ = 352 ms
ON ON

ON OFF

OFF OFF
1/ = 650 ms T
Figure II-9 : Modle ON/OFF.
Le modle ON/OFF montr dans la Figure II-9 est caractris par les paramtres suivants :
Priode moyenne pour les tats ON et OFF (1 / , 1 / ) [HAB 92]
1 / = 352 ms ; 1 / = 650 ms
Taux darrive des paquets pendant les priodes ON (1/T) ; taille constante du paquet (L) et
dbit correspondant durant la priode ON (R). Cependant, les valeurs de ces trois paramtres
dpendent du rseau tudier. Dans cette tude, nous supposons une configuration suivante
(elle est dtaille dans le chapitre IV)
1/T = 50 paquets/s ; L = 40 octets ; R = (1/T) * L = 16 Kbps
De plus, concernant le modle de trafic de tlphonie mobile, durant la conversation, pour coder
le bruit de fond (appel aussi le bruit de confort) et le reconstituer du ct rcepteur sans que
l'utilisateur saperoive dune coupure, un paquet est transmis toutes les 480 ms de la priode
OFF [3GPP TS 26 103].
Pour modliser plusieurs connexions phonie ouvertes/fermes (selon un nombre dutilisateurs), la

technique retenue consiste utiliser une agrgation de sources ON/OFF. Dans un premier temps,
nous nous intressons sur les caractristiques dun modle N-sources ON/OFF. Nous appelons
26
priode active le moment o une connexion est ouverte et priode idle le moment o elle
est ferme. Dans le modle N-sources ON/OFF montr par la Figure II-10, deux paramtres
supplmentaires sont ajouts [GRE 02].
Le temps darrive pour une connexion vocale : ce paramtre suit une loi exponentielle
dcroissante de moyenne 1/ (30 minutes).
La dure moyenne de la connexion : ce paramtre suit une loi exponentielle dcroissante de

moyenne 1/ (3 minutes).
X : Nombre dutilisateurs
1/ = 30 minutes 1/ = 352 ms

IDLE ACTIVE ON OFF

1/ = 3 minutes 1/ = 650 ms
Figure II-10 : Modle N-sources ON/OFF.
Avec ce modle, nous modlisons ensuite, laide du logiciel OPNET Modeler, un gnrateur de
trafic (voir lAnnexe E.2.1 pour plus de dtails). Le trafic gnr (30 Erlang) et ses caractristiques
sont montrs dans la Figure II-11. La courbe (a) enregistre le nombre paquets gnr toutes les
20ms, sa densit de probabilit cumule est montre dans (b). Nous nous intressons galement
au nombre de chanes actives chaque moment (c). Le trafic obtenu reprsente donc 25% en
moyenne de charge (d) pour la capacit disponible sur le canal (une bande passante de 1Mbps).
27
(a) : Trace (toutes les 20ms). (b) : Densit de probabilit cumule.
(d) : Taux de charge du lien satellite (une bande

(c) : Nombre de chanes actives.
passante de 1 Mbps).
Figure II-11 : Trafic gnr - N-sources ON/OFF.
Cependant, ce gnrateur de trafic avec N-sources ON/OFF est un modle trs lourd (surtout pour
une simulation avec un nombre important davions). Pour avoir une meilleure efficacit, nous
dcrivons dans un second temps le modle agrg. Ce modle reprsente lactivit associe une
superposition de sources unitaires, le but est de trouver une approximation pour les sources
multiples en respectant un bon compromis entre la prcision et l'efficacit.
Plusieurs mthodes ont t proposes pour dcrire analytiquement lagrgation de trafic ON/OFF
[HEF 86] [HAS 06]. La seule base inchange dans ces divers travaux est que lagrgation de flux
28
ON/OFF peut tre reprsente par le flux MMPP (Markov Modulated Poisson Process). Ce modle
MMPP, qui est une extension du modle ON/OFF, repose sur une chane de Markov N tats
(N>2).
N (N-1)
0 1 2 N-1 N
2 N
1 2 N 1 N

Figure II-12 : Processus de Poisson Modul par une chane de Markov (MMPP).
La chane de Markov montre dans la Figure II-12 peut tre dfinie en temps continu ou en temps
discret. Pour le modle en temps continu, un tat correspond un nombre de sources l'tat ON
(pour le modle ON/OFF classique, cela correspond un dbit car les paquets sont gnrs un
dbit constant et uniquement pendant les priodes ON). A temps discret, cest le nombre de
paquets qui est reprsent par un tat de la chane de Markov. Dans notre cas, puisque les
paquets ne sont pas seulement gnrs durant les priodes ON mais aussi pendant les priodes
OFF pour coder le bruit de confort, le modle MMPP en temps discret est plus appropri dans ce
contexte et est retenu pour modliser lagrgation de flux tlphonie mobile.
La modlisation repose sur le trafic obtenu par le gnrateur N-sources ON/OFF (a dans la Figure
II-11), nous prenons un cycle dchantillons de 10 heures de cette trace, ceux-ci enregistrent le
nombre de paquets gnrs toutes les 20ms. Ensuite, nous utilisons un programme crit en
langage C pour analyser ces chantillons et dfinir une matrice des probabilits de transition.
Cette matrice X par Y prcise chacune des intersections la probabilit davoir Y un instant,
lorsque linstant prcdent il y en avait X. Le nombre dchantillons utiliss pour dfinir les
valeurs de cette matrice est suffisamment important pour que la matrice obtenue soit
reprsentative (1.62x106 donnes sont analyses hors de priode de dmarrage). Un exemple de
cette matrice est montr par la Figure II-13. Elle fait apparatre :
Les probabilits de transitions ascendantes

Les probabilits de transitions descendantes
Les probabilits de non transition
29
Nombre de
0 1 2 3 4 5 6 7 8 9
paquet
0 0.83 0.16 0.01 0 0 0 0 0 0 0
1 0.08 0.78 0.13 0.01 0 0 0 0 0 0
2 0.01 0.15 0.72 0.12 0.01 0 0 0 0 0
3 0 0.02 0.21 0.66 0.1 0.01 0 0 0 0
4 0 0 0.04 0.25 0.61 0.09 0.01 0 0 0
5 0 0 0.01 0.06 0.28 0.56 0.08 0.01 0 0
6 0 0 0 0.01 0.08 0.31 0.52 0.08 0.01 0
7 0 0 0 0 0.01 0.1 0.35 0.47 0.07 0.01
8 0 0 0 0 0 0.05 0.13 0.34 0.42 0.05
9 0 0 0 0 0 0 0 0.2 0.6 0.2
Figure II-13 : Exemple de la matrice des probabilits de transition.
Puis en utilisant cette matrice de transition, une source agrge est enfin modlise pour gnrer
le flux de tlphonie mobile (dtaille dans lAnnexe E.2.2). La courbe (a) de la Figure II-14
prsente lvolution du nombre de paquets gnrs toutes les 20ms. La densit de probabilit
cumule de cette trace ainsi que le taux moyen dutilisation du lien satellite (1Mbps) sont
montres dans (b et d). En comparant avec les courbes b et d, nous remarquons que cette
source MMPP reprsente une bonne approximation du trafic obtenu par les N-sources ON/OFF.
(a) : Trace de la source MMPP. (b) : Densit de probabilit cumule.
30
(d) : Taux de charge du lien satellite (une bande (1) : Courbes dautocorrlation de la source N-
passante de 1 Mbps). ON/OFF et la source MMPP.
Figure II-14 : Trafic gnr - source MMPP.
Nous avons tudi galement la proprit dauto-similarit de ces deux sources diffrentes (1
dans la Figure II-14). Les courbes dautocorrlation font apparatre une dcroissance polynomiale
qui rvle une dpendance long terme pour le trafic gnr par les N-sources ON/OFF ; et une
dcroissance exponentielle qui signifie une dpendance court terme pour la source agrge
MMPP. Cependant, cette diffrence nimpacte pas significativement les performances du systme
(la charge moyenne gnre par les deux modles reste la mme), nous choisissons donc le
modle plus efficace en terme de simulation (MMPP) pour modliser la source de trafic
tlphonie mobile.
II.3.3 Source de trafic Internet embarqu
Comme prcis dans la partie II.2.2, lusage des services cabine pour les passagers dpend de
plusieurs considrations et hypothses. De plus, il ny a pas de modle simple et immdiat pour
anticiper lvolution du trafic bord. Dans cette tude, au lieu de crer un modle sophistiqu qui
prend en compte toutes les hypothses, nous proposons dutiliser un ensemble de sources
gloutonnes ( greedy ) reprsentant un trafic lastique qui sadapte dynamiquement la
capacit disponible. Ces sources sont reprsentes par plusieurs connexions TCP greedy . Pour
chaque connexion, tout moment, la quantit de paquets envoys par un metteur sans avoir
t acquitts est gale la taille de sa fentre de congestion (cwnd : congestion window). Les
31
caractristiques de chaque connexion TCP correspondent une version Reno [RFC 2581] du
protocole couramment utilis dans lInternet actuel. Reno est principalement bas sur trois
algorithmes suivants :
Algorithme de dmarrage lent - Slow-Start (SS)
Algorithme d'vitement de congestion - Congestion Avoidance (CA)
Algorithme de retransmission rapide et de rcupration rapide - Fast Retransmit and Fast

Recovery (FR-FR)
Le SS fonctionne soit au dbut de la connexion ou aprs l'expiration du dlai de retransmission

(RTO : Retransmission Time Out), en effectuant un accroissement exponentiel de la fentre de
congestion (cwnd) pour chaque segment acquitt. Ensuite, lorsque cwnd atteint un certain seuil
connu sous le nom ssthresh (slow-start threshold) ou aprs la phase FR-FR, TCP passe la phase
CA. Lalgorithme CA permet un sondage plus prudent que SS sur la capacit disponible en
augmentant linairement la taille de la fentre de congestion.
La perte de segment est gre par TCP en utilisant un mcanisme de temporisateur de

retransmission RTO. Si, l'expiration du RTO, l'metteur n'a pas reu ACK pour un segment
pralablement mis, TCP retransmet le segment perdu, ferme la fentre 1 segment et
recommence avec SS. RTO est calcul, l'aide d'un algorithme [RFC 2988] [JAC 88], en fonction du
dlai aller-retour mesur (RTT : Round Trip Time) i.e. la dure aller retour entre un metteur et un
rcepteur. Si la perte est dtecte par des acquittements (ACK) dupliqus (normalement 3), la
fentre de congestion de divise par 2, TCP retransmet le segment perdu et essaie de renvoyer
des autres paquets perdus appartenant la mme fentre de congestion (FR-FR), CA est donc
dclench.
La source de trafic TCP greedy est modlise laide du logiciel de simulation OPNET Modeler
(dtaille dans Annexe E.3). Le trafic gnr par cette source dpend fortement de la politique de
gestion de ressource satellite. Nous montrons ici (Figure II-15) le fonctionnement de la couche
TCP. La courbe (a) montre la fentre de congestion pour une connexion normale (aucune perte)
du TCP Reno, la taille de cette fentre est exprime en octets. La relation entre le RTT mesur, le
RTT liss et le RTO est prsente dans (b). Nous nous intressons galement deux types de
phnomnes de perte. Le premier type est une perte isole, cest--dire que la perte est
provoque dun seul paquet. Dans ce cas (c), grce aux ACK dupliqus, la perte est dtecte, la
32
fentre de congestion est divise par 2 et TCP retransmet le segment perdu et essaie de renvoyer
les autres paquets perdus appartenant la mme fentre de congestion (FR-FR). CA est donc
dclench. Le deuxime type de perte concerne la coupure du lien (d), la cwnd est ramene sa
valeur initiale (1 segment) et TCP se remet en mode SS. Le comportement (la taille cwnd et les
numros de squence reus par le rcepteur) de plusieurs connexions TCP greedy (5 dans cet
exemple) est montr dans (e).
(a) : Fentre de congestion (cas normal). (b) : RTT mesur, RTT liss et RTO (seconde).
(c) : Fentre de congestion (perte isole). (d) : Fentre de congestion (une seconde coupure).
33
(e) : Fentres de congestion (5 connexions) (f) : Les numros de squence reus (octet).
Figure II-15 : Comportement TCP Reno - source TCP greedy.
34
Chapitre III
III. RESEAU DACCES PAR SATELLITE
Dans le chapitre prcdent, nous avons prsent plusieurs services cockpit ou cabine ainsi que
leurs exigences en termes de performances. Le systme de communication par satellite retenu
doit rpondre ces besoins en performances. Nous nous intressons donc dans ce chapitre la
partie rseau daccs par satellite pour notre systme. Tout dabord, nous prsentons lestimation
des ressources radiolectriques disponibles pour les services bord. Ces ressources dpendent de
lattribution de frquences, de l'efficacit spectrale de la modulation et du codage utilis. Ensuite,
un aperu des diffrents types dattnuations est expos et un panorama des techniques pour
compenser ces affaiblissements est prsent. Enfin, une architecture daccs satellite, dit de
rfrence, est propose dans le cadre de ltude et ses proprits de couche physique sont
dtailles.
III.1 Ressources radiolectriques
III.1.1 Justification de lutilisation de la bande Ka
Lallocation des frquences radiolectriques est gre par lITU (International Telecommunication
Union), plus prcisment par le secteur des radiocommunications (ITU-R) dans larticle 5 du
Rglement des Radiocommunications. Cet article est rvis aprs chaque confrence mondiale
des radiocommunications (WRC : World Radiocommunication Conference). La dernire mise
jour de larticle 5 a eu lieu lors de la confrence WRC en 2007 [ITU-A5 07].
Les bandes de frquences sont attribues pour les diffrents services daprs la division du monde
en trois rgions gographiques. Dans cette tude, nous nous concentrons sur lallocation des
frquences pour les services MSS et FSS :
35
Chapitre III - Rseau dAccs par Satellite
Service MSS (Mobile Satellite Service) est un service de radiocommunication entre des
stations terriennes mobiles et le satellite. Le service AMSS que nous avons prsents
prcdemment appartient cette catgorie, dans ce cas, les stations terriennes mobiles sont
installes bord davions.
Service FSS (Fixed Satellite Service) se rfre un service par satellite, qui utilise les stations
terriennes fixes.
Dans notre contexte, User link (entre lavion et le satellite) correspond aux services MSS
(AMSS) et Feeder link (entre la Gateway et le satellite) aux services FSS. Par ailleurs, pour les
services MSS ou FSS, lallocation des frquences diffre selon le sens de liaison : la liaison
montante (Earth-to-space) reprsente la voie vers le satellite et la liaison descendante (space-to-
Earth) la voie depuis le satellite.
Une illustration du scnario de rfrence de cette tude (intgrant tous les termes gnraux
mentionns prcdemment) est donne par la Figure III-1.
Lien montant (Earth-to-space)
Lien descendant (space-to-Earth)
User link
(MSS/AMSS) Feeder link
(FSS)
Earth Station (mobile)
Earth Station (fixed)
Figure III-1 : Scnario de rfrence (cas gnral).
Les bandes de frquence alloues (zone europenne) [ITU-A5 07] sont rsumes et montres
dans le Tableau III-1 :
36
FSS (Fixed Satellite Service) MSS (Mobile Satellite Service)

Bande
Lien montant Lien descendant Lien montant Lien descendant
1518-1559 MHz
1610-1660,5 MHz
L (1613.8-1626.5)*
1668-1675 MHz
allocation secondaire
2170-2200 MHz
S 1980-2010 MHz
2483-2500 MHz
3400-4200 MHz
5150-5250 MHz
C 4500-4800 MHz
5850-7075 MHz
6700-7075 MHz
12.75-13.25 GHz
10.7 -11.7 GHz
13.75-14.8 GHz (14,0-14,5 GHz)*
Ku 12.5-12.75 GHz
15.43-15.63 GHz allocation secondaire
17.7-18.1 GHz
17.3-18.1 GHz
18.1-18.4 GHz (29.5-29.9 GHz)* (19,7-20,1 GHz)*

Ka 19.3-19.7 GHz 18.1-21.2 GHz allocation secondaire allocation secondaire
27.5-31 GHz 29.9-31 GHz 20.1 -21.2 GHz
Tableau III-1 : Bandes de frquence disponibles pour les services AMSS (Zone europenne).
Bande L (1-2 GHz) : bande utilise actuellement par le systme INMARSAT pour les services
mobiles aronautiques par satellite (AMSS). Le dbit maximum fourni est gale 10,5
Kbps/canal pour les services aronautiques classiques et 492 Kbps pour les services
SwiftBroadband. Comme les bandes S (2-4 GHz) et C (4-8 GHz), lutilisation de la bande L sur la
zone Europe a dj atteint la limite (saturation) pour introduire des nouveaux services.
Bande Ku (12-18 GHz) : bande qui est principalement employe pour la radiodiffusion par
satellite (BSS : Broadcasting Satellite Service), elle est aussi utilise actuellement pour les
systmes d'accs Internet par satellite. Un exemple dapplication de la bande Ku dans le
domaine aronautique est le systme Connexion By Boeing ddi aux services pour les
passagers. Cependant, dans cette bande, seulement 500MHz (en allocation secondaire) sont
attribus au lien montant pour les services MSS. Labsence d'allocation sur le lien descendant
pourrait tre un problme en ce qui concerne la durabilit du service.
Bande Ka (26-40 GHz) : le dploiement de la bande Ka pour les communications aronautique

par satellite est lhypothse retenue dans notre tude. Cette bande dispose dune large bande
passante attribue en allocation primaire aux services MSS (AMSS). De plus, par rapport la
bande Ku, elle permet lutilisation dantennes plus petites pour un mme dbit ou bien,
taille quivalente, un dbit plus lev. Cependant, les signaux de cette bande sont beaucoup
plus sensibles lattnuation atmosphrique et principalement, la pluie. La priode o
37
lattnuation rend la bande de frquence inutilisable pour la transmission est appele

outage (coupure), cet impact des conditions de propagation peut conduire la rduction
de la disponibilit des services de communication lis cette bande.
III.1.2 Propagation en bande Ka
Comme vu prcdemment, avec lutilisation de la bande de frquences Ka, les phnomnes

atmosphriques, lis la propagation des ondes, deviennent trs importantes et limitent
fortement les performances du systme. Ces attnuations, contribuant fortement la
dgradation des signaux satellitaires en bande Ka, sont provoques par les gaz atmosphriques,
les nuages et les prcipitations. La pluie est le phnomne daffaiblissement dominant dans les
bandes de frquence suprieure 10 GHz (ex : Ku, Ka) provoquant des diminutions importantes
de la qualit du signal. La Figure III-2 montre un exemple de sries temporelles dattnuation par
la pluie en bande Ka (mesures pour un point fixe au sol).
Attnuation (dB)
30
25
20
15
10
0 1000 2000 3000 4000 5000 6000 7000 8000

Temps (seconde)
Figure III-2 : Exemple de srie temporelle dattnuation par la pluie en bande Ka.
38
Lattnuation par la pluie est variable dans le temps et dpend fortement de la position de station
terrienne. Pour prdire cet effet, un modle statistique recommand par lITU [ITU-R P.618] peut
tre utilis. Dans ce modle, lattnuation induite par les prcipitations pour une station fixe au
sol est estime en fonction du pourcentage du temps (ex : 0,1% du temps) selon les zones
climatiques par la pluie. Une application de cette mthode de prdiction est dtaille dans le
Tableau III-2. Nous avons choisi plusieurs positions de stations, parmi lesquelles Cap Nordkinn,
Pointe de Tarifa, Cap de la Roca et Oural reprsentent les quatre points extrmes pour la zone
gographique de lEurope et Bari reprsente la position o il y a le plus fort taux de prcipitation
dans la zone climatiques de lEurope [ITU-R P.837] [CAS 03]. Les rsultats montrent que Bari
reprsente le pire cas en Europe : la perte en puissance cause des prcipitations dpasse 17.18
dB pendant 0.1% du temps sur une anne moyenne.
Cap Pointe de Cap de la

Rain attenuation Oural Bari
Nordkinn Tarifa Roca
Earth station latitude (N : +, S : -) 71.08 36.00 38.78 67.60 41.13

Elevation angle () 9.78 43.85 39.42 3.93 42.36
Frequency(GHz) 29.70 29.70 29.70 29.70 29.70
Rainfall rate 0,01(mm/hour) 30.00 42.00 42.00 22.00 60.00
hs: Height above mean sea level (km) 0.20 0.20 0.20 0.20 0.20
hR: Effective rain height (km) 1.39 4.03 3.82 1.66 3.64
Ls: Slant-path length (km) 7.03 5.52 5.70 21.23 5.11
LG: Horizontal projection (km) 6.93 3.98 4.40 21.18 3.77
L0 22.32 18.64 18.64 25.16 14.23
Reduction factor 0.76 0.82 0.81 0.54 0.79
Specific attenuation (V) (dB/km) 5.00 7.00 7.00 3.50 10.00
Specific attenuation (H) (dB/km) 6.00 8.50 8.50 4.30 12.40
Specific attenuation (Mean) (dB/km) 5.50 7.75 7.75 3.90 11.20
Rain Attenuation 0,01 (dB) 29.50 35.26 35.71 44.96 45.20
Rain Attenuation 0,1 (dB) 11.21 13.40 13.57 17.09 17.18
Tableau III-2 : Calcul de lattnuation par la pluie selon lITU-R P.618 (bande Ka).
Nanmoins, les prdictions montres dans le Tableau III-2 sappliquent des points de mesure
fixes au sol. Dans le contexte de communications aronautiques, laltitude et le mouvement de
l'avion doivent tre pris en compte. Dans la recommandation [ITU-R P.682] pour les propagations
39
terre-espace de systme AMSS, lattnuation par la pluie pour un terminal avion (toujours sur un
point fixe) est statiquement estime la base du modle [ITU-R P.618] montr prcdemment.
Dans certaines phases de vol o laltitude de lavion est suprieure laltitude maximum pour la
pluie (5 Km), lattnuation par la pluie est videmment nulle sur la liaison user link (ex :
domaines ENR et ORP). De plus, sachant que les cellules de pluie ont un diamtre moyen de
quelques kilomtres, loccurrence de la perte maximale pour un avion sera moindre que pour un
terminal fixe. Pourtant, il nexiste pas un modle statistique aronautique pour prdire
lattnuation dun terminal avion, car il dpend des plusieurs facteurs (phase de vol, trajectoire,
etc.) qui sont des configurations individuelles. Dans cette tude, le pire cas dutilisation de
systme est toujours bas sur le point fixe au sol. Dans le cas rel, la disponibilit du systme sera
trs certainement plus leve.
III.1.3 Techniques de compensation des affaiblissements
Comme montr dans la section prcdente, la bande Ka souffre dune dgradation du signal
cause de sa forte sensibilit aux phnomnes atmosphriques. Cette dgradation limite
fortement les performances (ex : disponibilit) des services de communications par satellite.
Habituellement, une marge fixe est introduite dans le bilan de liaison pour reprsenter le pire cas
d'utilisation du systme. Lide de cette mthode est de dimensionner le systme dune faon
statique et pessimiste pour une disponibilit requise par anticipation de la dgradation maximum.
De fait, cette mthode nest plus applicable pour les bandes Ku/Ka ou suprieures car les
attnuations peuvent atteindre des valeurs bien plus importantes. Par exemple : une marge fixe
de 5 dB est ncessaire en bande Ku et 17 dB en bande Ka pour assurer une disponibilit de 99.9%
du temps (point de mesure fixe au sol : Bari) [ITU-R P.618]. Dun point de vue conomique, un
dimensionnement de systme bas sur le bilan de liaison pire cas avec une grande marge statique
conduit une forte perte de performances, il en rsulte un gaspillage de la ressource.
Afin dquilibrer la fois la disponibilit ainsi que les performances du systme de communication
par satellite, des techniques FMT (Fade Mitigation Techniques) sont appliques. Ce sont des
techniques de compensation des affaiblissements qui permettent dadapter en temps rel la
couche physique du systme ltat dynamique du canal de propagation [CAS 03]. Grce
lutilisation des FMTs, le dimensionnement nominal du systme peut tre configur en prenant en
compte la meilleure condition de propagation (ciel clair) puis la disponibilit du systme est
garantie en temps rel dans les diffrents cas de propagation en modifiant les paramtres de la
40
couche physique. Cependant, avec le dploiement des FMTs, une caractrisation plus approfondie
de la dynamique du canal est ncessaire et un systme adaptatif doit tre dfini pour prendre en
compte ces effets dynamiques.
Il existe trois catgories de techniques FMT : le contrle de puissance, ladaptation de la forme

donde et la diversit [PAN 04] [CHA 04].
III.1.3.1 Contrle de puissance
Le principe du contrle de puissance (PC : Power Control) consiste adapter le niveau de

puissance de transmission aux conditions de propagation. Il peut tre raffin en 3 types :
Contrle de puissance de la liaison montante (ULPC : Up Link Power Control) : consiste

rgler la puissance mise par lmetteur. Dans le cas de lutilisation de satellite transparent,
lULPC permet de compenser des affaiblissements la fois pour la liaison montante et
descendante.
Contrle de puissance de la liaison descendante (DLPC : Down Link Power Control) : est
ralis par lajustement de la puissance du satellite. Cependant, cette mthode est trs
difficile mettre en uvre cause des contraintes de la charge utile satellite. De plus, par
rapport lULPC, elle introduit une plus haut niveau dinterfrence dans le bilan de liaison
[CAS 03].
Mise en forme de faisceau troit (SBS : Spot Beam Shaping) : utilise une antenne active et
permet dadapter le gain de faisceau aux conditions de propagation. Comme le DLPC,
linterfrence introduite par le SBS est relativement grande.
III.1.3.2 Adaptation de la forme donde
Cette technique consiste faire varier les paramtres de transmission comme la modulation (AM :
Adaptive Modulation) ; le codage de canal (AC : Adaptive Coding) et le dbit utile dinformation
(DRA : Dynamic Rate Adaptation) afin de sadapter aux conditions de propagation.
Pour lAC et lAM, il existe un compromis entre lefficacit spectrale et lefficacit de puissance.
Les modes plus spectralement efficaces sont utiliss dans les meilleures conditions de
propagation. Dans ce cas, le rapport signal sur bruit (SNR) est relativement grand et permet ces
modes de fonctionner efficacement en assurant le taux derreur binaire requis (BER : Bit Error
41
Rate). Les modes moins spectralement efficaces (mais plus efficaces en puissance et permettant
dassurer le BER avec un faible SNR) sont appliqus quand il y a dgradation du signal.
Le DRA permet de garder le BER constant en modifiant le dbit symbole de transmission : le dbit
nominal est utilis en condition de ciel clair tandis que le dbit est rduit selon le niveau
dattnuation. Cependant, cette technique nest satisfaisante que pour les services qui sont
tolrants aux rductions signifiantes de dbit.
III.1.3.3 Diversit
Le principe de la technique de diversit est dviter les affaiblissements par la redirection des
transmissions. Elle consiste en lutilisation des ressources qui sont dans les conditions de
propagation plus favorables. Cependant, la diversit est une technique coteuse parce que la
redondance dquipements est indispensable. Il existe 4 types de technique diversit :
Diversit de site : consiste diriger la liaison vers une autre station quand la liaison par dfaut
souffre dun fort affaiblissement. En gnral, la distance entre cette station alternative et la
station par dfaut doit tre plus large une cellule pluie de convective (gnralement
quelques dizaines de kilomtres de distance).
Diversit en frquence : permet de changer la frquence par dfaut contre une frquence
plus basse moins sensible aux attnuations si cette dernire est disponible. Cependant, cette
mthode introduit des complexits supplmentaires dans la gestion de ressources ainsi dans
le fonctionnement de composants du rseau.
Diversit satellite : consiste rediriger la transmission vers un autre satellite lorsque la liaison
par dfaut est dgrade par une forte attnuation. La diversit satellite est plutt pertinente
pour une constellation LEO. Dans le cas dune communication par GEO, les perturbations
atmosphriques pour lensemble des satellites est la mme et le gain introduit par cette
mthode est faible.
Diversit dans le temps : permet de retransmettre des donnes lorsque les conditions de
propagation deviennent favorables. Cette solution nest applicable que pour les services qui
supportent un grand dlai de transmission et des coupures du lien ; pour les services
temporels ou orients connexion, cette mthode nest donc pas acceptable.
42
En gnral, lutilisation dune seule technique FMT ne suffit pas pour fournir une grande
disponibilit du systme en bande Ka. Une combinaison de diffrentes FMTs sera plus approprie
dans ce contexte. Dans notre tude pour les communications aronautiques par satellite (plus
particulirement pour le user link ), en tenant compte la fois la faisabilit technique et le cot
de dploiement, les FMTs les plus adquates sont lULPC et ladaptation de la forme donde.
III.2 Accs satellite : DVB-S2/DVB-RCS
III.2.1 Normes pour les accs satellite haut dbit
Normes ETSI (European Telecommunications Standards Institute) : famille DVB
Le projet DVB (Digital Video Broadcasting) a t introduit en 1993. Lobjectif est de crer une
plateforme europenne commune pour toutes les spcifications et les normes pour la diffusion
de tlvision numrique. Le systme DVB permet de transmettre des donnes en utilisant
plusieurs supports de diffusion : cble (C) ; satellite (S) ; transmission terrestre (T) ou son
adaptation pour les rcepteurs portables (H). Les normes correspondantes dfinissent les
spcifications des niveaux liaison de donnes et physique du systme diffusion. Dans cette tude,
nous nous intressons au type de diffusion par satellite.
La norme DVB-S [ETSI 300 421] est un standard ouvert dont la premire version a t ratifie en
1994. Elle est conue pour les services unidirectionnels dans les bandes attribues (en primaire ou
secondaire) pour les services FSS ou BSS. Le systme DVB-S utilise une modulation sur 4 phases
(QPSK : Quadrature Phase Shift Keying) et une correction d'erreur directe "Convolutional / Reed-
Solomon" qui permettent davoir une transmission efficace faible rapport signal bruit.
La norme DVB-S a ensuite volu vers une solution bidirectionnelle pour satisfaire la demande
croissante en services interactifs. La norme DVB-RCS (Return Channel via Satellite) [ETSI 301 790]
a donc t approuve en 2000 dans ce contexte. Le but est de fournir un canal de retour pour
interagir avec le systme DVB-S. La modulation utilise dans DVB-RCS est identique au DVB-
S (QPSK). De plus, DVB-RCS dispose de deux schmas de codage - Turbo codes et une
concatnation de codes "Convolutional / Reed-Solomon" - qui permettent lutilisation de
technique AC (Adaptive Coding). Cependant, la marge maximum fournie (~4 dB) par ladaptation
de taux de codage ne suffit pas de compenser les dgradations rencontres en bande Ka. Une
43
combinaison avec dautres mthodes FMT (ex : AM, DRA, etc.) permet de concevoir un systme
adaptatif plus performant. Mme si la norme DVB-RCS est destine aux services fixes par satellite,
elle peut tre tendue pour lapplication mobile pour les MSS [ETSI 101 790]. Cette extension
mobile a commenc tre normalise comme une option et sera introduite dans la prochaine
version DVB-RCS (une version prliminaire a t publie dbut 2009 [ETSI 301 790]).
La deuxime gnration de la norme DVB-S [ETSI 302 307] a t dveloppe en 2003. Elle
reprsente une amlioration : meilleure performance de transmission, plus de souplesse et une
complexit moindre du rcepteur. Cette amlioration est obtenue grce aux technologies plus
rcentes en modulation (QPSK, 8PSK, 16PSK, 32PSK) et codage canal (codes LDPC : Low Density
Parity Check et BCH : Bose Chaudhuri Hocquenghem) qui permettent une gestion puissante de la
correction derreur (FEC : Forward Error Correction). De plus, le systme DVB-S2 profite de
lutilisation de modulation et codage adaptatif (ACM) dans le cas interactif (ex : accs Internet).
Cette technique FMT permet doptimiser les paramtres de transmission en fonction des
conditions de propagation par une boucle de contrle ferme en utilisant le lien retour satellitaire
(ex : DVB-RCS) ou terrestre. Comme prsent dans la partie III.1.3, lutilisation des FMTs permet
de reprendre la marge dite de ciel clair, qui est gnralement gaspille dans les liaisons
satellites en modulation et codage constant (CCM : Constant Coding and Modulation).
La norme TIA (Telecommunications Industry Association) : IPoS
La norme IP sur satellite [TIA-1008] (Internet Protocol over Satellite : IPoS par la suite) est
initialement publie par TIA en 2003 et cette version a t co-publie par l'ETSI dans [ETSI TS 102
354]. IPoS est une norme optimise pour fournir des services large bande par satellite. Le
systme IPoS permet doffrir des services IP "toujours activ" (always on) par satellites
gostationnaires aux utilisateurs rsidentiels et les SOHO (Small Office/Home Office). Ces services
IP peuvent tre des services TCP/IP typiques ou IP multicast valeur ajoute (ex : e-learning). Le
terminal IPoS pour le lien retour utilise une modulation OQPSK (Offset Quadrature Phase-Shift
Keying). Comme le DVB-RCS, la norme IPoS est compatible avec le lien aller qui est bas sur le
DVB-S2.
Autres systmes : DOCSIS-S
La spcification DOCSIS (Data Over Cable Service Interface Specification) est une norme
internationale qui dfinit les conditions d'interface de communications et de soutien d'opration
44
pour un systme de donnes utilisant le systme de tlvision par cble. La premire version de la
norme DOCSIS est publie en 1997 et la troisime version a t introduite en 2006 avec
laugmentation significative du dbit de transmission et le support IPv6. La norme DOCSIS-S est
une mise en uvre de la norme ouverte DOCSIS dans le contexte satellite. En gnral, les couches
protocolaires hautes sont compatibles avec le DOCSIS. La couche physique est base sur les
spcifications satellite. Toutefois, dans le contexte satellite, certaines adaptations doivent tre
spcifiquement prises en compte ; pour les canaux satellite, la bande passante est gnralement
plus faible, le taux d'erreur de transmission est plus lev et le dlai de transmission est plus long
par rapport aux cbles.
Dans [SKI 05], une synthse des comparaisons entre DVB-RCS, IPoS et DOCSIS-S est fournie. Les
comparaisons sont bases sur diffrents critres et sont montres par le Tableau III-3 :
45
Comparaison DVB-S2/DVB-RCS DVB-S2/IPoS DOCSIS-S
Aller : 50/ (108) Mbps

Dbit Maximum Aller : 100 Mbps + Aller : 100 Mbps +
Retour : 1203/ (2046)
Typique Retour : 2 Mbps Retour : 2 Mbps
Kbps
Aller :
Aller : Aller :
Flux MPEG-TS
MPEG-TS ou GS MPEG-TS ou GS
Format des bursts Retour :
Retour : Retour :
Trame Ethernet & En-
ATM ou MPEG Bursts variables
tte
Aller :
QPSK/8PSK/16APSK/32APS Aller :
Aller :
K 8PSK : Turbo code 1/2,
QPSK/8PSK/16APSK/32AP
Plusieurs types de codage (3/4), 5/6, (8/9)
SK
Retour : QPSK : Turbo code 1/2
Mode Plusieurs types de codage
QPSK, (5/8), (3/4), (7/8) ou
(Modulation & Retour :
*Extensions possibles code Reed-Solomon
Codage) O-QPSK, Turbo C (1/3, 1/2,
(BPSK, 8PSK) Retour : QPSK : Turbo
2/3, 4/5), code
Turbo C (1/3, 2/5,1/2, 2/3, code 1/2, (3/4) en code
convolutionnel ou code
3/4, 4/5, 6/7), code Reed-Solomon en option
Reed-Solomon
convolutionnel ou code
Reed-Solomon
OUI
OUI
(Adaptation des formats de OUI
Support ACM sur (Adaptation des formats
codage et de modulation) (Adaptation des formats
la voie retour de modulation et de
*Si les extensions : BPSK et de codage)
codage limits)
8PSK sont disponibles
Efficacit de la Aller : +++ Aller : +++ Aller : +

couche physique Retour : ++ Retour : + Retour : +
Efficacit de la
couche MAC sur la ++ ++ +
voie retour
Standard Ouvert Fonctionnement comme

Standard Ouvert
Grande nombre de un Huge Ethernet, une
Avantage Support de multi
terminaux oprationnels seule valeur PID est
fournisseurs
Cot faible ncessaire
Grand en-tte pour la

transmission des petits
Inconvnient Cot plus lev Rserv que pour IP paquets
Pas de standardisation
Seul fournisseur
Tableau III-3 : Comparaison des normes DVB-S2, DVB-RCS, IPoS et DOCSIS-S.
46
Comme montr dans le Tableau III-3, grce sa richesse en modulation et codage qui permet de
supporter parfaitement la technique ACM [ETSI 302 307], DVB-S2 offre de meilleures
performances que les autres sur la voie aller. Pour la voie retour, mme si dans la norme DVB-RCS,
lapplication de lACM nest pas explicitement introduite, aprs le succs de DVB-S2, plusieurs
travaux de recherche ont dj montr lintrt et la faisabilit de mise en oeuvre de lACM dans le
DVB-RCS [BOL 04]. Cette application est base sur le mode actuel (QPSK) qui est introduit dans la
norme et son extension aux modes disponibles (BPSK et 8PSK) ; les taux de codage (Turbo codes)
vont de 1/3 6/7. Les performances de codage et de modulation du DVB-S2/DVB-RCS sont
montres dans lAnnexe B.
III.2.2 Systme de rfrence
Dans le contexte de notre tude de convergence des trafics cockpit/cabine sur la liaison satellite,
la norme DVB-S2 est retenue comme spcification daccs pour la voie aller (de la station
terrestre aux avions : GES AES) et la norme DVB-RCS pour la voie retour (des avions la station
terrestre : AES GES). Bas sur cette approche, un scnario, dit de rfrence, qui prsente le
rseau daccs satellite est montr par la Figure III-3 :
Lien aller : DVB-S2

Lien retour : DVB-RCS
Fe
)
Ka
ed
k(
er
lin
li
nk
er
Us
( K/
Q/
V)
Terminal Satellite
(AES)
Faisceau
Faisceau
Gateway / NCC
Faisceau
(GES)
Faisceau
Figure III-3 : Scnario de rfrence (rseau daccs DVB-S2/DVB-RCS).
47
Conformment ce qui est prsent dans [ETSI 301 790], ce systme de rfrence est constitu
des composants suivants :
Terminal Satellite (ST : Satellite Terminal) : reprsente le systme embarqu dans notre
contexte. Il peut tre assimil lAES dans le contexte du systme AMSS.
Gateway : centralise les trafics dmission DVB-S2 et de rception DVB-RCS. Il permet au

rseau daccs satellite de sinterconnecter avec les rseaux terrestres.
Centre de contrle du rseau (NCC : Network Control Center) : prend en charge la gestion des
ressources satellitaires.
De plus, dans cette tude pour les communications aronautiques, certaines hypothses sont
introduites :
Couverture du satellite : nous supposons dans cette tude un seul satellite gostationnaire
multifaisceaux (multi-spots) capable de fournir une couverture globale pour toute lEurope. Le
dimensionnement des faisceaux satellite et les techniques de mobilit Handover entre
faisceaux ne sont pas tudis dans cette thse.
Satellite transparent : le satellite utilis dans le systme de rfrence est un satellite

gostationnaire transparent (sans traitement bord). Lutilisation de satellite rgnratif peut
tre considre comme une solution damlioration des performances, elle nest pas
considre dans cette tude.
Topologie toile : du fait de lutilisation dun satellite transparent, la topologie du rseau est
relativement simple : le rseau est en toile avec une station terrestre comme concentrateur
(Hub).
Co-localisation du NCC et Gateway : pour simplifier larchitecture du systme, le NCC et la

Gateway sont combins dans une seule station terrienne : GW . Cette unit combine peut
tre galement appele GES dans le contexte AMSS. Dans le systme de rfrence, nous
considrons lutilisation dune seule GW.
Bandes de frquence : nous supposons que le user link opre dans la bande de frquence
Ka ; pour le feeder link plusieurs bandes de frquence qui sont alloues pour les services
FSS sont possibles : Ka, Q (30-50 GHz), V (46-56 GHz), etc.
48
III.2.2.1 Lien aller DVB-S2
Dans le systme de rfrence, le feeder link (lien ascendant DVB-S2) utilise un transpondeur
de services FSS, ce transpondeur est ensuite partag par de nombreux de terminaux sur le lien
descendant DVB-S2. Compte-tenu des contraintes de lantenne sur lavion, le dbit fourni sur le
lien aller est limit (ex : environs 5 - 10 Mbps par transpondeur en bande Ku (EIRP : 48 dBW) [CBB-
1]), mais comme chaque terminal est capable de recevoir plusieurs transpondeurs, ce dbit peut
facilement tre multipli. Puisquune seule GW est considre dans le systme, la mthode
daccs au canal satellite est donc simple : la GW envoie un ou plusieurs multiplex occupant toute
la bande passante du transpondeur vis. Dans le cas de plusieurs GWs, la mthode daccs
sappuie gnralement sur un multiplexage par rpartition en temps (TDM : Time Division
Multiplexing) ou en frquences (FDM : Frquence Division Multiplexing).
Le partage de la ressource du lien aller DVB-S2 entre les STs est bas sur la mthode TDMA (Time
Division Multiple Access) : la GW dcoupe la bande de passante pour plusieurs terminaux par une
division temporelle. Avec lutilisation de lACM, une squence de trames TDM est mise par la GW
dont le type de modulation et de codage (28 combinaisons sont disponibles dans la DVB-S2 avec
un gain maximum de 18.4 dB) peut tre modifi trame par trame afin de sadapter
dynamiquement au canal. La dcision du mode ACM sappuie sur un contrle en boucle ferme
par la voie retour DVB-RCS. Les informations de retour comprennent notamment des mesures de
rapport signal sur bruit et interfrence (CNI : Carrier to Noise and Interference ratio) et le ModCod
(Modulation and Coding) le plus appropri pour le terminal. Selon ces informations, la GW prend
la dcision pour le changement de ModCod avec un mcanisme dhystrsis (pour viter les
basculements excessifs entre deux ModCod adjacents) [RAD 07].
III.2.2.2 Lien retour DVB-RCS
Le lien retour DVB-RCS est plus contraint que le lien aller DVB-S2 en termes de performances. Le
bilan de liaison depuis le mobile vers la station terrienne est impact par la limitation de la taille
dantenne et de la puissance dmission. La bande passante dun rpteur doit tre partage en
plusieurs porteuses sur lesquelles plusieurs terminaux doivent pouvoir mettre. La technique
daccs est donc du type MF-TDMA (Multi Frequency Time Division Multiple Access).
Premirement, un grand nombre de terminaux sont en contention de partage sur le mme canal
retour. Une mthode daccs plus sophistique doit tre utilise pour viter les collisions entre les
49
terminaux. Deuximement, lutilisation des techniques FMT nest pas native pour le lien retour
DVB-RCS (seul le codage adaptatif AC est introduit dans la norme). Comme mentionn
prcdemment, lutilisation dune seule technique FMT ne permet pas de garantir la disponibilit
demande pour les diffrents services en bande Ka (particulirement pour les services ATS/AOC
qui ont de trs fortes exigences de disponibilit). Dans le cadre de cette thse, nous nous
concentrons plus particulirement sur ce lien retour DVB-RCS.
La mthode daccs utilise pour le lien retour DVB-RCS est MF-TDMA (Multi Frequency Time
Division Multiple Access). Cette mthode suppose une rpartition en plusieurs frquences
distinctes, ces canaux frquentiels sont subdiviss en trames ; chaque trame est partage en
intervalles temporels (burst) durant lesquels les terminaux peuvent transmettre des donnes ou
de la signalisation (Figure III-4).
Porteuse 1 Porteuse 2 Porteuse n
CSC CSC ... ... ACQ Frquence
SYNC SYNC ... ... SYNC
TRF TRF ... ... TRF
TRF TRF ... ... TRF
... ... ... ... ... ...

Temps
Figure III-4 : Mthode daccs pour le lien retour DVB-RCS : MF-TDMA.
Il existe deux modes de partage MF-TDMA dans la norme DVB-RCS : MF-TDMA fixe et MF-TDMA
dynamique.
MF-TDMA fixe : la dure et la bande passante des time-slots successifs utilis par un RCST
sont fixes. Plusieurs paramtres sont dfinis dans la table de composition du time-slot (TCT :
Timeslot Composition Table). Au cas o il y a des modifications des paramtres, elles ne
seront appliques que dans la prochaine nouvelle super-trame.
MF-TDMA dynamique : mode plus complexe mais plus flexible. La dure et la bande de
passante des time-slots successifs attribus un RCST peuvent varier au sein dune super-
50
trame. De plus, ce mode permet de changer le dbit de transmission ainsi que le type de
codage dun burst un autre, ce qui donne une plus grande flexibilit dallocation. Dans cette
tude, nous utilisons le mode MF-TDMA dynamique pour mettre en uvre les techniques
FMT.
Dans la norme DVB-RCS, quatre types de bursts sont dfinis :
CSC (Common Signalling Channel) : permet aux STs de sidentifier auprs du centre de
contrle pendant la phase de Logon (premier accs au rseau).
ACQ (ACQuisition) : permet la synchronisation de la couche physique (correction de la

frquence de lmetteur) et la procdure de ranging (mesure fine de la distance mobile
satellite - station terrienne).
SYNC (SYNChronization) : permet de maintenir la synchronisation de la couche daccs et

denvoyer les informations de contrle. Le burst SYNC peut tre utilis en mode
contention .
TRF (TRaFfic) : est utilis pour transporter les donnes du ST au NCC. Les bursts de trafic sont
bass soit sur des cellules ATM (Asynchronous transfer mode), soit sur des paquets MPEG2-TS
(Moving Picture Experts Group 2 - Transport Stream) (voir la partie IV.4.1.2).
III.2.3 Couche physique DVB-RCS
La premire tape pour tudier les caractristiques de la couche physique DVB-RCS du systme
propos consiste dimensionner le cas nominal, cest--dire dterminer la meilleure
performance par porteuse qui permet une marge suffisamment grande pour introduire
lattnuation par la pluie. Pour cela, nous calculons le bilan de liaison ciel clair pour le lien retour
en bande Ka. Cependant, certains paramtres sont inconnus car dpendant des configurations et
des hypothses du systme. Au lieu de nous concentrer sur la prcision du bilan de liaison, nous
nous intressons plus particulirement la conception typique du systme. Les valeurs du bilan
de liaison montr dans lAnnexe C reprsentent donc un cas gnral (les paramtres et leur
valeurs sinspirent principalement de lexemple donn dans le guide ETSI [ETSI 101 790]). Quatre
dbits crtes sont tudis : 128 Kbps, 384 Kbps, 1 Mbps, 2 Mbps. Les rapports nergie sur bruit
(Eb/N0) obtenus et les marges maximum possibles par lACM (Annexe B) sont rsums dans le
Tableau III-4 :
51
Marge maximum
Dbit binaire Eb/N0 obtenu Es/N0 requis Dbit symbole
Mode offerte
(Kbps) (dB) (dB) (Ksps)
(dB)
128 8.4 8PSK 3/4 13.2 14.7 85
384 7.6 8PSK 2/3 11.5 13 256
1024 5.6 8PSK 1/2 8.7 10.2 683
2048 3.7 QPSK 1/2 4.5 6 2048
Tableau III-4 : Eb/N0 obtenus et les marges maximum offertes.
Afin dquilibrer la performance fournie et la marge maximum possible pour lapplication ACM, le
dbit 1 Mbps est retenu dans cette tude comme le mode nominal utilis lors des conditions
idales de propagation. Le mode correspondant est 8PSK avec un dbit symbole de 683 Ksps. Le
mode le plus robuste est BPSK 1/3 avec le dbit symbole rduit 171 Ksps. Les marges offertes
par les diffrentes techniques FMT sont montres dans le Tableau III-5. 10,2 dB est fournie par
lACM en modifiant le format de modulation et le codage du canal ; 6 dB est offert par le DRA en
rduisant le dbit du symbole (divis par 4 : 10log10(4) = 6dB) ; nous supposons galement que 3
dB de marge est possible par laugmentation de la puissance dmission (ULPC). La marge totale
offerte est donc 19,2 dB ; la combinaison des techniques ACM+DRA+ULPC assure une disponibilit
du systme de 99,9% du temps.
Technique FMT Marge offerte (dB)
ULPC 3
ACM 10,2
DRA 6
Total 19,2
Tableau III-5 : Marges offertes par les techniques FMT.
Comme la mthode daccs aux ressources DVB-RCS est base sur le MF-TDMA, la capacit de la
ressource est donc dimensionne pour ce mode. Dans la norme DVB-RCS, deux formats de paquet
peuvent tre utilis comme conteneur de donnes (burst TRF) : ATM et MPEG. Dans cette tude,
nous choisissons dutiliser le MPEG plutt que lATM pour des raisons telles quune meilleure
protection contre les erreurs ou encore une efficacit accrue pour lencapsulation de trafic IP.
Avant de dimensionner la capacit du lien retour, une hypothse sur le choix des modes FMT est
propose. Nous utilisons 5 modes FMT pour adapter le systme aux diffrentes conditions de
propagation : mode 1, 2, 3, 4 sont choisis avec un dbit symbole constant, les diffrentes
52
modulations et codages permettent une mise en uvre de lACM. Lutilisation du dbit symbole
constant signifie que la bande passante dune porteuse est constante. Dans ce cas, la gestion des
modes est relativement simple : le mode dune porteuse peut tre modifi sans aucun
changement du plan de frquences (le DVB-RCS fournit la signalisation adquate pour la
reconfiguration du plan de frquences). Mode 0 est le mode de secours qui utilise une forme
donde plus robuste (BPSK 1/3) avec un dbit symbole rduit. Lide davoir ce mode est dassurer
une grande disponibilit pour les services ATM au cas o il y a une trs forte attnuation. La
synthse de ces 5 modes FMT est montre par le Tableau III-6 :
Mode FMT Modulation / Codage Dbit Symbole Es/N0 Requis Dbit Binaire
0 BPSK 1/3 171 Ksps -1,5 dB 56 Kbps

1 BPSK 1/3 683 Ksps -1,5 dB 228 Kbps
2 QPSK 1/2 683 Ksps 4,5 dB 683 Kbps
3 QPSK 2/3 683 Ksps 6,9 dB 910 Kbps
4 8PSK 1/2 683 Ksps 8,7 dB 1024 Kbps
Tableau III-6 : Modes FMT retenues.
Bas sur les 5 modes FMT retenus et conformment au guide DVB-RCS [ETSI 101 790], nous
tudions ensuite le dimensionnement de la capacit du lien retour DVB-RCS. La structure dune
super-trame MF-TDMA est dfinie de la faon suivante :
Tout dabord, nous dterminons la structure et la dure de transmission dune super-trame pour
chaque mode FMT en supposant que :
Un crneau TRF contient un paquet MPEG (modul et cod) ainsi quun prambule de 48
symboles. Le paquet MPEG peut inclure un champ dadaptation MPEG. Le champ
dadaptation MPEG permet de porter des signalisations SAC (Satellite Access Control) qui sont
gnralement utilises pour les requtes de capacit.
Les crneaux de signalisation (mini-slot : CSC, ACQ et SYNC) sont placs en tte de chaque
trame et occupent la dure dun crneau TRF. Un mini-slot contient un prambule de 48
symboles et 16 octets de donnes.
Le temps de garde correspond une incertitude de 4 Km pour les crneaux TRF et 50 km pour
les mini-slots.
53
Ensuite, nous proposons une seule structure de super-trame pour les 5 modes. Lalignement bas
sur les structures initiales obtenues est donc ncessaire dans ce cas. Nous prenons la valeur
maximale parmi les dures de super-trames initiales et rglons les tailles et le nombre de
crneaux TRF/mini-slot pour chaque mode. La structure dtaille de cette super-trame ajuste est
montre dans le Tableau III-7.
54
Nombre de
Temps de Distance Taille et dure de mini-slot Temps de Distance
Dbit Longueur Longeur Nombre Signalling
Mode Modulation symbole du TRF garde incertitude crneau sig dans un garde incertitude Dure
(mini-slot) de TRF en-tte
FMT et Codage (mini-slot) (mini-slot) (CSC+ACQ+SYNC) crneau (TRF) (TRF)
sig
(Ksps) (symbole) (symbole) (km) (symbole) (ms) (symbole) (symbole) (km) (ms) 100%
0 BPSK 1/3 171 4611 3 5.3 922 5.4 2 461 29 50.8 2 59.32 9.1%
1 BPSK 1/3 683 4928 10 4.4 1096 1.6 2 548 116 50.9 8 59.32 2.7%
2 QPSK 1/2 683 1643 10 4.4 1096 1.6 2 548 116 50.9 24 59.32 2.7%
3 QPSK 2/3 683 1232 10 4.4 1096 1.6 2 548 116 50.9 32 59.32 2.7%
4 8PSK 1/2 683 1095 10 4.4 1096 1.6 2 548 116 50.9 36 59.32 2.7%
Tableau III-7 : Dimensionnement de la super-trame MF-TDMA.
55
Nous supposons quun rpteur dune largeur de bande de 25 MHz est utilis dans notre systme.
Le nombre de porteuses par rpteur est donc
25 MHz / (0.683 *(1+0.35)) MHz 25 porteuses
0.683 Mhz correspond au dbit symbole par porteuse, 0.35 est le facteur de dbordement. La
capacit disponible par rpteur (25 MHz) est
1.024 Mbps x 25 porteuses = 25.6 Mbps
Un exemple de la rpartition MF-TDMA est montr dans la Figure III-5. La super-trame a une
dure fixe de 59,32 ms. Pour chaque mode FMT, le nombre paquets TRF envoys dans la dure
dune super-trame est diffrent des autres modes. Il faut remarquer que la dfinition de 5 modes
FMT ne signifie pas que les 5 modes doivent tre activs en mme temps, le nombre de porteuses
pour chaque mode FMT peut tre modifi dynamiquement suivant les conditions de propagation.
Un cas typique de rpartition est aussi montr dans la Figure III-5 : le terminal obtient un crneau
temporel du mode BPSK 1/3 (171 Ksps) pour le trafic ATS/AOC et trois crneaux temporels du
mode BPSK 1/3 (683 Ksps) pour le trafic GSM ou IP.
Frquence Mini-slot Crneau de trafic

SYNC, CSC, ACQ TRF
36 TRF
4: 8PSK 1/2
36 TRF
32 TRF
3: QPSK 2/3
25 MHz
32 TRF

2: QPSK 1/2
24 TRF
8 TRF
1: BPSK 1/3

0: BPSK 1/3 2 TRF
Dure : 59.32 ms Temps

: Crneau allou au terminal par le NCC (Network Control Center)
Figure III-5 : Exemple de la rpartition MF-TDMA.
57
III.2.4 Qualit de service et DVB-RCS
Le mcanisme principal au niveau daccs avec lequel une architecture de QoS peut tre mise en
uvre est le protocole DAMA (Demand Assigned Multiple Access). Le DAMA propose un accs
aux ressources la demande (BoD : Bandwidth on Demand), qui permet une utilisation plus
efficace en prsence de diffrentes classes de trafic. Il permet aux terminaux STs denvoyer des
demandes de capacits (CR : Capacity Requests) au centre de contrle NCC. Dans ce cas, les
crneaux temporels (TRF) pendant lesquels les donnes peuvent tre transmises sur la voie retour
DVB-RCS peuvent tre rservs par les STs [NIV 06]. Il est noter que dans le systme DVB-RCS,
laccs un crneau TRF est toujours conditionn par lobtention dune rservation, il ny a pas
daccs alatoire comme dans IPoS. Les requtes CR sont calcules en fonction des besoins
ponctuels et rels de chaque ST avec une dfinition de plusieurs classes dallocation de capacit.
Dans la norme DVB-RCS [ETSI 301 790], 4 classes de CR ont t dfinies et permettent de mettre
en uvre de la QoS :
CRA (Continuous Rate Assignment) : permet une allocation dbit constant, c'est--dire que
le nombre de crneaux temporels rservs par un ST dans les trames DVB-RCS est fix. Cette
capacit fixe est alloue de faon permanente durant toute la connexion du ST sans demande
de rservation. Aucune signalisation nest ncessaire et le ST peut utiliser continuellement le
dbit allou. En gnral, cette classe dallocation reprsente une faible proportion de la
capacit totale car elle ne permet pas lutilisation efficace des ressources. Les crneaux
ventuellement non consomms provoquent un gaspillage.
RBDC (Rate Based Dynamic Capacity) : permet une allocation dynamique dbit variable. La
gestion se fait par dbit, ce dbit doit tre mis jour rgulirement (chaque supertrame) par
le terminal afin que le centre de contrleur puisse suivre lvolution de la source de trafic
(unit : multiples de 2 Kbps). Un seuil max (RBDCmax) est prdfini au moment de la
connexion et permet de garantir la capacit pour cette classe dallocation jusqu ce seuil. Au-
del du RBDCmax, les ressources sont alloues de manire ngocie (attribues si elles
sont disponibles). Au cas o le ST nutilise pas compltement sa ressource de type RBDC
(dbit demand < RBDCmax), le reste peut tre allou aux autres STs qui ont des besoins.
Cette classe dallocation la demande permet un partage efficace des ressources et doffrir la
QoS.
58
VBDC (Volume Based Dynamic Capacity) / AVBDC (Absolute - VBDC) : permet une allocation
de manire best effort (aucune garantie ne peut tre fournie). La gestion se fait par volume
(unit : paquet MPEG ou cellule ATM). Cette classe dallocation est entirement ngocie et
base sur les donnes en attente dans le ST. La capacit alloue cette classe dpend de la
disponibilit de la ressource restante aprs lallocation des classes CRA et RBDC. Pour le VBDC,
les requtes de capacit sont cumulatives ; pour lAVBDC, une nouvelle requte remplace la
prcdente.
FCA (Free Capacity Assignment) : permet une allocation sans demande lorsquil reste de la
bande passante non utilise. Cette capacit restante aprs le traitement des autres demandes
(CRA, RBDC, (A)VBDC) est attribue aux STs de manire quitable. Aucune garantie ne peut-
tre fournie par cette allocation de ressource.
Le Tableau III-8 suivant donne une synthse sur les diverses classes daccs aux ressources DVB-
RCS :
Classe de requte de A la demande ou

Priorit Garantie
capacit non
CRA Haut Oui Non
RBDC Moyen Oui (jusquau RBDCmax) Oui
VBDC/AVBDC Faible Non Oui
FCA Trs Faible Non Non
Tableau III-8 : Divers classes de requte de capacit.
La norme DVB-RCS dfinit galement des classes de trafic au niveau MAC qui peuvent tre
manipules dans le ST par des files dattentes distinctes :
RT (Real Time) : pour les flux temps rel fortes contraintes temporelles (ex : la VoIP, la vido
confrence, etc.).
VR (Variable Rate) : pour les flux dbit variable. Elle est dcompose en deux sous-classes :
la classe VR-RT ddies au trafic sensible la gigue et la VR-JT ddie au trafic tolrant la
gigue.
JT (Jitter Tolerant) : pour le reste du trafic.
59
Des correspondances entre les requtes de capacit et les classes de trafic sont recommandes
suivant :
CRA pour RT
RBDC pour VR
VBDC/AVBDC pour JT
Ces dfinitions offrent un moyen de diffrencier au niveau MAC des flux avec diffrentes
exigences en termes de QoS et dy rpondre par classes de trafic.
III.2.5 Mise en uvre de lalgorithme DAMA
Comme montr prcdemment, lutilisation du DAMA permet un partage souplesse et efficace

des ressources satellitaires en offrant diffrents niveaux de Qualit de Service. Pour le lien retour
DVB-RCS, le protocole DAMA repose sur la mthode daccs MF-TDMA qui partage la ressource
en crneaux temporels (TRF) sur plusieurs frquences. Le DAMA se droule entre le contrleur
DAMA (NCC) et le terminal ST de manire suivante :
Le contrleur DAMA gre le partage de la capacit du lien retour entre plusieurs STs qui y
accdent.
Le ST prend en charge lutilisation de la ressource alloue par le DAMA contrleur et gnre

les requtes de capacit.
Tout dabord, le ST calcule pendant un intervalle de temps fixe les requtes de capacit (CR) selon
ltat de ses filles dattente au niveau MAC. Ces CR sont ensuite envoyes au contrleur DAMA
par des signalisations SAC (partie III.2.3). Sur la base de ces CR, le contrleur DAMA permet
dallouer des ressources aux STs suivant lordre de priorit :
CRA > RBDC > (A)VBDC > FCA
Le contrleur DAMA gnre ensuite un plan dallocation des ressources (TBTP : Terminal Burst
Time Plan) dcrivant la rpartition des crneaux temporels de la super-trame MF-TDMA entre les
STs et lenvoie en diffusion (signalisation broadcast). Une fois reue la TBTP, le terminal ST
attribue la capacit alloue aux divers flux en attente dans les filles MAC. Cette attribution
peuvent tre effectue avec deux algorithmes : centralis ou distribu.
60
Algorithme centralis : avec ce mcanisme, chaque classe CR est identifie par un identifiant
de canal (Channel_ID). Le DAMA contrleur gre lallocation de crneaux TRF pour chaque
canal et envoie le rsultat par TBTP. En consquence, chaque TRF allou correspond un
terminal et un canal (classe dallocation) spcifis.
Algorithme distribu : dans ce cas, sur la base des requtes de capacit de chaque ST, le
contrleur DAMA dtermine une capacit globale alloue pour tous les canaux (channel_ID).
La ressource alloue au ST est donc une capacit globale commune tous les services. Cette
capacit non diffrencie peut tre attribue aux diffrents types de flux de manire souple
en fonction de la politique de service prdfinie et des objectifs de Qualit de Service.
Comme prsent dans le chapitre II, les caractristiques et les exigences en termes de QoS pour
les trois classes des services bord (ATS/AOC, GSM/UMTS, IP) sont htrognes. Pour les services
ATS/AOC, le trafic est faible, sporadique et na pas besoin dtre garanti en continu pendant toute
la dure de la connexion. De plus, les dlais requis pour ce type de services sont moins restrictifs
(3.8s pour la Phase 1 et 0.74s pour la Phase 2) par rapport aux autres services comme
GSM/UMTS (0.15s prfrable et 0.4s maximum). Dans ce cas, la classe VBDC est plus approprie.
Cependant, une trs grande disponibilit est ncessaire pour les services ATS/AOC. Pour cette
raison, nous proposons lutilisation dun canal exclusivement rserv pour tous les flux cockpit
(Channel_ID = 0). Pour les services de tlphonie mobile fortes contraintes temporelles,
compte-tenu les caractristiques du trafic, le type RBDC est propos (gestion par dbit). Pour le
trafic IP qui fonctionne dune manire Best Effort (aucune qualit de service ne lui est garantie)
dans notre contexte, le type VBDC (gestion par volume) est utilis.
La mise en uvre de lalgorithme DAMA avec diffrentes classes de services est donc rsume
dans le Tableau III-9 :
Service Priorit Channel_ID Classe de CR

ATS/AOC Haut 0 (A)VBDC
GSM/UMTS Moyen 1 RBDC
IP Bas 1 (A)VBDC
Tableau III-9 : Mise en uvre des requtes de capacit.
Pour avoir une utilisation efficace de la ressource dans le ST, nous adoptons lalgorithme distribu
pour lattribution des TRF allous aux diffrents flux bord. La ressource alloue au ST est donc
61
une capacit non diffrencie par canal, elle est attribue aux diffrents flux selon la politique de
service dfinie pour rpondre aux besoins de QoS. Une priorit suprieure est donne aux
services cockpit pour garantir la grande disponibilit. Le flux de tlphonie mobile a une priorit
plus leve que le flux IP pour respecter ses fortes contraintes temporelles. Grce cette
configuration, les trois types de services bord sont bien diffrencis en respectant leurs
performances demandes.
62
Chapitre IV
IV. ARCHITECTURE SYSTEME
Le systme propos doit assurer la convergence de trois flux de trafic sur la liaison satellite :
service aronautique ATC/AOC, service de tlphonie mobile et accs Internet. Dans ce chapitre,
nous prsentons les diffrentes architectures protocolaires associes. Ensuite, une comparaison
des architectures et une proposition pour la convergence des diffrents flux sur la liaison satellite
sont prsentes. Enfin, base sur cette architecture de convergence, ladquation des formats de
donnes et les mthodes dencapsulations utilisables sur la liaison satellite sont analyses.
IV.1 Modle OSI de lISO

Afin de fournir une base commune pour dcrire les systmes de communication et rduire la
complexit de conception dun rseau, lOrganisation Internationale de Normalisation (ISO :
International Organization for Standardization) a introduit un modle dinterconnexion de
systme appel OSI (Open Systems Interconnection) [ISO/IEC 7498]. Le concept important du
modle OSI est lorganisation en couche : chaque couche reprsente un module indpendant qui
contient un ensemble de fonctions et utilise les services de la couche infrieure. Les donnes sont
traites successivement couche par couche, chaque couche ajoute un en-tte lmission qui
sera retir puis utilis la rception.
Le modle de rfrence OSI contient 7 couches, lorganisation et la fonctionnalit de chaque

couche sont montres dans la Figure IV-1 :
63
Chapitre IV - Architecture Systme
7 - Application Sert de point daccs aux services rseaux pour lutilisateur
6 - Prsentation Ralise des fonctions sur la prsentation des donnes

(syntaxe, compactage, etc.)
5 - Session Organise et synchronise les changes entre les applications
4 - Transport Assure la transmission de donnes de bout en bout
3 - Rseau Permet dacheminer les paquets via le rseau (routage et adressage)
2 - Liaison de donnes Est charge de relier deux nuds de rseau sur une liaison physique
1 - Physique Dfinit la faon dont les donnes sont physiquement transferts (binaire)
Figure IV-1 : Modle OSI.
IV.2 Services aronautiques
IV.2.1 Architecture protocolaire dans lATN
Grce sa conception, sa stabilit, sa normalisation et sa souplesse, le modle OSI est largement

considr comme le modle de rseau de rfrence. Ce modle est utilis comme base pour
dfinir linter-rseau ATN ainsi que les protocoles utiliss dans chacune des couches. La dfinition
du rseau ATN a pour but de permettre des changes de donnes entre des avions et les
systmes de contrle au sol avec des performances attendues pour le service ATM. La structure
des protocoles utiliss ainsi que le format de donnes changes sont spcifis dans les
documents SARPs [ATN SARPs] [CAMAL] par lOACI.
Dans le rseau ATN, deux types de systmes sont identifis :
Systme Final (ES : End System) : est un systme qui comprend 7 couches en pile protocolaire
afin dtre capable de communiquer (directement ou indirectement) avec un autre ES pour
fournir de bout en bout des services de communication pour les applications ATN.
Systme Intermdiaire (IS : Intermediate System) : appel aussi le routeur ATN, est un
quipement qui est bas sur les trois couches basses du modle OSI et charg de relier les
diffrents types de sous rseaux afin de connecter les IS ou les ES au rseau et dacheminer
les paquets de donnes.
64
Le rseau ATN permet lexploitation des diffrents sous rseaux de communication : avionique,
sol-sol (fixe) et air-sol (mobile). Dans les SARPs ATN, les sous rseaux pour la communication air-
sol sont HF, VHF, Mode S et Satellite [CAMAL] [ANNEXE 10] :
Liaison de donnes HF (HFDL : High Frquence Data Link) : fonctionne dans les hautes
frquences (HF : High Frquence) du service mobile aronautique (3-22 MHz). Il permet
diffrents dbits (0.3, 0.6, 1.2, 1.8 Kbps) en utilisant diffrentes modulations (2PSK, 4PSK,
8PSK).
Liaison numrique VHF (VDL : VHF Digital Link) : fonctionne dans les trs hautes frquences
du service mobile aronautique (118-137 MHz) avec un espacement de 25 KHz. Il existe
plusieurs modes VDL (1, 2, 3 et 4). La VDL mode 2 est dploye en Europe pour les
communications ATS/AOC.
Liaison de donnes SSR mode S : fonctionne 1090 MHz dans le sens air-sol et 1030 MHz le
sol-air. Il sagit dune liaison radar secondaire adressage slectif dsign qui permet la
surveillance et lchange de donnes numriques en ayant recours des interrogateurs et
des transpondeurs mode S de radar secondaire de surveillance (SSR).
Liaison par satellite (AMSS : Aeronautical Mobile Satellite Service) : fonctionne actuellement
dans les bandes de frquence L du service mobile aronautique (1550-1630.5 MHz) et permet
de fournir la couverture mondiale (hors des rgions polaires) en utilisant les satellites
gostationnaires INMARSAT.
Un exemple de la pile protocolaire du rseau ATN est illustr dans la Figure IV-2. Le sous rseau
mobile de cette architecture est bas sur la liaison VDL mode 2. Cest une technologie oriente bit
qui utilise la modulation D8PSK (Differentially encoded 8-Phase Shift Keying). La ressource radio
est partage en contention par la mise en uvre de lalgorithme CSMA (Carrier Sense Multiple
Access) p-persistent. Le dbit fourni par la VDL mode 2 (31.5 Kbps) est 10 20 fois suprieur par
rapport la VHF ACARS (2,4 Kbps) utilis jusque l. Les dtails des protocoles VDL mode 2
(concernent les couches 1, 2 et une partie de la couche 3) peuvent tre trouvs dans le volume III
de lannexe 10 de lOACI [ANNEXE 10].
65
Modle OSI Systme Final (ES) SYSTEME EMBARQUE
Application
7 - Application
(CPDLC, ADS, etc.)
6 - Prsentation Prsentation
5 - Session Session
4 - Transport TP4 Routeur ATN (IS)
3.3 CLNP CLNP/ES-IS/IS-IS/IDRP
3 - Rseau 3.2 SNDCF LAN SNDCF LAN SNDCF Mobile
SNAcP LAN SNAcP LAN SNAcP Mobile

3.1 avionique avionique (VDL 8208)
VDL
DLS (AVLC) mode 2
2 - Liaison de donnes Liaison de donnes Liaison de donnes
MAC (accs CSMA)
1 - Physique Physique Physique D8PSK (31.5 Kbps)
Sous rseau avionique Sous rseau mobile
Figure IV-2 : Pile protocolaire du systme ATN (Exemple : VDL mode 2).
IV.2.2 Introduction du satellite dans larchitecture ATN
Dans le cas o le support physique est une nouvelle liaison par satellite, plus prcisment quand
lIS bord et lIS au sol sont interconnects par une nouvelle interface (DVB-S2/RCS dans notre
tude), ladaptation de ce nouveau sous rseau lATN doit tre prise en compte. Avec le mme
principe pour le sous rseau VDL mode 2 montr prcdemment, ladaptation est focalise dans
la couche rseau de lATN.
Conformment au modle ISO, la couche rseau de lATN est raffine en trois sous-couches
(fonctions) :
Couche 3.3 - fonction de convergence indpendante des sous rseaux (SNICF : SubNetwork
Independent Convergence Function) : est charge de fournir les services de la couche rseau
lutilisateur en masquant la diversit des sous rseaux. Le service fourni pour la transmission
de paquets est en mode sans connexion (CLNP : ConnectionLess Network Protocl [ISO 8473])
66
dans cette couche, ce mode sadapte facilement aux diffrents systmes avec une
connectivit universelle.
Couche 3.2 - fonction de convergence des sous rseaux (SNDCF : SubNetwork Dependent
Convergence Function) : est responsable de relier la couche 3.1 et 3.3 en fournissant les
services offerts par SNAcP la couche SNICF. Elle est capable dadapter et de convertir les
paquets du SNICF pour quils puissent tre compatibles avec le sous rseau.
Couche 3.1 - fonction daccs au sous rseau (SNAcP : SubNetwork Access Protocol) : est
totalement dpendante du sous rseau. Elle gre l'accs au sous rseau et le routage.
En gnral, le systme final dun avion est connect au routeur ATN bord par un rseau local
avionique. Dans notre tude sur lintroduction de liaison DVB dans lATN, nous nous focalisons sur
le routeur ATN. Comme illustr dans la Figure IV-3, les couches 1 3.2 sont impliques dans la
mise en uvre du sous rseau DVB.
Modle OSI Routeur ATN (IS)
3.3 CLNP/ES-IS/IS-IS/IDRP
3 - Rseau 3.2 SNDCF LAN

ADAPTATION
SNAcP LAN
3.1
avionique
DVB
2 - Liaison de donnes Liaison de donnes Dpendant
DVB-S2 DVB-RCS
1 - Physique Physique
Lien retour
Sous rseau avionique
Lien aller
Sous rseau mobile DVB
Figure IV-3 : Introduction de la liaison DVB dans larchitecture ATN.
67
IV.3 Services aux passagers
IV.3.1 Services de tlphonie mobile
Pour les services de tlphonie mobile, nous nous concentrons dans cette tude sur les
technologies 2G et 3G (GSM/UMTS) qui offrent les services majoritaires dans le march de
tlphonie mobile actuelle ainsi pour les dix prochaines annes.
IV.3.1.1 Rseau GSM
Typiquement, le rseau GSM est compos de trois sous-ensembles :
Sous-systme radio BSS (Base Station Sub-system) : assure et gre les transmissions radios
Sous-systme rseau NSS (Network Station Sub-system) : comprend l'ensemble des fonctions
ncessaires de commutation et de routage
Sous-systme oprationnel OSS (Operating Sub-System) : permet l'oprateur d'exploiter

son rseau.
Dans cette tude, nous nous intressons plus particulirement laccs du rseau tlphonie
mobile par la liaison satellite. La topologie du rseau GSM est simplifie pour se concentrer
uniquement sur les lments traits dans cette thse (voir la Figure IV-4).
BSS NSS
BTS BSC MSC PSTN
BTS
BTS
Um Abis A
Figure IV-4 : Structure du rseau GSM simplifie.
68
Les composants principaux de cette structure du rseau GSM sont :
BTS (Base Transceiver Station) : permet de communiquer avec les mobiles sur l'interface
radio (interface Um). Elle est comme un metteur-rcepteur central pour chaque zone cellule
qui comprend un ou plusieurs TRX (Transmission/Reception), chaque TRX peut supporter 8
communications simultanes.
BSC (Base Station Controller) : permet de contrler un ensemble de BTS sur linterface Abis. Il
prend en charge lallocation de la ressource radio et la dcision de l'activation/dsactivation
d'un canal vers un mobile. Le BSC soccupe aussi de la gestion du handover quand le mobile
passe dune BTS lautre.
MSC (Mobile Switching Center) : est un commutateur tlphonique qui permet de grer les
appels. Il multiplexe les trafics en provenance de plusieurs BSC sur linterface A et les relie au
rseau tlphonique commut public (PSTN : Public Switched Telephone Network).
IV.3.1.2 Rseau UMTS
La topologie du rseau UMTS avec la simplification pour cette tude est montre par la Figure
IV-5. Elle est compose de deux parties principales : le rseau daccs (similaire au sous-systme
BSS dans le rseau GSM) et le rseau cur. Comme un rseau GSM/GPRS, le rseau cur de
lUMTS est compos de deux domaines : dune part, le domaine de commutation de paquets (PS :
Packet Switched) permet laccs Internet ; dautre part, le domaine de commutation de circuits
(CS : Circuit Switched), qui est trs similaire celui du NSS dans le rseau GSM est utilis
principalement pour la tlphonie.
Rseau daccs Rseau coeur
Domaine CS
MSC PSTN
Node B RNC
Domaine PS
Node B
GSN
Node B Internet
Uu Iub Iu
Figure IV-5 : Structure du rseau UMTS simplifie.
69
Certains composants et interfaces UMTS jouent les rles quivalents ou trs similaires ceux du
rseau GSM. Au lieu de dtailler ces composants/interfaces UMTS et ses fonctionnalits, nous
prsentons ici un rcapitulatif bas sur les points communs/diffrents en comparant avec le
rseau GSM (voir le Tableau IV-1).
Composant Fonctionnalit
Localisation Comparaison avec GSM
/Interface principale
Radio transmission et Similaire BTS
Node B
rception Peut ventuellement tre localis
(Nud B)
avec un BTS existant
RNC
(contrleur de Point daccs au rseau Similaire BSC
rseau radio / cur, gestion dun Point daccs pour les services CS et
Radio Network ensemble de Nuds B PS
Controller)
GSN
Routeur et passerelle qui
(Nud de support
permet daccder au Nouveau nud
GPRS / GPRS
rseau Internet
Support Node)
Entre Mobile et
Interface Uu Equivalent linterface Um
Nud B
Entre Nud B
Interface Iub Equivalent linterface Abis
et RNC
Entre le rseau
Interface Iu daccs et le Equivalent linterface A
rseau cur
Tableau IV-1 : Comparaison rcapitulative des interfaces/composants des rseaux UMTS et GSM.
IV.3.1.3 Choix dun point de coupure pour lintroduction de la liaison satellite
Dans le contexte de la communication tlphonie mobile via satellite, le lien peut tre utilis pour
chaque segment du rseau GSM/UMTS montr prcdemment, cest--dire, chaque interface
peut tre employe comme liaison satellite. Dans cette tude, nous adoptons linterface Abis
(pour le rseau GSM, Iub pour lUMTS) comme un point de coupure pour lintroduction de la
liaison satellite. La motivation de ce mode de coupure est base sur les considrations suivantes :
La voix transmise sur cette interface peut utiliser un format compress, cest--dire que la
capacit ncessaire pour un appel est de 16 Kbps par rapport celle de linterface A qui est 64
Kbps. Ce dbit faible est plus adapt au contexte de communication par satellite o la bande
de passante est relativement contrainte.
70
Linterface Abis porte un nombre de communications simultanes homogne avec la

spcification de notre systme. Les interfaces de type A correspondent une agrgation de
plusieurs multiplex temporels de voix traits par les commutateurs MSC. Par ailleurs, le choix
de linterface Abis comme un point daccs satellite permet l'oprateur de lavion d'viter le
cot du dploiement des multiples lments principaux du rseau.
Enfin, la faisabilit de ce mode de coupure a t dmontre par des solutions dj existantes

(Gilat, Cisco) [GILAT] [CISCO].
La topologie GSM/UMTS par satellite retenue dans cette tude est donc montre par la Figure
IV-6 :
DVB-S2
DVB-RCS
BSC MSC PSTN

BTS/Node B Abis/Iub
RNC GSN
Internet
Figure IV-6 : Topologie GSM/UMTS par satellite.
Les spcifications de linterface Abis et Iub sont dfinies dans la norme 3GPP/ETSI [3GPP 01]
[3GPP 02]. Etant donn que ces deux interfaces sont quivalentes, nous ne prsenterons que
linterface Abis par la suite.
Comme spcifi dans [3GPP 03], l'accs physique entre la BTS et le BSC se fait par des liaisons
numriques PCM (Pulse Code Modulation) de 2 Mbps avec une structure de 32 crneaux
temporels de 64 Kbps (format E1). Chaque crneau temporel correspond un canal utilis sur
l'interface radio. Pour adapter le signal radio (13 Kbps) la liaison PCM (64 Kbps), lunit de
transcodage et d'adaptation de dbit (TRAU : Transcoder and Rate Adaptation Unit) doit tre
utilise. Dans cette tude, nous considrons que la TRAU est localise distance de la BTS pour
71
garder lintrt du signal compress pour le lien satellite (Figure IV-7). Dans ce cas, le transcodeur
TRAU est considr comme une partie de la BSC, la transmission dinformations (voix/donnes,
signalisations, synchronisations) est base sur le multiplexage de sous-canaux de 16 Kbps (4 sous-
canaux pour un canal de 64 Kbps) [3GPP 04].
BTS Abis BSC

Radio frames 64 Kbps
CCU TRAU
(Transcoder and
(Channel Rate Adaptor
Codec Unit) 16 Kbps
Unit)
320 bits/20 ms
(TRAU frames)
Figure IV-7 : Transmission sur linterface Abis.
Pour chaque sous-canal, les informations sont transportes par des trames de taille fixe de 320
bits (appeles les trames TRAU) toutes les 20 ms, ce qui correspond un dbit de 16 Kbps. En
effet, puisque lunit de transcodage et d'adaptation de dbit est positionne distance de la BTS,
une partie de la trame TRAU est rserve et sert au contrle entre la BTS et la TRAU/BSC. Un
exemple de trame TRAU pour la transmission de voix est montr dans la Figure IV-8. Dans cet
exemple, une charge denviron 20% (60 bits pour les champs C, T et 0/1) est ncessaire dans une
trame TRAU (320 bits) pour la signalisation et la synchronisation, le dbit rel pour la transmission
est donc bien 13 Kbps (conforme une liaison radio pour la voix).
Numro de bit
1 2 3 4 5 6 7 8 (Bit)
0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0
2 1 C1 C2 C3 C4 C5 C6 C7
Numro doctet
3 C8 C9 C10 C11 C12 C13 C14 C15

4 1 D1 D2 D3 D4 D5 D6 D7 Bit C : Contrle
5 D8 D9 D10 D11 D12 D13 D14 D15 Bit D : Donne

...
Bit T : Alignement

... Reste : Synchronisation
36 1 D214 D242 D243 D244 D245 D246 D247
37 D248 D249 D250 D251 D252 D253 D254 D255
38 1 D256 D257 D258 D259 D260 C16 C17
39 C18 C19 C20 C21 T1 T2 T3 T4
(Octet)
Figure IV-8 : Structure de la trame TRAU (Transcoder/Rate Adaptor Unit).
72
Durant la priode du bruit de confort (activation par la voix sur la liaison radiolectrique), le
mobile transmet une nouvelle trame toutes les 480 ms. Pendant ces 480 ms les trames TRAU
idle sont envoyes sur linterface Abis, cest--dire, une trame TRAU idle toutes les 20 ms.
Pour amliorer lutilisation de la ressource satellite, il est ncessaire dviter les trames TRAU
inutiles passes par le lien satellite. Les solutions proposes reposent souvent sur une logique de
suppression des trames idle lors de la transmission vers le satellite et de restauration de ces
trames lors de la rception [GILAT]. Les caractristiques dune voie phonie sur linterface Abis
sont rsumes par le Tableau IV-2 :
Etat Dure Moyenne Caractristique
ON 352 ms 1 TRAU / 20 ms
OFF 650 ms 1 TRAU / 480 ms
Tableau IV-2 : Caractristiques dune liaison voix sur linterface Abis.
IV.3.2 Services daccs Internet
Comme mentionn au dbut de ce chapitre, larchitecture gnrale dun rseau est dfinie par
lensemble des couches et les protocoles associs. Pour les services Internet, larchitecture de
rfrence de rseaux est le modle TCP/IP d'aprs le nom de deux protocoles majeurs : le
protocole de transport TCP (Transmission Control Protocol) et le protocole rseau IP (Internet
Protocol). Par rapport au modle de rfrence OSI (en 7 couches), TCP/IP (en 4 couches) offre les
avantages suivants :
Limplmentation du TCP/IP est moins complexe
La normalisation est plus libre
La technologie TCP/IP est plus optimise et efficace pour assurer linterconnexion de

systmes htrognes
TCP/IP est un modle largement utilis au niveau mondial
Le modle TCP/IP illustr dans la Figure IV-9 est base sur le modle de rfrence OSI mais
adapt limplmentation de lInternet.
73
Modle OSI Modle TCP/IP
7 - Application
6 - Prsentation 4 - Application
5 - Session TCP/IP
4 - Transport 3 - Transport
3 - Rseau 2 - Rseau
2 - Liaison de donnes
1 - Accs rseau
1 - Physique
Figure IV-9 : Modle TCP/IP.
Dans le modle TCP/IP, la couche Application qui se situe tout en haut du modle TCP/IP
correspond aux trois couches suprieures du modle OSI : Application, Prsentation et
Session. Cette couche contient tous les protocoles de haut niveau, comme par exemple HTTP
(HyperText Transfer Protocol), FTP (File Transfer Protocol) et SMTP (Simple Mail Transfer
Protocol). Le choix du protocole de la couche Application dfinit quel protocole de Transport
doit tre utilis. A la rception des donnes, les protocoles de Transport dterminent quelle
Application le paquet doit tre dlivr.
La couche Transport du modle TCP/IP joue le mme rle que celui de modle OSI, cest--
dire, grer les communications de bout en bout entre des entits. La couche Transport utilise
deux protocoles principaux : TCP (Transmission Control Protocol) et UDP (User Datagram
Protocol). TCP est un protocole fiable orient connexion qui permet des transmissions de
paquets sans erreurs. UDP est un protocole plus simple mais non fiable. UDP est souvent
utilis dans les cas o la rapidit de transmission est ncessaire et que la perte de donnes
nest pas trop gnante.
La couche Rseau est la couche essentielle dans larchitecture TCP/IP, elle permet
dacheminer des paquets de donnes (appels datagrammes) dans le rseau en mode non
connect.
74
La couche accs rseau peut tre considre comme la combinaison des couches Physique
et Liaison de donnes du modle OSI. Cette couche sous-rseau correspond linfrastructure
de communication limite la couche liaison de donnes (par exemple : LAN, satellite, etc.) et
ne fait pas partie de TCP/IP.
Comme prsent dans la norme [ETSI 301 790], les systmes DVB-S/RCS incluant IP peuvent
utiliser plusieurs architectures protocolaires.
Pour la voie aller DVB-S2, trois architectures protocolaires sont possibles :
IP sur l'encapsulation multi-protocole MPE (Multi Protocol Encapsulation) sur le flux de

transport MPEG-2 (MPEG-TS : Transport Stream)
IP sur la fonction de segmentation et rassemblage AAL5 (ATM Adaptation Layer 5) sur ATM
sur MPEG-TS (mthode optionnelle)
IP sur lencapsulation GSE (Generic Stream Encapsulation) sur le flux gnrique (GS : Generic
Stream) (mthode optionnelle pour les mobiles)
Pour la voie retour DVB-RCS, deux architectures sont possibles :
IP sur AAL5 sur ATM
IP sur MPE sur MPEG-TS (mthode optionnelle)
Une illustration de larchitecture IP via satellite base sur la norme [ETSI 301 790] est dcrite dans
la Figure IV-10.
75
Modle TCP/IP Systme Final
Application
Application
(HTTP, FTP )
Transport Routeur IP
Transport
(TCP, UDP)
Rseau IP IP
AAL5
MPE MPE AAL5
ATM GSE
Accs rseau Accs rseau
Accs rseau (Ethernet, WIFI) (Ethernet, WIFI)
MPEG-TS MPEG-TS ATM
DVB-S DVB-S2 DVB-RCS
Lien retour
Lien aller
Figure IV-10 : Pile protocolaire du systme IP via satellite.
IV.4 Convergence des trafics sur la liaison satellite

Comme montr dans les parties prcdentes, la fonction essentielle pour introduire la liaison
satellite dans une architecture rseau est dadapter les paquets de donnes (par exemple : CLNP,
TRAU, IP) au format de donnes DVB. Dans cette section, lobjectif est de faire converger les
diffrents trafics sur la liaison satellite. Nous tudions dabord les formats de donnes du lien aller
DVB-S2 et retour DVB-RCS. Ensuite, nous prsentons diffrentes mthodes pour encapsuler les
paquets de la couche rseau dans le transport de donnes DVB.
IV.4.1 Format de donnes DVB
IV.4.1.1 Lien aller DVB-S2
Pour le lien aller DVB-S2, le transport des donnes peut se faire travers le flux de transport
MPEG-TS [ETSI 301 192]. Plus prcisment, les trafics sont multiplexs en encapsulant les paquets
dans les trames MPEG de taille fixe (188 octets) dont la squence forme un flux de transport
MPEG-TS. La structure de MPEG-TS est illustre dans la Figure IV-11 :
76
Flux de transport MPEG (MPEG-TS)
Paquet TS (188 octets) Paquet TS (188 octets)

H Charge utile TS (184 octets) H Charge utile TS (184 octets)
H : En-tte TS (4 octets)
8b Synchronization pattern equal to 0x47
1b Transport Error Indicator
1b Payload Unit Start Indicator (PUSI)
1b Transport Priority
13b Packet IDentifier (PID)
2b Transport Scrambling Control
2b Adaptation Field Control (AFC)
4b Continuity Counter (CC)
Figure IV-11 : Structure de flux de transport MPEG-TS.
Chaque paquet TS est constitu de 4 octets den-tte et 184 octets de charge utile. Le champ PID
de 13 bits est utilis dans len-tte pour identifier diffrents canaux logiques ou flux de
signalisation (PID rserv) au sein dun multiplex. Cette indentification permet le premier filtrage
des paquets la rception. En utilisant la signalisation spcifique (cest--dire en transportant des
tableaux spciaux associs avec les PIDs spcifiques), les quipements du rseau DVB peuvent
tre configurs de faon approprie, afin qu'ils soient capables de transmettre les flux entrants
sans ambigut (lecture de tables dindirection successives). Toutefois, dans la mesure o les 13
bits du PID ne donnent accs qu 8192 valeurs, le nombre de canaux disponibles pour
transporter les paquets et la signalisation est limit. Le PID ne sert donc pas identifier les
terminaux destinataires mais bien les services. Par exemple, dans le cas dun service IPoS, la
signalisation IPoS utilise le PID 0x0190 et les donnes (les datagrammes IP) le PID 0x012C. Chaque
terminal doit rassembler les donnes transmises avec le PID du service et appliquer ensuite un
filtrage sur adresse (soit adresse MAC fournie dans len-tte MPE, soit adresse IP dans le
datagramme rassembl).
Le flux gnrique (GS: Generic Streams) est un nouveau mode de transport support par la
deuxime gnration du lien aller DVB (DVB-S2). Ce format de transport na pas une structure
spcifie, cest--dire que les paquets peuvent tre transports soit sur un flux continu (squence
de bits) soit sur un flux de paquets, sans les contraintes pour la taille du paquet et le dlai de
transmission.
77
IV.4.1.2 Lien retour DVB-RCS
Sur le lien retour, laccs au canal satellite est en mode partag entre plusieurs terminaux
reposant sur la technique MF-TDMA. Comme prsent dans le chapitre III, des bursts de trafic de
la super-trame MF-TDMA sont bass soit sur des cellules ATM soit sur des paquets MPEG-TS et
nous choisissons dans cette tude le format de paquet MPEG pour la voie retour DVB-RCS pour
les raisons cites prcdemment.
IV.4.2 Mthode dencapsulation
Avant de prsenter diffrentes mthodes dencapsulation, nous distinguons tout dabord les
termes utiliss pour dcrire le type de paquet trait chaque niveau du rseau pendant
lencapsulation.
Nom Niveau Exemple
PDU (Protocol Data Units) ou Datagramme Couche rseau IP, CLNP
SNDU (SubNetwork Data Unit) Couche dadaptation Paquet encapsul MPE
Trame Couche de liaison ATM, MPEG
Tableau IV-3 : Types de paquets pendant lencapsulation.
IV.4.2.1 Mthode dencapsulation sur le flux de transport MPEG
Comme prsent dans [ETSI 101 202], il existe plusieurs faons dencapsuler des donnes sur le
MPEG-TS. Dans cette section, nous nous intressons plus particulirement aux deux mthodes
courantes pour lencapsulation des datagrammes IP (ou des autres paquets de la couche rseau)
dans le support MPEG-TS DVB.
MPE (Multi Protocol Encapsulation)
Lencapsulation MPE a t propose pour la premire fois en 1996, elle est actuellement
largement accepte et est une mthode recommande par lETSI pour transporter des
datagrammes IP via DVB [ETSI 301 192]. De plus, MPE peut tre utilise dans des applications au-
del du DVB, par exemple la norme amricaine ATSC (Advanced Television Standards Committee).
78
MPE fournit un mcanisme dencapsulation des paquets PDUs au dessus de MPEG-TS. Il peut tre
appliqu dans le cas de flux unicast (les datagrammes sont adresss un rcepteur unique) ;
multicast (les datagrammes sont adresss un groupe des rcepteurs) et broadcast - diffusion (les
datagrammes sont destins tous les rcepteurs).
Les paquets PDUs sont encapsuls dans des sections DSM-CC (Digital Storage Media Command
and Control) compatibles avec le format de section prive de MPEG en ajoutant un en-tte de 12
octets en dbut de la section et 4 octets de contrle CRC (Cyclic Redundancy Check) la fin. La
longueur de la section est ventuellement ajuste par l'ajout de bourrage pour permettre une
segmentation en un nombre entier de mots de 188 octets. Le principe de cette mthode
dencapsulation est illustr par la Figure IV-12 :
PDU PDU
Rseau (IP, CLNP, etc) 1
SNDU MPE SNDU MPE

Adaptation (MPE) 2 3
Liaison de donnes ... ...

4
(MPEG-TS)
MPEG MPEG MPEG MPEG MPEG
1 : En-tte de PDU 2 : En-tte de SNDU (MPE) 4 : En-tte de paquet MPEG-TS

Hypothse : MTU < 4080 octets
donc pas de fragmentation pour PDUs 3 : CRC (MPE)
Figure IV-12 : Encapsulation MPE.
Dans lentte SNDU de lencapsulation MPE (2 dans la Figure IV-12), ladresse MAC du
destinataire (6 octets) est une partie importante de len-tte. Cependant, dans certains cas, cette
adresse MAC peut paratre inutile et introduit donc un cot lev surtout pour les PDUs de petite
taille (par exemple en cas de filtrage sur adresse IP).
ULE (Unidirectional Lightweight Encapsulation)
Une alternative lencapsulation MPE a t recommande par lIETF et sappelle ULE

(Unidirectional Lightweight Encapsulation (ULE) [RFC 4326]. Il sagit dune mthode de "data
piping" [ETSI 101 202], cest--dire que les PDUs sont directement encapsules dans la charge
79
utile des paquets TS via SNDU. La mthode dencapsulation ULE ne parait pas trs diffrente de
celle de MPE : elle repose toujours sur lencapsulation des PDUs dans des SNDUs du flux MPEG TS ;
dans un SNDU encapsul, on trouve toujours un en-tte et un CRC de 4 octets. Toutefois, lULE
utilise un en-tte moins complexe que la solution MPE en rduisant le nombre doctets et le
nombre de champs que le rcepteur doit analyser. La structure de paquets SNDU pour lULE est
montre dans la Figure IV-13.
SNDU ULE
4 octets
48b Protocol Data Unit CRC
1b 15b 16b (optional) (PDU) (32b)
En-tte de SNDU (ULE)

Destination Address Absent (D) Field (1b)
Length field (15b)
Type field (16b)
SNDU destination address field (optional) (48b)
Figure IV-13 : Structure de SNDU de lencapsulation ULE (sans extension).
Par rapport au MPE, la prsence du champ dadresse destination MAC dans len-tte ULE est
optionnel et signifie par lindicateur Destination Address Absent (D=0 : Prsence ; D=1 :
Absence). Cette dfinition permet, dans certains cas, domettre le champ dadresse qui est
redondant et inutile afin de diminuer la taille den-tte, par exemple, pour les rcepteurs qui sont
capable dutiliser une autre indentification (adresse destination IP). La prsence de ladresse
destination MAC est alors inutile. Dans ce cas, le D est mis 1 et 6 octets (optionnel) de ladresse
destination MAC sont ainsi conomiss.
De plus, ULE supporte aussi l'extension den-tte [RFC 5136] (ce qui n'est pas indiqu dans la
Figure IV-13). L'utilisation de l'extension den-tte permet dajouter des nouveaux champs de
protocole un PDU pour offrir une compatibilit avec les implmentations existantes. Toutefois,
l'utilisation dextension den-tte est dpendante du systme.
IV.4.2.2 Mthode dencapsulation sur le flux gnrique
GSE (Generic Stream Encapsulation)
80
Dans la seconde gnration du DVB-S, une nouvelle mthode de transmission est propose. Cette
mthode gnrique (dnomme GS) permet de transporter directement des paquets de la
couche rseau (PDUs) sur le lien satellite sans utiliser la couche liaison MPEG-TS. Un nouveau
mcanisme dencapsulation bas sur cette approche a t normalis la fin de lanne 2007, il
sappelle GSE (Generic Stream Encapsulation) [GSE 07]. Les caractristiques principales de cette
mthode dencapsulation sont :
permettre lencapsulation pour plusieurs protocoles de la couche rseau (IP, Ethernet, ATM,
etc.)
tre flexible pour appliquer les techniques FMT (ex : ACM) dans la deuxime gnration du
systme DVB
supporter plusieurs modes dadressage : sans/avec ladresse MAC (6 octets), adresse de 3

octets (ex : 1 octet group ID et 2 octets logon ID dans le DVB-RCS, serial number dans IPoS)
permettre le filtrage L3 (filtrage par ladresse IP)
proposer une mise en uvre simple
Le principe de la mthode GSE est dencapsuler les PDUs dans les paquets de la couche 2 (SNDU
GSE) de taille variable qui peuvent tre directement placs dans la charge utile Base Band Frame
(BB FRAME) de la couche physique :
PDU PDU
Rseau (IP, CLNP, etc) 1
Adaptation (GSE) 2 3
SNDU SNDU SNDU
Liaison de donnes GSE GSE GSE
(MPEG-TS)
Physique 4
BB FRAME BB FRAME
1 : En-tte de PDU 2 : En-tte de SNDU (GSE) 4 : En-tte de BB FRAME
3 : CRC (GSE)
Figure IV-14 : Encapsulation GSE.
81
En gnral, le SNDU GSE est de taille variable, compos dun en-tte GSE (minimum de 2 octets)
suivi par un paquet entier ou un fragment de paquet PDU et 4 octets du contrle dintgrit CRC.
Contrairement mthode MPE ou ULE, le CRC nest ncessaire que pour le dernier fragment dun
PDU fragment dans lencapsulation GSE (contrle du rassemblage). Le flux de paquets GSE est
ensuite plac dans le champ de BBFRAME. Souvent, un BBFRAME peut porter un ou plusieurs (il
sagit donc dun multiplexage) paquets GSE et la taille de BBFRAME peut tre constante ou
variable. Un exemple de format de SNDU GSE est montr dans la Figure IV-15.
SNDU GSE
2 octets <= 4096 octets
1b 1b 2b 12b 8b 16b 16b 24/48b >= 16b PDU *CRC

(32b)
En-tte de SNDU (GSE)

Start indicator (S) (1b)
End indicator (E) (1b) * : Nest ncessaire que pour le fragment final de PDU
Label Type indicator (2b)
GES length (12b)
Frag ID (8b)
Total length (16b)
Protocol type (16b)
Label (24/48b)
Extension header (>=16b)
Figure IV-15 : Exemple de format de paquet GSE.
GSE est une mthode simple et efficace pour fragmenter/rassembler des paquets PDUs en
utilisant la combinaison de trois indicateurs (flags) : S, E et Frag ID :
S (Start) E (End) Frag ID Description
1 1 Le paquet GSE contient un paquet PDU entier

Le paquet GSE contient le dbut dun paquet PDU fragment
1 0 prsent Le champ Total length est prsent pour vrifier la taille totale de
paquet PDU aprs le rassemblage au rcepteur
0 1 prsent Le paquet GSE contient la fin dun paquet PDU fragment
0 0 prsent Le paquet GSE contient un fragment PDU intermdiaire
Tableau IV-4 : Fragmentation/Rassemblage Indicateurs de GSE.
Tous les paquets GSE qui contiennent les fragments dun mme paquet PDU portent les frag ID
identiques et doivent tre transmis dans lordre. Le rcepteur commence la procdure de
82
rassemblage de paquet PDU sil reoit un paquet GSE (Dbut) avec S = 1 et E = 0. Il cre un buffer
qui permet de stocker le paquet PDU entier rassembler avec la taille prcise dans le champ
Total length du paquet reu (Dbut). Pour les paquets Intermdiaires (S = 0 et E =0) qui portent
les frag ID identiques, le rcepteur les place dans le buffer et vrifie si la taille totale du paquet
rassembl dpasse Total length (dans ce cas, la procdure de rassemblage choue et les
paquets stocks dans le buffer sont dtruits). Quand le paquet (Fin) avec S = 0 et E = 1 est reu, le
rcepteur termine le rassemblage par la vrification de la taille totale du paquet rassembl et
du contrle dintgrit CRC.
Comme lULE, GSE peut utiliser une extension den-tte [RFC 5136] pour la transmission de
nouveaux types de donnes, la concatnation des diffrents PDUs en un seul paquet GSE, etc.
GSE a t conu pour la liaison DVB-S2, ce qui explique que la norme fasse rfrence aux trames
BBFRAME typiques des liaisons DVB-S2 (Figure IV-14). Le principe de GSE est cependant
suffisamment souple pour envisager une application sur dautres supports.
Les performances des encapsulations MPE et ULE (surtout pour lencapsulation de paquets IP sur
MPEG-TS) ont dj largement tudis [HON 05] [XIL 06]. Grce la rduction den-tte en
liminant les champs inutiles pour la transmission des paquets IP via DVB, la mthode ULE offre
plus de simplicit et de meilleures performances que la mthode MPE. Cependant, la
comparaison entre GSE et ULE/MPE nest pas directe. Le but de la mthode GSE est concentr sur
la flexibilit de fragmentation et l'exploitation des mcanismes dadaptation (ACM), plutt que
sur la minimisation den-tte. Les performances du systme GSE dpendent fortement des
caractristiques de trafics, des politiques d'ordonnancement et de lutilisation de lACM.
83
Chapitre V
V. ARCHITECTURE DU TERMINAL AVION : APPROCHE

CLASSIQUE ET APPROCHE DYNAMIQUE
Dans ce chapitre, nous nous concentrons sur la conception de larchitecture du terminal avion
pour le lien retour DVB-RCS. Cette dmarche commence par la dfinition dune premire version
darchitecture dite classique et base sur le modle de rfrence BSM (Broadband Satellite
Multimedia), en respectant le concept en couches et ses rgles. Cependant, en effectuant
plusieurs tests exprimentaux par simulations, nous remarquons quil existe une ncessit davoir
des interactions entre des couches adjacentes ou non pour optimiser les performances du
systme. Ces techniques sont connues sous le nom de techniques Cross-Layer . Nous
proposons ensuite un tat de lart des diffrentes techniques Cross-Layer permettant
doptimiser la gestion de ressources et les performances. Bas sur cet tat de lart et une analyse
critique, nous proposons enfin une version optimise pour larchitecture du terminal avion avec
des interactions Cross-Layer .
V.1 Approche classique
V.1.1 Architecture BSM par ETSI
Le groupe BSM (Broadband Satellite Multimedia) de lETSI a dfini une architecture protocolaire
de rfrence [ETSI 102 292] pour un rseau IP intgrant le lien satellite. Cette architecture BSM
est montre dans la Figure V-1. Le concept de larchitecture BSM est la sparation entre les
fonctions qui sont applicables tous les systmes par satellite (satellite indpendant ou SI) et les
fonctions qui sont spcifiques une technologie satellitaire (satellite dpendant ou SD).
85
Chapitre V - Architecture du Terminal Avion : Approche Classique et Approche Dynamique
Modle OSI Modle BSM
Satellite IPv4/IPv6
3 - Rseau Indpendant
SIAF
REQUEST
REPONSE
INDICATION
CONFIRM
SI-SAP
SDAF
2 - Liaison de donnes SLC (Contrle de liaison satellite)

Satellite
dpendant SMAC (Contrle d'accs satellite)
Figure V-1 : Architecture protocolaire BSM.
Dans larchitecture BSM, une interface commune entre les couches SI et SD est dfinie pour
fournir essentiellement les mmes services toutes les familles de l'interface air pour les
systmes de communication par satellite (cest--dire toutes les couches SD). Cette interface est
appele SI-SAP (Satellite Indpendant - Service Access Point). Dans la spcification du SI-SAP [ETSI
102 357], deux fonctions dadaptation sont dfinies :
SIAF (Satellite Independent Adaptation Functions) : elle sapplique en bas de la couches 3

pour ladaptation entre les protocoles de couches 3 et les services SI-SAP
SDAF (Satellite Dependent Adaptation Functions) : elle opre en haut de la couche 2 pour
ladaptation entre les services SI-SAP et les services natifs offerts par le BSM
Les interactions entre les couches SD et SI sont bases sur les primitives de service SI-SAP. Ces
primitives reprsentent, dune manire abstraite, les changes dinformation et de contrle entre
les couches adjacentes (normalement entre SIAF et SDAF). Il existe quatre types de primitives
SI_SAP :
REQUEST : utilise quand la couche SI demande un service la couche SD.
86
INDICATION : utilise par la couche SD pour envoyer la notification la couche SI. Cette
notification peut tre lie une REQUEST ou juste une information sur les vnements de la
couche SD.
REPONSE : permet la couche SI de rpondre la primitive INDICATION envoye par la

couche SD.
CONFIRM : envoye par la couche SD pour confirmer que lactivit demande par lancienne
primitive REQUEST est termine.
A linterface SI-SAP, les trafics IP peuvent tre diffrencis en plusieurs files abstraites en utilisant
des identifiants de file (QIDs : Queue IDentifiers). Les QIDs reprsentent les files disponibles dans
les couches SD et permettent dassocier les files IP aux files SD en cachant les mises en uvre des
technologies satellitaires dpendantes. Chaque QID est caractris par une proprit qui dfinie
la faon comment les paquets sont transfrs dans le systme BSM (par exemple : la priorit de
traitement). Bas sur ces files, les couches SD sont charges de calculer les requtes de capacit
et dallouer la ressource satellite.
V.1.2 Projection de larchitecture BSM dans le cas du terminal avion
Larchitecture protocolaire BSM est ddie uniquement aux services Internet, mais elle peut
galement tre tendue aux autres rseaux, par exemple ATN, GSM/UMTS dans notre tude.
Nous utilisons donc le modle BSM comme rfrence pour tudier larchitecture du terminal
avion.
Une premire approche du terminal avion dite classique est dabord propose : elle respecte
strictement le concept en couches et la sparation entre les couches satellite indpendant
et les couches satellite dpendant . Cette approche est illustre dans la Figure V-2 :
87
Cockpit Routeur ATS

Systme avionique Routeur AOC Terminal Avion
DVB-S2 Lien satellite
BTS/Node B DVB-RCS
Routeur
PEP QoS
IP
Priorit daccs
LAN Gestion de la capacit
Satellite Indpendant Satellite Dpendant
Figure V-2 : Cur du systme : Approche classique.
Dans cette premire approche, les diffrents flux (ATS/AOC, GSM/UMTS, IP), qui sont associes
leurs couches SI, convergent linterface SI-SAP. Pour diffrencier les flux entrants, trois files
abstraites (QIDs) sont utilises avec des priorits de traitement :
ATS/AOC > GSM/UMTS > IP
Dans les couches SD, les donnes sont segmentes/encapsules en paquets MPEG. Ces paquets
MPEG constituent la charge utile des crneaux TRF envoys sur le lien DVB-RCS. Trois PID (Packet
IDentifier) sont ncessaires afin de permettre didentifier les paquets des trois types de service.
Au niveau MAC, un serveur est mis en place et permet les deux fonctions suivantes :
Calcul des requtes de capacit
Ordonnancement et contrle daccs au lien satellite
Comme indiqu dans la Figure V-2, dans cette approche classique, la gestion de la ressource, la
QoS et la priorit daccs sont toutes obtenues au niveau de la couche MAC. Autrement dit, les
diffrents flux sont multiplexs dans la couche daccs afin dtre transmis sur le lien unique DVB-
RCS. Larchitecture protocolaire de cette approche classique est dtaille dans la Figure V-3 :
88
Modle OSI ATN GSM/UMTS IP
CLNP Interface Abis/Iub IPv4/IPv6

Satellite
3 - Rseau PDU CLNP TRAU Datagramme IP
Indpendant
SIAF
SI-SAP
QID0 QID1 QID2
SLC (Contrle de liaison satellite)

SDAF
Segmentation/Encapsulation
2 - Liaison de donnes
Satellite
dpendant MPEG MPEG MPEG
SMAC (Contrle d'accs satellite)
Figure V-3 : Architecture du terminal avion (Approche classique).
V.1.3 Mise en uvre dtaille
V.1.3.1 Rseau ATN
Comme prsent dans la partie IV.2.2, la couche rseau de lATN utilise le protocole CLNP pour la
transmission de donnes. Les paquets envoys par le CLNP au sous rseau sont des PDUs CLNP
[ISO 8473]. Le format de paquet CLNP est montr dans la Figure V-4. Ce format de paquet
supporte des adresses (source et destination) de taille variable jusquau 20 octets de type NSAP
(Network Service Access Point) [ISO 8348] pour le routage. Ladresse NSAP est une adresse
structure hirarchique qui sapplique au niveau mondial et permet didentifier les quipements
terminaux (hosts) et intermdiaires (routeurs) dans les rseaux OSI. Dans lapproche classique,
puisquun canal logique (PID) est rserv chaque type de flux, le rcepteur est capable de filtrer
des paquets en utilisant la combinaison du PID et ladresse NSAP (L3 filtrage). Dans ce cas, La
prsence de ladresse destination MAC nest plus utile. Lencapsulation ULE est la mthode
retenue car, comme vu prcdemment dans le chapitre IV, elle gnre des en-ttes de paquet
89
SNDU de taille moins importante que MPE : un en-tte de 8 octets suffit avec le champ D
(Destination Address Absent field) = 1.
Network Layer Protocol Identifier Length Indicator

Version Protocol ID extension Lifetime
SP MS E/R Type Segment Length
Checksum
Destination Address Length Indicator
Destination Address
Source Address Length Indicator
Source Address
Data Unit Identifier Segment Offset Total Length
Options
DATA
Figure V-4 : Format de paquet PDU CLNP.
V.1.3.2 Rseau GSM/UMTS
Pour le rseau GSM/UMTS, comme dtaill dans la section IV.3.1.3, nous avons choisi linterface
Abis/Iub comme le point de coupure pour lintroduction de la liaison satellite. Le problme qui se
pose est que linterface Abis/Iub est base sur les structures E1 [HEI 98] ou ATM et aucune de ces
structures ne permet dintgrer le lien satellite DVB. Pour cette raison, nous proposons une
encapsulation ad-hoc qui sert encapsuler directement le flux de trafic (sous forme de trame
TRAU) la sortie du BTS dans les paquets MPEG. Compte-tenu de la charge utile dun paquet
MPEG (180 octets), le nombre maximum de trames TRAU (40 octets) pouvant tre encapsuls
dans un paquet MPEG est fix 4.
V.1.3.3 Rseau TCP/IP
Pour le rseau TCP/IP, les PDUs envoys aux couches SD sont sous forme de datagrammes IP.
Comme pour les PDUs CLNP, len-tte IP supporte ladresse (32 bits) qui permet didentifier un
quipement destinataire sur le rseau. Le filtrage L3 est ralis en combinant le PID et ladresse IP.
Ici aussi, la mthode dencapsulation ULE permet dviter la transmission de ladresse MAC.
90
La capacit maximum qui peut tre attribue un terminal avion est dpendante du bilan de
liaison et prsente dans le chapitre III (1 Mbps dans notre exemple). On peut faire lhypothse
que les flux IP qui excdent cette limite gnrent une congestion au niveau MAC. De plus, les
requtes de capacit calcules la base de cette file MAC congestionne ne peuvent pas tre
reprsentatives.
Dans le routeur IP, une technique de seau perc (Leaky Bucket) est mise en place pour
conditionner le flux IP. Ce contrle dadmission statique permet dobtenir un trafic ayant un dbit
constant R qui correspond la ressource disponible au niveau MAC. Le principe de ce mcanisme
est :
dbit de sortie constant (tant que le seau n'est pas vide)
contenance maxi (si dpassement alors perte)
sur un routeur, profondeur du seau = longueur de la file d'attente
En outre, un mcanisme de la gestion active de file d'attente RED (Random Early Detection) [FLO
93] est mise en uvre au routeur IP. Lavantage de lutilisation du RED est doptimiser la gestion
des files dattente et dviter les congestions lorsque plusieurs connexions TCP sont en
concurrence dans un routeur-goulet d'tranglement (IP routeur dans notre tude). De plus cette
technique permet de lisser les pertes de datagrammes dans le temps plutt que dobtenir des
pertes groupes sur congestion effective et gnant ainsi fortement les performances des couches
hautes.
Probabilit de rejet
Rejeter tout
maxp
Rejet avec Pa
Ne rien rejeter
avg
0 minth maxth
Figure V-5 : Mcanisme RED (Random Early Detection).
91
Le principe de lalgorithme RED (Figure V-5) est de dtecter la congestion avant d'avoir une file
dattente bien remplie. Chaque fois quun paquet arrive dans la file dattente, RED calcule la taille
moyenne glissante pondration exponentielle avg (EWMA : Exponentially Weighted Moving
Average) et la compare avec les deux seuils (minth et maxth). Si avg se trouve entre les deux
seuils, le paquet sera dtruit avec la probabilit calcule en fonction croissante de avg ; si avg
dpasse le seuil maximum maxth, le paquet est rejet. Les dtails de lalgorithme RED est
montrs par le pseudo-code ci-dessous :
Soit avg la taille moyenne de file dattente

Soit count le nombre de paquets depuis le dernier rejet
Soit minth la valeur de seuil minimum (en paquet)
Soit maxth la valeur de seuil maximum (en paquet)
Soit wq la pondration pour calculer lavg
Soit q la taille relle de file dattente
Soit Pa la probabilit de rejet
Initialisation :
avg 0
count -1
A larrive de chaque paquet
Si la file nest pas vide
avg (1-wq)*avg + wq*q
Sinon
m nombre de paquets gnrs pendant la priode o la file est vide
avg (1-wq)m *avg
Si minth <= avg < maxth

count = count +1
Pb maxp (avg - minth) / (maxth - minth)
Pa Pb / (1 count * Pb)
Avec probabilit Pa
Rejeter le paquet
count 0
Si avg >= maxth
Rejeter le paquet
count 0
Si avg < minth
count -1
Dans cette tude, les paramtres RED sont configurs avec les valeurs recommandes dans [FLO
97] :
minth = 5 paquets
maxth = 15 paquets
92
wq = 0,002
maxp = 0,02
La mise en uvre dtaille de larchitecture dans le contexte de lapproche classique est illustre
dans la Figure V-6 :
Terminal satellite (DVB-RCS)
SRC. ATS PID 0

Flux MPEG
SRC. AOC PDU CLNP
ULE File MAC
PID 1 Serveur MAC

Flux MPEG
Ordonnancement
Lien
SRC. GSM
TRAU
File MAC (Priority Queuing) satellite
Encapsulation
ad-hoc
Routeur IP
TBTP
PID 2
Flux Flux MPEG
SRC. IP
IP IP
ULE File MAC
RED Seau
perc Requte de capacit
Flux de donnes Signalisation DVB
Figure V-6 : Mise en uvre dtaille de larchitecture de lapproche classique.
V.1.4 Etude prliminaire de lapproche classique
Pour valuer les performances du systme de lapproche classique, un scnario de simulation est
modlis laide du logiciel OPNET Modeler. En ce qui concerne le terminal avion du lien retour
DVB-RCS, comme montr dans la Figure V-6, certaines simplifications et adaptations sont prises
en compte.
Dabord, conformment ce qui est prsent dans la partie II.3, nous supposons que les sources
de trafic ATS/AOC, GSM/UMTS reprsentent respectivement les flux des rseaux ATN et
GSM/UMTS arrivant linterface SI-SAP. Pour les services IP, nous utilisons un ensemble de
sources TCP greedy modlisant un trafic lastique qui sadapte dynamiquement la capacit
disponible et gnre les segments TCP qui sont ensuite encapsuls dans des datagrammes IP.
Pour rduire la complexit du scnario et se concentrer sur le fonctionnement du terminal avion,

la rpartition des terminaux, le dimensionnement de la ressource satellitaire ainsi que la mise en
uvre de techniques FMT sont tous simplement interprts par une seule variable de simulation :
93
nombre de paquets TRF allous. Cette variable reprsente le rsultat dallocation TBTP envoy au
terminal par la GW (NCC) chaque dure de super-trame. Cette simplification nous permet,
dallger le modle de simulation et donc de rduire les temps de calculs tout en obtenant un
fonctionnement global du systme reprsentatif.
Dans le premier essai, le nombre de crneaux TRF allous un terminal varie alatoirement et
uniformment de 24 36. Ceci correspond un canal avec :
dbit minimum : 580 Kbps

dbit maximum : 870 Kbps
dbit moyen : 730 Kbps
Sachant que les sources de trafics ATS/AOC et GSM/UMTS gnrent des flux qui correspondent un
dbit moyen cumul de 256 Kbps (sans compter la partie den-tte et lencapsulation), le dbit
moyen disponible pour le flux IP ne sera pas suprieur 474 Kbps. Cette remarque nous permet
destimer une borne suprieure pour le flux IP. Nous choisissons ensuite dtudier 3 dbits
diffrents pour configurer le seau perc mis en place au routeur IP : 384, 448, 512 Kbps.
Le Tableau V-1 nous montre les volumes reus en 1 heure pour les trois types de flux. Nous
remarquons que grce la politique PQ (Priority Queuing), la modification du dbit du seau perc
IP na pas dincidence pour les deux autres flux (ATS/AOC et GSM/UMTS) : laugmentation du
dbit IP ne se fait pas aux dpens de ces deux flux qui sont prioritaires. Pour le flux IP, suite
laugmentation du dbit du seau perc , les volumes IP reus accroissent. Les taux dutilisation
(en moyen) de la ressource alloue (Figure V-7) nous montrent que pour la configuration 512
Kbps, les trois types de flux remplissent pleinement la capacit alloue.
Dbit du seau Volume ATS/AOC Volume GSM/UMTS Volume IP Volume Total

perc (R) reu reu reu Recu
(Kbps) (Kilo octets) (Kilo octets) (Kilo octets) (Kilo octets)
384 60 76,984 162,630 239,674

448 60 77,058 189,645 266,763
512 60 77,225 194,748 272,033
Tableau V-1 : Volumes reus en 1 heure - Approche classique.
94
Figure V-7 : Taux dutilisation moyen de la ressource alloue - Approche classique.
Nous nous intressons galement au taux doccupation des files dattente au niveau MAC et au
fonctionnement du RED mis en place au routeur IP (Tableau V-2). Pour les flux ATS/AOC et
GSM/UTMS, les tailles moyennes des files dattente sont trs petites, les dlais dattente
correspondants sont donc trs courts (moins de 50 ms dans ces exemples). Cependant, un
problme apparat dans la configuration du dbit IP 512 Kbps : beaucoup de paquets sont stocks
au niveau MAC, cette file dattente norme introduit alors des dlais trs levs (~5 seconds en
moyenne) ce qui ne permet pas de garantir les performances des services IP. De plus, les requtes
de capacits calcules sur la base de cette file congestionne ne sont pas reprsentatives. Par
ailleurs, nous pouvons remarquer que pour la file dattente du routeur IP o le mcanisme RED
est mis en place, sa taille moyenne glissante pondration exponentielle est pratiquement nulle.
Cest--dire quaucun paquet nest rejet au routeur IP, et que le RED ne permet pas dviter les
congestions dans la couche MAC. Ceci sexplique par le fait que le dbit de sortie de la file
dattente au niveau 3 tant relativement lev, cette file ne stocke pratiquement pas et na donc
pas lieu de mettre en uvre le RED implment. Par contre la file aval (couche MAC) stocke
anormalement un nombre important de paquet (en moyenne 1800).
95
Niveau de mesure MAC MAC MAC IP
Taille de file Taille de file Taille de file

Dbit du seau perc (R) Avg RED
ATS/AOC GSM/UMTS IP
(Kbps) (paquet IP)
(paquet TRF) (paquet TRF) (paquet TRF)
384 4 5 14 7
448 4 5 160 5
512 4 5 1800 ~0
Tableau V-2 : Taille moyenne des files dattente dans le terminal avion - Approche classique.
Nous voyons donc quil est difficile de paramtrer le dbit du seau perc (R) avec une valeur fixe
et convenable. En cas de R trop faible, on obtient une sous utilisation de la capacit attribue ; et
en cas de R trop lev, des problmes de congestions ou du moins de surstockage sont mis en
vidence au niveau MAC et gnrent un dlai dattente lev. De plus, les requtes de capacits
calcules dans ce cas ne sont pas reprsentatives. Dans les exemples montrs prcdemment,
parmi les trois dbits choisis pour configurer le seau perc, R = 448 Kbps reprsente un bon
compromis entre lutilisation de ressource (98%) et le dlai pour le flux IP. Par contre, ce dbit
nest valide que dans ce scnario simplifi avec lhypothse sur la capacit alloue bien prcise.
Dans le cas rel, cette capacit alloue nest pas connue, car elle dpend plusieurs facteurs
comme la rpartition de la bande du rpteur, les charges des terminaux, la mise en uvre des
techniques FMT, etc. et il est alors impossible dvaluer la capacit effectivement disponible pour
le flux IP.
Les courbes de densit de probabilit cumules des dlais de couche 3 couche 3 pour les trois
types de services sont montres dans la Figure V-8 (R = 448 Kbps). Nous pouvons remarquer que
conformment la politique PQ (Priority Queuing) mise en oeuvre au niveau MAC, les trois types
de services sont transmis avec lordre des priorits ATS/AOC > GSM > IP. De plus, les dlais requis
pour les services cockpit et la tlphonie mobile sont garantis. Pour les services IP, 95% des
datagrammes sont transmis avec des dlais de 2 secondes ou moins.
96
Figure V-8 : Courbes CDF des dlais (ATS/AOC, GSM/UMTS, IP) - Approche classique.
Comme conclusion de ce premier scnario sur lapproche classique, nous soulignons que mme si
nous obtenons des rsultats corrects connaissant la capacit disponible pour le flux IP (ce qui
nest pas vrai en rel), cette approche classique nest pas adaptative. Afin de le dmontrer, nous
avons effectu une nouvelle simulation avec le mme dbit du seau perc de 448 Kbps mais
en mettant le flux GSM/UMTS en veille. Comme prvu, le volume IP reu reste le mme. Cest--
dire, mme si la capacit disponible pour le flux IP est accrue, le service IP ne peut pas profiter de
cette capacit supplmentaire cause du contrle statique. Le taux moyen dutilisation du canal
est dans ce cas relativement faible (68%).
V.1.5 Contrle dynamique du flux IP
Pour avoir une approche adaptative, nous proposons ensuite une nouvelle approche par la mise
en place dinteractions entre le serveur MAC et le seau perc par un flux de signalisation (Figure
V-9). Nous lappelons dans la suite : approche dynamique. Chaque fois que le serveur MAC reoit
la table TBTP, il attribue les slots TRF au trois files de MAC correspondant aux trois flux selon leur
priorit. Il utilise aussi ces informations pour estimer la capacit disponible pour le trafic IP. Pour
viter un contrle du dbit fluctuant trop rapidement, cette capacit correspond un dbit
97
moyen glissant pondration exponentielle. Le rsultat destimation est ensuite envoy au

contrleur de dbit du routeur IP par la signalisation et lui permet dadapter la valeur R du seau
perc pour conditionner le flux IP. Autrement dit, le dbit de sortie du seau perc est
dynamiquement pilot par le serveur MAC dans cette approche.
SRC. ATS PID 0

Flux MPEG
SRC. AOC PDU CLNP
ULE File MAC
PID 1 Serveur MAC

Flux MPEG
Ordonnancement
Lien
SRC. GSM
TRAU
File MAC (Priority Queuing) satellite
Encapsulation
ad-hoc
Routeur IP
PID 2 TBTP
Flux Flux MPEG
SRC. IP
IP IP
ULE File MAC
RED Seau
perc Requte de capacit
Flux de donnes Signalisation Cross-Layer Signalisation DVB
Figure V-9 : Mise en uvre dtaille de larchitecture de lapproche dynamique.
Pour tester cette approche dynamique, nous utilisons la mme configuration que lapproche
classique. Le dbit de sortie du routeur IP est donc dynamiquement pilot par le serveur MAC.
Comme montr par la Figure V-10, ce dbit du seau perc est ajust dynamiquement avec une
moyenne de 448.6 Kbps. Nous remarquons que ce dbit moyen obtenu est trs proche que celui
trouv de faon empirique dans lapproche classique et qui offre les meilleures performances
(448 Kbps). Nous comparons donc par la suite, les comportements et les performances de ces
deux approches.
98
Figure V-10 : dbit/dbit moyen du seau perc - Approche dynamique.
En premier lieu, nous nous intressons aux volumes reus en 1 heure pour les trois types de flux.
Nous remarquons que les deux approches offrent des performances similaires sur lutilisation de
la ressource (Tableau V-3 et Figure V-11 a). Cependant, une nette amlioration est introduite
dans lapproche dynamique quand le flux GSM/UMTS est mis en veille. Grce au contrle
dynamique, le flux IP peut profiter entirement la capacit ainsi libre par le flux GSM/UMTS.
Le dbit moyen de sortie du seau perc IP est environ 634.5 Kbps et le taux moyen dutilisation du
canal est toujours lev (Figure V-11 b). Ceci est le rsultat de lutilisation de la signalisation de la
couche MAC vers IP qui permet dadapter le dbit IP la capacit disponible aprs avoir servi les
flux ATC/AOC et GSM.
Volume Volume Volume Volume

Dbit du seau perc
ATS/AOC reu GSM/UMTS reu IP reu Total recu
(Kbps)
(Kilo octets) (Kilo octets) (Kilo octets) (Kilo octets)
GSM/UMTS Fixe : 448 60 77,058 189,645 266,763

active Dynamique (~448.6) 60 76,850 192,067 268,977
GSM/UMTS Fixe : 448 60 0 188,638 188,698
en veille Dynamique (~634.5) 60 0 272,969 273,029
Tableau V-3 : Comparaison de lapproche classique et dynamique - Volumes reus en 1 heure.
99
(a) : GSM/UMTS active. (b) : GSM/UMTS en veille.
Figure V-11 : Comparaison de lapproche classique et dynamique - Taux moyen dutilisation de la ressource
alloue.
Le remplissage des files dattente au niveau MAC et le fonctionnement du RED mis en place dans
le routeur IP sont galement tudis pour ce dernier scnario (Tableau V-4). La file MAC pour le
flux IP est dans un tat stationnaire avec une taille moyenne de 120 paquets au lieu de 160, soit
plus 30%, pour contrle statique du flux IP. Cette diffrence permet de diminuer le dlai du trafic
IP (Figure V-12).

Dbit du seau perc Avg RED
ATS/AOC GSM/UMTS IP
(Kbps) (paquet IP)
Fixe : 448 4 5 160 5

Dynamique 4 5 120 5.5
Tableau V-4 : Taille moyenne des files dattente dans le terminal avion - Approche dynamique.
100
Figure V-12 : Comparaison de lapproche classique et dynamique - Courbes CDF de dlai IP.
Les courbes de densit de probabilit cumules des dlais de trois types de services sont
montres dans la Figure V-13. Sensiblement identique lapproche classique, les trois types de
services sont transmis avec lordre des priorits ATS/AOC > GSM/UMTS > IP. Les dlais requis pour
les services cockpit et de tlphonie mobile sont garantis. 95% des datagrammes IP sont transmis
avec les dlais de 1,7 secondes ou moins.
95% <= 1.7 s
101
Figure V-13 : Courbes CDF des dlais (ATS/AOC, GSM/UMTS, IP) - Approche dynamique.
Cependant, une nouvelle limite apparat dans cette approche dynamique : comme le dbit du
seau perc est pilot par la couche MAC, ce dbit ne reprsente que la capacit disponible pour
le flux IP. Nous remarquons que dans le cas o le dbit du seau perc est mis 0, parce quil
ny a plus rien mettre ou que la capacit est rquisitionne pour les flux prioritaires, alors il n'y
a plus de datagramme IP dans la file dattente MAC. Ceci est d principalement un dfaut de
cette approche avec pour consquence une famine pour le service IP : comme il ny a plus de
datagrammes mis par la couche IP, la couche MAC nen stocke pas et na donc plus de raison
dmettre des requtes de capacit pour ce flux IP. Et les TBTP suivantes nauront donc aucune
raison de contenir des avis de crneaux allous pour IP.
Il faudrait donc dfinir une approche permettant de fixer les requtes de capacit en fonction de
ce qui est effectivement stock dans les couches plus hautes de larchitecture (notamment au
niveau IP). Cependant, larchitecture de cette dernire approche dynamique est dj complexe et
sen trouverait certainement encore alourdie. Nous proposons donc dintgrer cette dernire
problmatique dans la dernire approche que nous exposons dans le chapitre VI et qui sera
optimise. Cette approche devra utiliser des techniques de communication inter-couches cross-
layer afin de rsoudre notamment le conflit entre contrle de flux au niveau IP et gestion de la
ressource radiolectrique par le DVB-RCS.
Une premire optimisation de la couche protocolaire nous a donc amen introduire la notion
dinterdpendance entre couches protocolaires adjacentes ou non par des flux de signalisation.
Ces techniques sont regroupes sous le nom de techniques Cross-Layer . Elles font
actuellement lobjet de beaucoup dtudes pour les gains performances quelles permettent
doffrir. Mais compte-tenu de leurs diversits, il nous parat important de terminer ce chapitre par
une prsentation plus dtaille et un tat de lart des techniques Cross-Layer . Ceci est ensuite
complt par un expos des techniques Cross-Layer dans le cas particulier qui nous intresse :
les communications par satellite.
V.2 Etat de lart des techniques Cross-Layer

Comme prsent dans le chapitre prcdent, les architectures OSI applique dans lATN ainsi que
TCP/IP sont toutes deux bases sur un concept en couches . Cest--dire que chaque couche
102
ralise un ensemble de fonctions spcifiques en utilisant des services fournis par la couche
infrieure et offrant des services la couche suprieure. Les protocoles dans ces architectures
sont conus de faon indpendante les uns des autres. Les communications entre les couches
non-adjacentes ne sont pas permises de faon garantir la modularit de larchitecture.
Cependant, cette approche stricte ne convient pas toujours notamment dans le contexte des
rseaux sans fils qui imposent des contraintes particulires lies la couche physique. Les
inconvnients principaux sont suivants [GIO 07] :
Les exigences de performances des services sont dfinies dans la couche applicative, mais
cette dfinition ignore les considrations de performances globales qui dpendent
gnralement des couches basses.
Les informations importantes peuvent tre perdues pendant la conversion couche par couche.
Les couches sont optimises, mais on peut supposer que les communications entre elles
peuvent ventuellement apporter des gains de performances
Pour optimiser les performances globales des systmes de communication, lapproche Cross-
Layer est donc de plus en plus souvent propose. Dans [SRI 05], lapproche Cross-Layer est
dfini comme suit : elle est une conception des protocoles qui ne se conforme pas exactement
larchitecture de communication de rfrence. Plus prcisment, le but de lapproche Cross-
Layer est de fournir des interactions et/ou des adaptations entre couches diffrentes non
ncessairement adjacentes afin damliorer les performances globales.
V.2.1 Diffrentes catgories de Cross-Layer
Dans la littrature, il existe plusieurs faons de mettre en uvre des techniques Cross-Layer .
Un panorama des diffrents types de Cross-Layer est prsent dans [SRI 05] :
Type 1 : introduire des nouvelles interfaces (Figure V-14)
Les nouvelles interfaces sont utilises dans ce type de Cross-Layer pour partager des
informations entre les couches. Ce type peut tre encore raffin en trois sous-classes selon la
direction d'informations :
1. Interface Top-Down : permet aux couches hautes de configurer un paramtre dune

couche infrieure. Par exemple : la VoIP (voix sur IP) est une application qui est trs
103
sensible au dlai de transmission. Elle peut annoncer son exigence de dlai la couche de
liaison afin que ce dernier puisse envoyer les paquets correspondants avec une priorit
leve.
2. Interface Bottom-Up: est propose quand un protocole de haut niveau a besoin des
informations des niveaux infrieurs. Elle permet une signalisation explicite d'une couche
infrieure une couche suprieure. Par exemple : cette interface ascendante est
approprie pour la mise en uvre de lACM. Puisque dans ce cas, les informations
peuvent tre envoyes aux couches suprieures pour prendre en compte des adaptations
dynamiques qui se sont droules en couches infrieures [SKI 07].
3. Interfaces Boucle : sont des interfaces bidirectionnelles qui permettent une collaboration
entre deux couches.
Nouvelle Interface Nouvelle Interface Nouvelles interfaces

Top-Down Bottom-Up Boucle
Figure V-14 : Diffrentes conceptions de Cross-Layer - Type 1.
Type 2 : fusionner les couches adjacentes (Figure V-15)
Combiner plusieurs couches adjacentes dans une seule super couche est la deuxime catgorie
de technique Cross-Layer . Elle permet cette super couche de dialoguer directement avec
les couches qui restent dans la pile protocolaire par des interfaces dj existantes. Certains
travaux ont dj montr la tendance ignorer la frontire entre des couches adjacentes (par
exemple entre la couche physique et MAC). Cependant, il ny a pas de proposition explicite pour
cette mthode jusqu prsent.
Type 3 : prconfigurer les couches (Figure V-15)
104
Cette mthode permet doptimiser les couches par des pr-configurations de comportements au
dbut de la conception. Cest--dire, de concevoir une couche en prenant en considration les
autres couches. Le problme qui se pose est quil est impossible de modifier une couche sans
adaptation des autres couches qui lui sont associes.
Type 4 : calibrer verticalement les couches (Figure V-15)
Le dernier type de Cross-Layer consiste calibrer les paramtres en traversant plusieurs

couches. Gnralement, les performances dune application peuvent tre considres comme
une fonction dont les paramtres dpendent de toutes les couches infrieures. Les rglages
conjoints permettent dobtenir de meilleures performances quavec des rglages indpendants.
Les paramtres peuvent tre statiquement configurs en dbut de la conception avec une
optimisation l'esprit ; ils peuvent tre aussi adapts dynamiquement pendant les excutions.
Cependant, pour les rglages dynamiques, des en-ttes ou des fonctions supplmentaires sont
indispensables pour assurer que les paramtres soient correctement mis jour.
couche optimise
couche optimise
Super Layer
Type 2 :

Type 3 : Type 4:

Fusionner les

prconfigurer Calibrer verticalement

couches adjacentes

les couches les couches

Figure V-15 : Diffrentes conceptions de Cross-Layer - Type 2, 3 et 4.
V.2.2 Les architectures Cross-Layer
Dan la section prcdente, nous avons prsents plusieurs types de techniques Cross-Layer
pour loptimisation globale des performances de systme de communication. Dans la suite, nous
105
montrerons comment ces diffrentes conceptions de Cross-Layer sont mises en uvre dans
les diffrentes architectures (Figure V-16).
Communications directes entre les couches
Cette implmentation permet aux couches de communiquer directement entre elles (conception
de Type 1 ou Type 4 - dynamique). Cest--dire que les variables dune couche peuvent tre
connues par les autres. Il existe plusieurs techniques qui permettent les communications directes
entre les couches. Par exemple, utilisant des en-ttes de paquets pour transporter des
informations Cross-Layer ; ou appliquant le protocole ICMP (Internet Control Message
Protocol) en envoyant des messages ICMP du bas vers le haut uniquement quand la valeur dun
paramtre est modifie ; etc. Cependant, les cots supplmentaires (complexit, rduction du
dbit, etc.) sont invitables pour cette implmentation.
Communications via une base de donnes partage
Dans cette architecture, les couches peuvent communiquer entre elles en partageant une base de
donnes commune (on lappelle aussi lunit de la gestion des communications Cross-Layer).
Cette mthode permet une compatibilit avec larchitecture de rfrence car aucune modification
de protocole ne sera introduite. De plus, elle permet une volution libre sur la politique de
gestion des communications sans la modification des protocoles de couches. En gnral, cette
base de donne commune peut tre considre comme une nouvelle interface travers la quelle
les informations sont partages (conception de Type 1). Cette mthode convient aussi
lapproche de Type 4. Lenjeu de cette implmentation est la conception des interactions dans
une seule entit commune.
Communications via un modle compltement abstrait
La troisime architecture sabstrait compltement de larchitecture de rfrence. Elle propose

une nouvelle faon dorganiser les protocoles : en groupes, mais plus en couches. Cette
architecture permet une grande flexibilit et une richesse dinteractions entre les groupes de
protocoles. Par contre, cette approche viole compltement larchitecture de rfrence en couches
et a besoin dune mise en uvre absolue.
106
interface
existante
base de
donnes
partage
nouvelle
interface nouveau groupe
Communications Communications via une Communications via un

directes base de donnes partage modle compltement abstrait
Figure V-16 : Implmentations dinteractions Cross-Layer .
V.2.3 Techniques Cross-Layer dans les systmes de communication par

satellite
Dans cette section, un aperu des diffrentes techniques Cross-Layer dans le contexte de
rseaux de communication par satellite est prsent. Ces exemples nous permettent de
comprendre plus concrtement les mises en uvre des interactions Cross-Layer dans les
diffrents systmes et de trouver des ides personnelles pour loptimisation du systme tudi.
Bien videmment, dans cette partie, nous nous concentrons plus particulirement sur les
techniques pour la gestion des ressources et loptimisation des performances. Des informations
complmentaires sur ce sujet peuvent tre trouves dans la rfrence [GIO 07], ainsi que dans le
Special Issue de la revue internationale des communications par satellite [IJSC 06].
V.2.3.1 Cross-Layer pour loptimisation de la gestion de ressources
Concernant loptimisation de la gestion des ressources satellitaires, ce sont les couches dites
satellite dpendant qui utilisent les techniques Cross-Layer .
Dans le cas o les techniques FMT (ACM, DRA, etc.) sont utilises pour adapter en temps rel la
couche physique du systme ltat dynamique du canal de propagation, la couche MAC doit
prendre en compte ces changements au niveau physique pour le contrle daccs. Comme
prsente dans la partie III.2.3, les ressources satellitaires disponibles sur le lien retour DVB-RCS
sont sous forme de trames MF-TDMA. Une boucle de contrle est mise en uvre entre les
couches MAC et physique et permet dadapter dynamiquement la structure MF-TDMA la forme
donde utilise (AC : Adaptive Coding) [VAZ 08].
107
Dans [LUC 06] [CAN 08- 1], la gestion de ressource (particulirement sur le lien aller DVB-S2) est
optimise par une mthode dencapsulation flexible et des interactions entre la couche
dadaptation et MAC. Cette mthode dencapsulation sadapte bien lutilisation dACM dans
DVB-S2 et ces travaux ont contribus partiellement la dfinition du protocole GSE [GSE 07].
Loptimisation de lallocation de la ressource pour les connexions TCP est aussi une problmatique
dj largement tudie dans la littrature. Le lien satellite est considr comme le goulot
d'tranglement partag par plusieurs connexions TCP. Dans [CHI 06], les performances de TCP
sont optimises par la mise en correspondance des requtes de capacit et de la taille de fentre
de congestion du TCP. Une autre optimisation est propose dans [PEN 06], elle spare les
connections TCP (Split-TCP) par les PEPs (Performance Enhancement Proxies). Lavantage
dutiliser les PEPs est que la congestion TCP peut tre gre entre ces PEPs sans changer la
configuration de lutilisateur final. Une signalisation de la couche MAC la couche TCP (PEP) est
alors propose pour notifier la congestion en mesurant le remplissage de la file MAC par
lalgorithme RED.
V.2.3.2 Cross-Layer pour loptimisation de performances
Il est logique que loptimisation de la gestion de ressource puisse amliorer les performances.
Dans cette partie, nous nous ne concentrons que sur les techniques qui impactent directement les
performances pour les utilisateurs (exprimes en dlai, gigue, taux de perte, etc.). La plupart des
travaux dans ce domaine sintressent notamment aux interactions entre les couches daccs,
rseau et physique.
Concernant lalgorithme dordonnancement, [VIE 06] propose des interactions entre les couches
physique, MAC et IP. Ces interactions permettent dadapter, dune manire quitable, la
configuration de lordonnanceur aux conditions de propagation et de diffrencier les services
pour garantir les besoins de performance. Dans [NAR 06], lordonnanceur au niveau IP peut
continuer garantir la QoS pour les services diffrentis ou rservs grce lutilisation des
interactions entre la couche MAC et IP.
Au niveau du contrle derreur, [CAN 08-2] propose deux mcanismes. Le premier partage des
informations entre les deux couches (FEC de la couche physique et CRCs de la couche
dadaptation). Ce mcanisme permet de rduire la partie redondante de CRC afin de limiter la
108
proportion den-tte. Le deuxime consiste corriger efficacement et prcisment des erreurs de

la couche basse selon len-tte de la couche suprieure.
109
Chapitre VI
VI. ARCHITECTURE DU TERMINAL AVION : APPROCHE

DYNAMIQUE AVEC ENCAPSULATION GENERIQUE
Dans le chapitre prcdent, plusieurs exprimentations par simulation ont t menes afin de
dfinir larchitecture du terminal avion. Nous avons montr la ncessit de mettre en uvre un
mcanisme Cross-Layer pour amliorer les performances. Dans ce chapitre, nous proposons
une nouvelle architecture avec des flux de signalisations entre couches protocolaires pour
optimiser les performances globales du systme avec une nouvelle approche dencapsulation dite
gnrique. Sur la base de ce nouveau scnario, une nouvelle srie de simulations est effectue et
les rsultats permettant dvaluer les performances du systme sont analyss.
VI.1 Architecture retenue pour le terminal avion
VI.1.1 Choix des techniques Cross-Layer
Comme montrs dans le chapitre V, ltude prliminaire des performances de lapproche

classique puis sa version amliore soulignent la ncessit davoir des interactions de type
Cross-Layer pour loptimisation globale du systme. En sappuyant sur ltat de lart des
techniques cross-layer propos au chapitre prcdent, nous choisissons une technique Cross-
Layer pour larchitecture terminal avion dans notre systme reposant sur les trois
considrations suivantes :
La mise en uvre des techniques Cross-Layer doit tre simple et efficace avec un
minimum de violations du modle OSI et des standards.
Lutilisation des interactions adjacentes est prfrable aux interactions non-adjacentes .

Techniquement, les interactions entre les couches adjacentes peuvent tre mises en uvre
111
Chapitre VI - Architecture du Terminal Avion : Approche Dynamique avec Encapsulation Gnrique
simplement par un ajout des primitives supplmentaires dans les interfaces dj existantes.
Par contre, une nouvelle interface ou des en-ttes additionnels sont ncessaires pour les
interactions non-adjacentes.
Les techniques SD-based sont prfrables aux techniques SI-based (mme si centaines
variable des couches SI sont considrs comme les paramtres dentres). Conformment la
dfinition du modle de rfrence BSM, les interactions Cross-Layer entre les couches SD
ne servent qu loptimisation de lutilisation des technologies satellitaire. Ces interactions
peuvent tre considres comme transparentes aux couches SI. Plus concrtement, dans
larchitecture du terminal avion, si les interactions Cross-Layer ne sont focalises que sur
les couches au-dessous de la couche rseau, ceci signifie que nous pouvons avoir une grande
libert pour intgrer ces techniques Cross-Layer dans les technologies satellite DVB sans la
modification des parties satellite indpendant (TCP/IP, ATN et GSM).
En prenant en compte ces considrations pour la mise en uvre des techniques Cross-Layer ,
nous proposons une nouvelle architecture pour le terminal avion. Dans cette architecture, la
gestion de la ressource, la QoS et la priorit daccs sont toutes concentres vers une couche
dadaptation multifonctions , qui est base sur la mthode dencapsulation GSE (nous
lappelons dans la suite couche dadaptation GSE). Les motifs du choix de cette couche
dadaptation GSE comme point dtude pour loptimisation du systme sont :
GSE est la premire mthode dencapsulation qui est standardise avec le concept du Cross-
Layer .
La mise en uvre du protocole GSE est plus simple que le protocole MPE.
Cette architecture est compatible avec la dernire version du standard DVB-RCS pour
introduire lapplication mobile.
Cette architecture finalement retenue est illustre dans la Figure VI-1 et nous lappelons dans la
suite - architecture dynamique avec encapsulation gnrique .
112
1
Couche dadaptation GSE
SRC. ATS Flux
Pr i
PDU CLNP
ori
SRC. AOC
ty
ueQ
u
PID 0
ing
Flux MPEG Lien
SRC. GSM/UMTS
TRAU Serveur MAC
satellite
File MAC
TBTP
Flux
SRC. IP
IP
Requtes de capacit
Flux de donnes Signalisation cross-layer Signalisation DVB
Figure VI-1 : Architecture retenue pour le terminal avion.
VI.1.2 Les flux de signalisation Cross-Layer
Dans lapproche classique, les requtes de capacit sont gnres sur la base du dbit ou du taux
de remplissage des files MAC. Cependant, les rsultats prliminaires de lapproche dynamique
prsente au chapitre prcdent ont dj montrs des limites et des problmes. Nous avons
notamment soulign les difficults pour obtenir une indication reprsentative permettant
dexprimer les requtes de capacit. Toujours dans ce cas, les requtes de capacit sont calcules
non seulement en fonction des caractristiques des trafics mais aussi de la politique de contrle
mise en place la couche suprieure. Pour ces raisons, nous prfrons utiliser dans la nouvelle
approche des informations obtenues lentre de la couche dadaptation (dbit de donnes,
taille de file dattente, etc.) pour gnrer les demandes de capacit.
Dans cette nouvelle approche, il existe deux signalisations Cross-Layer qui permettent le
contrle daccs aux ressources satellitaires sur la voie de retour et la diffrenciation des services :
Signalisation bottom-up de la couche MAC vers la couche dadaptation GSE (1 dans la

Figure VI-1) : le serveur MAC reoit la TBTP envoye par la Gateway/NCC. Il en dduit la
capacit disponible et en informe le processus de contrle mis en place au GSE.
113
Signalisation top-down de la couche dadaptation GSE vers la couche MAC (2 dans la

Figure VI-1) : la couche dadaptation GSE estime la capacit relle ncessaire. Elle en informe
le serveur MAC qui se charge de gnrer les requtes de capacits.
VI.1.3 Mcanismes mis en uvre la couche dadaptation
Comme prsent dans le chapitre III, le paquet MPEG a t retenu dans notre systme comme
format de donnes pour le lien retour DVB-RCS. Bas sur ce format, nous avons propos un
dimensionnement de super-trame MF-TDMA qui prend en compte la mise en uvre des
techniques FMT. Lintrt dutiliser cette structure propre MF-TDMA est double : dabord, elle
permet dappliquer les techniques FMT dans la couche Physique dune faon transparente aux
autres couches suprieures ; aussi, elle facilite ladaptation de la mthode dencapsulation GSE au
lien retour DVB-RCS (qui nest pas forcment en flux continu comme le DVB-S2). En effet, le lien
retour DVB-RCS est considr comme le flux de paquets MPEG o les donnes peuvent tre
transmises dune faon gnrique avec lencapsulation GSE. Comme prsent dans le chapitre IV,
cette mthode dencapsulation permet de multiplexer plusieurs PDUs dans un mme paquet
MPEG (Figure VI-2).
Trafic ATS/AOC Trafic IP Trafic GSM
Rseaux PDU (CLNP) PDU (datagramme IP) PDU (TRAU)
Adaptation
GSE h GSE data h GSE data h GSE data CRC h GSE data
DVB-RCS
H MPEG data H MPEG data
MF-TDMA (MPEG)
h : En-tte de paquet GSE H : En-tte de paquet MPEG
CRC : Cyclic Redundancy Check (nest ncessaire que pour le fragment final de PDU)
Figure VI-2 : Encapsulation GSE sur le lien retour DVB-RCS.
Le serveur MAC connat la capacit totale alloue (sous forme de nombre de crneaux TRF) au
terminal satellite quand il reoit la signalisation TBTP envoye par la Gateway/NCC. Il envoie
immdiatement ce rsultat de lallocation la couche dadaptation GSE par une
114
signalisation Cross-Layer . Sur la base de cette information sur la capacit disponible, GSE est
dabord charg de contrler daccs et dordonnancer les paquets vers la couche infrieure selon
la priorit (flux ATS/AOC > flux TRAU > flux IP). Cette configuration de priorit est base sur la
considration, comme expliqu dans le chapitre III, que le trafic des services aronautiques ATM
a besoin dune grande disponibilit et le trafic GSM prsente une forte contrainte de dlai. Le
trafic IP est transmis en mode Best Effort dans ce contexte, cest--dire quaucune qualit de
service ne lui est garantie.
Ensuite, les paquets ordonnancs sont encapsuls en paquets GSE puis placs dans des paquets
MPEG (taille fixe de 188 octets) comme indiqu dans la Figure VI-2 pour tre envoys. Grce
lutilisation de Frag ID (Identifiant du fragment), le filtrage au niveau rseau est possible la GW.
Dans ce cas, un PID est suffisant pour multiplexer les trois types de flux dans un seul canal logique
auquel sajoute un PID supplmentaire pour la signalisation. Le nombre de terminaux avion peut
tre doubl par rapport lapproche classique dans laquelle 4 PIDs sont ncessaires pour chaque
terminal.
La couche dadaptation GSE analyse le profil des flux de trafic entrant afin dindiquer le dbit ou le
volume ncessaire pour chacun deux. Cela signifie que la couche MAC neffectue quune mise en
forme des requtes de capacit afin de les rendre conforme qu format DVB-RCS. Le flux ATS/AOC
est gr par volume du fait de sa forte sporadicit. Il est associ lidentifiant Channel ID 0. Le
flux GSM est gr par dbit et utilise lidentifiant Channel ID 1. Le traffic IP est gr par volume et
utilise lidentifiant Channel ID 1. De cette faon, le centre de contrle NCC dispose dune
connaissance des besoins pour chaque flux de faon distincte ce qui permet dappliquer une
politique de priorit au niveau de lalgorithme DAMA.
VI.1.4 Dimensionnement des files dattente du Terminal Satellite.
La taille des files dattente est un facteur important pour garantir la QoS et optimiser lutilisation
de la ressource du rseau. Les files dattente sont essentielles pour absorber les rafales de trafics.
Le sous dimensionnement dune file dattente engendre une sous utilisation de la ressource avec
un grand taux de perte de paquets. Cependant, une file dattente de taille plus grande introduit
des dlais dattente plus importants. Dans certains cas, ces dlais importants peuvent tre
critiques, notamment pour les flux fortes contraintes temporelles (par exemple, le service
115
GSM/UMTS). Cest pour cela que les files dattente doivent tre dimensionnes avec un
compromis entre le dlai et le dbit.
Dans larchitecture dynamique avec GSE, la gestion de la ressource et la qualit de service sont
mises en place la couche dadaptation. Dans notre modle, la file MAC est suppose avoir une
taille suffisamment grande pour garantir quil ny aura pas de rejet de paquet et vrifier quil ny
aura pas de congestion ce niveau. Grce au contrle daccs mis en place dans la couche
dadaptation, la taille de cette file MAC ne dpassera jamais le nombre maximum des crneaux
TRF qui peuvent tre transmis dans la dure dune super-trame. Dans cette architecture, le
dimensionnement des files dattente la couche dadaptation GSE est dterminant.
Pour le flux ATS/AOC, une file dattente de taille suffisamment grande est utilise. Cette
configuration permet davoir une grande disponibilit pour les services cockpit avec un mode de
transmission sans rejet.
Cependant, pour le flux GSM/UMTS, il est difficile de paramtrer la taille du buffer :

premirement, il est ncessaire davoir une file assez grande pour absorber les rafales du trafic.
Comme montr dans la partie II.3.2, le nombre maximum des TRAU gnres pendant la dure
dune super-trame est (60/20) x 28, soit 84 TRAU. Deuximement, cette file ne peut pas tre trop
grande, sinon, les dlais requis ne peuvent pas tre garantis. Comme indiqu dans le chapitre II, le
dlai maximum admis pour le service GSM/UMTS est de 400 ms. Sachant que le dlai de
propagation du canal satellite est 250 ms et le dlai maximum introduit par la file MAC est 60 ms
(dure dune super-trame), le dlai maximum dattente dans la couche dadaptation ne doit pas
dpasser 90ms. Nous supposons que le trafic de type RBDC est garanti avec un dbit de 256
Kbps, dans ce cas, la taille maximum du buffer est donc :
(Dlai maximum* Dbit garantie)/ Taille dune trame TRAU
(90ms*256kbps)/320bits = 72 TRAU
Pour avoir un compromis entre le dlai et le dbit entre ces deux considrations, nous proposons
dutiliser une file dattente relativement petite : 80 TRAU. Une analyse laide dun modle de
type bande quivalente permet de valider le choix de cette taille de file dattente et destimer
le dbit de sortie ncessaire pour la source de trafic GSM/UMTS. Le trafic gnr est envoy dans
une file dattente de taille ebw_max_queue_size. Cette file sert les paquets entrant avec un dbit
116
ebw_rate. La gigue admise ebw_jitter est lie aux deux paramtres prcdents par lquation :
ebw_jitter= ebw_max_queue_size / ebw_rate. Le principe de ce modle est montr sur la figure
suivante.
ebw_max_queue_size = ebw_jitter/ebw_rate
Source GSM ebw_rate
taux de perte
Figure VI-3 : Modle bande quivalente pour la source GSM.
La simulation indique que pour un taux de perte admis de 10-7 et une taille de file dattente de 80
TRAU, le dbit ncessaire est de 280 Kbps.
100000 150000 200000 250000 300000 350000 400000

0
-1
-2
50
log10(loss_ratio)
-3
60
70
-4
80
90
-5
100
-6
-7
-8
ebw_rate
Figure VI-4 : Modle bande quivalente GSM, taux de perte vs dbit (taille de file en paramtre).
Pour le trafic IP, la file dattente est dimensionne par la mise en uvre de lalgorithme RED. En
effet, RED est un mcanisme de gestion de files d'attente qui permet de garder la taille moyenne
de file dans un intervalle prvu. Cependant, cet intervalle doit tre soigneusement configur dans
notre architecture car il est non seulement utilis pour le contrle de congestion, mais participe
aussi au calcul de requtes de capacit VBDC. Une file de taille trop petite introduit une sous
utilisation du rseau (trop de paquets sont rejets, moins de requtes de capacit VBDC sont
117
envoyes) ; par contre, au cas o on utilise une file de taille trop grande, les dlais dattente sont
plus importants. Nous choisissons donc dutiliser les paramtres par dfaut prciss dans [FLO 93].
VI.2 Etude des performances

Pour valuer les performances du systme de lapproche dynamique avec encapsulation GSE et
les comparer avec les rsultats des deux architectures prsentes dans le chapitre V (approche
classique et approche dynamique), un scnario de simulation est propos avec OPNET Modeler.
Ce dernier modle est dtaill dans lAnnexe F.
VI.2.1 Simulation avec un seul terminal et conditions de propagations fixes
Tout dabord, nous effectuons des simulations avec la mme configuration que les deux
approches prcdentes. Cest--dire, le nombre de crneaux TRF allous un terminal varie
alatoirement et suivant une loi uniforme de 24 36 crneaux.
Les volumes reus en 1 heure pour les trois types de flux sont montrs dans le Tableau VI-1. Nous
remarquons que lapproche dynamique avec GSE offre de meilleures performances sur
lutilisation de la ressource (un gain denviron 16% par rapport l'approche dynamique). Cette
optimisation est obtenue grce lutilisation de GSE qui permet une encapsulation flexible
adapte la capacit disponible. En effet, dans les deux approches prcdentes, les PDU sont
encapsuls et places dans des paquets MPEG dune faon statique et indpendante. Dans ce
cas, le format de donnes DVB-RCS (MPEG avec la taille strictement fixe) est une contrainte
importante pour lutilisation de la ressource. Par exemple, pour le service ACL, 2 paquets de 93
octets sont gnrs chaque utilisation du service. Dans les deux approches prcdentes, 2
paquets MPEG (2x180 octets sont utiles) sont ncessaires, cela correspond une capacit libre
denviron 50%. Cependant, cet espace libre ne peut pas tre utilis par les autres flux comme
GSM/UMTS ou IP puisque le multiplexage nest effectu qu la couche infrieure - MAC. Cet
espace libre reprsente donc une perte de capacit. Au contraire, dans lapproche avec
lencapsulation GSE, les PDU sont encapsuls dune faon adaptive et gnrique . Le
multiplexage peut tre effectu dans la couche dadaptation, cest--dire que plusieurs PDU
peuvent se trouver dans un mme paquet MPEG mme si elles nappartiennent pas au mme flux.
La contrainte introduite par la taille fixe des trames MPEG sera moins importante dans ce cas.
118
Nous prenons le mme exemple pour le service ACL, 2 paquets MPEG sont toujours ncessaires,
mais lespace qui reste dans ces paquets MPEG peut tre utilis par les paquets des autres flux.
Dans ce cas, nous pouvons par exemple multiplexer un segment de paquet ACL, une trame TRAU
et un segment de datagramme IP, dans une seule trame MPEG.
Dbit du seau Volume Volume Volume Volume

perc (R) ATS/AOC reu GSM/UMTS reu IP reu Total reu
(Kbps) (Kilo octets) (Kilo octets) (Kilo octets) (Kilo octets)
448 60 76,984 162,630 239,674
Dynamique 60 76,850 192,067 268,977
GSE 60 77,162 233,145 310,367
Tableau VI-1 : Comparaison des trois approches - Volumes reus en 1 heure.
Les courbes de densit de probabilit cumules des dlais de couche 3 couche 3 pour les trois
types de services sont montres dans la Figure VI-5. Comme prcdemment, grce la politique
PQ mise en place la couche dadaptation GSE, les trois types de services peuvent tre
diffrentis et transmis avec lordre des priorits ATS/AOC > GSM > IP. Les dlais requis pour les
services cockpit et de tlphonie mobile sont tous garantis. Par contre, par rapport aux deux
approches prcdentes, cette approche dynamique avec GSE permet des dlais beaucoup plus
courts pour les services IP : 95% des datagrammes sont transmis avec les dlais de 750 ms ou
moins (Figure VI-6). Cette amlioration peut tre encore souligne par laffichage des courbes de
densit de probabilit cumules des RTT mesurs au niveau TCP (Figure VI-7).
119
95% <= 0.75 s
Figure VI-5 : Courbes CDF des dlais (ATS/AOC, GSM/UMTS, IP) - Approche dynamique avec GSE.
Figure VI-6 : Comparaison des dlais du trafic IP (IP-IP) entre les trois approches tudies.
120
Figure VI-7 : Comparaison des RTT mesurs (TCP-TCP) entre les trois approches tudies.
Une exprimentation supplmentaire est effectue en mettant le flux GSM/UMTS en veille afin
de vrifier le caractre adaptatif de cette dernire approche. Comme prvu, lapproche GSE
permet au flux IP de sadapter la capacit disponible en loccupant.
Volume
Dbit du seau perc Volume ATS/AOC Volume GSM/UMTS Volume IP
Total
(R) reu reu reu
Recu
(Kbps) (Kilo octets) (Kilo octets) (Kilo octets)
(Kilo octets)
448 60 0 188,638 188,698
Dynamique 60 0 272,969 273,029
GSE 60 0 310,940 311,000
Tableau VI-2 : Comparaison des trois approches - Volumes reus en 1 heure (GSM/UMTS en veille).
De plus, par rapport la premire approche dynamique, cette nouvelle approche GSE permet une
signalisation plus simple. En effet, dans lapproche dynamique que nous avons prsente dans le
chapitre V, la signalisation sert mette en correspondance la capacit disponible pour le flux IP et
le dbit du seau perc mis en place au routeur IP. Cette capacit est estime par le serveur MAC
en calculant le dbit moyen disponible pour le flux IP. Pour viter davoir des contrles fluctuants,
nous avons propos de calculer le dbit moyen glissant pondration exponentielle EWMA.
Evidemment, ce mode de calcul diminue la sensibilit du systme. Par consquent dans la
premire approche dynamique, la taille moyenne de la file MAC (flux IP) est gale 120 MPEG
121
environ (Tableau VI-3). Dans lapproche dynamique avec GSE, le serveur MAC compte le nombre
de crneaux TRF allous au terminal et envoie cette information la couche dadaptation GSE.
Aucune estimation ni calcul nest ncessaire dans ce cas et la capacit disponible constitue une
valeur prcise et reprsentative. Pour la couche dadaptation GSE, cette information peut tre
utilise directement pour le contrle daccs et lencapsulation. La taille moyenne de la file MAC
(flux multiplex) est donc moins importante dans ce cas : 15 MPEG (Tableau VI-3). Ainsi, comme
cit prcdemment, cette approche dynamique avec GSE permet des dlais beaucoup plus petits
pour les services IP sans altrer le niveau de qualit de service qui est toujours garanti pour les
autres flux (ATS/AOC et GSM/UMTS).

Dbit du seau perc Avg RED
ATS/AOC GSM/UMTS IP
(Kbps) (paquet IP)
Fixe : 448 4 5 160 5

Dynamique 4 5 120 5.5
Niveau de mesure GSE GSE GSE/IP MAC
Taille de file Taille de file

Avg RED Taille de file
ATS/AOC GSM/UMTS
(paquet IP) (paquet TRF)
(paquet CLNP) (paquet TRAU)
GSE 0.5 17 9 15
Tableau VI-3 : Comparaison des trois approches - Taille moyenne des files dattente.
VI.2.2 Simulation avec plusieurs terminaux et conditions de propagations fixes
Lobjectif des simulations suivantes est dtudier le comportement du terminal avion dans un
rseau charg. En effet, en fonction du nombre davions devant se partager la mme ressource
radiolectrique, le comportement attendu de lalgorithme dallocation de ressource DAMA du
centre de contrle NCC peut tre diffrent de la simulation simplifie retenue jusqualors.
VI.2.2.1 Configuration du scnario et trafic exogne
Le modle de simulation utilis reprend les mmes lments que le modle prcdent. Un
terminal avion est simul avec une chane de lien retour complte : sources de trafic, couche
122
dadaptation GSE, couche daccs et nud de transmission. La Figure VI-8 rappelle cette
configuration :
Sat_terminal_aero
Figure VI-8 : Modle de simulation N avions.
La station terrienne GW est galement simule avec les diffrentes couches protocolaires et la
connexion aux serveurs dapplication.
La principale difficult vient de la simulation des autres avions partageant la mme ressource
radiolectrique que le terminal tudi. Une premire solution serait dinstancier plusieurs fois le
terminal avion. Ceci conduit des simulations trs difficiles manipuler en raison du nombre
dvnements gnrs, de la taille des fichiers de rsultat et par consquent du temps de
simulation. Le choix a donc t fait de simuler les autres avions sous forme dun trafic exogne.
123
Un nud spcifique (Exo_traffic sur la Figure VI-8) est introduit dans la simulation ; ce nud
gnre les requtes de capacit correspondant au trafic gnr par (N-1) avions et envoie ces
requtes directement au nud NCC, lalgorithme DAMA prend ainsi en compte le trafic gnr
par ces avions. Les requtes du terminal avion complet sont extraites des messages SAC (Satellite
Access Control) ports par les crneaux TRF ou SYNC de la liaison DVB-RCS. La Figure VI-9 illustre
le principe retenu :
Messages SAC
Requtes
RBDC/VBDC
Requtes
Modle GSM MMPP
RBDC/VBDC
DAMA
Modle IP (distribution exponentielle)
(N-1) instances
Figure VI-9 : Modle de simulation N avions, gnrations des requtes de capacit.
Le scnario comprend 12 porteuses en mode ciel clair (mode FMT spectralement le plus
efficace). Ce chiffre est arbitraire et pris en cohrence avec le scnario suivant comportant 20
porteuses dont 8 dans les modes FMT plus robustes. La capacit du systme mesur en entre de
la couche MAC (donc hors overhead du DVB-RCS) est alors de 12.8 Mbps.
VI.2.2.2 Etude des performances en fonction de la charge
Le systme est simul avec un nombre davion variant de 10 100. Pour chaque configuration, 10
simulations avec une initialisation diffrente du gnrateur de nombre alatoire sont lances. Les
rsultats obtenus sont prsents sur la Figure VI-10.
124
(a) Dlais (min, max, moyen) pour le service ATC/AOC.
(b) Dlais (min, max, moyen) pour le service GSM.
125
(c) Dlais (min, max, moyen) pour le service IP
Figure VI-10 : Simulation N avions - Dlais par services.
Le service ATC/AOC nest pas affect par laugmentation du nombre davion dans le rseau au
niveau du dlai moyen. Le dlai maximum augmente de faon limite avec le nombre davion actif.
La qualit de service pour le service ATC/AOC est donc assure quelque soit le nombre davions
dans le rseau. Ce phnomne est un effet de la priorit haute pour ce trafic que ce soit dans le
terminal avion ou au niveau du centre de contrle NCC.
La qualit du service GSM est impacte partir de 80 avions. La gigue augmente alors de manire
sensible. Il est surtout ncessaire de tenir compte du dlai maximal observ ( 99%). En effet,
bien que la liaison satellite utilise un format paquet (trames TRAU encapsules par tapes
successives jusquau crneau TRF), le rseau GSM reste synchrone et les trames TRAU doivent
tre resynchronises avant traitement par la BSC. La limite de retard admis peut tre fixe 320
ms. Cette valeur avait t retenue comme objectif de performances des services de classe QoS 1
dans les rseaux ATM (Asynchronous Transfer Mode) utilisant une liaison satellite [ITU I.356].
126
Le service IP est visiblement la variable dajustement du systme. Le retard maximal des

datagrammes IP augmente assez vite au-del de 50 avions. Surtout, la Figure VI-11 montre que le
dbit moyen offert au trafic IP dcroit rapidement.
Figure VI-11 : Simulation N avions - Dbit moyen IP.
VI.2.2.3 Etude du fonctionnement du rseau charg
Nous analysons dans cette partie le fonctionnement du rseau avec 60 avions. Lobjectif est de
prciser les conditions de fonctionnement des diffrents nuds de communication et ainsi de
mettre en vidence lenchanement des traitements.
La Figure VI-12 prsente la rpartion des dlais observs pour les trois services (CDF : Cumulative
Distribution Function). Le comportement est similaire celui obtenu avec les simulations utilisant
le modle DAMA simplifi (Figure VI-5).
127
Flux ATS/AOC
Flux GSM/UMTS
Flux IP
Figure VI-12 : Simulation 60 avions - CDFs des dlais par services.
Il est intressant de regarder de quelle faon se rpartit lallocation de ressource dans cette
simulation charge. La Figure VI-13 prsente la rpartition du nombre de crneaux allous au
terminal tudi. Lhypothse retenue pour les phases prcdentes de ltude, savoir une loi
uniforme entre deux bornes, apparat comme une simplification raisonable au vu du comptement
observ avec le DAMA complet.
Figure VI-13 : Simulation 60 avions - CDFs du nombre de crneaux allous.
128
La Figure VI-14 prsente la faon dont les requtes en dbit sont gnres pour le service GSM.
La difficult principale vient de la diffrence dchelle de temps entre la gnration du trafic (les
trames TRAU sont gnres toutes les 20 ms) et la gestion DVB-RCS (supertrame de 59 ms). Par
ailleurs, le temps de boucle pour la signalisation est long compar lvolution du trafic (250 ms
pour lenvoi de la requte, 59 ms pour le traitement et 250 ms pour le retour). La gnration des
requtes repose donc sur une estimation lisse du dbit (estimation par fentre glissante, courbe
verte) puis les requtes sont gnres en tenant compte de ce dbit liss et de sa variance
(courbe rouge). Il apparat clairement que les besoins de la source de trafic temps rel sont sur-
estims, condition ncessaire pour que la gigue observe reste satisfaisante.
Dbit GSM gnr (bit/s)

RBDC (bit/s)
Estimation lisse du dbit (bit/s)
Figure VI-14 : Simulation 60 avions - Gnration des requtes de capacit en dbit pour le service GSM.
La validit de ce principe de gnration des requtes de capacit en dbit peut tre vrifie
laide dune simulation o seul le trafic GSM est prsent (pas de trafic IP). Ainsi, les transferts de
capacit entre services GSM et IP sont supprims. La Figure VI-15 prsente la rpartition des
dlais dans ce cas. 99% des trames TRAU subissent un dlai infrieur la limite impose de 320
ms.
129
Figure VI-15 : Simulation 60 avions - CDF du dlai dans le cas dun trafic GSM seul.
VI.2.2.4 Performances daccs pour un avion avec le seul trafic ATC/AOC
La simulation est ensuite utilise pour simuler un rseau charg (60 avions) dans le cas o seul le
service ATC/AOC est activ bord de lavion observ. Lobjectif est de vrifier que la gestion de la
qualit de service mais galement la mthode daccs sur la liaison DVB-RCS permettent de
maintenir les objectifs fixs pour le service ATC/AOC en dpit de sa forte sporadicit.
La Figure VI-16 rappelle la squence dchange entre le terminal avion et le centre de contrle
dans le cas de la transmission de messages isols. La procdure mme de signalisation du DVB-
RCS ne permet pas dobtenir des retards infrieurs 750ms dans ce cas.
130
Terminal Avion Gateway/NCC

GSE MAC
Message ATC/AOC SYNC

Requte de capacit
(VBDC, Channel ID : 0)
DAMA
TBTP
Paquets MPEG TRF

(message ATC/AOC)
Paquets MPEG
(message ATC/AOC)
Rassemblage
Message ATC/AOC
Figure VI-16 : Squence dchange DVB-RCS dans le cas dun message ATC/AOC isol.
La Figure VI-17 prsente la distribution des dlais. La ncessit dune premire signalisation
daccs par crneau SYNC en dbut de rafale de trafic augmente sensiblement le temps daccs, la
distribution CDF montre que les retards observs sont suprieurs 750 ms.
Figure VI-17 : Simulation 60 avions - Distribution (CDF) des dlais pour trafic ATC/AOC seul.
131
La seule solution pour viter ces temps daccs serait une allocation de ressource fixe (CRA
Continuous Rate Allocation) qui irait lencontre de la recherche defficacit de la gestion de la
ressource.
La Figure VI-18 prsente le cumul de toutes les requtes traites par lalgorithme DAMA dans le
centre de contrle NCC. Ce graphe confirme que la configuration de la simulation correspond un
scnario charg.
Figure VI-18 : Simulation 60 avions - Requtes de capacit cumules en entre du NCC.
VI.2.3 Simulation avec plusieurs terminaux et conditions de propagations

variables
Afin de complter notre tude, nous avons effectu des simulations intgrant plusieurs terminaux
et des conditions de propagations variables. Lobjectif est ici simplement de montrer que la
conception du terminal avion est capable de prendre en compte les variations de capacit du lien
satellite.
Il nexiste pas lheure actuelle de modle accessible pour le canal de propagation aronautique
en bande Ka. Le canal de propagation en bande Ka a t tudi de faon approfondie par
132
lONERA dans le cas de stations terriennes ; les modles correspondant fournissent des sries
temporelles dattnuation tenant compte de la conception de la boucle de dcision FMT [CAS 04].
Ces fichiers peuvent tre lus par le modle de simulation OPNET. La Figure VI-19 nous donne un
exemple pour ce type de fichier dentre. Comme attendu, nous voyons que les modes FMT
suivent bien les conditions de propagation.
Figure VI-19 : Exemple de fichier dentre du modle de simulation.
Dans notre cas, le comportement attendu de la liaison satellite est sensiblement diffrent que
dans le cas dun terminal fixe au sol :
- le mouvement de lavion conduit le terminal sortir de la zone dattnuation due la

pluie, principale contribution lattnuation en bande Ka. Le mouvement horizontal
permet de traverser rapidement les cellules de pluie dont le diamtre nexcde pas
quelques kilomtres. Le mouvement vertical amne lavion au-dessus de la couverture
nuageuse.
- dautres effets difficilement modlisables contribuent modifier le bilan de liaison. Par

exemple, lvolution de lavion basse altitude impose des contraintes sur le pointage
antenne et peut conduire une rduction de la puissance rayonne afin dviter
dinterfrer avec les satellites proches.
133
Il a donc t choisi dutiliser un profil simplifi pour lvolution des modes FMT avec une premire
pente faisant passer le terminal du mode 0 (le plus robuste et le moins spectralement efficace) au
mode 4 (le moins robuste mais le plus efficace) sur une priode de 14 minutes, puis une seconde
pente du mode 4 au mode 0 pendant la dernire partie du vol (1 heure simule au total). Ce profil
FMT est prsent sur la Figure VI-20.
Figure VI-20 : Profil FMT pour la simulation.
Conformment ce qui est prsent dans le chapitre III, la ressource radiolectrique correspond
un ensemble de porteuse dans un rpteur de 25 MHz (Tableau VI-4). La rpartiation par mode
FMT est la suivante :
Nombre de TRF slots disponibles

Nombre de porteuse Mode FMT associ
par porteuse
2 0 2
2 1 8
2 2 24
2 3 32
12 4 36
Total 20 5 modes 636
Tableau VI-4 : Rpartition de la ressource radiolectrique dans la simulation.
Les rsultats de simulation obtenus sont prsents sur les figures suivantes.
134
Figure VI-21 : Dlais ATC/AOC et GSM avec modes FMT variables.
Figure VI-22 : Dlais IP avec modes FMT variables.
Les courbes prsentes sur les prcdentes montrent que le terminal gre les priorits de trafic
quelque soit le mode activ. La capacit de la liaison satellite est insuffisante sur les modes 0 et 1
pour assurer la transmission du trafic GSM. Le trafic IP ne peut tre achemin qu partir du mode
2.
135
CONCLUSION
La thse prsente dans ce mmoire trouve son origine dans les travaux mens l'ENAC et l'ISAE
sur les rseaux de communication aronautiques. Ces dernires annes, ce domaine connat une
volution rapide pour la partie contrle arien et communications des compagnies ariennes avec
le dploiement de nouvelles liaisons de donnes (par exemple VDL Mode 2). Par ailleurs, lis aux
nouvelles habitudes en mobilit, une demande croissante est apparue pour des services offerts
en cabine aux passagers. Dans le domaine des communications par satellite, la rponse ces deux
besoins passe actuellement par le dploiement de systmes disjoints (par exemple INMARSAT et
Connexion by Boeing). Il est apparu intressant d'tudier les modalits de dploiement d'un
systme de communication par satellite unique assurant l'ensemble de ces services.
Dans notre scnario, la liaison satellite fournit un sous-rseau d'accs entre un terminal avion et
l'infrastructure terrestre. Aussi, il est particulirement important d'identifier de quelle faon ce
sous-rseau s'intgre dans l'architecture globale. Notre proposition repose sur l'intgration de la
liaison satellite dans trois rseaux :
- le rseau aronautique ATN (Aeronautical Telecommunication Network). Ce rseau, bas sur

une architecture OSI (structure en couches et protocoles associs), supporte l'ensemble des
services aronautiques ATC (Air Traffic Control) et AOC (Aeronautical Operational
Communications).
- le rseau de tlphonie mobile GSM (Global System for Mobiles). Ce rseau est structur avec
une approche connexion qui impose par consquent des contraintes fortes sur les formats de
donnes et la synchronisation dans le rseau.
- le rseau Internet. Les protocoles utiliss sont alors ceux du modle TCP/IP.
Les diffrents services prsentent une forte htrognit en terme de caractristiques (volume
et sporadicit notamment) mais aussi en terme de qualit de service requise (taux de perte, dlais,
et gigues). Nous avons men l'tude sur deux axes : caractrisation des sources de trafic, tant du
137
CONCLUSION
point de vue ressources ncessaires que qualit de service, et dfinition des points de
convergence possible entre ces trois rseaux fondamentalement htrognes.
Architecture du systme
Dans une premire tape, nous nous sommes concentrs sur la caractrisation des services et
lidentification des protocoles utiliss.
Dans le cas du rseau ATC/AOC, la caractrisation des services a t ralise l'aide d'une tude
prospective mene par Eurocontrol et la FAA (Federal Aviation Administration) appele COCR.
Cette tude fournit une liste qui se veut exhaustive des services aronautiques avec les
performances attendues pour la transmission des informations. Il est ncessaire de synthtiser
l'important volume de donnes contenu dans ce document pour extraire les services
effectivement utilisables avec une liaison satellite et les domaines de vol associs. Ce travail est
concrtis par le dveloppement dun modle de trafic.
Le rseau GSM a t choisi comme base pour le service de tlphonie mobile bord de l'avion. En
effet, en dpit des volutions constantes des rseaux mobiles, le rseau GSM reste dominant au
niveau mondial. Par ailleurs, l'utilisation de liaisons satellite l'intrieur des rseaux GSM est
valide par le dploiement de plusieurs solutions par rseaux VSAT. Notre proposition est
caractrise par l'utilisation d'un format paquet entre la station BTS bord de l'avion et la station
BSC au sol. Dans les rseaux GSM terrestres, l'interface Abis entre ces deux noeuds utilise un
multiplex temporel (trame MIC). Cependant, les donnes issues des communications
tlphoniques ainsi que la signalisation utilisent un format appel TRAU (TRansceiver Adaptation
Unit). Ce format est prsent dans la partie IV du mmoire et a t retenu pour la transmission
sur la liaison satellite. Il est cependant noter qu'une resynchronisation de ces trames TRAU est
ncessaire aprs le bond satellite ce qui impose un respect strict de la borne suprieure du dlai
de transmission.
Il est apparu naturel de considrer le rseau TCP/IP dans notre architecture. La demande des
utilisateurs dans l'avion est de disposer d'un accs Internet avec les services associs : courrier
lectronique, navigation Web ... Les satellites sont couramment utiliss pour fournir un accs de
ce type et l'ETSI propose en particulier tout un ensemble de normes regroupes sous le terme
BSM (Braodband Satellite Multimedia).
138
CONCLUSION
D'un point de vue dfinition du rseau d'accs satellite, la solution retenue repose sur les normes
ETSI DVB-S2 (lien aller) et DVB-RCS (lien retour). Ces normes dfinissent la fois la couche
physique (formes d'onde) et la couche d'accs (canaux physiques et logiques). Par ailleurs, nous
avons fait le choix de la bande Ka pour le dimensionnement des liaisons. Ce choix est motiv par
la rglementation ITU et l'allocation de bandes de frquence importantes pour les
communications mobiles aronautiques dans cette bande. Dans les rseaux de terminaux fixes,
l'utilisation de la bande Ka va de pair avec l'activation de techniques FMT (Fade Mitigation
Techniques). En effet, entre 20 et 30 GHz, les attnuations observes peuvent tre importantes, la
pluie tant la principale contribution. Il n'existe pas l'heure actuelle de modle de propagation
aroanutique ces frquences, mais les conditions de propagation seront assurment trs
diffrentes du fait du mouvement de l'avion. Les FMT n'en sont pas moins un moyen
indispensable pour adapter dynamiquement le bilan de liaison soit du fait de problmes de
propagation, soit du fait dune modification des paramtres (pointage antenne, adaptation de la
puissance rayonne ...). Nous avons pris en compte ces FMT dans la dfinition du systme avec
une dynamique leve. Ce rsultat est obtenu par combinaison de la technique de contrle de
puissance de la liaison montante (ULPC), de ladaptation de la forme donde (ACM : adaptation
des formats de modulation et de codage) et de ladaptation du dbit (DRA).
Architecture du terminal avion
L'tude de l'architecture du terminal avion est focalise sur la liaison retour (avion vers station
terrienne). En effet, cette liaison est la plus contraignante du point de vue de la mthode d'accs.
Lvaluation des performances repose sur l'utilisation dun logiciel de simulation vnements
discrets (OPNET Modeler). La dmarche est la suivante :
- tude des architectures protocolaires par simulation dtaille du terminal et utilisation d'un
algorithme d'allocation de ressource (DAMA) simplifi dans la station terrienne. La capacit
alloue au terminal est ainsi totalement matrise (allocations moyenne, minimale, maximale)
afin d'identifier les problmes potentiels dans les couches d'accs elles-mmes.
- analyse de l'architecture finalement retenue pour le terminal avion dans une simulation
comportant en plus du terminal avion lui-mme une simulation du trafic gnr par les autres
avions en concurrence sur la ressource radiolectrique disponible. L'algorithme d'allocation
DAMA ragit alors aux requtes de capacit provenant de tous les utilisateurs du rseau d'accs
139
CONCLUSION
et la capacit disponible pour le terminal peut varier rapidement. Cette simulation prend
galement en compte l'volution des modes FMT.
L'ensemble des modles ainsi dvelopps nous ont permis de mettre en vidence la ncessit
d'utiliser une pile protocolaire avec des interactions inter-couches ("cross-layer"). Nous avons
finalement obtenu une architecture du terminal avion dite dynamique avec encapsulation
gnrique. Cette nouvelle approche est base sur lutilisation de la technique rcente GSE
(Generic Stream Encapsulation) qui permet lencapsulation flexible et efficace sur un canal
dynamique. Dans notre systme, avec lutilisation de la signalisation Cross-Layer , GSE permet
dordonnancer et de multiplexer les diffrents types de flux dune faon gnrique et adaptative.
Les performances du systme bas sur cette architecture finale ont t values par simulations.
Cette approche dynamique avec GSE offre les meilleures performances, notamment pour les
services daccs Internet pour les passagers, tout en garantissant les performances requises
pour les autres flux prioritaires (ATS/AOC et tlphonie mobile).
Futurs travaux et perspectives
Plusieurs axes peuvent faire suite cette thse.
Nous avons prsent brivement dans le chapitre III une version prliminaire de la mise jour de
la norme DVB-RCS qui a t publie dbut 2009 [ETSI 301 790]. Les nouveauts dans cette
version se concentrent plus particulirement sur lapplication du DVB-RCS dans le contexte de
services mobiles par satellite. Nous avons justement tudi la compatibilit entre cette nouvelle
version de norme et notre dernire solution avec lencapsulation GSE. Des travaux
supplmentaires sont ncessaires pour intgrer la nouvelle version de la norme DVB-RCS dans
larchitecture propose ainsi que dans le modle de simulation.
De plus, deux axes dtudes pourraient complter notre tude :
- le premier axe concerne lintgration du systme dans lavion. Parmi les quipements
ncessaires, le plus critique est lantenne. La ncessit dune intgration dans le fuselage avion
(traine rduite) favorise la solution dune antenne active. De nombreuses interrogations
subsistent sur les performances de pointage et de formation du faisceau de telles antennes. Hors
ces performances conditionnent la fois le dbit maximal disponible et la compatibilit du
nouveau systme avec les systmes existants (interfrences avec les satellites adjacents).
140
CONCLUSION
- par ailleurs, nos efforts ont ports sur la conception du terminal avion. Dans le cas o un tel
systme de communication par satellite serait dploy sur une majorit des avions commerciaux,
le dimensionnement global du rseau deviendrait critique. Ainsi, il serait ncessaire dvaluer le
nombre de satellites pour une couverture europenne, le type de charges utiles (mono ou multi-
faisceaux) et les mthodes de rutilisation de frquence.
141
REFERENCE
[3GPP 01] 3GPP TS 48.052 V.7.0.0: "Base Station Controller - Base Transceiver
Station (BSC - BTS) interface; Interface principles". 2007 (ETSI TS
148.052 V.7.0.0)
[3GPP 02] 3GPP TS 25.426 V.7.1.0: UTRAN Iur and Iub interface data transport &
transport signalling for DCH data streams, 2006 (ETSI TS 125.426
V.7.1.0)
[3GPP 03] 3GPP TS 48.054 V.7.0.0: Digital cellular telecommunications system

(Phase 2+); Base Station Controller - Base Transceiver Station (BSC -
BTS) interface; Layer 1 structure of physical circuits, 2007 (ETSI TS
148.054 V.7.0.0)
[3GPP 04] 3GPP TS 48.060 V.7.0.0: Digital cellular telecommunications system

(Phase 2+); In-band control of remote transcoders and rate adaptors
for full rate traffic channels, 2007 (ETSI TS 148.060 V.7.0.0)
[3G Americas] GSM to 3G and Beyond, 3G Americas, 2008
[AeroMobile] http://www.aeromobile.net/
[AirCell] http://www.aircell.com/
[ALO 97] M. S. Alouini, et al. Channel characterization and modleing for Ka-
Band very small aperture terminals, Proc. IEEE, vol. 85, pp. 981997,
1997
[ANASTASIA] http://www.anastasia-fp6.org
[ANNEXE 10] ICAO - International Standards and Recommended Practices:

Aeronautical Telecommunications ANNEX 10 Volume III Part I: Digital
Data Communication Systems; Part II Voice Communication Systems
[ATN SARPs] International Civil Aviation Organization, Manual of technique

provisions for the Aeronautical Telecommunication Network (ATN),
Third edition, 2002
[BOL 04] A.I. Bolea-alamanac, Conception et mise en uvre de mthodes de

compensation des effets du canal de propagation pour optimiser les
ressources radio, thse de lEcole Nationale Suprieure de
lAronautique et de lEspace, 2004
[BRA 69] P. T. Brady, A model for generating on-off speech patterns in twoway
conversation, Bell Syst. Tech. J., vol. 48, no. 7, pp. 2445-2472, 1969.
143
REFERENCE
[CAMAL] Aeronautical Telecommunication Network (ATN) Comprehensive ATN

Manual (CAMAL), Final Editors drafts of the ATN Guidance Material,
1999
[CAN 08-1] J. Cantillo, et al. GSE: A Flexible, yet Efficient, Encapsulation for IP over
DVB-S2 Continuous Generic Streams, International Journal of Satellite
Communications and Networking, 2008
[CAN 08-2] J.Cantilo, Codage multi-couches pour systmes de communication par

satellites, thse, Telecom Paris, 2008
[CAS 03] L. Castanet, et al. Interference and Fade Mitigation Techniques for Ka
and Q/V Band Satellite Communication Systems, COST 272-280
Intl.Wksp. Satellite Commun, 2003
[CAS 04] L. Castanet, et al. Development and validation of time series

synthesizers for Ka-band satellite communication systems, 10th Ka-
band Utilisation Conference, October 2004, Vicenza (Italy)
[CBB-1] E.Laase, et al. Connexion by BoeingSM Global Broadband Satellite

Services for Aircraft, PTC, 2003
[CBB-2] Boeing to Discontinue Connexion by Boeing Service, Boeing news,

2006
[CHA 04] R. Chaggara, Les Modulations Phase Continue pour la Conception

dune Forme dOnde Adaptative Application aux Futurs Systmes
Multimdia par Satellite en Bande Ka, thse de lEcole Nationale
Suprieure des Tlcommunications, 2004
[CHI 06] P. Chini, et al. Dynamic resource allocation based on a TCP-MAC Cross-
Layer approach for interactive satellite networks, International Journal
of Satellite Communications and Networking, 2006
[CISCO] Satellite Backhaul Optimization for GSM and UMTS with RAN
Optimization Solution, http://www.cisco.com, 2005
[COCR 2.0] Communications Operating Concept and Requirements for the Future
Radio System (COCR), EUROCONTROL/FAA Future Communications
Study Operational Concepts and Requirements Team, Version 2.0, 2007
[DTI 00] Services et applications de liaison de donnes, DSNA-DTI, revue

technique 59, 2000
[ETSI 101 202] ETSI TR 101 202 V1.2.1 Digital Video Broadcasting (DVB);
Implementation guidelines for Data Broadcasting, 2003
[ETSI 101 984] ETSI TR 101 984 V1.2.1 Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM); Services and architectures,
2007
144
REFERENCE
[ETSI 102 357] ETSI TR 102 353 V1.1.1 Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM); Guidelines for the Satellite
Independent Service Access Point (SI-SAP), 2004
[ETSI 101 790] Digital Video Broadcasting (DVB); Interaction channel for Satellite
Distribution Systems; Guidelines for the use of EN 301 790, 2006
[ETSI 300 421] Digital Video Broadcasting (DVB); Framing structure, channel coding
and modulation for 11/12 GHz satellite services, 1997
[ETSI 301 192] ETSI EN 301 192 V1.4.1 Digital Video Broadcasting (DVB); DVB
specification for data broadcasting, 2004
[ETSI 301 790] ETSI EN 301 790 V1.4.1 Digital Video Broadcasting (DVB); Interaction
channel for satellite distribution systems, 2005
[ETSI 301 790] Draft ETSI EN 301 790 V1.5.1 Digital Video Broadcasting (DVB);
Interaction channel for satellite distribution systems, 2009
[ETSI 302 307] Digital Video Broadcasting (DVB); Second generation framing
structure, channel coding and modulation systems for Broadcasting,
Interactive Services, News Gathering and other broadband satellite
applications, 2006
[EUROCAE ED-78A] EUROCAE WG 53, Guidelines for approval of the provision and use of
air traffic services supported by data communications (ED-78A)
[FLO 93] S. Floyd, et al. Random early detection gateways for congestion
avoidance, IEEE/ACM Transactions on Networking, 1993
[FLO 97] S. Floyd, RED: Discussions of Setting Parameters, 1997
[GIA 07] G. Giambene Adaptive Resource Management in Satellite Networks:

Optimization and Cross-Layer Design, Springer-Verlag New York Inc.,
2007
[GILAT] Gilats Sky-Abis Solution for GSM via satellite,

http://www.gilatnetworks.com, 2006
[GON 06] J. Gonda, et al. Joint U.S.-European Future Communications Operating

Concept, AIAA/IEEE 25th Digital Avionics System Conference, 2006
[GRE 02] O. Grmillet et al. Aggregate traffic modles for satellite multimedia
services, 20th AIAA International Communication Satellite System
Conference and Exhibit, 2002
[GSE 07] ETSI TS 102 606 V1.1.1, Digital Video Broadcasting (DVB); Generic
Stream Encapsulation (GSE) Protocol, 2007
145
REFERENCE
[HAB 92] I.W.Habib et al. Multimedia traffic characteristics in broadband

networks, IEEE Communications Magazine, 1992
[HAF 07] F. Hafid Fazli, et al. Capacity Dimensioning for Air Traffic Management
(ATM) Services in a Spot Beam Satellite System, IWSSC '07
International Workshop on Satellite and Space Communications, 2007
[HAS 06] H. Hassan, et al. Aggregate Traffic Modles for VoIP Applications,
Digital Telecommunications, ICDT '06., 2006
[HEF 86] H. Heffes, et al. "A Markov Modulated Characterization of Packetized

Voice and Data Traffic and Related Statistical Multiplexer
Performance", IEEE Journal on Selected Areas in Communications,
Volume 4, Issue 6, 1986
[HEI 98] Gunnar Heine, GSM Networks: Protocols, Terminology and

Implementation, Artech House, 1998
[HON 05] T.C. Hong, et al. A Comparison of IP Datagrams Transmission using

MPE and ULE over Mpeg-2/DVB Networks, Fifth International
Conference on Information, Communications and Signal Processing,
2005
[ICAO 07] ICAO - Aeronautical Communications Panel (ACP), 17th meeting of

working group F, Regulatory best practices on the use of mobile
phone on-board the aircraft, 2007
[INMARSAT-1] http://www.INMARSAT.com/
[INMARSAT-2] SwiftBroadband Capabilities to Support Aeronautical Safety Services,

WP3: Airborne Architectures for SwiftBroadband Services,
EUROCONTROL, 2006
[ISO/IEC 7498] Information Processing Systems - OSI Reference Model - The Basic
Model, 1994
[ITU-A5 07] ITU Radio Regulations - Volume 1 (Article 5) international table of

frequencies by ITU Region, 2007
[ITU G.1010] Transmission systems and media, digital systems and networks, quality
of service and performance, End-user multimedia QoS categories, 2001
[ITU I.356] B-ISDN ATM layer cell transfer performance, 03/2000
[ITU-R P.618] Propagation data and prediction methods required for the design of
Earth-space telecommunication systems
[ITU-R P.682] Propagation data required for the design of earth-space aeronautical
mobile telecommunication systems
146
REFERENCE
[ITU-R P.837] Characteristics of precipitation for propagation modelling
[JAC 88] V. Jacobson et al. Congestion avoidance and control, in Proc.

SIGCOMM88, 1988
[JON 01] W.H. Jones, et al. Connexion by BoeingSM-broadband Satellite

Communication System for Mobile Platforms IEEE MILCOM, 2001
[KER 05] R.J Kerczewski, et al. Communications, navigation and surveillance for
improved oceanic air traffic operations, IEEE Aerospace Conference,
2005
[LUC 06] O Lucke, et al. MAC and encapsulation efficiency of satellite DVB using
fade mitigation techniques, International Journal of Satellite
Communications and Networking, 2006
[MON 03] A.D. Monk, et al. Calibration and RF test of Connexion by BoeingSM
airborne phased arrays, IEEE International Symposium on Phased
Array Systems and Technology, 2003
[MOWGLY] http://www.mowgly.org
[NAR 06] A. Narula-Tam, et al. QOS considerations for future military satcom
networks with link layer dynamic resource allocation, International,
2006
[NEWSKY] http://www.newsky-fp6.eu/
[NIV 06] F. Nivor, et al. Amlioration de l'Allocation Dynamique de Ressource

dans un Systme Satellite DVBS/RCS, Colloque Francophone sur
l'Ingnierie des Protocoles CFIP, 2006
[ONAIR] http://www.onair.aero/
[PAN 04] A.D Panagopoulos, et al. Satellite communications at Ku, Ka, and V
bands: propagation impairments and mitigation techniques, IEEE
Communications Surveys and Tutorials, 2004
[PEN 06] F. Peng, et al. Cross-Layer enhancement of TCP split-connections over

satellites links, International Journal of Satellite Communications and
Networking, 2006
[RAD 06] J. Radzik, et al. Satellite Access Performances Assessment and

Optimization for In-Cabin Internet and ATC Traffic, 24th AIAA
International Communications Satellite Systems Conference, 2006
[RAD 07] J. Radzik, et al. Satellite system performance assessment for In-Flight
Entertainment and Air Traffic Control, Space Communications journal,
special issue on Satellite Networks for Mobile Services, 2007
147
REFERENCE
[RFC 2581] M. Allman et al. TCP Congestion Control, 1999
[RFC 2988] V. Paxson et al. Computing TCP's Retransmission Timer, 2000
[RFC 4326] G. Fairhurst, et al. Unidirectional Lightweight Encapsulation (ULE) for

Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS),
2005
[RFC 5136] G. Fairhurst, et al. Extension Formats for Unidirectional Lightweight

Encapsulation (ULE) and the Generic Stream Encapsulation (GSE),
2008
[RTCA-189] RTCA Special Committee-189, ICAO Manual on Required

Communications Performance (RCP Manual)
[SESAR] http://www.sesar-consortium.aero
[SKI 05] H. Skinnemoen, et al. A comparative Study of DVB-RCS, IPOS and

DOCSIS for satellite, 23rd AIAA&Ka Band Joint Conference, 2005
[SRI 05] V. Srivastava, et al. "Cross-Layer Design: A Survey and the Road Ahead",
IEEE Communications Magazine, 2005
[TIA-1008] TIA standard: IP over Satellite (IPOS), 2006

[ETSI TS 102 354] Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM); Transparent Satellite Star - B (TSS-B); IP over
Satellite (IPoS) Air Interface Specification, 2006
[VIE 06] F. Vieira, et al. A tunable-fairness Cross-Layer scheduler for DVB-S2,

International Journal of Satellite Communications and Networking,
2006
[XIL 06] G.Xilouris, et al. Unidirectional Lightweight Encapsulation:

Performance Evaluation and Application Perspectives, IEEE
Transactions On Broadcasting, VOL. 52, NO. 3, 2006
148
PUBLICATIONS
Revue Internationale
Jos Radzik, Alain Pirovano, Na Tao, Michel Bousquet, Satellite system performance assessment
for In-Flight Entertainment and Air Traffic Control, The Space Communications journal, Special
issue on "Satellite Networks for Mobile Services", 2007
Confrences Internationales
Jos Radzik, Alain Pirovano, Na Tao, Convergence of aeronautical communications on a single

DVB-S2/RCS link, accept, 27th AIAA International Communications Satellite Systems Conference
(ICSSC 2009), 1-4 June, 2009, Edinburgh, UK
Na Tao, Michel Bousquet, Alain Pirovano, Jos Radzik, DVB-S2/DVB-RCS satellite system
performance assessment for IFE and ATN aeronautical communications, International Workshop
on Satellite and Space Communications (IWSSC2006), 14-15 September 2006, Universidad Carlos
III de Madrid, Legans, Spain
Jos Radzik, Alain Pirovano, Na Tao, DVB-S2/DVB-RCS satellite system design for in-cabin Internet
and Aeronautical Telecommunication Network, Advanced Satellite Mobile Systems (ASMS)
Conference 2006, Munich, Germany
Jos Radzik, Alain Pirovano, Na Tao, Satellite Access Performances Assessment and Optimization
for In- Cabin Internet and ATC Traffic, 24th AIAA International Communications Satellite Systems
Conference (ICSSC 2006), 11 - 14 June 2006, San Diego, California
149
ANNEXES
Annexe A Recommandation COCR
Nous montrons dans cette annexe les diffrents lments ncessaires pour tudier les
caractristiques du trafic ATS/AOC et la performance du systme. Les hypothses et les valeurs
prsentes sont bases sur la recommandation COCR [COCR 2.0] et concentrs sur la Phase 1
(jusqu' 2020).
Tout dabord, les performances requises pour les services ATS/AOC du futur systme de radio
(FRS) sont listes dans les Tableau A- 1 et Tableau A- 2. Ces exigences sont concentres sur les
communications air-sol point point et dfinies en termes dintgrit, de disponibilit et de TT95
(one-way). Ensuite, les hypothses sur lenvironnement et le mode dopration des diffrents
services ATS/AOC et leurs caractristiques dimplmentation sont dtaills dans les Tableau A- 3,
Tableau A- 4 et Tableau A- 5. Ces hypothses sont utilises pour modliser la source de trafic
cockpit (prsents dans la partie II.3.1) et permettre ltude du comportement et des
performances globales du systme tudi.
151
Annexes
TT95 - one way (sec.)
Service TMA Intgrit Disponibilit

ENR ORP
(Dpart et Arrive)
ACL 3,8 3,8 26,5
ACM 3,8 3,8 26,5
ARMAND / 9,2 /
C&P ACL / 5,7 26,5
D-ATIS (Arriv) 4,7 4,7 /
DLL / 5,7 26,5
D-ORIS / 4,7 26,5
D-OTIS 4,7 4,7 /
D-RVR 4,7 4,7 /
5,00E-06 0,9965
DSC / 22,2 26,5
D-SIG 9,2 / /
D-SIGMET 4,7 4,7 26,5
D-TAXI 5,7 / /
FLIPCY 13,6 13,6 26,5
FLIPINT 13,6 13,6 26,5
ITP ACL / / 26,5
M&S ACL 5,7 5,7 /
PPD 13,6 13,6 26,5
Tableau A- 1 : Performances requises des services ATS pour le FRS.
152
Annexes
TT95 - one way (sec.)
Service TMA Intgrit Disponibilit

ENR ORP
(Dpart et Arrive)
AOCDLL / / 26,5 5,0 E-8
ENGINE 26,5 26,5 / 5,0 E-5
FLTPLAN / 13,6 26,5 5,0 E-8
FLTSTAT / 13,6 26,5 5,0 E-4
FREETEXT / 26,5 51,7 5,0 E-4
FUEL 26,5 26,5 51,7 5,0 E-4
GATES / 13,6 / 5,0 E-4
LOADSHT 13,6 / / 5,0 E-8 0,995
MAINTPR / 13,6 26,5 5,0 E-5
MAINTRT / 26,5 51,7 5,0 E-5
NOTAM / 26,5 51,7 5,0 E-8
POSRPT 26,5 26,5 51,7 5,0 E-5
WXGRAPH / 13,6 26,5 5,0 E-8
WXRT 13,6 13,6 26,5 5,0 E-8
WXTEXT / 13,6 26,5 5,0 E-8
Tableau A- 2 : Performances requises des services AOC pour le FRS.
Paramtre de vol
Domaine oprationnel
Nombre de secteurs Dure (minute)
TMA_Dpart 2 8
TMA_Arriv 2 14
ENR 8 90
ORP 6 255
Tableau A- 3 : Hypothse sur les paramtres de vol.
153
Annexes
Taille du message
Frquence dutilisation
Quantit x Taille (Octet)
Service
TMA TMA
ENR ORP SOL-AIR AIR-SOL
Dpart Arrive
ACL 5 4 4 2 2 x93 2x93
ACM 8 2 2 6 1x126 1x88
ARMAND 1 0 0 0 1x260 1x88
C&P ACL 1 0 0 1 2x93 2x93
D-ATIS (Arriv) 1 0 1 0 5x100 3x93
DLL 1 0 0 1 1x491 1x222
D-ORIS 1 0 0 1 9x478 3x93
D-OTIS 1 0 1 0 11x193 3x107
D-RVR 1 0 1 0 4x116 3x121
DSC 1 0 0 1 3x96 4x87
D-SIG 0 0 1 0 4x1340 3x129
D-SIGMET 1 0 1 1 4x130 3x129
D-TAXI 0 0 1 0 2x132 1x98
FLIPCY 1 1 0 1 1x105 1x173
FLIPINT 4 1 1 36 1x143 1x2763
ITP ACL 0 0 0 1 2x93 2x93
M&S ACL 1 0 1 0 2x93 2x93
PPD 1 1 1 1 1x105 1x277
Tableau A- 4 : Caractristiques des services ATS.
154
Annexes
Taille du message
Frquence dutilisation
Quantit x Taille (Octet)
Service
TMA TMA
ENR ORP SOL-AIR AIR-SOL
Dpart Arrive
AOCDLL 0 0 0 1 2x413 2x148
ENGINE 1 1 1 0 1x88 1x727
FLTPLAN 1 0 0 1 17x285 17x90
FLTSTAT 1 0 0 1 / 1x157
FREETEXT 2 0 0 2 1x377 1x377
FUEL 2 1 1 2 / 3x127
GATES 1 0 0 0 1x589 /
LOADSHT 0 0 1 0 2x913 2x93
MAINTPR 1 0 0 1 4x133 4x133
MAINTRT 2 0 0 2 5x88 5x127
NOTAM 2 0 0 2 3x265 2x134
POSRPT 6 1 1 17 1x88 1x338
WXGRAPH 5 0 0 7 6x4246 6x93
WXRT 60 8 14 88 / 1x103
WXTEXT 2 0 0 2 5x680 2x103
Tableau A- 5 : Caractristiques des services AOC.
155
Annexe B Performances de codage et de modulation du DVB-S2/RCS
Efficacit Spectrale Es/N0 Requis

Modulation Codage
(Bits/Second/Hz) (dB)
1/4 0,49 -2,35
1/3 0,66 1,24
2/5 0,79 -0,30
1/2 0,99 1,00
3/5 1,19 2,23
QPSK 2/3 1,32 3,10
3/4 1,49 4,03
4/5 1,59 4,68
5/6 1,65 5,18
8/9 1,77 6,20
9/10 1,79 6,42
3/5 1,78 5,50
2/3 1,98 6,62
3/4 2,23 7,91
8PSK
5/6 2,48 9,35
8/9 2,65 10,69
9/10 2,68 10,98
2/3 2,64 8,97
3/4 2,97 10,21
4/5 3,17 11,03
16APSK
5/6 3,30 11,61
8/9 3,52 12,89
9/10 3,57 13,13
3/4 3,70 12,73
4/5 3,95 13,64
32APSK 5/6 4,12 14,28
8/9 4,40 15,69
9/10 4,45 16,05
Tableau A- 6 : Performances de codage et de modulation du DVB-S2. [ETSI 302 307]
157
Annexes
Efficacit Spectrale Eb/N0 Requis Es/N0 Requis

Modulation Codage
(Bits/Second/Hz) (dB) (dB)
1/3 0,33 2,9 -1,5
2/5 0,40 3,1 -0,5
1/2 0,50 3,5 1,0
BPSK 2/3 0,67 4,4 3,3
3/4 0,75 5,2 4,7
4/5 0,80 6 5,8
6/7 0,86 6,7 6,9
1/3 0,67 2,9 1,8
2/5 0,8 3,1 2,9
1/2 1,00 3,5 4,5
QPSK 2/3 1,33 4,4 6,9
3/4 1,50 5,2 8,3
4/5 1,60 6 9,5
6/7 1,71 6,7 10,6
1/3 1,00 4,34 5,2
2/5 1,20 4,74 6,7
1/2 1,50 5,54 8,7
8PSK 2/3 2,00 6,74 11,5
3/4 2,25 7,74 13,2
4/5 2,40 8,54 14,3
6/7 2,57 9,84 16,0
Tableau A- 7 : Performances de codage et de modulation du DVB-RCS. [BOL 04]
158
Annexe C Bilan de liaison ciel clair
Dans cette annexe, nous calculons le bilan de liaison ciel clair pour un terminal fixe (pire cas en
Europe pour lattnuation par la pluie). Ce calcul est bas sur une liaison de retour transparent
DVB-RCS en utilisant la bande de frquence Ka. Une marge statique de 2dB est ajoute dans le
bilan de liaison pour prendre en compte les effets imprvisibles (par exemple : la scintillation,
etc.). Aucune technique FMT nest introduite dans le calcul et les rsultats obtenus dans le bilan
de liaison constituent des cas nominaux.
Le calcul suit lordre de la liaison montante, descendante et globale. Pour le lien montant et
descendant, la formule gnrale utilise pour calculer le rapport signal sur bruit (C/No : Carrier on
Noise) est la suivante:
2
C G 1 1
= PG
No 4 R T K L
C/No reprsente le rapport signal pour le lien montant : (C/No)Uplink ou descendant

(C/No)Downlink
P reprsente la puissance rayonne par l'antenne isotrope en watts
G est le gain dantenne, il est obtenu en utilisant la formule
D
G = ( )

est le rendement (o coefficient defficacit) dantenne

D est le diamtre dantenne
est la longueur donde exprime par c/f, c vitesse de la lumire
Le produit PG est la puissance isotrope rayonne quivalente (exprime en dBW) (PIRE :

Puissance Isotrope Rayonne Equivalente du satellite) ou EIRP en anglais
159
Annexes
(/4R)2 est la perte en espace libre due la distance

G/T correspond au facteur de qualit de rception
K est la constante de Boltzmann dont 1/K gale - 228.6 dBWK-1Hz-1
L reprsente des pertes additionnelles (en ciel clair : pas de lattnuation par la pluie)
Une fois (C/No)Uplink et (C/No)Downlink obtenus, le rapport signal sur bruit pour la liaison globale
(C/No)Total est dtermin par la formule suivante (hypothse dun satellite transparent) :
1 1
C C C
No = +
Total No Uplink No Downlink
Sachant que la relation entre le dbit maximum possible de la connexion Rb partir du rapport
nergie sur bruit requis (Eb/N0) et le rapport signal sur bruit (C/No)Total est montr par la formule
suivante :
C E
No = b Rb
Total No
Le dbit maximum dpend donc du choix de lEb/N0 minimum.
Nous choisissons quatre dbits crtes (128 Kbps, 384 Kbps, 1 Mbps et 2 Mbps) pour comparer
leurs Eb/N0 enfin de dfinir le cas nominal le plus appropri pour le systme tudi.
160
Annexes
Caractristiques du ST
Dbit crte tudi (Kbps) 128.00 384.00 1024.00 2048.00
Facteur de Roll-off 0.35 0.35 0.35 0.35
Bande passante (MHz) 25 25 25 25
Frquence (GHz) 29.70 29.70 29.70 29.70
Diamtre d'antenne (m) 0,8 0,8 0,8 0,8
Efficacit d'antenne 0,65 0,65 0,65 0,65
Puissance d'antenne (Watt) 1,0 1,0 1,0 1,0
Gain d'antenne (dBi) 46,04 46,04 46,04 46,04
PIRE (dBW) 45.00 45.00 45.00 45.00
Pertes de pointage (dB) 1.00 1.00 1.00 1.00
PIRE effective (dBW) 44.00 44.00 44.00 44.00
Lien montant (Up-link)

Distance (km) 37606.58 37606.58 37606.58 37606.58
Perte de propagation (dB) 213.41 213.41 213.41 213.41
Attnuation atmosphrique (dB) 0.90 0.90 0.90 0.90
Attnuation par la pluie (dB) 0 0 0 0
Perte total (dB) 214.31 214.31 214.31 214.31
G/T du satellite 13.00 13.00 13.00 13.00
Constante de Boltzmann (dBW/K-Hz) -228.60 -228.60 -228.60 -228.60
C/N0 Uplink (dBHz) 71.29 71.29 71.29 71.29
Eb/N0 Up-link (dB) 20.22 15.45 11.19 8.18
161
Annexes
Caractristique du Satellite
Frquence (GHz) 18.50 18.50 18.50 18.50
PIRE (dBW) 50.00 50.00 50.00 50.00
OBO par porteuse (dB) 38.01 32.78 28.98 25.97
Total OBO (dB) 5.00 5.00 5.00 5.00
PIRE par porteuse (dBW) 11.76 16.99 20.79 23.80
Lien descendant (Down-link)

Distance (m) 37606.58 37606.58 37606.58 37606.58
Perte propagation (dB) 209.30 209.30 209.30 209.30
Attnuation atmosphrique (dB) 0.60 0.60 0.60 0.60
Attnuation par la pluie (dB) 0.00 0.00 0.00 0.00
Perte total (dB) 209.90 209.90 209.90 209.90
Diamtre d'antenne - Gateway (m) 6.00 6.00 6.00 6.00
Efficacit d'antenne 0.55 0.55 0.55 0.55
Gain de l'antenne (dB) 58.71 58.71 58.71 58.71
Pertes de pointage (dB) 0.30 0.30 0.30 0.30
Pertes de couplage (dB) 0.50 0.50 0.50 0.50
G/T (dB/K) 35.12 35.12 35.12 35.12
constante de Boltzmann (dBW/K-Hz) -228.60 -228.60 -228.60 -228.60
C/N0 down-link (dBHz) 64.78 70.01 73.81 76.82
Eb/N0 down-link (dB) 13.71 14.17 13.71 13.71
Liaison globale (Up-link+Down-link)

C/N0 up-link (dBHz) 71.29 71.29 71.29 71.29
C/N0 down-link (dBHz) 64.78 70.01 73.81 76.82
C/N0 total (dBHz) 62.48 66.44 68.68 69.79
Perte d'implmentation (dB) 2.00 2.00 2.00 2.00
Dgradation BER (dB) 1.00 1.00 1.00 1.00
Eb/N0 total (dB) 8.41 7.60 5.57 3.68
Tableau A- 8 : Bilan de liaison sur le lien retour DVB-RCS.
162
Annexe D Le logiciel de simulation OPNET
Simulation
La simulation des rseaux de tlcommunication consiste modliser de faon conforme la

ralit le comportement des diffrents lments constituants ces rseaux par des outils
informatiques afin de rcolter des donnes statistiques. Elle complte souvent la modlisation
mathmatique et permet de mieux tudier les dtails de fonctionnement dun systme complexe.
OPNET
OPNET modeler, le premier produit et outil principal dOPNET (OPtimum Network Engineering
Tool), sest actuellement impos dans le monde de la recherche et dveloppement pour la
modlisation et la simulation de rseaux de tlcommunication. OPNET Modeler est propos par
la socit OPNET Technologies (www.opnet.com). Pour simplifier la prsentation, nous lappelons
par la suite OPNET.
OPNET est un logiciel bas sur une approche de modlisation oriente objet et une simulation
vnement discrets. Il utilise une interface graphique afin de permettre aux utilisateurs de
modliser et de simuler les rseaux facilement et intuitivement. OPNET dispose de codes sources
totalement ouverts et clairement expliqus, cela aide les dveloppeurs mieux comprendre les
fonctionnements dtaills de chaque composant dans le rseau.
OPNET est bas sur des modlisations hirarchiques, cette mthode correspond bien la
structure des rseaux actuels. Comme le montre la Figure A- 1, Il dispose de trois niveaux
hirarchiques imbriqus : le plan de rseau, le plan de nud et le plan de processus.
163
Annexes
Plan de rseau
Plan de noeud
Plan de processus
Code
Figure A- 1 : Modlisation hirarchique dans lenvironnement OPNET.
Plan de rseau : est le niveau le plus lev de la hirarchie d'OPNET. Il permet de dcrire la
topologie gnrale du rseau tudi. Le rseau est dcrit sous forme dun ensemble
dlments de communication (routeurs, stations de travail, hub, etc.) qui sont appels les
nuds et de liens entre eux. Les utilisateurs peuvent configurer le rseau en paramtrant les
attributs associs aux nuds et aux liens.
164
Annexes
Plan de nud : permet de dfinir larchitecture des nuds en traduisant les flux de donnes
changs entre les blocs fonctionnels appels les modules. Les modules peuvent reprsenter
les applications, les couches de protocoles, les buffers, etc. Les modules peuvent
communiquer entre eux via des flux des paquets ou via des liens statistiques (changer des
informations de statistiques, par exemple : remplissage de file dattente, dlai limite de
transmission, etc.). La fonctionnalit de chaque module est ensuite spcifie au niveau
processus.
Plan de processus : permet de dfinir le rle du module composant le nud. Le

comportement de module est spcifi au niveau de processus laide de machine tats finis.
Chaque tat correspond une activit dcrite en code C/C++ support par une bibliothque de
fonctions prprogrammes. Les transitions entre les diffrents tats sont dtermines par des
conditions dexcution, par exemple : les vnements dinterruption.
Pour chaque niveau hirarchique prsent ci-dessus, les diteurs graphiques correspondants sont
utiliss pour simplifier la modlisation. De plus, OPNET dispose de beaucoup dditeurs/outils
supplmentaires (diteur de paquets, outil de sondes, outil de simulation, etc.) qui permettent
facilement et efficacement de simuler et analyser le rseau tudi.
La modlisation et la simulation sous OPNET peuvent se faire de deux manires :
en utilisant la palette pr-modlise dans la bibliothque dOPNET
en programmant soi-mme les composants suivant lordre hirarchique
Certainement, la premire mthode est beaucoup plus rapide et facile que la deuxime car les
programmations et les descriptions des lments sont transparentes pour les utilisateurs. Par
contre, dans le cas o des nouveaux algorithmes ou protocoles doivent tre tests, la deuxime
mthode, qui est une tape indispensable, est plus souple et plus facile adapter que la premire.
Dans cette thse, les simulations sont toutes bases sur la deuxime mthode.
165
Annexe E Sources de trafic
Cette partie prsente dune manire dtaille les modles de sources de trafic utiliss dans notre
tude, conformment ceux exposes dans le chapitre II, trois sources de trafic sont tudies :
cockpit ATS/AOC, GSM bord et Internet cabine.
Annexe E.1 Source de trafic cockpit ATS/AOC
Comme le montre dans la Figure A- 2, nous utilisons quatre modules diffrents pour dcrire la
source de trafic cockpit. Les modules gauches gnrent le trafic des services ATS/AOC durant les
phases TMA et ENR. Les modules droite sont ddis au trafic du domaine ORP. Cependant, ces
quatre modules ne se sont pas excuts en mme temps, les activations des modules dpendent
du type de trafic auquel nous nous intressons : services ATS ou AOC ; domaine TMA/ENR ou ORP.
Figure A- 2 : Vue globale du modle de source de trafic cockpit.
167
Annexes
Description des modules
Les modules ATS_TMA/ENR_gen et AOC_TMA/ENR_gen
Figure A- 3 : Modle de source : trafic cockpit (domaine TMA&ENR).
Le trafic gnr par ces deux modules reprsente lutilisation des services ATS/AOC dans
les domaines oprationnels TMA et ENR. Les mcanismes de ces deux modules sont
identiques et sont montrs par la Figure A- 3.
Ltat INIT permet dinitialiser des diffrentes variables ncessaires au fonctionnement

du module.
Ltat RANDOM permet de choisir au hasard ltat (domaine) initial parmi les tats
TMA_DEPT, ENR et TMA_ARRV, cest--dire, pour chaque avion, ltat de dpart pour
un instant donn est alatoire.
Les tats TMA_DEPT, ENR et TMA_ARRIV correspondent aux domaines oprationnels

dfinis dans le COCR (dpart TMA, ENR et arrive TMA). Ces trois tats ont des
fonctionnements similaires. Un compteur de dure (Timer) est associ chaque domaine,
une fois la dure expire, lavion passe au prochain tat suivant lordre : TMA_DEPT
ENR TMA_ARRV ; plusieurs services ATS (pour le module ATS_TMA/ENR_gen) ou
AOC (pour le module AOC_TMA/ENR_gen) sont dfinis chaque tat. Selon une
frquence dutilisation qui lui est associe, chaque service est activ en envoyant des
interruptions uniformes (portent des informations comme le nombre et la taille de
message et la classe de service) ltat correspondant (TMAD_MSG ou ENR_MSG ou
TMAA_MSG) pour la gnration des messages.
168
Annexes
Les tats TMAD_MSG, ENR_MSG et TMAA_MSG sont dclenchs lors de la rception

de linterruption envoye par ltat TMA_DEPT, ENR et TMA_ARRIV. Bass sur les
informations associes cette interruption, les messages sont enfin gnrs.
Les modules ATS_ORP_gen et AOC_ORP_gen
Figure A- 4 : Modle de source : trafic cockpit (domaine ORP).
Ces deux modules permettent dtudier indpendamment le trafic du domaine ORP.

LORP peut tre considr comme un domaine particulier, car il sagit de secteurs
gographiques l'extrieur de l'espace arien domestique et ne constituent pas une
phase indispensable pour tous les vols. En outre, puisque les exigences des services ORP
(TT95 : 26,5 s) sont beaucoup moins restrictives par rapport aux services TMA/ENR (TT95 :
3.8 s) nous utilisons un modle distinct qui dsigne uniquement le trafic de services ORP.
Le fonctionnement des modles ATS_ORP_gen et AOC_ORP_gen est dcrit dans la

Figure A- 4. Aprs linitialisation des variables par ltat INIT, ltat ORP permet
dactiver plusieurs services ORP en lanant des interruptions ltat correspondant
ORP_MAG qui est charg de la gnration des messages.
169
Annexes
Annexe E.2 Source de trafic tlphonies mobile bord
Dans la section II.2.1, nous avons tudi deux approches pour modliser la source de trafic GSM :
le modle N-sources ON/OFF et la source agrge. Dans la suite de cette annexe, nous prsentons
la modlisation de ces deux sources diffrentes.
Annexe E.2.1 Modle N-sources ON/OFF
Le modle N-sources ON/OFF consiste reprsenter plusieurs connexions phonie, cest--dire,

dcrire lagrgation de sources ON/OFF selon un nombre dutilisateurs. Comme expos dans la
Figure A- 5, ce modle est constitu de deux modules hirarchiques : GSM_gen_pre et
GSM_gen_fils. Le module GSM_gen_pre (a) a une mission relativement simple qui cre des
processus fils (le nombre de fils correspond au nombre dutilisateurs) et nous ne dtaillons dans la
suite que le processus fils GSM_gen_fils.
(a) : Module GSM_gen_pre (b) : Module GSM_gen_fils
Figure A- 5 : Modle de source : trafic GSM (N-sources ON/OFF).
Description du module GSM_gen_fils
Le fonctionnement du module GSM_gen_fils est dcrit par le graphe tat prsent

dans (b). Ce module est constitu de 7 tats essentiels :
Ltat INIT permet dinitialiser des variables et grer linterruption pour produire le
premier appel. Nous supposons que dans un premier temps, tous les utilisateurs
170
Annexes
commencent par ltat IDLE, cest--dire quaucun appel nest activ en dbut. Le temps
darrive du premier appel est tir alatoirement entre 0 et le temps maximum de la
dure IDLE (nous supposons 60 minutes).
Ltat IDLE a une fonction tout simple qui attend lactivation dun appel.
Les tats CALL_ACTIVE et CALL_DESACTIVE permettent de grer les priodes

activ/dsactiv pour un appel, les dures de ces priodes suivent une loi exponentielle
dcroissante de moyenne 3 minutes (pour CALL_ACTIVE) et 60 minutes (pour
CALL_DEACTIVE).
Ltat CALLING reprsente la voix phonie dun appel qui est base sur le modle le plus
populaire ON/OFF. Cet tat est non forc, cest--dire que dans ltat CALLING, le
processus excute une partie de son code dentre (Enter Execs) et ensuite sinterrompt
pour passer le relais au noyau de simulation ou un autre module. Il redevient actif
lorsquil est rveill par des nouveaux vnements.
Ltat SIGNAL permet denvoyer et grer les interruptions pour dfinir les priodes
ON/OFF. Il existe deux types dinterruption dans cet tat. Le premier type gre la
commutation entre ON et OFF : les temps passs dans les priodes ON et OFF suivent une
loi exponentielle dcroissante de moyenne respective 352 ms et 650 ms. Le deuxime est
charg dactiver ltat SEND pour gnrer des paquets correspondants.
Ltat SEND est dclench sur rception de linterruption pilote par SIGNAL et permet
de gnrer des paquets avec un dbit constant selon la priode qui lui est associe (un
paquet de taille 40 octets est gnr toute les 20 ms pour la priode ON et toutes les 480
ms pour la priode OFF).
Annexe E.2.2 Modle agrg
Par rapport au modle N-sources ON/OFF, le modle agrg est beaucoup plus simple. Ce modle
est bas sur la trace gnre par le modle N-sources ON/OFF. Il est ncessaire de tenir compte
en dbut de simulation de la priode de dmarrage durant laquelle le systme nest pas encore
dans un tat stationnaire. La source agrge est donc base sur la trace au-del de cette priode
de dmarrage (nous avons choisi une priode assez longue comme la dure de dmarrage : 1
heure). Cette trace enregistre le nombre de paquets gnrs toutes les 20 ms. Nous utilisons
171
Annexes
ensuite un programme crit en C danalyser les donnes de la trace (1.62x106 sont analyses) et
calculer la matrice des probabilits de transition. Bas sur cette matrice, une source agrge
(montre par la Figure A- 6) est enfin modlise pour gnrer les trames TRAU.
Figure A- 6 : Modle de source : trafic GSM (MMPP).
Description du module GSM_gen_MMPP
Le module est constitu de deux tats :
Ltat INIT permet dinitialiser les variables ncessaires pour le fonctionnement du

processus. Cet tat permet aussi de lire le fichier de la matrice des probabilits de
transition (engendr par un programme crit en C) et enfin planifier la premire
interruption pour gnrer les paquets.
Ltat GEN est dclench toute les 20 ms (lhorloge de BTS/Node B). A chaque
dclenchement, une probabilit est gnre alatoirement entre 0 et 1. Selon cette
probabilit et le nombre des paquets gnrs prcdemment, le nombre des paquets
gnrer est dtermin en parcourant la matrice des probabilits de transition. Daprs ce
nombre, les paquets correspondants sont enfin produits.
172
Annexes
Annexe E.3 Modle de source Internet embarqu
Nous proposons dans la partie II.3.3, une source greedy pour dcrire le trafic Internet, cette
source est raffine par plusieurs connexions TCP greedy. Pour chaque connexion, nous
implmentons lalgorithme TCP - Reno. Nous supposons quil y a toujours suffisamment de
paquets prts tre envoys et tout moment, la quantit de paquets envoys dans le rseau
sans avoir t acquitts est gale la taille de la fentre cwnd.
Description des modules
TCP fonctionne en mode connect entre metteur et rcepteur (client/server). Du cot metteurs,
un module pre qui sappelle TCP_client_mgr est charg de crer et grer des processus fils
TCP_greedy_client. Chaque processus fils (metteur) est identifi par un numro de port qui lui
attribu en dbut de la connexion et cette connexion reste ouverte tout au long de la vie de ce
processus.
Le mme mcanisme du cot rcepteur, un module pre TCP_server_mgr dont la tche est de
crer des processus fils TCP_greedy_server sur les demandes de connexion par des metteurs ; il
a aussi pour rle de trier les segments quil a reus est les distribuer aux diffrents ports
destination (serveurs) correspondants.
Le module TCP_greedy_client
Figure A- 7 : Module TCP_greedy_client.
173
Annexes
Le fonctionnement du module TCP_greedy_client est dcrit dans Figure A- 7. Il est bas

sur 5 algorithmes essentiels qui correspondent au protocole Reno.
Ltat INIT permet linitialisation des diffrentes variables ncessaire au fonctionnement

du module et lidentification du processus par le numro de port.
Ltat non forc OPEN correspond louverture de la connexion TCP. Il envoie tout
bord le premier segment de synchronisation (SYN) la destination (serveur). Ensuite il
sinterrompt pour passer le relais au noyau de simulation et redevient actif lorsquil reoit
laccus de rception (ACK) avec la requte de synchronisation (SYN) de la part du serveur
(interruption ARRIVAL). Avant de passer ltat suivant INIT_CNX, il rpond au serveur
par un ACK et partir de l, la connexion est tablie.
Ltat INIT_CNX permet dinitialiser la connexion tablie en dfinissant les diffrents

paramtres montrs dans le Tableau A- 9 [RFC 2581] [RFC 2988], et de commencer
ensuite envoyer le premier segment de donnes.
SMSS (Sender Maximum Segment Size) (octet) 1500

RMSS (Receiver Maximum Segment Size) (octet) 1500
16
RWND (Receiver Window) (octet) 2
14
Initial ssthresh (octet) 2
SRTT (Smooth Round Trip Time) (second) 10
1/8
1/4
Initial RTO (second) 20
Tableau A- 9 : Initialisation des paramtres TCP.
Ltat non forc WAIT correspond un tat dattente dun vnement qui peut tre de 2
types. Lvnement ARRIVAL reprsente larrive dun acquittement (ACK) de la part
du serveur. Lvnement TIMEOUT est dclench une fois le dlai de temporisation
associe chaque envoie est expir.
Lorsque lmetteur reoit un ACK du serveur, il entre dans ltat RECEIVE, si lmetteur
reoit 3 duplications du ACK, lvnement fast_retransmit est dclench, il passe ltat
FR ; sinon il calcule la nouvelle valeur de RTO daprs algorithme Jacobson [JAC 88]
montr ci-dessous et passe ltat SS/CA.
174
Annexes
Err = RTT - SRTT SRTT : RTT liss

Err : diffrence entre SRTT et nouvelle mesure
SRTT = SRTT + g x Err
D : cart moyen du RTT
D = D + h x ( |Err| - D) g : accroissement de la moyenne tablie 1/8
RTO = SRTT + 4 x D h : accroissement de la dviation tablie 1/4
Ltat SS/CA est charg dutiliser les diffrents algorithmes dfinis en fonction de la
fentre de congestion (cwnd) et du seuil de slow-start (ssthresh). Si cwnd est moindre que
ssthresh, slow-start est utilis et cwnd crot exponentiellement. Par contre, si cwnd est
plus grand ou gal ssthresh l'algorithme congestion avoidance (CA) est utilis. Dans les
deux cas, les nouveaux segments sont envoys et la temporisation est renclenche.
Le module passe ltat FR, quand lvnement fast_retransmit est dclench.

Lmetteur met ssthresh la moiti de cwnd, rduit cwnd de moiti plus trois fois la taille
du SMSS et retransmet le dernier segment non acquitt, il ensuite passe ltat non forc
IDLE qui est en attente dvnement.
Lvnement ARRIVAL qui reprsente larriv dun ACK permet de sortir de ltat IDLE.
Si lACK reu est un acquittement dupliqu, lmetteur incrmente cwnd dun segment et
transmet un nouveau segment si cette nouvelle cwnd le permet (Fast Recovery) ; si lACK
concerne un nouvel acquittement (non dupliqu), on sort de la phase FR-FR en mettant
fast_retransmit 0.
Lorsque le Timer RTO est expir (quelque soit son tat : WAIT pour la phase SS ou CA,
IDLE pour la phase FR-FR), TCP passe ltat TIMEOUT. Dans cette phase, TCP rduit
ssthresh la moiti du cwnd courant et rduit cwnd la taille dun segment.
Le module TCP_greedy_server
Le rle du serveur est relativement simple par rapport celui de lmetteur (voir Figure A- 8).
Ltat INIT permet dinitialiser les diffrentes variables ncessaires au fonctionnement

du module, ensuite le serveur passe ltat non forc IDLE qui correspond un tat
dattente dun vnement qui peut tre de trois types.
175
Annexes
Figure A- 8 : Module TCP_greedy_server.
Le premier type dvnement (ARRIVAL && syn ==1 && ack == 0) est dclench lorsque la
destination reoit le premier segment de synchronisation (SYN) pour la demande de
connexion. Dans ce cas, TCP tombe dans ltat ACK_SYN et envoie en retour un segment
accus de rception (ACK) avec la requte de synchronisation (SYN) et revient ltat
IDLE.
Le deuxime type dvnement (ARRIVAL && syn ==1 && ack == 1) est dclench
larrive de ACK de la part du metteur pour rpondre la requte de synchronisation SYN.
Le troisime type dvnement (ARRIVAL && syn == 0) correspond la rception dun

premier segment de donne envoy par lmetteur lors de la connexion tablie.
TCP passe ltat non forc WAIT quels que soient les deux derniers types dvnement
dclenchs. Il attend donc lvnement ARRIVAL qui correspond larrive dun segment.
Ltat NEW_SEG permet danalyser le numro de squence du segment reu et
denvoyer lacquittement correspondant ACK lmetteur. Les ACK sont gnrs suivant
la mthode introduite dans [RFC 2581].
176
Annexe F Modles de simulation
Dans cette partie, nous donnons une prsentation dtaille sur le modle et les mthodes
utilises dans le corps de cette thse.
Comme illustr par la Figure A- 9, le modle du rseau retenu dans notre tude est bas sur deux
types de nuds :
Terminal satellite (plusieurs terminaux sont regroups dans une mme zone gographique)
GW (reprsente une combinaison du NCC et Gateway)
Figure A- 9 : Modle du rseau.
177
Annexes
Annexe F.1 Terminal avion (ST)
Figure A- 10 : Nud terminal satellite davion (ST).
Comme montr par la Figure A- 10, le nud ST est constitu de 8 modules reprsentants une
simplification du terminal avion. Cette simplification nous permet de nous concentrer sur les
tudes de performances du rseau daccs DVB-RCS sans entre dans les dtails des architectures
du rseau (ATM, GSM, etc.).
Les modules ATC_gen, GSM_gen et TCP_client sont conformes ceux prsents dans
lANNEXE E du mmoire qui reprsente les sources de trafic pour les services tudis.
Le module IP_encap a un rle relativement simple dans ce modle simplifi. Il est charg
dencapsuler les segments TCP dans les paquets IP et ensuite les acheminer la couche
suivante.
Le module GSE_server est un point essentiel pour cette tude, il reprsente la couche
dadaptation qui est en charge de la gestion de la qualit de service, lencapsulation et les
requtes de capacit. Le diagramme dtat de transition de ce modle est montr par la
Figure A- 11.
178
Annexes
Figure A- 11 : Module GSE_server.
Ltat INIT permet linitialisation des diffrentes variables ncessaires au

fonctionnement du module.
Ltat non forc WAIT correspond un tat dattente dun vnement qui peut tre de
2 types : lvnement ARRIVAL reprsente larrive dun/ou plusieurs paquets des
modules source ; lvnement SIG_FROM_MAC correspond la signalisation envoye
depuis la couche MAC.
Lorsque GSE reoit un/ou plusieurs paquets, il passe de ltat WAIT ltat ARRIVAL.
Les paquets reus sont placs dans les files dattente correspondantes avant dtre
encapsuls en paquets MPEG. Lalgorithme RED est appliqu dans la file IP. Bases sur
les mesures (dbit moyen, la taille de file), les requtes de capacit sont calcules pour
chaque type de trafic et envoyes ensuite au MAC_SERVER par une signalisation Cross-
Layer. A chaque paquet arrivant la couche dadaptation, sil sagit dun paquet
ATS/AOC ou IP, une requte de capacit de type AVBDC est calcule base sur le
nombre de paquets en attente (dans les files ATS/AOC et IP) ; sil sagit dune trame
TRAU du GSM, une mesure de dbit moyen darrive de trame TRAU est mise jour et la
requte de capacit de type RBDC est alors calcule.
Lencapsulation se fait quand lvnement SIG_FROM_MAC est dclench. Cet

vnement correspond une allocation de ressource TBTP reu au niveau MAC du ST et
inform par une signalisation Cross-Layer la couche GSE. GSE passe ensuite ltat
179
Annexes
SIG_ARRIVE. Conformment au protocole dencapsulation GSE et la norme DVB-RCS,

les units de donnes de protocole (PDU : Protocol Data Unit) y compris les
datagrammes IP, les trames TRAU ou les donnes de services ATS/AOC sont
encapsuls/fragments dans un ou plusieurs paquets MPEG de taille fixe de 188 octets
selon la capacit alloue au ST (exprime en nombre de paquets MPEG). Suivant la
ressource alloue, les trames MPEG encapsuls sont ensuite envoyes la couche
daccs.
Le module MAC_QUEUE est en charge de la rception des paquets MPEG envoys par GSE et
de la mise en attente dans une file dattente.
Le module MAC_serveur joue le rle essentiel de recevoir le rsultat dallocation de

ressource (TBTP) et transmettre des donnes et des requtes de capacit via le lien satellite.
Le fonctionnement du MAC_serveur est dcrit par le graphe tat prsent dans la Figure A-
12 :
Figure A- 12 : Module MAC_serveur.
180
Annexes
Ltat INIT permet dinitialiser des diffrentes variables et de gnrer la premire

interruption pour recevoir le rsultat de lallocation de ressource. Ce rsultat est envoy
de GW vers ST sous format TBTP toutes les 60ms (la dure dune super-trame).
Ltat FRAME est dclench toutes les 60 ms. Il regarde tout dabord le nombre de slots
TRF allous ST et indiqu par la signalisation TBTP ; ensuite, selon cette capacit
alloue il passe soit ltat SYNC pour la synchronisation (quand il y a des donnes
envoyer et pas de capacit alloue), soit ltat TRF pour envoyer les donnes.
Ltat SYNC permet du ST denvoyer les requtes de capacit par le mini-slot (burst
SYNC). Ce burst SYNC contient la configuration du champ SAC (requtes de capacit) et
est envoy la GW par la signalisation TCT en mode contention avec les autre STs.
Ltat TRF est charg denvoyer les slots TRF selon la capacit alloue par la GW. La
requte de capacit est configure dans le message SAC suivant lordre de priorit RBDC
> VBDC. Le message SAC est donc envoy la GW par la mthode MPAF (MPEG
Adaptation Field Method). Cette mthode utilise directement le champ dadaptation
den-tte de paquet MPEG pour transporter la signalisation SAC.
Le module Tx reprsente une transmission physique via satellite, conformment aux

caractristiques du lien satellite, tous les paquets sont envoys avec un dlai de propagation
de 250 ms.
181
Annexes
Annexe F.2 Gateway (NCC intgr)
Au niveau de la rception, un seul nud, Gateway, permet les connexions entre plusieurs STs et
les destinataires de services (rle Gateway) et la gestion des ressources (rle NCC). Le
comportement du Gateway est dcrit par la Figure A- 13 :
Figure A- 13 : Nud Gateway (NCC intgr).
Le module indpendant signal_monitor est charg dimporter les rsultats de simulations

extrieures. Ces sries temporelles synthtises sont produites par la simulation de la boucle
de dcision FMT suivant les conditions de propagation. Au point de vue du Gateway, chaque
intervalle de temps, chaque ST correspond un mode FMT spcifi (0 ~ 4).
Le module GW_rx soccupe de la rception des paquets et de les envoyer au module MAC.
Le module MAC permet danalyser les diffrents bursts reus est de les acheminer la
destination correspondante. Les bursts CSC constituent les signalisations pour la procdure
Logon et sont envoys au module LOGON_mgr. Les bursts SYNC ne contient que les
messages SAC pour que les requtes de capacit soient expdies directement au module
DAMA_controller pour la rpartition des ressources. Les bursts TRF contiennent les donnes
et ventuellement les messages SAC ; les donnes sont transmises au module suprieur
GSE_SAR et les messages SAC sont envoys au DAMA_controller.
182
Annexes
Le module LOGON_mgr permet le contrle laccs des STs au rseau satellite et fournit tous
les paramtres de connexion associs au STs au moment du logon.
Le module DAMA_controller joue un rle essentiel grer les ressources du rseau satellite.
Le graphe tat sur le fonctionnement du DAMA_controller est montr par la Figure A- 14 :
Figure A- 14 : Module DAMA_controller.
Ltat INIT permet dinitialiser les paramtres ncessaires au fonctionnement du module

y compris les variables et les diffrentes tables pour les signalisations (FCT, TCT, TBTP, etc.).
Cet tat permet aussi de gnrer la premire interruption FRAME pour la gestion des
ressources.
Quand DAMA_controller reoit une signalisation envoy par le ST (correspond

lvnement SIGNAL), il passe ltat SIGNAL. Dans cet tat, les requtes de capacit
pour chaque ST sont enregistres est sont utilises pour la rpartition de la ressource.
Dans ltat FRAME, la ressource est partage entre plusieurs STs suivant lordre de
priorit RBDC > VBDC. Le DAMA alloue dabord les ressources aux ST qui demandent la
capacit en mode RBDC (si la somme de demandes RBDC est suprieur que la capacit du
lien satellite, la capacit est galement rpartie) ; ensuite les demandes VBDC sont traites
suivant la mme politique.
Le module GSE_SAR permet de d-multiplexer les donnes reus et de les envoyer aux
destinataires correspondants. Il permet de dsencapsuler les paquets MPEG reus et de les
183
Annexes
segmenter (si le paquet encapsul compos de plusieurs paquets PDUs) ou de les assembler
(si le paquet encapsul sagit dun/plusieurs fragments de paquets PDUs).
Le module IP permet de dsencapsuler les datagrammes IP et denvoyer les segments TCP au

serveur TCP.
Les modules sink_ATC, sink_GSM et TCP_serveur reprsentent les puits pour les trois
types de donnes reues.
184

Tao PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tao PDF

Uploaded by

Copyright:

Available Formats

THSE

DOCTORAT DE LUNIVERSIT DE TOULOUSE

Prsente et soutenue par

Titre : Etude des Performances et Optimisation d'un Rseau

Ecole doctorale : Ecole Doctorale Aronautique Astronautique (EDAA)

Je remercie Gilles ROUSSEL, professeur lUniversit de Marne-La-Valle, davoir accept de prsider ce

Je ddie cette thse mes parents et wentao.

II. SERVICE A BORD.............................................................................................................. 7

III. RESEAU DACCES PAR SATELLITE.................................................................................. 35

IV. ARCHITECTURE SYSTEME ............................................................................................. 63

V. ARCHITECTURE DU TERMINAL AVION : APPROCHE CLASSIQUE ET APPROCHE

CONCLUSION ..................................................................................................................... 137

REFERENCE ........................................................................................................................ 143

ANNEXES ........................................................................................................................... 151

3GPP 3rd Generation Partnership Project

ACARS Aircraft Communication Addressing and Reporting System

BER Bit Error Rate

CBB Connexion By Boeing

DRA Dynamic Rate Adaptation

EIRP Equivalent Isotropic Radiated Power

FAA Federal Aviation Administration

HF High Frequency (3MHz ~ 30MHz)

ICAO International Civil Aviation Organization

Kbps kilo bits per second

LAN Local Area Network

MAC Media Access Control

ULE Unidirectional Lightweight Encapsulation

VBDC Volume Based Dynamic Capacity

W-CDMA Wideband - Code Division Multiple Access

Figure II-1 : Relation entre le service et lapplication. ....................................................................................... 9

NCC Network Control Center

OPA Operational Performance Assessment

QoS Quality of Service

RBDC Rate Based Dynamic Capacity

SAC Satellite Access Control

TBTP Terminal Burst Time Plan

Tableau A- 1 : Performances requises des services ATS pour le FRS............................................................. 152

allger la charge du travail de contrle

aider la localisation et la surveillance des avions

amliorer le contrle despace

viter les erreurs de procdure (malentendu, etc.).

Le concept du datalink a t introduit avec le systme de communications entre avion et sol

I.2 Services aux passagers et premires exprimentations

I.3 Convergence des communications aronautiques sur un lien

I.4 Plan du mmoire

Le quatrime chapitre aborde la conception de larchitecture du systme satellite devant assurer

Le cinquime chapitre est consacr la dfinition de larchitecture du terminal avion. Deux

II. SERVICE A BORD

II.1 Services pour lATM

Figure II-1 : Relation entre le service et lapplication.

II.1.3 Diffrents types de services de communication

Les services de communication ATM se composent principalement de deux grandes catgories :

ADS-A, galement connu sous le nom de ADS-C (Automatic Dependant Surveillance -

Figure II-2 : Interface graphique de lapplication CPDLC.

II.1.4 Une tude prospective : le COCR

2005 2010 2015 2020 2025 2030 2035

Figure II-3 : Dfinition des phases dans le COCR.

Domaine oprationnel Dfinition dans le COCR

Zone cylindrique de 10 miles de diamtre et dune hauteur ~5000

Tableau II-1 : Dfinition des domaines despace arien dans le COCR.

II.1.5 Performances requises

conformment aux besoins oprationnels et aux exigences de scurit, il est indpendant de la

Intgrit IRCP Le pourcentage de transactions ralises sans erreur non dtecte