Fasson

n ordre 2187
COLE DOCTORALE INFORMATIQUE ET TLCOMMUNICATIONS
TUDE DUNE ARCHITECTURE IP INTGRANT

UN LIEN SATELLITE GOSTATIONNAIRE
Thse pour le doctorat en Rseaux et Tlcommunications de

lInstitut National Polytechnique de Toulouse
par :
M Julien Fasson
Soutenue le 15 dcembre 2004 devant le jury compos de

M. Grard Maral
Prsident du jury
M. Christian Fraboul
Directeur de thse
M. Walid Dabbous
Rapporteur
M. Samir Tohm
Rapporteur
M. Emmanuel Chaput
Membre, co-encadrant
M. Stphane Combes
Membre
M. Giovanni Giambene
Membre invit
REMERCIEMENTS
Remerciements
Lune des tapes incontournables de ce type de travail rside dans les remerciements. Bien
sr la crainte doublier quelquun est l, mais je vais tout de mme essayer de me lancer.
Toutefois, jespre que personne ne se sentira offusqu davoir t omis et jespre que lmotion
davoir termin ce travail justifiera quelques oublis si il y en a.
Bien sr je commencerai par remercier les diffrents membres de mon jury. Jai t trs
touch que M. Samir Tohm accepte de relire mon manuscrit malgr ses soucis de sant, et je
tiens profondment le remercier pour son intrt et ses diffrents commentaires sur mon
travail. Mes penses vont aussi M. Walid Dabbous qui a clair dun point de vue nouveau mon
travail. Je remercie profondment M. Giovanni Giambene davoir pu participer la soutenance.
Enfin un grand merci M. Grard Maral qui ma fait lhonneur dassumer la fonction de
prsident de jury de ma thse avec lgance.
Jai vraiment apprci les diffrents apports dAlcatel mon travail, dune part par
DIPCAST o jen profite pour remercier les diffrents acteurs du projet, et en particulier Cline
Bnassy-Foch, et dautre part, par mon contact rcent avec Stphane Combes qui a t un lecteur
attentif de mon travail et a su mettre laccent sur certaines perspectives notamment lors de la
soutenance.
Je noublierai pas de dire toute ma gratitude mes deux encadrants, en commenant par
mon directeur de thse, Christian Fraboul, qui ma accompagn lors de ce travail et au-del. Il
sest investi dans cette recherche malgr de nombreuses difficults, ouvrant sans cesse le dbat
pour ne pas se perdre dans des points techniques qui navaient pas leur place ici.
Je souhaite vivement remercier Emmanuel Chaput. Il a co-encadr ce travail en apportant
sa vision du monde protocolaire, notamment avec IP. Mais, plus que le co-encadrant de ce
travail, il a t un tuteur pour le travail de recherche comme denseignement, un ami et un
compagnon de voyage, toujours prsent aux confrences, dans les moments de stress et de doutes.
Je remercierai aussi tous les membres de lquipe de recherche IRT, et en particulier AndrLuc Beylot, le plus jeune professeur de notre laboratoire qui sait faire des merveilles avec
quelques files dattentes, mais qui aurait pu faire aussi une trs bonne carrire en tant que
concierge du 17 bis.
Je marrterai pour saluer tous les membres du laboratoire TSA qui ont su crer une
ambiance propice ce travail. Je ne citerai pas tous les noms, mais uniquement celui de Sylvie,
ternelle protectrice du thsard gar ; celle qui sait comment il faut faire et qui a toujours su
nous faire sourire.
Le bureau 5 est un endroit o jai pass un grand nombre dheures cette dernire anne, et
je noublie pas ses figures emblmatiques : Farid, Hussein, et Sakouna.
Je voulais, avant de terminer, remercier les trois amis qui mont paul au cours de cette
thse. Merci Flo avec qui jai partag le bureau pendant presque quatre ans, en commenant par
la mme cole, puis le mme DEA et enfin la thse dans le mme laboratoire. Merci Dj, mon
solide appui tout au long de ce travail, tu as su trouver les actions comme les mots justes pour
mamener prsenter ce travail aujourdhui. Et enfin toute mon amiti Fabrice, qui a partag un
grand nombre de soires studieuses au laboratoire jusqu deux heures du matin, avec qui je
mangeais les week-ends au boulot. Cest certainement grce toi que jai russi finir ce travail
dans les temps.
Merci toi maman, et toi Hlne qui avaient relu ce travail.
3
REMERCIEMENTS
Merci tous mes amis : Anne, Jeff, Olivier, Titi, Alexandre, et incontestablement le plus
grand psychanalyste de tous les temps et mon ami de toujours, Charles.
Enfin ceux de ma famille qui ont cru en moi.
Bien sr si ce travail est avant tout le mien, je crois quil est le rsultat de la collaboration de
tous ces tres, alchimie lente et discrte de trois annes au sein du laboratoire TSA, prsent
termin comme nous le connaissions.
LISTE DES ACRONYMES
Liste des acronymes

AAL5
ACQ
ADSL
AIT
AMR
AR
ARP
ARPA
ATM
ATSC
BAT
BER
BSM
CAC
CAT
CBR
CDN
CGMP
CMT
CRA
CSC
Cwnd
DAMA
DIPCAST
DS
DSL
DSM-CC
DULM
DVB
DVB-C
DVB-CA
DVB-CI
DVB-CSA
DVB-RCS
DVB-S
DVB-SI
DVB-T
DVB-X
EIT
EPG
ES
ETSI
FAI
FCA
FCT
FDMA
FEC
ATM Adaptation Layer 5

ACQuisition burst
Asymmetric Digital Subscriber Line
Application Information Table
Adaptative Multi Rate
Address Resolution
Address Resolution Protocol
Advanced Research Projects Agency
Asynchronous Transfer Mode
Advanced Television Systems Committee
Bouquet Association Table
Bit Error Rate
Broadband Satellite Multimedia
Connection Admission Control
Conditional Access Table
Constant Bit Rate
Content Delivery Network
Cisco Group Management Protocol
Correction Map Table
Continuous Rate Assignment
Common Signalling Channel burst
Congestion WiNDow
Demand Assignment Multiple Access
Dvb pour lIP multiCAST
DiffServ
Digital Subscriber Line
Digital Storage Media Command and Control
Data Unit Labelling Method
Digital Video Broadcasting
DVB for Cable
DVB Common Access
DVB Common Interface
DVB Common Scrambling Algorythm
DVB Return Channel for Satellite
DVB for Satellite
DVB System Information
DVB for Terrestrial
DVB for mobile
Event Information Table
Electronic Program Guide
Elementary Stream
European Telecommunications Standards Institute
Fournisseur dAccs Internet
Free Capacity Assignment
Frame Composition Table
Frequency Division Multiple Access
Forward Error Correcting
5
LISTE DES ACRONYMES
FLS
FSI
FTP
GEO
GES
HDTV
HEO
HTTP
IAP
IBIS
IETF
IGMP
IN
INT
IP
IPsec
IRD
ISP
LAN
LEO
MAC
MARS
MCDDD
MEO
MF-TDMA
MHP
MMT
MNMC
MPE
MPEG
MTU
NCC
NIT
NNI
NVoD
OBP
OBPC
P2P
PAT
PC
PCR
PDU
PEP
PES
PID
PIM-SM
PLR
PMT
PoP
PPP
PS
6
Forward Link Signalling

Fournisseur de Services Internet
File Transfer Protocol
Geostationary Earth Orbit
Gateway Earth Station
High Definition TeleVision
High Earth Orbit
Hyper Text Transfer Protocol
Internet Access Provider
Integrated Broadcast Interactive System
Internet Engineering Task Force
Internet Group Management Protocol
Interactive Network
IP/MAC Notification Table
Internet Protocol
IP security protocol
Integrated Receiver Decoder
Internet Service Provider
Local Area Network
Low Earth Orbit
Medium Access Control
Multicast Address Resolution Server
Multi-Carrier Demultiplexer Demodulor Decoder
Medium Earth Orbit
Multiple Frequencies Time Division Multiple Access
Multimedia Home Platform
Multicast Map Table
Mission and Network Management Centre
Multi Protocol Encapsulation
Motion Pictures Experts Group
Maximum Transfer Unit
Network Control Centre
Network Information Table
Network-Network Interface
Near Video on Demand
On-Board-Processing
On-Board-Processing Controler
Peer-to-Peer
Program Association Table
Personal Computer
Program Clock Reference
Protocol Data Unit
Performance Enhancement Proxy
Packetized Elementary Stream
Packet IDentifier
Protocol Independent Multicast Sparse Mode
Packet Loss Rate
Program Map Table
Point of Presence
Point to Point Protocol
Program Stream
LISTE DES ACRONYMES
PSI
PSTN
PUSI
QoS
RBDC
RCST
RMT
RNIS
RNRT
ROHC
RST
RSVP
RTC
RTO
RTP
RTT
QEF
SAC
SACK
SCR
SCT
SDT
SMAP
SNDU
SPT
STC
SYNC
TBTP
TCP
TCT
TDMA
TDT
TIM
TM/TC
ToS
TS
UDLR
UDP-Lite
UES
ULE
UMTS
UNI
VBDC
VCi
VLAN
VoD
VoIP
VPi
VPN
VSAT
WAP
Program Specific Information

Public Switched Telephonic Network
Payload Unit Start Indicator
Quality of Service
Rate-Based Dynamic Allocation
Return Channel Satellite Terminal
Rcs Map Table
Rseau Numrique Intgration de Services
Rseau Nationnal de Recherches en Tlcommunications
RObust Header Compression
Running Status Event
Resource reSerVation Protocol
Rseau Tlphonique Commut
Retransmission Time Out
Real Time Protocol
Round Trip Time
Quasi Error Free
Satellite Access Control
Selective ACKnowledgment
Source Clock Reference
Supertrame Composition Table
Service Description Date
Satellite Multicast Adaptation Protocol
SubNetwork Data Unit
Satellite Position Table
Source Time Clock
SYNChronisation burst
Terminal Burst Time Plan
Transmission Control Protocol
Time slot Composition Table
Time Division Multiple Access
Time and Date Table
Terminal Information Message
TeleMetry/TeleCommand
Type of Service
Transport Stream
UniDirectional Link Routing
Lightweight User Data Protocol
User Earth Station
Ultra Lightweight Encapsulation
Universal Mobile Telephone Service
User-Network Interface
Volume Based Dynamic Capacity
Virtual Channel Identifier
Virtual Local Area Network
Video on Demand
Voice over IP
Virtual Path Identifier
Virtual Private Network
Very Small Aperture Terminal
Wireless Application Protocol
7
LISTE DES ACRONYMES
LISTE DES FIGURES
Liste des figures

Figure 2.1 Deux types de multiplexage pour MPEG-2 ......................................................................................... 26
Figure 2.2 DVB-S et ses concurrents dans le monde ............................................................................................ 27
Figure 2.3 Piles de protocoles du DVB-S comme support des flux MPEG-2....................................................... 28
Figure 2.4 Dtail dun paquet MPEG-2 TS et de son en-tte................................................................................ 28
Figure 2.5 Encapsulation dun PES dans des paquets MPEG-2 TS via data-streaming....................................... 29
Figure 2.6 Aperu de la chane de codage du DVB-S........................................................................................... 30
Figure 2.7 Reprsentation des quatre tables de service PSI .................................................................................. 31
Figure 2.8 Reprsentation des tables de service SI ............................................................................................... 32
Figure 2.9 Schma dun guide de programme ................................................................................................ 33
Figure 2.10 Architecture DVB-S/DVB-RCS ........................................................................................................ 34
Figure 2.11 Deux encapsulations proposes pour le DVB-RCS ........................................................................... 35
Figure 2.12 Aperu de la chane de codage du DVB-RCS ................................................................................... 35
Figure 2.13 Segmentation de la bande alloue la voie retour en supertrames, trames et time-slots................... 38
Figure 3.1 Cinq mthodes de multiplexage de donnes dans la couche MPEG-2 TS........................................... 41
Figure 3.2 Exemple dencapsulation dun datagramme par data-piping .............................................................. 42
Figure 3.3 Exemple dencapsulation dun datagramme par data-streaming......................................................... 42
Figure 3.4 Exemple dencapsulation dun datagramme par MPE......................................................................... 43
Figure 3.5 Insertion du champ pointeur dans le champ dadaptation MPEG-2 TS............................................... 44
Figure 3.6 Comparaison des tailles des donnes une fois encapsules avec MPE et Ethernet.............................. 45
Figure 3.7 Champs obligatoires de len-tte dune section datagramme (12 octets)............................................. 45
Figure 3.8 Dcoupage de ladresse MAC destination dans les champs Deviced_Id de la section........................ 46
Figure 3.9 Architecture classique IP sur DVB-S comme accs Internet ............................................................ 47
Figure 3.10 Couches protocolaires entre une gateway et un terminal mettant en jeu un lien retour terrestre ....... 48
Figure 3.11 Exemple de localisation dun flux IP/MAC avec la table INT .......................................................... 49
Figure 3.12 Architecture IP sur DVB-S/DVB-RCS comme accs Internet ....................................................... 53
Figure 3.13 Double bond entre deux RCST sur un systme GEO transparent...................................................... 53
Figure 3.14 Encapsulation dun datagramme unicast IPv4 via la mthode ULE .................................................. 55
Figure 3.15 En-tte obligatoire et optionnel utilis par la solution ULE............................................................... 55
Figure 3.16 Deux encapsulations dun datagramme IP via la mthode ULE........................................................ 56
Figure 3.17 Comparaison entre lencapsulation ULE et MPE .............................................................................. 56
Figure 3.18 Couverture dun satellite multi-spots................................................................................................. 58
Figure 3.19 limination du double bond entre deux RCSTs sur un satellite intgrant un OBP............................ 59
Figure 3.20 Contours du systme DIPCAST segment sol et air ........................................................................ 60
Figure 3.21 Architecture IP sur DVB bidirectionnelle.......................................................................................... 61
Figure 3.22 Couche protocolaires du systme rgnratif DIPCAST................................................................... 62
Figure 3.23 Schma de lOBP du systme DIPCAST .......................................................................................... 63
Figure 3.24 En-tte dune cellule UNI et dune cellule NNI................................................................................. 64
Figure 3.25 Traitement sol dun datagramme multicast avant mission ............................................................... 66
Figure 3.26 Borne suprieure sur le dbit aller en fonction du dbit de la voie retour ......................................... 69
Figure 3.27 Principe de spoofing TCP utilisation de proxies ............................................................................. 72
Figure 4.1 Cinq architectures de VoD sur un systme satellite gostationnaire.................................................... 78
Figure 4.2 Diagrammes dactivit caractristiques de la topologie 1.................................................................... 79
Figure 4.5 Cinq architectures daccs Internet via un systme satellite gostationnaire....................................... 85
Figure 4.6 volution du dbit en fonction du nombre dutilisateurs pour la topologie 2...................................... 86
LISTE DES FIGURES

Figure 4.7 volution du temps de transfert sur un lien satellite unidirectionnel et bidirectionnel ........................ 87
Figure 4.8 Quatre topologies dinterconnexion via un systme satellite gostationnaire...................................... 90
Figure 4.9 Stucture de la charge utile hybride....................................................................................................... 97
Figure 4.10 mission de deux gateways vers le systme hybride......................................................................... 98
Figure 4.11 mission de RCSTs situes dans des spots diffrents vers le systme hybride ................................. 99
Figure 4.12 Vision densemble des diffrentes entits spcifique larchitecture hybride ................................ 100
Figure 4.13 Les couches protocolaires de larchitecture hybride dans le plan utilisateur ................................... 103
Figure 4.14 Distinction pour le multicast entre un systme avec et sans rplication bord ............................... 106
Figure 4.15 Exemple de relation entre laiguillage de niveau 3 et les couches infrieures pour une RCST ....... 107
Figure 4.16 Mapping dune adresse IP multicast sur une adresse MAC............................................................. 109
Figure 4.17 Topologie dtude du traitement des flux IP sur larchitecture hybride........................................... 114
Figure 4.18 Organisation des diffrents flux sur le lien montant en provenance de A et de F............................ 115
Figure 4.19 Organisation des diffrents flux sur le spot 2 descendant en provenance de A et de F ................... 115
Figure 4.20 Organisation des diffrents flux rgnratifs sur le spot 2 descendant en provenance de A et de F
dans le cadre dune commutation MAC bord................................................................................................... 116
Figure 4.21 Exemple dintgration de services dans une architecture hybride ................................................... 118
Figure 5.1 Modlisation des pertes de paquet selon une chane de Markov deux tats.................................... 123
Figure 5.2 Comparaison de lencapsulation MPE et ULE sur le lien montant DVB-S dans le systme hybride 129
Figure 5.3 Comparaison de lencapsulation ATM et ULE sur le lien montant DVB-RCS dans le systme hybride
............................................................................................................................................................................ 131
Figure 5.4 Comparaison de lencapsulation ATM et ULE sur le lien descendant DVB-S dans le systme hybride
............................................................................................................................................................................ 132
Figure 5.5 Part moyenne de dbit utile en fonction de la taille moyenne des segments TCP vhicul sur le
systme hybride .................................................................................................................................................. 133
Figure 5.6 Taille dune table INT en fonction du nombre de flux IP traits ....................................................... 135
Figure 5.7 volution du poids de la signalisation SI en fonction du nombre de clients simultans.................... 137
Figure 5.8 Scnario de comparaison entre un accs Internet via une connexion terrestre et le mme service via un
systme satellite unidirectionnel ......................................................................................................................... 146
Figure 5.9 Observation du dlai dun transfert FTP en fonction de la technologie daccs Internet................ 147
Figure 5.10 Exemple de pertes en rafale pour un PLR de 10-3 avec le modle de Gilbert .................................. 149
Figure 5.11 volution du nombre de pages http consultes en un quart dheure en fonction de la taille moyenne
de ces pages......................................................................................................................................................... 150
Figure 5.12 Comparaison de lvolution du dlai requis pour tlcharger un fichier via FTP en fonction du dbit
offert par le lien retour pour un lien aller de 512 Kb/s........................................................................................ 151
Figure 5.13 Diagramme simplifi dune communication HTTP......................................................................... 153
Figure 5.14 Utilisation du monofaisceau et du multifaisceaux pour la voie aller DVB-S .................................. 154
Figure 5.15 Scnario de comparaison entre un accs Internet via une connexion terrestre et le mme service via
un systme satellite bidirectionnel ...................................................................................................................... 156
Figure 5.16 volution du dbit applicatif observ sur le lien aller et retour en fonction du temps..................... 157
Figure 5.17 Profil de pertes au cours de la simulation sur la voie aller et retour ................................................ 158
Figure 5.18 volutions du dbit applicatif observ sur le lien aller et retour en fonction du temps de simulation
avec limitation 80 Kb/s et 100 Kb/s du dbit de type upload........................................................................... 159
Figure 5.19 volution du dbit applicatif observ sur le lien aller et retour en fonction du temps avec un buffer
dmission de 50 KB et de 100 KB..................................................................................................................... 160
Figure 5.20 volution du dbit moyen applicatif sur 5000 s en fonction de la taille des buffers dmission ..... 161
Figure 5.21 volution du dbit applicatif observ sur le lien aller et retour en fonction du temps avec une
politique de Deficient Round Robin sur le buffer dmission de 150 KB ........................................................... 162
Figure 5.22 volution du dbit applicatif observ sur le lien aller et retour en fonction du temps avec une
politique de Fair Queueing sur le buffer dmission de 150 KB ........................................................................ 162
Figure 5.23 Aperu de lvolution de la file dattente dmission dans le cas DRR et FQ................................. 163
Figure 5.24 volution du dbit applicatif observ sur le lien aller et retour en fonction du temps et de la MSS du
lien retour. ........................................................................................................................................................... 163
10
LISTE DES FIGURES

Figure 5.25 volution du dbit moyen sur 5000 s en fonction de la taille des buffers dmission pour un lien
retour terrestre de 28.8 Kb/s et une MSS de 476 et 1460 B ................................................................................ 164
Figure 5.26 Observation du comportement de TCP Tahoe et Reno sur un lien satellite face une perte
ponctuelle............................................................................................................................................................ 166
Figure 5.27 Observation du comportement de TCP Tahoe et Reno sur un lien satellite face des pertes en
rafales.................................................................................................................................................................. 167
Figure 5.28 Observation du comportement de TCP NewReno sur un lien satellite face des pertes en rafales. 168
Figure 5.29 Comparaison entre lutilisation une connexion sans PEP et une connexion avec PEP sur un lien
satellite unidirectionnel 1 Mb/s avec lien retour terrestre de 9.6 Kb/s ................................................................ 170
Figure 5.30 Topologie toile et maille............................................................................................................. 175
Figure 5.31 Comparaison du temps de transfert FTP entre une topologie star et mesh sans perte ..................... 176
Figure 5.32 Comparaison de lvolution du dbit applicatif maximum en fonction du PLR pour une architecture
toile et une architecture maille....................................................................................................................... 176
Figure 5.33 volution du dbit moyenn sur une seconde au cours du temps pour une topologie de type star et
mesh .................................................................................................................................................................... 177
11
LISTE DES FIGURES
12
LISTE DES TABLEAUX
Liste des tableaux

Tableau I.
Table embarque de correspondance entre IN, VP et Spots cibles
65
Tableau II.
Les diffrents besoins des trois services tudis
91
Tableau III.
Dlai daller retour dune requte de type ARP sur un systme hybride
109
Tableau IV.
Exemple de table de correspondance dun RCST
110
Tableau V.
Dpendance entre les requtes VoD pour un mdia et le mode du systme
117
Tableau VI.
Tables SI consultes pour avoir accs au PID dun flux IP
134
Tableau VII.
VALUATION du poids de la signalisation pour un flux IP
136
Tableau VIII.
Composition dune supertrame
139
Tableau IX.
Linfluence de la rpartition bord/sol sur la ractivit du systme
143
Tableau X.
Comparaison du dbit moyen observ sur un transfert FTP en fonction de la dure
dobservation Modle derreur uniformment rpartie
148
Tableau XI.
Comparaison du dbit moyen observ sur un transfert FTP en fonction de la dure
dobservation Modle derreur deux tats
148
Tableau XII
Gain du multifaisceaux pour la voie aller en mode unipoint
155
Tableau XIII
Segment maximal transfr au bout de 2000 s
166
Tableau XIV
Dbit moyen observ sur 200 s en fonction du type damlioration apport par le PEP
169
13
LISTE DES TABLEAUX
14
GLOSSAIRE
Glossaire
Canal logique :
Il sagit de lensemble des paquets MPEG-2 TS partageant le mme PID sur un multiplexe donn. Ces paquets
constituent un mme programme (missions, films, etc. ).
Digital Video Broadcasting :

Il sagit de la norme de tlvision numrique europenne. Cette norme est largement dploye mme aux tatsunis, et elle connat un succs incontestable, notamment sur les supports cbles et satellites.
DVB-RCS :
Le DVB Return Channel for Satellite est le standard DVB qui dfinit la voie retour pour satellite. Coupl au
DVB-S, il permet dinterconnecter un rseau intgralement par une connexion satellite.
DVB-S :
Le DVB for Satellite est une norme de diffusion de donne, lorigine multimdia, par satellite. Elle est
construite autour des principes de diffusion unidirectionnelle.
DVB-SI :
Il sagit de la norme qui gre la signalisation des flux DVB. En plus des tables dfinies dans la norme MPEG-2
(tables PSI), elle ajoute un certain nombre de tables nommes SI.
GES :
La Gateway Earth Station est une entit fortement mettrice dun systme satellite. Elle met gnralement en
DVB-S, mais peut aussi mettre en DVB-RCS. Dans ce cadre, il sagit le plus souvent dune gateway multiporteuses.
MPE :
Le MultiProtocol Encapsulation est, comme son nom le signale, un protocole dencapsulation de donnes
gnriques dans les paquets MPEG-2 TS en utilisant le DSM-CC. Cest le protocole recommand par la norme
DVB. Cependant il prsente un certain nombre de limites.
MPEG-2 TS :
La couche MPEG-2 TS est utilise comme niveau liaison par la norme DVB-S. Cette couche est dfinie par la
norme ISO MPEG-2, et est considre dans le cadre de cette norme comme un niveau transport, assurant le
transport des flux applicatifs MPEG-2 (vido, audio, synchronisation et donnes supplmentaires). Les
conteneurs de ce niveau sont nomms les paquets MPEG-2 TS, et sont fixs 180 B. La notion de flux MPEG-2
TS est souvent utilise pour deux choses diffrentes : soit le flux de paquets MPEG-2 TS rfrant un flux vido
et audio commun (on parle de canal logique, ou plus rarement de flux logique puisque les paquets partagent le
mme PID), soit le flux de paquets MPEG-2 TS une fois multiplex, celui-ci est form de plusieurs flux et
constitue un multiplexe, ou transpondeur.
On-Board-Processing :
Encore appel intelligence embarque, lOBP propose dintgrer un certain nombre de fonctionnalits bord,
comme le multiplexage des flux descendants, la gnration de signalisation, la commutation bord, et mme une
gestion de la QoS bord dans le cadre de commutation paquet. terme, le routage bord semble envisageable.
PID :
Un PID est un identifiant dun canal logique. Associ aux systmes des tables dinformations, il permet de
reprer les diffrents flux, et dindiquer aux dcodeurs sur quels canaux rcuprs les programmes.
RCST :
Les terminaux de type RCST sont dfinis par la norme DVB-RCS. Il sagit de terminaux capable dmettre en
DVB-RCS, et donc offrant une voie retour satellite.
Satellite gostationnaire :
Un satellite en orbite 35900 km de la Terre est appel satellite gostationnaire puisquil a une dure de
rvolution gale la priode de rotation de la Terre (23h 56min), lui garantissant une position fixe en vis--vis
d'un lieu donn.
15
GLOSSAIRE
Satellite multi-spots :
Les techniques multi-spots (ou multifaiceaux) proposent de dcouper la couverture du satellite en plusieurs
zones, via lutilisation de plusieurs faisceaux. Les satellites commerciaux actuels sont gnralement
multifaiceaux. Linterconnexion entre les faisceaux peut tre ralise de diffrentes manires, en utilisant des
techniques physiques, ou en utilisant un OBP. Lutilisation dune intelligence bord permettant la commutation
permet une plus grande flexibilit du systme. Les satellites actuels ne font que peu dinterconnexion de spots.
Systme transparent :
Un satellite gostationnaire dit transparent ne met en place aucune fonctionnalit dun niveau autre que
physique. La plupart du temps un tel systme se contente de rpter les signaux vers la Terre, en les amplifiant.
Un tel systme est parfois nomm hub spatial ou rpteur.
ULE :
Ce protocole se propose de remplacer le protocole MPE en offrant une interface plus simple, plus lgre et plus
ouverte.
16
GLOSSAIRE
17
TABLES DES MATIRES
Table des matires

1.
CONTEXTE DE LTUDE
1.1.
1.2.
1.3.
1.4.
2.
LA TRANSMISSION DE DONNES
LE SATELLITE, UN OUTIL DE COMMUNICATION
UNE COEXISTENCE PROBLMATIQUE
LE PLAN DE LTUDE
DVB COMME NORME DE COMMUNICATION SPATIALE

2.1.
LA NORME DVB
2.1.1.
Historique du DVB
2.1.2.
Standards DVB
2.1.3.
MPEG-2
2.2.
LA NORME DVB-S
2.2.1.
Pile de protocoles DVB-S
2.2.2.
MPEG-2 TS
2.2.3.
Chane de transmission
2.2.4.
Mthode daccs
2.3.
LES TABLES DE SERVICE
2.3.1.
Tables PSI
2.3.2.
Tables SI
2.3.3.
Exemple de structure dun programme
2.4.
LA NORME DVB-RCS
2.4.1.
Mise en uvre du DVB-RCS
2.4.2.
Pile de protocoles
2.4.3.
2.4.4.
Mthode daccs
2.5.
CONCLUSION
3.
LE SATELLITE COMME SUPPORT DIP

3.1.
LTAT DE LART ET LES OBSTACLES LIMPLANTATION D IP SUR SATELLITE
3.2.
LE DVB-S COMME SUPPORT DIP
3.2.1.
tude de lencapsulation IP
3.2.2.
Architecture dtude
3.2.3.
Limites des architectures classiques
3.2.4.
Conclusions sur larchitecture classique
3.3.
LE DVB-RCS COMME SUPPORT DIP
3.3.1.
DVB-RCS comme seul support dIP
3.3.2.
DVB-RCS comme complment au DVB-S
3.3.3.
Persistance de limites
3.4.
DE NOUVELLES TECHNIQUES ET TECHNOLOGIES AU SERVICE DIP SUR SATELLITE
3.4.1.
Techniques de rsolutions dadresses et dencapsulations : ULE
3.4.2.
Les techniques de multifaisceaux
3.4.3.
Lintelligence embarque
3.4.4.
Exemple darchitecture intgrant intelligence bord et multifaisceaux
3.5.
UN PROBLME PROTOCOLAIRE : TCP SUR SATELLITE
3.5.1.
TCP standard et les limites de son utilisation sur satellite
3.5.2.
TCP et ses adaptations au support satellite
3.5.3.
Conclusion sur le problme de la couche transport TCP
3.6.
CONCLUSION
4.
PROPOSITION DUNE ARCHITECTURE HYBRIDE

4.1.
LES BESOINS DES SERVICES
4.1.1.
Vido la demande
4.1.2.
Accs Internet
4.1.3.
Interconnexion de rseaux distants
4.1.4.
Conclusion et ouverture dautres services
18
20
20
20
21
22
24
24
24
25
25
27
27
28
30
30
31
31
32
33
33
34
34
35
36
38
40
40
41
41
46
50
52
52
52
52
53
54
54
58
59
60
67
67
70
72
73
74
74
75
84
88
90
TABLE DES MATIRES

4.2.
LES OBJECTIFS DUNE ARCHITECTURE
4.2.1.
Adaptation aux trafics actuels
4.2.2.
Optimisation du systme satellite
4.2.3.
Adaptation aux trafics futurs
4.3.
LARCHITECTURE HYBRIDE
4.3.1.
Description de la charge utile hybride
4.3.2.
Description des autres entits du systme hybride
4.3.3.
Description de larchitecture protocolaire
4.4.
CONCLUSION
5.
EVALUATION DE LARCHITECTURE HYBRIDE
5.1.
LE NIVEAU PHYSIQUE ET SON INFLUENCE SUR LE SYSTME
5.1.1.
Diffusion du mdium satellite
5.1.2.
Dlai dun bond satellite
5.1.3.
Pertes sur le support physique
5.2.
LE NIVEAU LIAISON
5.2.1.
Le temps daccs au support
5.2.2.
tude et comparaison de lencapsulation
5.2.3.
tude du poids des messages de signalisation
5.2.4.
tude du temps de rponse du systme en fonction de la rpartition bord/sol des
fonctionnalits du NCC
5.2.5.
Conclusion sur la signalisation de larchitecture hybride
5.3.
LE NIVEAU RSEAU
5.3.1.
IP et son conomie
5.3.2.
Conclusion sur le niveau 3
5.4.
LACCS INTERNET
5.4.1.
Reprsentation du trafic Internet
5.4.2.
Accs Internet standard
5.4.3.
Accs Internet volu
5.4.4.
Intgration doptimisations dans larchitecture hybride
5.4.5.
Conclusion sur laccs Internet
5.5.
LA VIDO LA DEMANDE
5.5.1.
Comparaison entre multi-spots et mono-spot
5.5.2.
Influence du lien retour
5.5.3.
Conclusion sur la Vido la Demande
5.6.
LINTERCONNEXION DE RSEAUX PRIVS
5.6.1.
Performances du multiplexage embarqu
5.6.2.
Intrt du multi-spots pour linterconnexion
5.6.3.
Conclusion sur le service dinterconnexion
5.7.
CONCLUSION SUR CETTE VALUATION
6.
CONCLUSION ET PERSPECTIVES
91
91
92
92
93
93
99
102
116
120
121
122
122
122
124
125
126
134
140
143
143
144
144
144
145
145
156
165
170
171
171
174
174
174
174
177
177
178
180
19
CHAPITRE 1. INTRODUCTION ET PROBLMATIQUE
1. CONTEXTE DE LTUDE
Ce travail se situe la frontire de deux mondes distincts, aux vocabulaires diffrents et aux
mthodes spcifiques. Les problmes traits par cette tude reposent en grande partie sur
lvolution disjointe de ces deux domaines, responsable des difficults de leur intgration au sens
large du terme.
Ce premier chapitre propose dintroduire cette problmatique, posant le contexte de cette
tude. La premire section retrace lmergence dIP comme le support incontournable de la
transmission de donnes une large chelle. La deuxime section introduit le domaine des
satellites, et plus prcisment les satellites de type GEO. La problmatique est souleve par une la
confrontation de ces deux domaines dans une troisime section. Nous prsentons dans une
dernire section le plan de cette tude.
1.1.
La transmission de donnes
Aprs son apparition dans le projet ARPANet, IP est vite devenu un standard mondial.
Entre 1990 et 2000, le rseau Internet a connu un vritable succs, si bien quaujourdhui, en
septembre 2004, on estime 23.23 millions le nombre dinternautes en France1.
Cette mergence dIP a clairement montr que les solutions molothiques proposant une
architecture de bout en bout (ATM par exemple) ntaient pas adaptes une large diffusion et
dissmination, en particulier pour des raisons videntes de cot dinfrastructure. En revanche, IP
ne suppose presque rien des rseaux sur lequel il est dploy, interconnectant et fdrant des
rseaux disparates de manire transparente pour lutilisateur. Grce cette capacit, les
applications se sont dveloppes autour dIP (plus particulirement de la pile TCP/IP), le rseau
sest naturellement tendu, et les applications ont finalement prolifres, passant du simple mail,
aux serveurs FTP, aux chats, aux multimdias, au Peer-to-Peer, entrinant le succs dIP un tel
point quil semble aujourdhui indtrnable.
IP est donc devenu la rfrence, dissminant le savoir grande vitesse et portant lre du
numrique. Mais cette volution ne saurait sarrter l. La pense IP dtrne peu peu les
supports ddis. Quil sagisse du tlphone, de la tlvision, des jeux, ou encore des livres, IP a
cr une vritable rvolution dans nos habitudes. Ainsi le triple play, offre de service daccs
Internet coupl la Voix sur IP (VoIP) et la tlvision, se dveloppe rapidement grce la
prolifration de lADSL, se posant en dangereux concurrent de la tlphonie traditionnelle, de la
tlvision analogique et numrique par ondes terrestres, cble ou satellite.
IP offre donc un fort pouvoir intgrateur, ide que le RNIS (Rseau Numrique
Intgration de Services) proposait dj il y a prs de 20 ans [1], mais qui na pu tre mise en
oeuvre une large chelle.
1.2. Le satellite, un outil de communication

Quil soit cr pour surveiller, pour calculer, pour observer, le satellite reste un outil de
communication parce quil doit transmettre les informations quil collecte. De l, le pas
permettant de le transformer en un relais spatial de communication a vite t franchi en 1962
1
Source mdiamtrie, www.mediametrie.fr .
20
avec Telstar 1 ou encore Relay [2]. Ces satellites dfilant basse altitude ont vite dmontr avec la
diffusion de quelques missions de tlvisions, mais aussi avec des relais tlphoniques entre
tats-unis, Grande-Bretagne et France, les apports des satellites pour les tlcommunications.
Cependant le mode dfilant est peu appropri la retransmission tlvise. Cest en 1965,
avec Early Bird que nat un rseau commercial de tlcommunications par satellites
gostationnaires, Intelsat, proposant la diffusion de 36 programmes simultans [3].
Parmi les quatre types de satellite (LEO, MEO, HEO et GEO), seul les GEOs offrent un
relais fixe par rapport un point de la Terre1, proposant une couverture pouvant atteindre un
tiers du globe2. La tlvision numrique trouve alors un support de choix dans de tels satellites :
la fin des annes 90, le MPEG-2 [4] rvolutionne le monde de limage et ouvre lhorizon de la
tlvision numrique. Le satellite connat alors un vritable succs en temps que support
privilgi de ce service.
1.3. Une coexistence problmatique

Parmi les diffrents types de satellite, les GEOs offrent de meilleures perspectives quant
la diffusion de donnes une large chelle, apparaissant alors comme un support de choix
lintgration de divers services. Or, les diverses tentatives dintgration (ATM, RNIS, ) ont
prouv la difficult de lenjeu, alors que le phnomne Internet a montr quune grande capacit
dadaptation tait un atour majeur. Vhiculer des flux IP est donc incontournable.
La grande diversit du monde des tlcommunications spatiale propose des satellites
gostationnaires trs spcifiques chaque constructeur comme chaque service, posant un
vritable problme lintgration dIP sur ces systmes. Dans ce cadre, la norme DVB semble
appele tre un lment important. De plus en plus rpandue, cette norme est en passe de
devenir un standard mondial, proposant une base commune pour les systmes satellites et visant
avec les instances de normalisation comme lETSI un interfaage commun.
En parallle, les possibilits offertes par les GEOs (et plus gnralement les rseaux sans
fil) nont pas chapp au monde IP. Ainsi lIETF, lorganisme de normalisation dIP, travaille
lintgration de ces systmes dans les rseaux IP.
La convergence de ces deux initiatives reste encore venir, promettant des solutions quant
la normalisation dun interfaage entre les deux mondes. Actuellement toutefois, les solutions
classiques intgrant IP sur satellite prsentent des limites (gaspillage de ressources, double bond,
voie retour, comportement de TCP, etc.). En rponse, des nouvelles technologies apparaissent
(intelligence embarque, multi-spots, etc.) ainsi que des solutions protocolaires.
Il apparat alors clairement au travers de ces diverses propositions que tous les verrous
technologiques devraient pouvoir tre levs et les solutions correspondantes normalises. Se pose
alors la question de leur intgration dans une architecture globale oprationnelle qui soit la fois
prenne et capable de supporter les volutions technologiques.
Les problmes au cur de cette nouvelle tape vers une cohabitation profitable des deux
mondes sont donc :
lintgration dIP aussi efficace que possible sur un systme satellite ;
lintgration homogne et cohrente de diffrents services ;
1 En orbite circulaire 35900 km de la Terre, le satellite gostationnaire a une dure de rvolution gale la
priode de rotation de la Terre (23h 56min), lui garantissant une position fixe en vis--vis d'un lieu donn.
2 La couverture dun systme gostationnaire est une valeur thorique : les zones polaires ne sont pas
couvertes par un tel satellite
21
lutilisation et la pertinence des nouvelles technologies dans un cadre IP.

Ces questions sont au centre de la problmatique de notre tude que nous nous proposons
de dtailler dans les premires parties de ce mmoire, en nous reposant sur une approche
synthtique du satellite comme support dIP, pour ensuite dfinir, une architecture globale
capable dintgrer diffrents services et technologies.
1.4. Le plan de ltude

Le deuxime chapitre de ce mmoire proposera une prsentation de la norme DVB, et
particulirement du DVB-S, DVB-RCS et DVB-SI, et de leur lien troit avec la norme MPEG-2.
A la lumire de cette analyse, le chapitre 3 se focalisera sur lutilisation du satellite
gostationnaire comme support dIP. Aprs avoir tudi les solutions classiques, et soulign leurs
dfauts, nous verrons comment ces limites peuvent tre leve laide de nouvelles technologies et
dadaptations protocolaires. Afin de comprendre quels impacts peuvent avoir ces diffrents
lments sur un systme satellite orient IP, nous tudierons lintgration dun brasseur ATM sur
un satellite multi-faisceaux. Mais nous observerons que ces solutions posent des questions la
viabilit et la justification de tels systmes.
Dans le chapitre 4, nous proposons de rpondre ces questions qui proviennent dun
vritable besoin architectural. Nous tudierons dans un premier temps diffrents services (la
vido la demande, laccs Internet et linteconnexion de rseaux privs) dans loptique dune
intgration sur un systme satellite. Nous verrons alors leurs diffrents besoins qui nous
amneront la dfinition des objectifs dune architecture. Sur cette base une proposition sera
dtaille reposant dune part sur lintgration de deux charges utiles bord dun mme systme, et
dautre part sur la mise en uvre dIP comme entit fdratrice, aboutissant lintgration des
diffrents services prcits.
Ltape suivante, laquelle sera consacre le chapitre 5, sera lvaluation du concept
darchitecture hybride en sattachant montrer sa pertinence et son adquation une grande
diversit de services. Cette tude reposera sur les diffrentes couches de larchitecture, du niveau
physique au niveau aplicatif. Cette partie montrera comment larchitecture hybride peut offrir les
trois services proposs en leur faisant profiter de sa flexibilit sans pour autant induire une
signalisation plus lourde.
Enfin le chapitre 6 conclura ce travail, et dgagera des perspectives ultrieures de
recherche.
22
23
CHAPITRE 2. DVB COMME NORME DE COMMUNICATION SPATIALE
2. DVB COMME NORME DE

COMMUNICATION SPATIALE
Le satellite est un domaine fortement htrogne. Les GEOs ont t, en effet, un mdium
de communication depuis plus de 40 ans, et chaque systme a t conu plus ou moins
indpendamment des autres, souvent avec des protocoles privs ou des adaptations propritaires
de mcanismes existants. Ltude du satellite est alors souvent force rester soit gnrale, soit
spcifique un type de systme (une tude de cas). Toutefois, larrive du standard MPEG-2 [4]
proposant une compression raliste pour la transmission dun flux vido numrique, change la
donne en offrant la capacit de distribuer la tlvision digitale avec un dbit raisonnable. Une
nature diffusante, une trs large couverture et une grande capacit font vite des GEOs un
support de choix pour la tlvision numrique. Dans ce cadre, un standard de communication
merge en Europe. troitement li au transport de flux MPEG-2, le Digital Video Broadcasting
(DVB) [5] profite de la large dmocratisation de la tlvision numrique et se positionne comme
un standard trs ouvert et largement rpandu.
Le DVB-S (DVB for Satellite) devient rapidement le standard pour la tlvision par
satellite, avec un seul vritable concurrent, le standard amricain HDTV (High Definition
TeleVision) adopt par lATSC [6] (Advanced Television Systems Commitee). Ce standard est
similaire au standard europen sur de nombreux points. La norme DVB est utilise dans la
plupart des satellites gostationnaires actuel, commerciaux comme projet. Pour cette raison elle
est le support choisi pour nos travaux. Nous proposons donc ici dtudier plus en dtail ses
principes comme son fonctionnement. Cette tude permettra de comprendre mieux comment
cette norme, avant tout cre pour vhiculer des flux multimdia, peut tre utilise pour des flux
de natures diffrentes et plus particulirement des datagrammes.
Cette partie prsente donc les diffrents standards DVB lis au satellite. Cette tude, aprs
avoir abord les principes du standard (MPEG-2), propose danalyser le standard DVB-S (DVB
for Satellite), puis la signalisation avec le DVB-SI (DVB System Information) et enfin le DVBRCS (DVB Return Channel for Satellite)
2.1. La norme DVB

La norme DVB est une norme rcente, issue de la norme MPEG-2. Lhistorique de sa
cration est brivement abord ici. Nous prsenterons aussi les diffrents standards regroups
sous le cigle DVB et enfin la norme MPEG-2, essentielle la comprhension du DVB.
2.1.1.
Historique du DVB
Le groupe DVB (Digital Video Braodcasting) apparat entre 1993 et 1996 en mme temps
que la premire publication de la norme MPEG-2 [4]. Initiative europenne, le groupe DVB
trouve son origine avec lELG (European Launching Group) lanc en 1991.
Les standards DVB sont publis depuis janvier 1995 par l'Union Europenne de
Radiodiffusion, et prsente les techniques basiques pour l'implantation de la transmission TV
numrique en Europe, Asie, Australie et de nombreux autres pays. Le seul concurrent semble tre
le standard amricain HDTV, lui-mme reposant sur la technologie MPEG-2, mais incompatible
en partie avec le DVB. Aujourdhui le groupe DVB est un vritable consortium regroupant plus
de 300 membres et ses normes sont tlchargeables gratuitement sur le site ETSI (European
24
Telecommunications Standards Institute). Un nouveau standard, le DVB-S2 est dailleurs dans sa

phase de test, et grce ses performances au niveau codage, il devrait pouvoir remplacer
prochainement le DVB-S.
Le DVB est une initiative en rponse au problme de la tlvision analogique : la
normalisation. En effet les standards de tlvision analogique (PAL, SECAM, D2-MAC) ne
sont pas uniformes et prsentent des problmes dincompatibilit entre eux [7]. Le succs du
DVB na pu donc tre complet sans une impulsion assez forte des organismes europens pour
inciter toute la chane des acteurs, de la conception la production, entrer dans le consortium.
A lheure actuelle la norme DVB est bien implante dans le monde entier, notamment en ce qui
concerne sa version pour le satellite. La concurrence reste leve pour des mdia tels que le cble
ou les ondes terrestres [5].
Si le DVB doit son succs en grande partie celui de la compression MPEG-2 et de
linitiative europenne dont il est le fruit ; son adaptabilit est un lment fondamental de son
succs actuel comme venir. En effet, le systme DVB a t conu dans un but large et
intelligent, adaptable diffrents moyens de transmissions dans la mesure o il nimpose pas de
restrictions sur le matriel utilis. Le DVB a t cr pour tre en mesure de transmettre la vido
comme laudio, mais aussi les EPG (Electronic Program Guides), les tltextes, et dispose mme
de moyens pour transmettre des donnes en mode paquet (datagramme).
Ce ct ouvert du DVB est un des lments qui intressent actuellement les diffrents
projets europens et asiatiques, et cest ce qui nous a amen ltude de ce standard.
2.1.2.
Standards DVB
Le DVB est une norme complexe qui rgit en premier lieu la transmission de tlvision
numrique par cble, onde terrestre, ou satellite. Les standards DVB sont nombreux et divisibles
en diffrentes catgories :
Les standards de transmission qui traitent de limplmentation du transport des ES

(Elementary Streams) MPEG-2 sur diffrents supports. Les trois principaux standards
de ce domaine sont le DVB-S (Satellite), le DVB-C (Cble) et le DVB-T (Terrestre).
Dautres standards sont en projet comme le DVB-X (ad hoc, encore nomm DVB-H,
ou DVB-M) qui doit aboutir des offres commerciales pour mobiles (tlvision sur
tlphones cellulaires, vido la demande) couples au DVB-T en 2006 [8] [9].
Les standards dinteraction qui soccupent des voies retours et des connexions (DVBDATA). On trouve tous les standards DVB-RC* (DVB - Return Channel for *)
comme par exemple le DVB-RCS (DVB Return Channel for Satellite) qui normalise
la voie retour via satellite. On trouve aussi le support des applications telles que le
tltexte (DVB-TXT) ou le sous-titrage (DVB-SUB) et enfin un standard fondamental
le DVB-SI (DVB System Information) qui rgit la signalisation des diffrents
programmes prsents dans le flux DVB, en utilisant des tables de signalisation.
Les standards dinterfaage et de codage avec notamment le DVB-CI (DVB Common

Interface) utilisant laccs conditionnel (DVB Conditional Access) couramment crypt
avec le DVB-CSA (DVB Common Scrambling Algorithm).
2.1.3.
MPEG-2
Le MPEG-2 est la base de la norme DVB. Avant tout connu comme norme de
compression, le standard regroupe aussi des mthodes de multiplexage particulires reposant sur
le dcoupage des flux lmentaires (ES Elementary Stream) en PES (Packetised Elementary
Stream) [4]. Le multiplexage MPEG-2 est donc abord ici puisque ces informations sont
indispensables la comprhension des normes DVB.
25
Figure 2.1 Deux types de multiplexage pour MPEG-2
Dans la figure ci-dessus (Figure 2.1) le MPEG-2 propose deux mthodes diffrentes pour
multiplexer les PES en fonction de lapplication, formant deux types de flux distincts. Le
Program Stream (PS) est form partir dun unique programme regroupant plusieurs PES (vido,
audio et donnes prives). Constitu de paquets relativement longs (2048 octets par exemple), le
PS est utilis pour la transmission sur un canal prsentant un taux derreurs faibles (Quasi Error
Free). Il est utilis pour le stockage des mdia sur disque dur, CD, et DVD. De son ct, le
Transport Stream (TS) peut mlanger diffrents programmes. De plus il est le flux utilis pour
transporter les donnes multimdia sur diffrents supports qui sous-entendent un risque derreur
non ngligeable (cbles, ondes terrestres, satellites, ). Le flux TS utilise alors des paquets de
petite taille (fixe 188 octets) pour lefficacit des codes correcteurs.
Le TS est donc le flux qui nous intresse plus particulirement ici. Reprenant la figure cidessus plus en dtail, llaboration du TS seffectue en plusieurs tapes :
Les flux vido et audio sont compresss sparment, donnant en sortie de chaque
codeur un flux constant appel ES.
Une fois compresss, les flux vido et audio (deux ES distincts) sont dcoups en PES
en utilisant la mme base de temps (Source Time Clock), pour un mme programme ;
Les PES sont ensuite multiplexs dans des paquets MPEG-2 TS, composant le
Transport Stream, via une mthode nomme data-streaming. Un paquet MPEG-2 TS ne
26
peut par cette mthode contenir quun seul morceau de PES. Du bourrage est donc
utilis dans ce cas pour remplir les paquets MPEG-2 TS 188 octets.
2.2. La norme DVB-S

DVB-S est le standard de transmission de la tlvision numrique via satellite
gostationnaire. Ce standard regroupe des informations sur les protocoles utiliss pour
multiplexer les donnes en se basant sur le standard MPEG-2 (cf. partie prcdente), des
mthodes daccs et enfin des informations sur le codage canal ainsi que sur la modulation du
signal. Il sagit dun standard ouvert dont la premire publication remonte 1993, alors que la
dernire version de ce standard date de 2004. La norme DVB-S a donc su senrichir tout au long
de cette dernire dcennie devenant un standard mondial comme le montre cette carte (Figure
2.2).
Cette partie propose ltude de cette norme en insistant particulirement sur le niveau
liaison (dit aussi niveau accs dans le monde satellite) afin de comprendre son fonctionnement et
son interaction ventuelle avec des couches plus hautes.
Figure 2.2 DVB-S et ses concurrents dans le monde1
2.2.1.
Pile de protocoles DVB-S
La pile de protocoles du DVB-S sappuie majoritairement sur la norme MPEG-2. La figure

suivante (Figure 2.3) propose un aperu de cette pile de protocoles dans le plan utilisateur dune
part, et dans le plan de contrle/gestion dautre part [10] [11]. Ces deux piles montrent la
diffrence de traitement entre les flux MPEG-2 et la signalisation de ces derniers. En effet, les
flux MPEG-2 suivent le traitement observ prcdemment, le data-streaming encapsule des PES
dans les paquets MPEG-2 TS de charge utile de 184 octets (auxquels il faut ajouter 4 octet dentte), tandis que les tables de signalisation suivent un processus part : Les tables MPEG-2 et
DVB-S, organises dans la norme DVB-SI, sont multiplexes dans des sections MPE
(MultiProtocol Encapsulation), qui sont elles-mmes encapsules dans les paquets MPEG-2 TS
et multiplexes avec les paquets MPEG-2 TS contenant les flux MPEG-2. Le data-streaming dans
le plan utilisateur et le Multi Protocol Encapsulation dans le plan de contrle diffrent la fois sur la
mthode dinsertion dans les paquets MPEG-2 TS, et sur la gestion du bourrage, puisque MPE
Source www.DVB.org
27
peut autoriser lencapsulation de deux sections diffrentes dans un mme paquet MPEG-2 TS1,
tandis que le data-streaming utilise toujours le bourrage pour complter un paquet MPEG-2-TS
Figure 2.3 Piles de protocoles du DVB-S comme support des flux MPEG-2
2.2.2.
MPEG-2 TS
Conformment la norme, la couche MPEG-2 TS possde plusieurs points daccs (nous

en avons dj voqu deux : le protocole MPE et le data-streaming). Nous analyserons diffrentes
mthodes dencapsulation dans la partie 3. Cette partie se concentre sur le data-streaming, le
protocole du plan utilisateur qui multiplexe les PES dans le flux de paquets MPEG-2 TS.
Figure 2.4 Dtail dun paquet MPEG-2 TS et de son en-tte
Les paquets MPEG2-TS (Figure 2.4) sont de courts paquets de taille fixe, 188 octets. Le
paquet a un en-tte de 4 octets et une charge utile de 184 octets. Toutefois len-tte du paquet
peut tre augment grce des champs optionnels, diminuant du mme coup la charge utile du
paquet. La figure ci-dessus dtaille le paquet MPEG-2 TS et son en-tte standard de 4 octets [4]
[5] [7] [11]. Les champs de len-tte MPEG-2 TS sont par ordre dapparition :
Synchronisation byte : loctet de synchronisation qui prend pour valeur 0100 0111
(0x47) et permet ainsi de dtecter le dbut dun nouveau paquet.
Transport_error_indicator : lindicateur derreur de transport, 1 bit, indique la prsence

dau moins un bit incorrect et irrcuprable dans le paquet MPEG-2 TS. Ce bit peuttre mis un par un autre protocole que la couche MPEG-TS, indiquant une erreur
rencontre dans la chane de transmission.
Cette mthode est nomme section-packing.
28
Payload_unit_start_indicator : le PUSI (1 bit) indique si le dbut dun PES est prsent

dans ce paquet. Plus gnralement, son utilisation est indique pour savoir si le dbut
dune donne encapsule par MPEG-TS est prsent dans ce paquet. Pour les tables PSI
par exemple, sa prsence indique que le premier octet de charge utile est un pointeur
sur le dbut de la nouvelle table.
Transport_priority : il sagit dun flag de 1 bit. Lorsquil est activ, le paquet a une
priorit plus grande que tout autre paquet de mme PID. Un mcanisme de QoS peut
se baser sur ce bit pour donner une plus grande priorit aux paquets concerns.
PID : compos de 13 bits, il le canal logique, cest--dire un numro de flux. Certains

PID sont rservs (cf. partie 2.3).
Transport_Scrambling_Control : champ de 2 bits indiquant le type de cryptage utilis

pour la charge utile du flux de transport. Ce champ ne doit pas tre crypt. Dans le cas
dun paquet nul, cest--dire un paquet o il ny a que du bourrage, ce champ prend la
valeur 00.
Adaptation_Field_Control : ce champ (2 bits) permet de savoir si un en-tte optionnel,

nomm champ dadaptation, suit len-tte standard :
00 : rserv pour des utilisations futures,
01 : pas de champ dadaptation, seulement des donnes,
10 : seulement un champ dadaptation, pas de donnes,
11 : champ dadaptation suivi de donnes.
Continuity_Counter : le compteur de continuit est constitu de 4 bits, ce champ est
incrment de un chaque nouveau MPEG-TS de mme PID. Lorsquil arrive au
maximum, il repasse 0.
Lencapsulation dun flux de PES se fait en utilisant le data-streaming comme illustr dans la
figure ci-dessous (Figure 2.5). Dans le data-streaming, le PUSI nest pas utilis et on comble le
paquet MPEG-2 TS avec du bourrage. Ainsi dans un mme paquet il ne peut y avoir quun
lment dun unique PES. Le PID des paquets sera le mme pour un PES donn ainsi que pour
le mme flux de PES, cest--dire lES original.
Le bourrage utilis en DVB est considr comme un champ dadaptation. Ladaptation field
control est donc fix 11, et un champ dadaptation est insr indiquant la taille du champ suivie
des octets de bourrage, permettant ainsi de retrouver facilement le dbut des donnes (Figure
2.5).
Figure 2.5 Encapsulation dun PES dans des paquets MPEG-2 TS via data-streaming
29
2.2.3.
Une fois le flux MPEG-2 TS cr, celui-ci est trait pour tre mis vers le satellite par la
couche DVB-S. Ce niveau est en constante volution suite aux nombreux progrs technologiques
tels que les turbo-codes ou lapparition du DVB-S 2.
Si lon reste sur les dernires normes DVB-S, les flux MPEG-2 TS sont traits par la chane
de codage suivante (Figure 2.6). Lobjectif de ce document ntant en aucune manire de rentrer
dans le dtail de ce niveau, cette partie se contente de retracer les tapes principales du codage
physique [7] [12] :
Le brouillage : aussi appel dispersion dnergie, il permet dviter une trop longue
succession de 1 ou de 0 qui aurait comme impact la cration dune raie forte nergie.
Le signal est multipli par la sortie dun gnrateur pseudo alatoire.
Le codage Reed-Solomon : ce codage rajoute un code de 16 octets la fin du paquet

MPEG-2 TS, permettant de corriger au maximum 8 octets dfectueux.
Lentrelacement : ce mlange des donnes permet dviter les suites conscutives

derreurs, plus difficiles corriger, en entrelaant les octets de plusieurs paquets.
Le code convolutif : code en treillis, il ajoute de la redondance au signal raison de 2

bits pour 1 (dcodage Viterbi).
Le poinonnage : il permet damliorer le rendement du code convolutif en liminant

certains bits (on parle de Forward Error Code pour ce rendement).
La modulation QPSK : elle permet de moduler le signal sans faire de modulation

damplitude puisque le signal est trs bruit par le travail en saturation des
transpondeurs.
Le dbit symbole de la chane de transmission est de 27,5 106 symboles par seconde, pour
un transpondeur de 35 MHz, do un dbit utile de 38 Mbit/s pour un FEC de .
Figure 2.6 Aperu de la chane de codage du DVB-S
2.2.4.
Mthode daccs
quipes de transpondeurs, les stations qui ont accs au systme satellite sont couramment
nommes des gateways. Celles-ci sont peu nombreuses, souvent rduites une seule entit par
systme. Toutefois plusieurs gateways peuvent se partager le systme. Les mthodes daccs, dans
ces cas, restent pour le plus souvent des solutions propritaires, reposant souvent sur une division
frquentielle de la bande passante, voire temporelle pour des systmes avec intelligence bord.
Les gateways mettent dbit constant et permanent, le bourrage tant donc communment
utilis en cas de ncessit. Les metteurs DVB-S mettent en uvre une technologie pointue et
ont donc un cot lev, tandis que les rcepteurs DVB-S sont peu coteux, fruit dune technique
rode. En effet, le succs de la tlvision numrique a grandement contribu au dveloppement
des IRD (Integrated Receiver Decoder) et ce moindre cot.
30
2.3. Les tables de service

Pour grer lmission et la rception des diffrents flux et programmes vhiculs par le
satellite, des tables de signalisation sont ncessaires. Ces tables sont nommes tables de service et
sont dfinies dans plusieurs standards :
La norme ISO MPEG-2 [4] dfinit les tables PSI (Program Specific Information) qui
dcrivent les diffrents lments prsents dans un flux MPEG-2 TS.
La norme DVB-SI (DVB System Information) [13] propose des tables spcifiques au
systme DVB. Les tables SI sont un complment dinformation aux tables PSI,
indiquant aux terminaux les diffrents services offerts par le systme.
Dautres tables sont envisages par les normes DVB. Les normes interactives telles que
DVB-RCS ajoutent une signalisation pour grer la voie retour (capacit et accs).
Cette tude se focalise uniquement sur les tables de services MPEG-2 et DVB-SI, pour
pouvoir au final caractriser la mthode de dtection des diffrents programmes par un terminal.
2.3.1.
Tables PSI
Les tables PSI sont de quatre types diffrents (Figure 2.7) et vhiculent linformation
minimale qui permet aux terminaux didentifier et daccder aux diffrents flux dun multiplexe.
Ces tables ont pour la plupart un PID fixe et portent uniquement sur le multiplexe dans lequel
elles sont vhicules.
La table PAT (Program Association Table) indique pour chaque service du multiplexe le
PID de sa table PMT (Program Map Table). De plus celui-ci doit aussi renseigner sur le PID de la
table NIT (Network Information Table) (ce dernier tant souvent fix 10). Cette table, unique
par multiplexe, est cre par lentit de gestion du systme satellite.
La table CAT (Conditional Access Table) contient des informations de type priv, et donc
spcifiques au systme, sur laccs au systme. En particulier cette table indique les flux EMM
(Entitlement Management Message) contenant une autorisation daccs au service pour les
terminaux.
La table PMT (Program Map Table) dtient les informations sur un unique programme
cest--dire tous les PIDs des ES constituant le programme ainsi que la localisation du PCR
(Program Clock Reference) de ce service.
La table NIT (Network Information Table) fait partie du standard MPEG-2 mais son
contenu, sa syntaxe et son caractre obligatoire ont t introduits par la norme DVB-SI. Cette
table fournit des informations sur lorganisation physique des multiplexes et TS dun rseau
donn ainsi que des informations sur le rseau courant (table_id = 0x40) ou sur un autre rseau
(table_id = 0x41). Ces informations de type priv sont par exemple le nombre de transpondeurs,
les coordonnes de lorbite du satellite, etc.
Figure 2.7 Reprsentation des quatre tables de service PSI
31
2.3.2.
Tables SI
Ces tables ont t spcialement ajoutes par la norme DVB pour traiter un certain nombre
dinformations supplmentaires. Ces tables sont divises en deux types : des tables obligatoires
dune part, et des tables optionnelles dautre part. Nous prsentons brivement ici ces tables
(pour plus dinformations se rfrer au standard ETSI EN 300 468 [13]) :
Les tables obligatoires, mise part la table NIT dcrite ci-dessus, sont :
la table SDT (Service Description Table) dcrivant les services prsents dans le
systme,
la table EIT (Event Information Table) dcrivant le service courant sur le multiplexe
ainsi que le service venir (heure de dpart, dure, ),
la table TDT (Time and Date Table) fournissant lheure et la date courante aux
IRDs.
Les tables optionnelles regroupent de nouvelles tables ainsi que des extensions des
tables prcdentes :
lextension de la table NIT des rseaux autres que celui courant,
la table BAT (Bouquet Association Table) identifiant les diffrents services dun
mme bouquet,
lextension de la table SDT des rseaux autres que celui courant,
les extensions de la table EIT des rseaux autres que celui courant, et
lintroduction dun planning complet des diffrents services venir,
la table RST (Running Status Table) informant de ltat dune diffusion (cette table
est plutt diffuse au dbut et la fin de lmission),
la table TOT (Time Offset Table) donnant le dcalage entre le temps local et le
temps de rfrence du systme,
la table ST (Stuffing Table) utilise pour remplacer et invalider une section.
Cette prsentation nest pas exhaustive, dautant plus que la norme autorise lutilisation de
tables prives. Les tables prives permettent la mise en uvre de nouvelles techniques au risque
toutefois de perdre en interoprabilit. Pour combler ce problme, la norme DVB essaie
dincorporer les tables dintrt gnral dans ses mises jour, comme notamment la table INT
[14] que nous tudierons plus tard, dans la partie 3.
Figure 2.8 Reprsentation des tables de service SI
32
2.3.3.
Exemple de structure dun programme
Ces tables peuvent tre mises par lentit de contrle et de gestion du systme, mais aussi
par les fournisseurs de services (PMT par exemple). La plupart de ces tables, lexception des
tables RST, sont mises priodiquement afin que les IRDs puissent dcoder et accder aux
programmes qui les intressent.
Figure 2.9 Schma dun guide de programme
Pour pouvoir dcoder un programme, le jeu des tables PSI peut tre suffisant (Figure 2.9).
En effet, une fois la gestion des bouquets et du rseau effectue, et la table SDT consulte pour
connatre la liste des services proposs, la table PAT est consulte par lIRD pour connatre le
PID de la table PMT correspondant au programme choisi. La table PMT permet de trouver et de
dcoder les diffrents ESs constituant le programme.
Il peut arriver dailleurs que dans un mme programme on retrouve diffrents flux (par
exemple audio) qui correspondent des choix utilisateurs comme la langue, le sous-titrage, etc.
2.4. La norme DVB-RCS

La norme DVB-S prsente un certain nombre davantages : une grande capacit, un dbit
constant ou encore une parfaite adquation la tlvision. Toutefois larrive sur le march de
nouveaux types de services permettant un vritable choix voire mme un dialogue avec
lutilisateur final, demande ce dernier de pouvoir transmettre des donnes. Or cette interactivit
nest pas prvue par DVB-S. Plusieurs solutions ont t proposes comme lutilisation dun lien
terrestre pour se charger des requtes de lutilisateur. Ce type de techniques fonde sur un lien
retour dissymtrique, est nomm UDLR (UniDirectionnal Link Routing) [15], et propose une
solution, dans le cas o une connexion terrestre est possible. Toutefois un standard DVB
considre la possibilit dun lien retour satellite interactif, le standard DVB-RCS (DVB Return
Channel for Satellite) [16].
Le DVB-RCS est un standard interactif rpondant au besoin dun lien retour notamment
pour la tl interactive. Cette norme nest donc pas spcifique un type de donnes multimdia
contrairement au DVB-S, puisquil sagit de donnes des utilisateurs finals dpendants de
lapplication (achats, jeux, chats, requtes diverses).
La norme DVB-RCS a t spcialement cre pour un canal interactif. Elle allge le cot de
la liaison proposant un lien retour satellite aux utilisateurs sans que cela ne monopolise les
33
ressources inutilement, ce qui nest pas le cas avec le DVB-S qui met un flux constant de
donnes et provoque du bourrage en absence de donnes mettre. La norme DVB-RCS est
prsente comme un apport au DVB-S, et cest lune des raisons pour lesquelles les deux normes
sont souvent confondues, puisquelles fonctionnent en troite corrlation. Il est donc naturel de
la prsenter ici en lincorporant une architecture DVB-S, comme le prconise la norme.
2.4.1.
Mise en uvre du DVB-RCS
La norme prvoit pour un systme DVB-S la possibilit dinteragir avec un systme DVBRCS. Ce systme peut tre support par deux satellites diffrents (Figure 2.10), ou un seul satellite
intgrant les deux technologies. Le systme DVB-RCS est intgralement dpendant des flux aller
DVB-S qui contiennent les diffrentes informations pour rgler le systme (accs, signalisation et
synchronisation des terminaux).
La mthode envisage par la norme permet donc de rester dans le cadre DVB-S actuel tout
en apportant une marge interactive diffrentes applications. Les avantages des deux
technologies sont ainsi runis en un seul systme, avec toutefois une nuance : mme si le cot
technologique dun transpondeur DVB-RCS est moins lourd quun metteur DVB-S, notamment
avec les VSAT, les cots matriels, dinstallation comme de location de la bande passante restent
levs. Dans la norme, ces terminaux sont nomms les RCST (Return Channel Satellite
Terminal).
Figure 2.10 Architecture DVB-S/DVB-RCS
Dans la figure ci-dessus, on remarque plusieurs entits de gestions du systme : le NCC

(Network Control Centre) et le NMNC (Mission and Network Management Centre). Ces entits
sont charges de grer le systme, de soccuper de laccs au systme ainsi que dune grande partie
de la signalisation. Ces fonctionnalits peuvent tre intgres dans une gateway. Les flux DVB-S
transportent la signalisation DVB-RCS. Celle-ci est diffuse sur tout le faisceau DVB-S, et les
terminaux peuvent ainsi se synchroniser et mettre leurs donnes vers la gateway, via un faisceau
descendant restreint.
2.4.2.
Pile de protocoles
Le DVB-RCS contrairement au DVB-S nest pas fond sur lmission dun flux constant
mais sur lmission de bursts utilisant un dcoupage spcifique en temps et frquence (cf. partie
2.4.4). Peu dpendant du type de donnes vhiculer, le DVB-RCS propose deux mthodes
34
dencapsulation : une mthode utilisant les cellules ATM et une autre reposant sur les paquets
MPEG-2 TS. Comme le montre la figure suivante (Figure 2.11), la pile de protocoles mise en jeu
pour lencapsulation dune donne de type standard (ici un datagramme IP) diffre avec la
mthode choisie.
Figure 2.11 Deux encapsulations proposes pour le DVB-RCS
Comme on peut le constater ces deux mthodes diffrent uniquement au niveau 2 :
Lencapsulation dans des cellules ATM est gre par la couche dadaptation AAL5
(ATM Adaptation Layer 5), qui est adapte lencapsulation de datagrammes. Cette
technique est dcrite par la norme comme devant tre obligatoirement supporte par
tout systme utilisant la technologie DVB-RCS.
Lencapsulation en paquet MPEG-2 TS utilise la mthode des sections utilise pour

encapsuler les tables SI et PSI : le protocole MPE (MultiProtocol Encapsulation). Cette
mthode est optionnelle daprs la norme de 2003 [16].
Dans ces deux cas, le niveau physique reste le mme : le DVB-RCS. Les donnes une fois
encapsules en cellules ou paquets, sont regroupes en un burst (1, 2 ou 4 cellules gnralement)
puis sont brasses pour disperser lnergie. Un prambule est ensuite appliqu au paquet en
fonction des diffrents codages (cf. partie 2.4.3). On notera enfin la prsence dun champ
optionnel, qui est notamment utilis par la mthode daccs SAC (Satellite Access Control).
2.4.3.
Contrairement la chane de transmission DVB-S, la norme DVB-RCS propose dutiliser

les turbo-codes comme option [16]. En effet, comme lillustre la figure ci-dessous (Figure 2.12),
aprs le codage CRC, on peut, soit suivre un traitement identique la chane de transmission
classique du DVB-S (cf. 2.2.3), soit remplacer la chane codage Reed-Solomon, entrelacement et
codage convolutif (aussi appel codage concatn) par du turbo-code [17].
Figure 2.12 Aperu de la chane de codage du DVB-RCS
Il faut toutefois noter que la tendance gnrale est lutilisation des turbo-codes dans le
DVB-RCS. Ces codes plus complexes que le codage convolutif en treillis, sont aussi beaucoup
plus performants [18].
35
2.4.4.
Mthode daccs
La mthode daccs du systme DVB-RCS est plus complexe que celle du DVB-S, puisque
le DVB-S na pas vocation partager sa bande passante entre beaucoup de gateways. En effet, il
faut rappeler que le DVB-RCS a une vocation dinteractivit, et doit permettre ainsi un grand
nombre de terminaux davoir accs au systme. Un partage des ressources fixe et constant nest
donc pas viable.
Pour cela, chaque terminal envoie des messages au NCC (Network Control Centre)
permettant de fixer et de garantir certains aspects de la qualit du service (dbit, gigue, temps de
transfert..etc.)
Dans cette partie nous proposons un aperu des messages DVB-RCS, de la signalisation
spcifique et des diffrentes mthodes daccs qui prennent appui sur ces derniers.
2.4.4.1.
La signalisation sur la voie aller
La gestion du rseau interactif est en grande partie prise en charge par le lien aller DVB-S,
la signalisation FLS (Forward Link Signalling). Cette signalisation est fonde sur trois points :
de nouvelles tables SI,
des messages spcifiques appels TIM (Terminal Information Message),
les informations PCR (Program Clock Reference), dj utilises dans de DVB-S.

Ces messages sont tous encapsuls en utilisant le section-packing utilis pour les tables SI en
DVB-S. La plupart sont dailleurs gnrs par le NCC et insrs au niveau de la gateway, comme
peut ltre une table PAT.
Les nouvelles tables SI sont :
CMT (Correction Map Table) : Cette table permet aux terminaux de corriger leurs
temps, frquences et puissances pour leurs prochaines missions. Elle est calcule par le
NCC, ou par le systme bord dans le cadre dune intelligence embarque.
FCT (Frame Composition Table) : cette table dfinit le nombre et le type de time slots
contenus dans une trame. Elle est mise par le NCC.
RMT (Rcs Map Table) : cette table indique au terminal comment se positionner sur le
multiplexe descendant de son fournisseur daccs au rseau. Cette table est mise par
loprateur satellite, et son PID est indiqu par la table NIT.
SCT (Supertrame Composition Table) : cette table dcoupe la capacit du satellite en

supertrames, indiquant lheure de dmarrage, la frquence centrale, la dure ainsi que le
nombre de trames qui la composent. Cette table est mise par le NCC et son PID est
renseign dans la table PMT.
SPT (Satellite Position Table) : Cette table est transmise sur chacun des multiplexes et
indique la position du (ou des) satellite(s). Cette table est sous la responsabilit de
loprateur satellite.
TBTP (Terminal Burst Time Plan) : cette table attribue les diffrents time slots aux
diffrents terminaux, en faisant la relation entre les numros des time slots et les
identifiants logiques des terminaux. Cette table est mise par le NCC et est
indispensable pour quun terminal puisse utiliser les time slots qui lui sont attribus. Le
TBTP informe donc les terminaux de la capacit relle qui leur est alloue.
TCT (Time slot Composition Table) : cette table dcrit le type de burst contenu dans
chaque time slot (CSC, ACQ, SYNC ou TRF), le taux de codage, etc. Cette table fixe
aussi le prambule ; elle est mise par le NCC.
36
Les messages TIM ne sont pas vraiment des tables de signalisation dans la mesure o il
sagit de messages privs envoys vers un groupe ou un seul terminal par un organisme de
contrle du systme. Ces messages peuvent contenir des informations diverses, comme la
rponse dun NCC une demande douverture de connexion, les identifiants dun terminal, des
attributions de time-slots pour un court temps, des informations sur le rseau
Pour viter une drive des frquences, et donc des collisions, les messages PCR sont
gnrs, permettant lasservissement des oscillateurs des terminaux. Ces messages sont diffuss
avec une priodicit de 5 100 ms et leur PID est indiqu dans la table PMT.
2.4.4.2.
La signalisation sur la voie retour
La signalisation sur la voie retour est effectue via des bursts. En effet nous avons vu
prcdemment (cf. partie 2.4.2) que les donnes taient envoyes sous forme de bursts, appels
bursts de trafic (TRF). Toutefois, dautres bursts sont utiliss par la technologie DVB-RCS :
Le burst CSC (Common Signalling Channel) : ce burst permet aux terminaux de

sidentifier durant la phase de login. Il comporte des champs tels que ladresse MAC du
terminal (IEEE 802.11) ou bien les capacits du terminal ;
Le burst ACQ (ACQuisition) : il sert la synchronisation ;
Le burst SYNC (SYNChronisation) : ce burst est utilis pour maintenir la

synchronisation et envoyer des informations de contrle tant que le terminal est
connect. Ce burst contient un champ SAC (Satellite Access Control).
A partir de ces messages, la signalisation sur la voie retour peut tre gre selon deux
mthodes :
la mthode SAC (Satellite Access Control) qui utilise le champ optionnel des bursts de
trafic et les bursts SYNC et utilise les slots SYNC comme un canal contention pour les
requtes dallocation,
la mthode DULM (Data Unit Labelling Method) qui cre des circuits virtuels.
2.4.4.3.
Le partage de la ressource
Le mode daccs TDMA (Time Division Multiple Access), utilis parfois pour la voie aller
(dans le cadre dune charge utile rgnrative), pose problme sur la voie retour. En effet, pour la
voie aller, il y a le plus souvent une seule gateway qui se contente de dcouper sa bande alloue
entre diffrents groupes dutilisateurs, tandis que dans le cadre de la voie retour, un grand nombre
de terminaux veulent se partager le mme canal. Aussi le TDMA ne suffit pas viter les
collisions entre les diffrents bursts des terminaux actifs.
Le mode daccs utilis pour la voie retour est alors le mode MF-TDMA qui utilise un
dcoupage de la bande alloue en supertrames. A chaque groupe de terminaux une supertrame est
alloue et celle-ci est elle-mme dcoupe en trames. Chaque trame est constitue dun ensemble
de time-slots, chacun ddi la transmission dun burst prcis. La figure suivante (Figure 2.13)
prsente ce dcoupage.
Il existe deux types de partage MF-TDMA de la bande passante : un mode statique et un
mode dynamique. La mthode statique utilise des time-slots de mme dure et de codage identique.
Il suffit alors des informations sur un seul time-slot pour que le terminal puisse mettre, donc dun
seul message TIM. Cette technique rduit grandement les temps dattente dmission sur le mdia
et les messages envoyer (notamment les TCT). Plus complexe, la mthode dynamique se
construit sur des time-slots de taille variable, permettant une meilleure flexibilit, et donnant la
NCC la possibilit dattribuer plus ou moins de grands time-slots, en fonction de lallure du trafic.
Toutefois cette mthode demande plus de calculs de la part de la NCC (elle doit transmettre les
informations de chaque time-slot), ce qui risque de dgrader le temps daccs au support.
37
Figure 2.13 Segmentation de la bande alloue la voie retour en supertrames, trames et time-slots
La mthode dallocation de ressources peut tre de plusieurs types. Nous en prsentons

deux ici. Laccs au support peut tre fix pour toute la dure dune communication, allouant un
terminal ou un groupe dutilisateurs une partie fixe de la bande passante. Les mthodes de ce
type sont souvent gres par la fonction CAC (Connection Admission Control). La bande
passante pour une communication peut aussi tre attribue dynamiquement, permettant ainsi de
sadapter au trafic, et doptimiser lutilisation de la capacit satellite. Ces mthodes, appeles
DAMA (Demand Assignment Multiple Access), sont toutefois plus complexes mettre en uvre
et introduisent un temps daccs au support variable et complexe modliser.
2.5. Conclusion
Ce chapitre offre une vision densemble de la norme DVB et de sa mise en uvre dans le
cadre satellite. Cest pour cette raison quil est relativement court.
Il sagissait ici de familiariser le lecteur avec les systmes satellite DVB pour pouvoir
aborder ensuite pleinement le dploiement dIP dans ce contexte. Le niveau de dtail a donc t
38
port en priorit sur les aspects de niveau 2, savoir laccs et lencapsulation sur lesquels nous
allons revenir plus en dtail dans la partie suivante.
39
CHAPITRE 3. LE SATELLITE COMME SUPPORT DIP
3. LE SATELLITE COMME SUPPORT DIP

Aprs la prsentation de la norme DVB-S, largement utilise actuellement, un axe central
de peut tre abord : le satellite comme support dIP.
Lutilisation du satellite comme support dIP date du dbut des annes 90 : plusieurs tudes
ont t menes en utilisant la technologie ATM [19] [20]. ATM a ainsi laiss sa marque dans les
rseaux satellites, mais ce nest pas pour autant un frein pour le support dIP. Toutefois les
solutions actuelles ne sont quen partie satisfaisantes, ouvrant la voie la recherche sur le
domaine, notamment avec les perspectives offertes par la norme DVB. Ces dernires annes
(2003-2004) ont vu un grand nombre de projets donner de nouveaux lments, et les annes
venir (2005-2006) devraient voir laboutissement de beaucoup de projets orchestrs par lESA, le
CNES ou encore ALCATEL.
Cette partie propose une tude du satellite gostationnaire comme support dIP. Aprs un
aperu dans la section 3.1 des techniques passes (annes 90) et de leurs inconvnients, lattention
est porte sur le DVB-S et son adquation au support dIP (section 3.2). Les points forts de cette
technique tout comme ses dfauts sont souligns. Si le standard DVB-RCS apporte quelques
rponses ces difficults, notamment en terme dinteractivit, des problmes persistent comme
nous pourrons le remarquer avec la section 3.3. Dans un quatrime temps, le cur de la
problmatique de notre travail est trait avec la nouvelle donne propose par les perspectives
actuelles du satellite GEO comme support dIP (section 3.4). Toutefois, au-del des problmes
technologiques et des diffrentes solutions, un autre problme fondamental rside dans
ladquation du satellite au protocole TCP (Transmission Control Protocol). Nous observerons
ces problmes comme les solutions dans la section 3.5, avant de conclure cette partie sur un
besoin architectural que nous proposerons daborder par la suite (section 3.6).
3.1. Ltat de lart et les obstacles limplantation d IP sur

Satellite
IP sur satellite, ou plus gnralement le transfert de donnes sur satellite, est un axe de
recherche qui a pris de lampleur dans les annes 90. cette poque, le satellite privilgie les
solutions ATM. Avec lessor prvu alors pour cette technologie, le satellite est envisag pour
interconnecter des rseaux et lATM est choisi dans le dbut des annes 90 comme support
dintgration des services haut dbit sur satellite [21]. Plusieurs projets [22] sont alors organiss
autour de cette thmatique avec COMSAT et la NASA aux USA, les programmes COST
(European Cooperation in the field of Scientific and Technical Research), RACE (Research and
technology development in Advanced Communications technologies in Europe) et ACTS
(Advanced Communication Technologies and Services) en Europe [21]. Ces programmes
proposent un grand nombre de solutions, interconnectant des rseaux ATM par satellite mais
aussi utilisant ATM comme support dIP sur satellite.
Les VSAT (Very Small Aperture Terminal) [23] jouent alors un rle fondamental, car quelle
que soit la technologie physique utilise, les VSAT offrent une interconnexion bidirectionnelle
avec les utilisateurs finals. Un VSAT est un terminal li un GEO muni dune petite antenne (1.2
m 2.8 m de diamtre). Compte tenu de son prix souvent lev (mme en location), le VSAT est,
la plupart du temps, utilis comme tte de pont dun rseau (interconnexion agences bancaires,
40
VPN, etc.). Cette technologie est apparue dans les annes 70, et a pris son envol entre 1998 et
1999 avec un dveloppement de prs de 400% (de 60000 installations 300000).
Cependant, la spcificit et la nature propritaire de ces systmes conduisent un milieu
htrogne o les comparaisons approfondies deviennent dlicates. Ces problmes de
standardisation [24] conduisent des solutions au cas par cas et entranent alors un problme de
cot technologique : les quipements tant spcifiques, leur cot est rdhibitoire, freinant ainsi
lexpansion dune solution par rapport une autre [25]. Si ces technologies ont su trouver parfois
leur place, notamment dans le cadre de linterconnexion commerciale, lhtrognit des
protocoles reste un obstacle majeur, surtout au niveau du cot et de ladaptabilit des systmes
aux technologies venir : satellite avec routage, IPv6, etc. De plus les mthodes daccs des
systmes de type VSAT sont de type ALOHA, limitant fortement la bande passante utile pour les
utilisateurs (64 Kb/s) [26].
Dans ce cadre, le dveloppement massif des satellites DVB propose une solution partielle
ce problme, avec un standard uniforme au moins au niveau 1 et une marge dadaptabilit leve.
Les mthodes daccs dans les systmes DVB-RCS posent toutefois problme, conduisant
plusieurs recherches dans le domaine.
3.2. Le DVB-S comme support dIP

Le DVB-S a t conu avec la possibilit de vhiculer des donnes autres que des flux
multimdia. Cette notion ouverte de la norme ainsi que sa large diffusion dans le monde satellite
(cf. 2.2) font delle un support de choix pour lIP. Dailleurs, un grand nombre de projets a tudi
et tudie encore cette hypothse [27][28][29][30], et des offres commerciales tout public
commencent timidement leur entre depuis les annes 2000 en Europe [31].
Cette partie sattarde sur la faon dont le DVB-S peut tre utilis pour vhiculer des
datagrammes, afin de souligner les diffrentes techniques utilises et ainsi de pouvoir mieux
comprendre les points qui restent encore problmatiques.
3.2.1.
tude de lencapsulation IP
Lorsquun datagramme IP doit tre achemin via un systme satellite, une entit de niveau
3 doit tre prsente en bordure du systme pour formater et multiplexer le datagramme dans le
trafic satellite, le trafic MPEG-2 TS. Cette partie aborde donc les diffrentes mthodes envisages
par la norme DVB pour encapsuler et ensuite multiplexer des donnes dans un flux MPEG-2 TS.
Figure 3.1 Cinq mthodes de multiplexage de donnes dans la couche MPEG-2 TS
La norme DVB prvoit six mthodes dencapsulation [32]. Parmi elles, la mthode prive
laisse linitiative totale sur le choix dencapsulation et dimplantation condition que les
datagrammes soient au final encapsuls dans les paquets MPEG-2 TS. Toutefois, ce type de
41
mthode peut sinscrire dans une dmarche de normalisation seulement si elle est envisage pour
un systme global comme par exemple dans le cadre des travaux du groupe IP sur DVB [33].
Une mthode spcifique un systme donn ne prsente aucun intrt si elle nest pas
rutilisable, et contraint le systme rester en marge des autres, sans la possibilit dune
interconnexion directe.
Les cinq autres mthodes proposes par la norme DVB sont illustres dans la figure cidessus (Figure 3.1), et sont dtailles dans les parties suivantes, en insistant sur lencapsulation
recommande par la norme, la mthode MPE (Multi Protocol Encapsulation).
3.2.1.1.
Le data-piping
Le data-piping est souvent proche de la mthode prive, puisque sa seule contrainte est
lencapsulation des donnes comme sil sagissait de PES. Le reste (dcoupage, rassemblage)
reste la discrtion du dveloppeur. Comme lillustre la figure suivante (Figure 3.2), le data-piping
reproduit lencapsulation des PES dans le flux MPEG-2 TS, et utilise notamment le bourrage vu
prcdemment. Pour le reste, savoir len-tte, un code correcteur ou encore le rassemblage, la
mthode reste de type priv. Cette technique est souvent employe pour lencapsulation dIP (les
propositions du groupe IP sur DVB sont de ce type [33]). On la considre le plus souvent
comme la mthode prive (prsente prcdemment), et donc son nom est gnralis toutes les
techniques prives, incluant alors une encapsulation possible sans bourrage.
Figure 3.2 Exemple dencapsulation dun datagramme par data-piping
3.2.1.2.
Le data-streaming
Le data-streaming considre les donnes comme un flux continu, comparable un flux vido
ou audio. Ainsi ce flux de donnes est segment en PES et ensuite encapsul comme tout PES
dans les paquets MPEG-2 TS. Cette encapsulation peut tre faite de manire synchrone,
synchronise dautres PES (en utilisant le PCR) ou asynchrone (ce qui est le cas de donnes
Internet). Ce mcanisme est illustr ci-dessous (Figure 3.3) mais est peu adapt au transport de
flux IP, dans la mesure o les datagrammes forment rarement un flux continu de donnes.
Figure 3.3 Exemple dencapsulation dun datagramme par data-streaming
42
3.2.1.3.
Le data-carousel et lobject-carousel
Le data-carousel et lobject-carousel sont des techniques dencapsulation et de multiplexage trs

proches. La couche data-carousel utilise un buffer pour stocker les donnes mettre. Ces donnes
sont ensuite vides cycliquement (peu importe leur type). Cette transmission priodique est
utilise notamment dans la transmission des tables de programmes, les EPG. Le data-carousel
utilise les mmes techniques que MPE pour lencapsulation (le DSM-CC). Toutefois, les sections
utilises sont de taille fixe.
Lobject-carousel est trs semblable au data-carousel. Reposant sur le DSM-CC, il est utilis pour
envoyer de manire cyclique des donnes lies des services. Ces donnes peuvent tre lies au
temps grce au stream event.
3.2.1.4.
Le Multi Protocol Encapsulation (MPE)
Parmi les diffrentes mthodes dencapsulation proposes par le DVB, MPE est celle que
la norme retient et recommande pour les flux IP [11] [14]. MPE est la mthode utilise par
MPEG-2 et DVB pour encapsuler les tables de services. Ce protocole sappuie sur le DSM-CC
(Digital Storage Media Command and Control) pour oprer. Cette utilisation est dfinie dans la
partie 6 de la norme MPEG-2 [4] et met en place une connexion client/serveur. MPE utilise cette
extension de MPEG-2 pour encapsuler les datagrammes IP en mulant un LAN.
Le datagramme IP, une fois la gateway, est trait par le niveau IP de celle-ci. Envoy au
niveau MPE, il est alors encapsul dans une section prive appele une section datagramme (ou
section adressable dans la norme ATSC). La section a une taille variable avec une MTU de 4080
octets. Cette opration est illustre dans la figure suivante (Figure 3.4). On peut noter que la
couche MPE ne fait pas la fragmentation de la donne, et cest le niveau rseau qui doit
fragmenter le datagramme IP si la taille de ce dernier est suprieure la MTU dune section. MPE
ajoute un en-tte de 12 octets chaque fragment de datagramme. Cet en-tte est appel un pointerfield. Enfin un CRC de 4 octets est appos la fin de la section. Il faut toutefois remarquer que
len-tte peut aussi contenir des champs optionnels et notamment le champ LLC-SNAP
conforme la norme ISO/IEEE pour les LAN/MAN. Cet ajout de 8 octets supplmentaires
alourdit certes loverhead du paquet, mais permet de faire directement du bridge Ethernet, en
encapsulant des trames Ethernet. Dans un cadre IP classique, cette option nest pas ncessaire.
Une fois sous forme de sections, les fragments sont encapsuls et multiplexs dans des
paquets MPEG-2 TS. Cela peut tre fait avec ou sans bourrage. Le mode sans bourrage est plus
couramment nomm loption section-packing.
Figure 3.4 Exemple dencapsulation dun datagramme par MPE
43
Lintroduction du pointeur de 1 octet pour renseigner sur le dbut de la prochaine section

utilise le champ PUSI de len-tte obligatoire MPE (Figure 3.7). Ce flag, sil est utilis en accord
avec la norme indique la prsence dun champ optionnel suivant len-tte. Nomm adaptation-field,
ce champ est compos ici de 4 octets supplmentaires, dont 1 octet (le dernier) est le champ
pointeur, indiquant le dbut de la nouvelle section (Figure 3.5). Toutefois parmi ces quatre octets
optionnels, seul le champ pointeur est rigoureusement ncessaire. Ainsi, il est envisageable, en
contournant lgrement la norme MPEG-2 TS, dimplanter uniquement lajout dun unique octet,
le champ pointeur, et ainsi de changer la signification du champ PUSI. Dans le cadre de cette
modification, le flag PUSI indique la prsence directe dun unique pointeur juste aprs len-tte
obligatoire MPEG-2 TS. Cette utilisation rend toutefois incompatible le champ PUSI avec un
champ dadaptation classique. Cette solution nest donc pas totalement conforme la norme,
mais apporte un allgement lencapsulation.
Figure 3.5 Insertion du champ pointeur dans le champ dadaptation MPEG-2 TS
Lencapsulation avec bourrage conomise ce pointeur associ au dbut dune nouvelle

section (et les 3 autres octets de champ optionnel supplmentaire dans le cas dune implantation
rigoureuse). Cependant, le gain peut savrer faible sil est compar aux octets perdus par le
bourrage. Le section-packing propose un rendement quivalent une encapsulation classique IP sur
Ethernet, comme le montre le graphique suivant (Figure 3.6).
En effet si lon note s la taille du datagramme en octets et TE(s) la taille de la trame
Ethernet en octets encapsulant ce datagramme. Puisque la taille minimale dune trame Ethernet
est de 72 octets, on obtient la formule suivante (1), avec 22 octets den-tte et 4 octets de CRC
(IEEE 802.3) :
(1)
TE ( s ) = max(72, s + 26)
De mme lorsquil sagit de la taille MPEG-2 TS gnre par le mme datagramme de taille
s, lon trouve trois valeurs possibles : TMB qui est la taille avec bourrage (2), TMP la taille avec
section-packing (3), et TMPA la taille avec section-packing rduite un seul octet supplmentaire (4).
TMB est obtenu en calculant le nombre de paquets MPEG-2 TS requis pour contenir le
datagramme. Comme il y a du bourrage, cest un nombre entier, donc une partie entire
suprieure qui est obtenue. Pour le section-packing, il faut prendre en compte le pointeur, mais
seulement une fraction du dernier paquet est utilise pour la donne. Il faut noter que ces calculs
sont effectus dans un cadre o les donnes arrivent un rythme suffisant pour permettre
dviter le bourrage dans le cadre du section-packing.
44
(2)
TMB ( s ) = ( s + 16) 184 .188
(3)
TMP ( s ) = ( ( s + 16 + 4) 184 ) .188
(4)
TMPA ( s ) = ( ( s + 16 + 1) 184 ) .188
On obtient en faisant les rapports TMB sur TE, TMP sur TE et TMPA sur TE la courbe cidessous (Figure 3.6). Cette courbe montre alors les bonnes performances du section-packing avec
MPE, permettant dobtenir un rendement voisin dune encapsulation Ethernet.
3
Rapport taille MPE sur taille Ethernet
2.5
1.5
0.5
200
400
avec bourrage
section packing
section packing amlior
600
800
1000
1200
1400
Taille du datagramme (Octets)
Figure 3.6 Comparaison des tailles des donnes une fois encapsules avec MPE et Ethernet
Pour terminer ltude de MPE, son en-tte, appel le pointer-field, est dcrit ici. Cet en-tte
est compos des champs obligatoires suivants (Figure 3.7) [4] [6] :
Figure 3.7 Champs obligatoires de len-tte dune section datagramme (12 octets)
45
Table_Id : ce champ dun octet prend la valeur 0x3F, dsignant ainsi une section
datagramme.
Section_Syntax_Indicator : cet indicateur est fix zro (selon lannexe A de [11])
Error_Detection_Type : ce drapeau dun bit mis la valeur 1 indique lutilisation du

checksum, la valeur 0 indiquant lutilisation dun CRC_32.
Reserved : ce champ de 2 bits est fix 11 et est rserv des utilisations futures.
Section_Length : il sagit de la taille de la section code sur 12 bits.
Device_Id : ce champ est compos de 48 bits diviss en 6 parties de 1 octet chacune. Il

sagit de ladresse du destinataire. Cest une adresse MAC conforme la norme
ISO/IEEE et celle-ci est rordonne selon la figure (Figure 3.8).
Payload_Scrambling_Control : ce champ de 2 bits dfinit le mode de cryptage de la

charge utile de la section. La mthode de cryptage utilise est de type priv.
Address_Scrambling_Control :ce champ de 2 bits dfinit le mode de cryptage du

device_Id de cette section. La mthode de cryptage utilise est de type priv.
LLCSNAP_Flag : cet indicateur de 1 bit, indique sil est fix 1, que la charge utile
transporte un datagramme encapsul avec LLC/SNAP. Cet en-tte optionnel est plac
sur 8 octets supplmentaires juste aprs le deviced_Id [47..40].
Current_Next_Indicator : ce bit est fix 1 pour les sections adressables DSM-CC.
Section_Number : ce champ dun octet correspond au numro de la section,

incrment de un chaque nouvelle section dun mme flux.
Last_Section : ce champ dun octet correspond au numro de la dernire section, cest-dire le numro le plus grand pour une section de cette table.
Figure 3.8 Dcoupage de ladresse MAC destination dans les champs Deviced_Id de la section
Ces techniques dcrites, leur utilisation va tre observe, travers un exemple.
3.2.2.
Architecture dtude
Cette partie propose une vision densemble des systmes DVB-S comme support dIP.
Cette architecture dtude est un cas classique dIP sur DVB-S.
3.2.2.1.
Une vision densemble de larchitecture
Cette structure satellite classique sappuie sur une liaison DVB-S unidirectionnelle. Le lien
DVB-S inonde les terminaux du systme via un satellite monofaisceau et transparent (sans
intelligence bord). Le satellite est donc assimilable un hub spatial qui rpte et amplifie le signal
vers le sol dans une couverture quivalente 1/3 1/4 de la surface du globe.
46
Si le lien aller utilise le DVB-S, dans la plupart des cas, il nest pas envisageable que la voie
retour repose sur cette mme technologie. En effet, dune part le cot dune gateway par
utilisateur, ou mme par regroupement dabonns, reste prohibitif, et dautre part le systme
DVB-S ne peut fonctionner pour un grand nombre de gateways. Le lien retour doit utiliser une
autre technologie, et le plus simple apparat comme un retour terrestre. Laccs Internet via
satellite est donc traditionnellement accompagn dune voie de retour terrestre fonde sur la
technologie en place, le RTC (Rseau Tlphonique Commut). Cest pour ce type de
configuration asymtrique que le protocole UDLR a t cr [15]. La figure suivante prsente
alors cette architecture (Figure 3.9) dans le cadre dun service daccs Internet, et nous
reviendrons plus en dtail dans la partie suivante sur les piles de protocoles mises en jeu.
Satellite GEO
Transparent
IP
MPE
MPE
DVB-S
-S
VB
MPEG-2 TS
UDLR
DV
BS
UDLR
IP
MPEG-2 TS
DVB-S
Terminal
Satellite
Terminal
Satellite
Gateway
Terminal
Satellite
FAI
FAI
RTC
RTC
Internet
Internet
Figure 3.9 Architecture classique IP sur DVB-S comme accs Internet
Ce type darchitecture est adapt aux applications diffuses et quasi unidirectionnelles

comme le caching, le pushing, ou la VoD.
Un tel systme est gnralement contrl et gr par un NCC (Network Control Centre) et
un MNMC (Mission and Network Management Centre). Ces lments ne sont toutefois pas
reprsents sur la figure ci-dessus, et peuvent tre incorpors une gateway.
Ce systme fonctionne en bande Ku avec un C/N de 6.9 dB [34]. Les terminaux sont
quips de petites paraboles (60 cm de diamtre) et la gateway dispose dune antenne de quelques
mtres de diamtre (3 6 mtres). A lmission on dispose dun dbit utile par canal de 38
Mbits/s pour un FEC de . Une gateway peut ainsi tre quipe de plusieurs transpondeurs et
mettre ainsi plus fort dbit sur diffrents canaux. Toutefois, il faut noter quun quipement
uniquement ddi au transport de datagrammes nest pas courant, et loffre IP doit le plus
souvent partager la bande passante avec dautres services tels que la tlvision numrique, les
radios ou les services de NVoD (Near Video on Demand) directes sur DVB.
3.2.2.2.
Les couches protocolaires
Les couches protocolaires mises en uvre se retrouvent dans la gateway et les terminaux,
puisque lun met en DVB-S et lautre reoit. La figure suivante (Figure 3.10) prsente la mise en
uvre de lUDLR sur cette architecture via une connexion PPP sur RTC comme voie retour.
47
Figure 3.10 Couches protocolaires entre une gateway et un terminal mettant en jeu un lien retour
terrestre
Lillustration propose un aperu des diffrents niveaux de protocoles qui entrent en jeu
dans une communication entre une gateway (ou un agent routeur du FAI) et le terminal utilisateur
connect au systme DVB-S. Le protocole UDLR nintervient ici que sur le lien retour : les
datagrammes destination de linterface air sont traits par la couche IP comme si cette interface
tait bidirectionnelle. Cest la couche UDLR qui intercepte le datagramme et lencapsule via GRE
(Generic Routing Encapsulation) dans un nouveau datagramme, mis cette fois-ci sur linterface
du rseau terrestre. A la rception du datagramme, le traitement est effectu jusquau niveau IP.
Le protocole GRE restitue le datagramme original au niveau 3 comme sil provenait de la couche
MPE. Si cette solution rajoute tout de mme de loverhead en encapsulant des datagrammes dans
des datagrammes, elle a lnorme mrite dtre transparente pour lutilisateur et donc le niveau
transport et applicatif.
3.2.2.3.
La signalisation du trafic
La signalisation du trafic IP nest pas une mince affaire et soulve un grand nombre de
problmes, questions que se posent en commun industriels et chercheurs dans un groupe de
travail de lIETF, IP sur DVB [33]. En effet la rsolution dadresse (AR), lment clef de la
signalisation du trafic IP sur satellite nest pas une tche aise puisquelle nest ni rglemente ni
associe une couche protocolaire. Pourtant, il est certain quil faut faire le lien entre ladresse
IPv4 (IPv6), ladresse MAC utilise dans MPE et le PID des paquets MPEG-2 TS.
Dans ce cadre un certain nombre de mthodes ont vu le jour [35] : des mthodes statiques
prives ou des mthodes dynamiques comme la mthode MMT (Multicast Map Table) que nous
avons utilise dans DIPCAST [28], ou encore la mthode AIT (Application Information Table)
utilise dans MHP (Multimedia Home Platform) [36].
Les mthodes statiques prsentent une solution simple mais coteuse pour le niveau 3. Ces
solutions de type priv proposent dutiliser un seul PID pour contenir tout le trafic IP. Aussi,
toutes les donnes sont contenues dans le mme TS et le filtrage doit tre fait au niveau IP ou
MPE (ou quivalent). Cela implique donc que toutes les stations intresses par le trafic IP
doivent couter et recevoir cet unique TS.
48
Les mthodes dynamiques utilisent la signalisation SI, des tables prives ou des protocoles
spcifiques. Ces tables permettent ainsi dindiquer le PID correspondant une adresse IP ou un
groupe dadresses IP. La norme DVB propose une solution gnrale utilisant cette mthode par
le biais de la table INT (IP/MAC Notification Table) [14]. Cette solution nest en rien obligatoire
et a t propose aprs le protocole MPE. Tout comme la mthode MPE est recommande par
la norme, la signalisation via les tables INT est aussi conseille.
La solution INT propose un mcanisme pour vhiculer les localisations dans un rseau
DVB des diffrents flux contenant des datagrammes (ou des trames Ethernet). Elle sappuie sur
trois notions principales :
La plateforme IP/MAC (IP/MAC platform) : identifie par son platform_id, elle

regroupe des flux IP/MAC et/ou des rcepteurs. Il sagit dun espace dadressage sans
conflit qui peut cohabiter avec dautres plateformes sur le mme multiplex comme tre
prsent sur diffrents multiplexes.
Le flux IP/MAC (IP/MAC stream) : il sagit du flux encapsul qui doit tre signal sur
le multiplexe. Ce flux peut contenir une adresse IP et/ou une adresse MAC.
Lidentifiant de plateforme (Platform_id) : il identifie de manire unique une plateforme

et son attribution est centralise par le projet DVB.
Si cette mthode est utilise, cela est notifi prfrentiellement dans la table NIT (la table
BAT peut aussi faire laffaire). Le descripteur utilis permet daccder au programme
correspondant aux informations de la plateforme IP/MAC (table PMT) via la table PAT. La table
PMT localise la table INT. En fonction de ladresse cherche, la table INT indique un numro de
service qui permet de trouver dans la table PAT, le PID de la table PMT correspondante, et
enfin le flux IP/MAC. Cette procdure est illustre dans la figure ci-dessous par un schma
rcapitulatif du processus dinterrogation des diffrentes tables (Figure 3.11).
Figure 3.11 Exemple de localisation dun flux IP/MAC avec la table INT
49
Les tables INT supportent les sous-rseaux, les adresses IPv4, IPv6, MAC ainsi que les
adresses multicast de type (*, G) comme (S, G)1. Ces tables permettent la gestion dun rseau FAI,
de la scurit des flux, de lidentification, etc. (cf. norme ETSI EN 301 192 [14])
La mthode INT propose donc un jeu de descripteurs pour grer lIP sur un rseau DVB.
Toutefois cette mthode ne donne pas de pistes quand lattribution des PID en fonction des
adresses IP, ni sur la rsolution dadresse au niveau MAC. Ce mcanisme sinscrit donc bien dans
la dmarche du DVB : proposer un standard ouvert. Cependant, la brche est ouverte aux
solutions propritaires tant que des questions majeures subsistent : la rservation des PIDs estelle statique ou dynamique ? Y a-t-il une translation entre PIDs et adresses IP ? O dclarer les
PIDs disponibles ? Comment grer les nouveaux abonns ?
3.2.3.
Limites des architectures classiques
Larchitecture classique fait lobjet de la partie prcdente : elle utilise un lien satellite
unidirectionnel DVB-S qui inonde les terminaux et se prsente comme atout pour les services
largement unidirectionnels et diffuss. Pour cette raison, la tlvision numrique sur satellite est
un succs. Nanmoins elle risque dtre abandonne lentement, face aux satellites de nouvelle
gnration, et avec motifs. Des techniques prives, des protocoles lourds, un problme de voie
retour ; ce type de structure prsente des limites, non ngligeables dans un contexte IP o laccs
Internet par ce systme classique na pas su percer. Cette partie propose dtudier les raisons de
ce semi chec, c'est--dire les limites des architectures classiques.
3.2.3.1.
Lencapsulation MPEG-2 TS et ses inadquations
Un des points les plus dbattus actuellement est lencapsulation des datagrammes dans les
paquets MPEG-2 TS. La mthode privilgie par la norme, MPE, ne contente pas tous les
acteurs du monde satellite. Dans ce cadre, le remplacement de cette mthode controverse est
lobjectif premier du groupe de travail de lIETF, IP sur DVB [33]. Deux solutions ont t
envisages : une dsormais obsolte, Simple Encapsulation for transmission of IP datagrams
[37]et ULE (Ultra Lightweight Encapsulation) [38], sur laquelle nous reviendrons plus tard. Une
question se pose alors : quest-ce qui justifie cette relle volont de remplacer MPE ?
La comparaison entre lencapsulation MPE et lencapsulation Ethernet montre que le
bourrage nest pas une bonne solution. Loption section-packing permet toutefois de rduire le foss
entre les deux encapsulations et de parvenir un ratio proche de 1 (Figure 3.6). Cependant le cas
dun section-packing total est idal, car selon le rythme des applications, les diffrentes congestions
et les passages dans des divers rseaux, il nest pas toujours possible de complter un paquet
MPEG-2 TS. Il faut alors faire un choix entre attendre ou mettre avec du bourrage [39].
Lencapsulation MPE reste cependant peu lourde en terme de poids den-tte et de CRC, mais
cest son efficacit qui est surtout en question. MPE semble ne pas vraiment tre adapt au trafic
IP, et son en-tte pourrait tre mieux utilis, en vitant les options trop nombreuses qui
augmentent invitablement le temps de traitement des stations terrestres. En effet, il nest pas
optimis, puisquil contient des lments non ncessaires la rception du datagramme [40].
MPE, sil convient de lIPv4 et peut transporter des trames Ethernet (avec un impact non
ngligeable sur loverhead), nest pas pour autant un protocole ouvert et flexible. Le protocole nest
pas adapt de lIPv6 tout comme la gestion de QoS. Il nest pas prt pour de la compression
den-tte IP, et noffre pas une bonne adquation avec lIP multicast, si bien que des solutions
proposent des encapsulations prives pour contourner le problme [41], ouvrant vers les satellites
de nouvelle gnration.
1 Cette notation correspond des adresses multicast de type adresse de groupes (*,G) ou adresse source et
adresse groupe (S,G).
50
En ce qui concerne la signalisation du flux, MPE ne met rien en place, et celle-ci doit tre
gre part, comme par exemple avec les tables INT (cf. partie 3.2.2.3). Ce problme est
certainement un dfaut majeur des mthodes proposes : aucune neffectue le travail
dencapsulation et de signalisation de bout en bout, souffrant alors de redondances et de
lourdeurs invitables. La translation entre adresses IP, PID et adresses MAC reste ce jour une
question ouverte, et mme si le travail du groupe IP sur DVB semble sorienter vers une
proposition, il reste encore sous forme desquisses [35]. Le problme dencapsulation laisse donc
une brche ouverte aux faiblesses de normalisation du monde satellite, incitant la multiplicit des
mthodes prives et propritaires.
3.2.3.2.
La voie retour et ses difficults
Un autre problme, tout aussi important, est la question de la voie retour. En effet, nous
avons vu pralablement que les gateways DVB-S ne pouvaient tre utilises pour la voie retour
puisque dune part leur cot est rdhibitoire et dautre part la technologie DVB-S et ses mthodes
daccs ne peuvent supporter un grand nombre de gateways. Or lun des intrts majeurs du
satellite est son dploiement ais qui ne requiert quasiment aucune infrastructure terrestre. Cette
position est confortable car elle permet au satellite de se placer seul sur un march o la
concurrence terrestre nexiste pas (dserts, bateaux, avions, plates-formes) ou difficilement
(villages, montagnes, mobiles, trains, ). Mais le problme du lien retour coupe toute
interactivit possible.
LUDLR et les solutions de ce type permettent doffrir lutilisateur cette interaction
recherche au prix dune infrastructure terrestre. Ces terminaux sont pour la plupart quips dun
retour RTC classique 28.8 Kbits/s (modem 56k) [42], puisque la prsence dune ligne ADSL
rend lutilisation dun lien satellite obsolte dans le cadre dun accs Internet (les prix comptitifs
des accs ADSL et plus gnralement des technologies terrestres compares aux technologies
satellites ne peuvent pas permettre une concurrence directe du satellite avec le terrestre).
Toutefois si cette mthode peut paratre une bonne solution, elle est coteuse pour un avantage
restreint. La ncessit dun lien retour terrestre prive dune part le systme satellite des clients des
zones isoles o les infrastructures terrestres ne sont pas dployes (question de cot ou
dimpossibilit physique). Dautre part cette asymtrie extrme entre lien satellite et modem 56k
nest pas adapte aux dveloppements massifs des applications tendance plus symtrique sur
Internet (chat, peer-to-peer, jeux vidos, etc). Avec un lien retour terrestre, le satellite perd son
accessibilit et donc une grande partie de ses clients potentiels.
3.2.3.3.
Les limites des satellites GEO transparents
Les satellites gostationnaires de type transparent ont de nombreux avantages, et proposent

une adquation relle la diffusion de la tlvision numrique. Toutefois, leurs adquations aux
besoins dIP restent partielles.
Dans larchitecture classique propose prcdemment (3.2.2), le satellite transparent influe
considrablement sur lutilisation de la bande passante utile. En effet lors dune transaction
unicast, comme dans le cas dun accs Internet, un datagramme envoy sur le systme
destination dun unique terminal sera reu (au moins au niveau DVB) par tous les autres
terminaux, et consommera la bande passante des autres terminaux, qui ne pourront pas recevoir
leurs donnes dans cette mme plage. Il sagit bien l dun gaspillage de ressources, provenant de
la nature diffusante intrinsque du mdia satellite ; un avantage premier qui peut vite devenir
nuisible pour fournir un accs Internet des milliers dutilisateurs.
La nature du faisceau du satellite peut tre change pour devenir plus troite, toutefois le
satellite perdrait son intrt dinterconnexion en un seul bond par une rduction de sa couverture
comparativement au dlai important quil engendre.
51
3.2.4.
Conclusions sur larchitecture classique
Larchitecture prsente dans cette partie est appele architecture classique car elle drive
directement des systmes DVB actuels utiliss pour la diffusion de la tlvision numrique.
Dailleurs une telle architecture pourrait tre ralise sur un satellite qui diffuse dj de la
tlvision, proposant le support dIP comme un service supplmentaire. Cette architecture
prsente un certain nombre davantages, de limites et dinconnues, et son intrt nest
certainement pas contester. Pour ces diffrentes raisons tout comme son importance historique,
nous avons choisi de lutiliser comme tmoin pour la suite de nos travaux. Elle servira alors de
rfrence et de comparatif, permettant de montrer en quoi elle peut tre suffisante dans certains
cas, tout comme en quoi de nouveaux systmes sont ncessaires.
3.3. Le DVB-RCS comme support dIP

Lun des problmes fondamentaux du DVB-S est son manque dinteractivit, entranant
lutilisation dune voie retour pnalisante pour le dveloppement dIP. Le DVB-RCS est la
rponse du groupe DVB au dfaut dinteractivit du DVB-S. Moins gourmande en ressource et
bande passante, la technologie DVB-RCS se couple aux VSATs pour donner des transpondeurs
prix raisonnables, compars aux gateways DVB-S. Cette partie tudie deux approches distinctes :
lutilisation du standard DVB-RCS comme seul support daccs au satellite, et le DVB-RCS
comme voie retour du DVB-S, conformment la norme. Cette partie conclut alors sur les
problmes qui restent rsoudre malgr lapport du DVB-RCS.
3.3.1.
DVB-RCS comme seul support dIP
Une solution fonde uniquement sur le standard DVB-RCS est dlicate. En effet la norme
DVB-RCS [16] prvoit que la synchronisation et la gestion du systme DVB-RCS soit orchestre
par le flux aller DVB-S. Sans ce flux aller, le systme DVB-RCS sur un systme GEO transparent
ne peut tre ralis de manire entirement conforme la norme.
Il est toutefois possible de raliser une telle architecture quand la signalisation est gnre
par une autre entit du systme. Une possibilit a dailleurs t envisage dans le cadre dun projet
RNRT auquel nous avons particip, DIPCAST (DVB pour lIP multiCAST) [28], utilisant le
satellite pour gnrer la signalisation et la synchronisation adquate. Cependant cette technique
dpasse le cadre de cette prsentation par son utilisation de lintelligence embarque et nous
lobserverons plus tard dans la section 3.4.4.
Le DVB-RCS seul ne semble pas une solution viable sur un satellite purement transparent.
De plus, mme lorquil y a une intelligence bord, cest le satellite qui met en DVB-S. Par
consquent le systme DVB-RCS cohabite toujours avec un systme DVB-S sur lequel sa
signalisation repose.
3.3.2.
DVB-RCS comme complment au DVB-S
Cette architecture envisage par la norme permet dutiliser le DVB-RCS comme palliatif au
problme de lien retour du DVB-S. Ainsi des zones totalement isoles comme une plateforme
ptrolire ou un refuge de montagne peuvent accder au systme sans aucune connexion
terrestre. Lutilisation du DVB-RCS reste strictement identique celle propose dans la partie 2.4,
puisquil a t conu pour vhiculer des donnes telles que les datagrammes IP. Dans la figure cidessous (Figure 3.12), une architecture utilisant le DVB-S et le DVB-RCS comme support de
lIP est propose. Cette structure met en place un accs Internet via le couplage DVB-S voie aller
et DVB-RCS voie retour. Contrairement larchitecture propose dans la partie 2.4, celle-ci est
supporte par un unique satellite. En effet lintgration du DVB-S et du DVB-RCS sur un mme
satellite est possible et a mme t choisie dans le cadre du projet DIPCAST, pour le systme dit
transparente [43].
52
Figure 3.12 Architecture IP sur DVB-S/DVB-RCS comme accs Internet
Un tel systme permet doffrir un meilleur dbit retour compar un lien modem classique
RTC, supportant mieux les applications plus symtriques. De plus, mme pour un accs plus
classique, le lien retour satellite est parfois plus adapt. En effet pour un gros transfert de
donnes dun serveur vers lutilisateur, la mise en uvre de TCP peut induire une congestion des
acquittements, diminuant le dbit aller [42]. Un retour satellite peut donc avoir un intrt, mme
dans le cadre dun service classique daccs Internet, comme nous pourrons dailleurs le constater
par la suite.
3.3.3.
Persistance de limites
Cette partie montre lapport du DVB-RCS, tout comme la ncessit de le coupler au DVBS. Le DVB-RCS se pose comme une solution incontournable pour un systme totalement
satellite, indpendant dinfrastructures terrestres et facilement dployable. Toutefois le DVB-RCS
nest pas la solution miracle toutes les limites des systmes classiques.
Figure 3.13 Double bond entre deux RCST sur un systme GEO transparent
53
Le DVB-RCS napporte au DVB-S que la notion dinteractivit. Les problmes

dencapsulation, de signalisation, de gaspillage de ressources et de standardisation subsistent. Les
solutions restent malgr tout spcifiques aux systmes mis en place comme cest par exemple le
cas avec DIPCAST, et un changement dans le systme satellite utilis implique des changements
parfois drastiques sur les couches protocolaires et la signalisation.
Enfin les solutions DVB-RCS si elles sont moins chres que les gateways, impliquent un
cot dquipement pour lutilisateur final bien plus important que pour une connexion terrestre
classique. Pour pouvoir produire des RCST moindre cot, une synergie doit tre cre partir
dune uniformisation forte et ouverte (comme cest le cas avec linitiative de SATLABS [44])
couple une offre relle de services attrayants. Le DVB-RCS soulve notamment un autre
problme : le double bond. En effet, comme le souligne la figure ci-dessus (Figure 3.13), pour
que la communication puisse avoir lieu entre deux RCSTs un passage par la gateway est ncessaire.
Les RCST ne sont capables de recevoir que le flux DVB-S, la technologie mettre en oeuvre
tant trop complexe et donc coteuse.
3.4. De nouvelles techniques et technologies au service dIP

sur satellite
La ncessit de coupler les technologies semble le point central dune ralisation plus
adapte au trafic IP. Toutefois le DVB-RCS seul ne peut suffire combler les limites des
architectures classiques, dautant plus quil amne ses propres limites (double bond).
Dans cette partie, nous proposons dtudier des techniques et technologies qui permettent
damliorer lintgration dIP sur satellite. Lencapsulation ULE est ainsi propose comme
alternative MPE. Puis lintelligence embarque ainsi que les techniques multifaisceaux sont
abordes pour enfin tre intgre dans une solution envisage dans le projet DIPCAST.
Ces diffrents lments permettront de dgager une problmatique qui guidera la suite de
notre travail : la ncessit dune architecture capable de faire le lien entre systme classique et
systme rgnratif, entre applications actuelles et services venir.
3.4.1.
Techniques de rsolutions dadresses et dencapsulations :

ULE
La mthode MPE a diffrents dfauts comme nous lavons soulign dans la partie 3.2.3.1.
Dans ce cadre un certain nombre de solutions propritaires ont vu le jour utilisant comme base
dencapsulation la mthode du data-piping [41]. IP sur DVB, groupe de travail de lIETF, uvre
pour la normalisation dun nouveau protocole reposant sur le data-piping et adapt la couche
MPEG-2 TS / DVB : ULE (Ultra Lightweight Encapsulation) [38].
3.4.1.1.
Les principes de lencapsulation ULE
Au niveau dIP, ULE doit permettre dassurer lunicast, le broadcast comme le multicast IPv4,
lunicast et le multicast IPv6 ou encore la compression den-ttes [45] [46]. Le protocole ULE
permet aussi de vhiculer directement dautres PDUs (Protocol Data unit) comme les trames
Ethernet, permettant ainsi la mise en place dun pont Ethernet via le satellite.
La mthode ULE repose sur lencapsulation des PDUs dans des SNDUs (SubNetwork
Data Unit). Comme pour MPE, la SNDU est encapsul dans le flux MPEG-2 TS. Ce mcanisme
utilise alors lindicateur PUSI pour renseigner sur la prsence dun dbut de SNDU dans le
paquet. Lorsque le PUSI prend la valeur 1, un pointeur de 1 octet suit len-tte MPEG-2 TS,
indiquant le dbut dune nouvelle SNDU. Si plusieurs SNDU peuvent ainsi se retrouver dans un
mme paquet MPEG-2 TS, du bourrage peut aussi tre utilis quand il ny a pas de SNDU
54
dorigine identique transmettre cest--dire utilisant le mme PID. La figure suivante prsente
lencapsulation dun datagramme unicast IPv4 en utilisant le protocole ULE (Figure 3.14).
Figure 3.14 Encapsulation dun datagramme unicast IPv4 via la mthode ULE
Cette encapsulation ne semble pas si diffrente que cela de la mthode MPE premire
vue. Comme MPE on trouve un en-tte, un en-tte optionnel et un CRC. Comme MPE, une
forme de section packing est utilis. Toutefois len-tte dune SNDU a un champ obligatoire de 4
octets compar au pointer-field de 12 octets dune section datagramme. La solution ULE propose
un en-tte moins complexe que la solution MPE, avec une option pour ladresse MAC
destinataire, qui rend len-tte beaucoup plus court si celui-ci nest pas ncessaire.
Figure 3.15 En-tte obligatoire et optionnel utilis par la solution ULE
La figure ci-dessus (Figure 3.15) propose un aperu de len-tte ULE, montrant ces trois
champs obligatoires et quelques champs optionnels utilisables. Les champs obligatoires sont :
D (Destination Address Present) : ce champ prend la valeur 0 pour indiquer quil y a un

champ optionnel Receiver Destination Address.
Length field : cod sur 15 bits, ce champ indique la longueur en octet de la SNDU,
compte partir du premier bit suivant le champ type, jusquau CRC inclus.
Type field : le champ de type est cod sur 2 octets. Il propose deux types possibles ; les
valeurs de 0 1535 sont utilises pour des types rservs du systme ULE tandis que
les valeurs au dessus de 1536 correspondent au type Ethernet IEEE.
55
Les champs optionnels sont plus spcifiques, on notera toutefois le champ Receiver
Destination Address qui est prsent dans le paquet quand D est fix 1. Cette adresse est un NPA
(Network Point Attachment) qui identifie sur 6 octets le (ou les) rcepteurs. Elle est similaire au
standard IEEE LAN/MAN et peut tre une adresse unicast, multicast ou mme une adresse de
broadcast (0xFF :FF :FF :FF :FF :FF). Les autres champs optionnels de la SNDU peuvent tre
utiliss pour faire notamment du pont Ethernet. Len-tte prsent dans la figure ci-dessus est
dailleurs un bon exemple dencapsulation dune trame Ethernet par la mthode ULE. Comme
dans le cadre IP, le champ Receiver Destination Address peut tre occult dans certaines conditions.
Figure 3.16 Deux encapsulations dun datagramme IP via la mthode ULE
Pour lencapsulation dun datagramme IPv4 (Figure 3.16), les champs obligatoires et le
champ optionnel Receiver Destination Address sont suffisants, donnant un overhead total de 12 octets
contre 16 octets pour MPE. Cependant, si le systme est capable de filtrer au niveau PID
correctement et a une capacit de filtrage IP suffisante, ce champ optionnel nest pas obligatoire,
donnant un overhead de 8 contre 16 (Figure 3.16).
Rapport taille ULE sur taille MPE
0.8
0.6
0.4
0.2
10
100
Taille du datagramme en octet
1 10
Figure 3.17 Comparaison entre lencapsulation ULE et MPE
56
3.4.1.2.
Les avantages de la mthode ULE
Lencapsulation ULE semble alors apporter une rduction de complexit et doverhead

compar la mthode MPE. Si lon veut comparer lencapsulation MPE et ULE, lquation (4)
donne TMPA(s), la taille de donnes de niveau 2 ncessaires lencapsulation dun datagramme de
s octets. Soit TU(s) cette taille pour une encapsulation via ULE en version la plus lgre (5).
s + 8 +1
TU ( s ) =
.188
184
(5)
On reprsente le rapport entre TU(s) et TMPA(s) via la figure ci-dessus (Figure 3.17),
donnant un aperu de lefficacit de ULE compare MPE. On remarque que plus les
datagrammes sont de petites tailles, plus le gain entre ULE et MPE est plus important.
Le protocole ULE a fait ainsi lobjet dune tude approfondie dont le rapport final a t
rcemment rendu public [47]. Ce rapport conclut sur un gain defficacit dULE par rapport
MPE, de 10 15%, pour des trafics importants. De plus la grande flexibilit dULE lui permet
dtre adapt de nouveaux protocoles, sans avoir de modifications fondamentales apporter,
grce notamment son champ type et ses options sur mesure.
Aussi les premires implantations relles de la solution ULE apparaissent (Thales, GCS
GmbH, ECC, ) et lon trouve mme des IRDs intgrant cette solution [48].
3.4.1.3.
Les objectifs dune rsolution dadresse standardise
En ce qui concerne une mthode de rsolution dadresse complte et uniformise, aucune

solution na encore vraiment abouti. En effet pour pouvoir rendre la signalisation des flux privs
et notamment IP uniforme, la rsolution dadresse doit proposer une solution capable
dencapsuler les PDUs de manire simple et efficace, de faire le lien entre le canal logique TS et
une adresse IP, et de permettre la mise en place de QoS.
Avec ULE, un certain nombre dobjectifs sont atteints : dune part loverhead est rduit, et
dautre part la mthode permet dviter les champs inutiles via un systme doptions facilitant le
traitement par les stations et offrant une encapsulation un grand nombre de protocoles.
Toutefois, lencapsulation nest pas suffisante lorsquil sagit de compatibilit, de gestion
des flux (gestion du dlai, de la gigue), dinteroprabilit, de facteur dchelle, etc. Pour cela, il
faut une couche protocolaire complte proposant une interaction totale entre la couche MPEG-2
TS (et donc les canaux logiques) et la couche suprieure, ici IP [49]. Le protocole doit donc :
tre robuste face aux erreurs de liaison et de dcodage,
associer les adresses IP aux canaux logiques, en respectant la technique MPEG-2

(tables SI) ou en utilisant un canal pour des messages de type ARP (Address Resolution
Protocol),
supporter les protocoles IPv4 et IPv6,
grer la QoS, le multicast, le broadcast et la compression den-tte,
supporter des protocoles de scurit tels que IPsec (IP security protocol),

Il reste donc encore du travail duniformisation avant darriver intgrer ces diffrents
objectifs dans un seul et mme niveau protocolaire, ULE ntant quune tape vers une solution
plus globale.
57
3.4.2.
Les techniques de multifaisceaux
Les satellites traditionnels sont le plus souvent des satellites monofaisceau. Or un unique
faisceau peut tre problmatique dans plusieurs cas. Dun ct si le faisceau est trs large, il
permet dinonder un grand nombre de terminaux au prix dun gain limit et dun gaspillage de
ressources. En effet, dans le cadre de message unicast, la donne va prendre la ressource sur tout
le spot. Dun autre ct, un faisceau troit permet davoir un meilleur gain dantenne mais ne
dessert quun nombre limit de stations, rendant lutilisation dun satellite quivoque. Une
solution ce problme est le multifaisceaux, encore appel multi-spots ou multi-beams.
Un satellite multi-spots combine ces deux avantages dans un mme systme : plusieurs
faisceaux troits permettent de partager la couverture globale du satellite en plusieurs zones ou
spots (Figure 3.18). Ainsi lconomie au niveau du bilan de liaison du multi-spots permet de rduire
la taille des stations, et donc leur cot. De plus les techniques multifaisceaux permettent de
rutiliser les frquences dun spot un autre, augmentant ainsi les capacits sur chaque spot en
termes de frquences utilisables. Le gain obtenu par la rduction de la taille des faisceaux offre de
bien meilleures perspectives lutilisation de la bande Ka. Des systmes multifaisceaux se
dveloppent depuis longtemps dj, tels que Astra 1h (8 faisceaux en bande Ka)
Figure 3.18 Couverture dun satellite multi-spots
Cependant cette amlioration a un prix : la complexit du systme. La prsence de plusieurs

spots induits invitablement des interfrences entre les diffrents spots. De plus si lon souhaite
grer linterconnexion entre les diffrentes zones de couverture, cette complexit est accrue. En
effet, si une gateway dans un spot x veut envoyer une donne sur un spot y, il doit y avoir un lien
entre ces deux faisceaux. Pour ce lien plusieurs mthodes sont possibles, mais toutes requirent
un quipement bord. Une de ces techniques utilise un filtrage sur les frquences (transponder
hopping) mais nest envisageable que pour un nombre restreint de spots. La commutation bord est
un autre type de solution, ncessitant un OBP parfois coteux, mais permettant une plus grande
marge de manuvre et ractivit que la mthode reposant sur les signaux.
Le multi-spots est une technologie qui peut permettre un gain important de capacit pour un
cot et une complexit maitris. Ainsi il y a eu de nonbreux satellites transparents lancs
dernirement (Astra 1K, IPStar, ) utilisant cette technique, mais sans permettre
linterconnexion directe entre spots, impliquant une flexibilit rduite et des doubles bonds.
58
3.4.3.
Les satellites transparents proposent des solutions simples et efficaces qui permettent de
rpter le signal sur le/les faisceaux descendants. Toutefois cette simplicit nest pas toujours
satisfaisante, et parfois un traitement bord serait souhaitable pour amliorer les performances
des systmes et ouvrir le monde du satellite une relle gestion des flux IP. Cette tape passe par
la mise en place dquipements permettant un traitement non seulement analogique du signal,
mais aussi numrique. Cest ce que lon nomme lintelligence embarque, ou On-Board Processing
(OBP). Cette technologie est dj au point et utilise dans les systmes Skyplex HOT BIRD 5
et 6. Ces derniers multiplexent les diffrents flux montants envoys par diffrentes gateways en un
seul flux descendant. Mais lintelligence embarque propose plus que du multiplexage ; la
gnration de tables de signalisation bord, la commutation ou encore le routage bord sont
autant de possibilits que lOBP est capable doffrir.
Dans le cadre du DVB-RCS, lintelligence embarque peut apporter de nombreuses
amliorations au systme. Nous avons vu prcdemment deux limites du DVB-RCS comme
support dIP : la signalisation qui doit tre apporte par un flux DVB-S, et le double bond entre
deux RCSTs (cf. 3.3). LOBP permet de dpasser ces limites en multiplexant les flux montants
DVB-RCS en un seul flux DVB-S descendant par faisceau. Ainsi, lorsque quun RCST
communique avec un autre RCST, il envoie des bursts DVB-RCS vers le satellite. Le signal est
trait pour obtenir les donnes de niveau 2 (cellules ATM ou paquets MPEG-2 TS). Ces donnes
sont ensuite multiplexes sur le TS descendant. Le signal DVB-S est ainsi directement reu par
lautre RCST sans une gateway intermdiaire. Ce mcanisme est illustr dans la figure ci-dessous
(Figure 3.19). De mme, la prsence dun multiplexage bord, permet au satellite de gnrer
directement des tables de signalisation, de la synchronisation, et de devenir ainsi une entit part
entire de gestion du systme.
Figure 3.19 limination du double bond entre deux RCSTs sur un satellite intgrant un OBP
Dautre part lOBP permet de grer de manire plus flexible les systmes multi-spots en
remontant au niveau 2 et permettant ainsi une commutation des paquets (on parle alors de onboard switching). Cependant lutilisation dune telle technologie a, comme le multi-spots, un prix
bien considrer : la complexit. Celle-ci entrane un cot nettement suprieur celui dun satellite
transparent. De plus la complexit de lOBP introduit des risques de dysfonctionnement du
systme qui inquitent les constructeurs et les investisseurs. Ce cot plus lev (de 1.5 2 fois
suprieur) associ des risques plus importants de rupture de service, freine en partie le
dveloppement de cette technologie. Tout comme le multifaisceaux, lOBP doit tre considr
avec soin, et son apport longuement envisag avant dopter pour son utilisation.
59
3.4.4.
Exemple darchitecture intgrant intelligence bord et

multifaisceaux
Notre participation au projet DIPCAST [28] nous a mens travailler sur un systme
multifaisceaux intgrant une intelligence bord. Ce travail a t loccasion de mieux comprendre
les objectifs dun industriel dans le domaine, et surtout de prendre note des diffrents acquis et
comptences dans le cadre de ces nouvelles technologies. Toutefois cette partie du projet tait
davantage une tude de faisabilit quune vritable ouverture vers de nouvelles technologies : il
sagissait de rutiliser un brasseur ATM, dj valid pour lespace, pour raliser la commutation
bord. Cette contrainte, qui peut paratre lgre dans un premier temps, a en ralit restreint de
manire importante nos choix sur la structure protocolaire de la solution.
Dans cette partie, nous proposons de prsenter ce travail [50] [51] [52].
3.4.4.1.
La mission du systme DIPCAST avec OBP
La mission du systme DIPCAST avec OBP est dassurer le transport de contenus :
entre FAI, le rseau satellite tant alors une solution alternative au rseau terrestre qui
donne la possibilit dallger le trafic terrestre et permet de contourner les points de
congestion comme cela est fait dans certains backbones,
entre POPs (Point of Presence) dun FAI, placs en tte des diffrents rseaux daccs
qui regroupent un ensemble de clients de ce FAI,
entre utilisateurs finals, connects des rseaux daccs, qui utilisent le rseau
DIPCAST comme mdium dinterconnexion.
Ce type de rseau constitue selon le terme DIPCAST un rseau EDGE, reliant des rseaux
daccs entre eux et Internet.
3.4.4.2.
Larchitecture gnrale DIPCAST
Le systme DIPCAST a un cadre bien dlimit qui ne comprend pas la totalit du rseau
(dune source premire vers un utilisateur final). Le systme proprement parler se limite deux
segments : le segment sol et le segment spatial. Les contours du systme sont prsents dans la
figure suivante (Figure 3.20).
DIPCAST
DV B -RCS
DV B -S
Rs eau
dac c s
UE S
NCC
P op dun
IS P loc al
S erv eur de
c ontenu
UE S
Rs eau
dac c s
GES
P op dun
IS P loc al
MNMC
S erv eur de
v ideo
Rseau
Internet C ur
Figure 3.20 Contours du systme DIPCAST segment sol et air
60
Le segment sol est compos de plusieurs lments comme indiqus sur la figure ci-dessus :
Une GES (Gateway Earth Station), voire plusieurs. La gateway est un lment central du
systme, grant le trafic provenant des FAIs et destin aux rseaux daccs. Cette entit
a des fonctions appartenant au segment utilisateur (transmission du trafic) ainsi quun
contact privilgi avec le/les NCC. Elle a galement des fonctions de niveau rseau
pour traiter les diffrents trafics, cest--dire quil sagit dun routeur. Cet lment est
compos de diffrents modules (sept) qui communiquent entre eux en utilisant des
circuits ATM. Les GES sont quipes dantenne de 3 4 mtres de diamtre pour un
dbit pouvant aller de 8 40 Mbit/s, en mission multi-porteuses.
Des UES (User Earth Station). Dans la norme DVB-RCS, il sagit de stations RCST.
Celles-ci sont capables dmettre vers dautres UES, ou vers la GES. Ces stations sont
les ttes de pont des rseaux daccs. Les UES sont quipes dantenne de 0,75 1,2
mtres de diamtre pour un trafic de 512 Kbit/s 4 Mbit/s.
Le MNMC (Mission and Network Management Centre). Il fait partie du segment sol de
contrle et soccupe des diffrentes informations reues du satellite (contrle dorbite,
dtat de fonctionnement, corrections de codages).
Le ou les NCCs (Network Control Centre). Ils font partie du segment sol de contrle.
Ils grent laccs au systme, la mise jour des tables de commutation, lattribution des
PIDs, lmission de la plupart des tables SI ou encore la scurit du systme.
Le segment spatial est constitu du seul satellite gostationnaire multifaisceaux
intelligence embarque. Ce systme est appel systme rgnratif et est compos de 8 faisceaux
montants et descendants. Le processeur embarqu bande de base ralise la commutation des
cellules ATM selon leur port dentre (correspondant au spot montant) et leur VPi (Virtual Path
identifier). Il permet ainsi linterconnexion entre les faisceaux montants et descendants. LOBP
est divis en trois sections :
une section de tlcommunication en charge du traitement des signaux tlcoms

(dmultiplexeur, brasseur, encapsulateur, multiplexeur, encodeur DVB-S) ;
une section de traitement de la signalisation et des signaux de commande et de contrle

(gestion de la communication avec MNMC et NCC, tables gnres bord) ;
une dernire section dhorloge rseau : NCR (Network Clock Reference).
Figure 3.21 Architecture IP sur DVB bidirectionnelle
61
Larchitecture est donc compose dune ou plusieurs GES et dUES interconnectes les
unes aux autres grce un satellite rgnratif. Les liens montants sont tous en DVB-RCS,
permettant une gestion identique des cellules en provenance des GES comme des UES. Le lien
descendant repose sur le standard DVB-S, permettant le multiplexage en un seul flux descendant
par spot, linsertion des tables de signalisation par le satellite et lutilisation de rcepteur DVB-S au
sol (quipement peu cher compar la complexit des rcepteurs DVB-RCS).
Cette architecture, comme le montre la figure prcdente (Figure 3.21), permet de
connecter les rseaux FAIs de coeur leurs diffrents rseaux daccs sans aucune infrastructure
terrestre. Ces rseaux daccs peuvent tre des rseaux ATM, WiFI, ADSL, Ethernet Le projet
DIPCAST ne sinterrogeait pas sur une autre interconnexion possible, mais uniquement sur une
connexion totalement satellite permettant la mise en place du multicast de manire souple et
adapte aux services proposes (tlvisions interactives, applications partages, CDN).
3.4.4.3.
Larchitecture protocolaire DIPCAST
Les couches protocolaires supportant une telle architecture sont prsentes ici (Figure
3.22). Ces piles reprsentes les protocoles dploys entre deux stations (UES ou GES)
interconnectes dun ct par le rseau DIPCAST, et de lautre ct par un LAN Ethernet. On
pourra noter ici le rle double de lOBP qui dune part soccupe de la gestion des diffrents
faisceaux et de leur interconnexion grce au brasseur ATM, et permet dautre part la mise en
oeuvre du multiplexage des cellules ATM dans les paquets MPEG-2 TS.
Figure 3.22 Couche protocolaires du systme rgnratif DIPCAST
Dans ce projet le choix ATM a orient fortement la proposition. Si le brasseur ATM tait
une contrainte du projet, il nen est pas moins important de noter les intrts de lutilisation
dATM pour un systme comme celui-ci. Dans un premier lieu, il faut remarquer quATM daprs
la norme DVB-RCS [16] doit tre support par tout systme intgrant ce standard. De plus ATM
propose pour les commutateurs et les brasseurs une technologie mre qui a connu plusieurs
expriences dans le domaine spatial, avec notamment les constellations ou encore les VSATs,
mais qui reste du domaine des laboratoires pour le moment. Il nexiste donc pas de commutateur
ATM dj bord de vritables GEOs. Les commutateurs MPEG-2 TS sont pour linstant du
domaine de lexprimental comme dans le cadre des projets IBIS et AmrHis (lanc en
septembre 2004). LATM propose aussi une gestion prcise de la QoS avec diffrentes classes de
62
service. Enfin, les courtes tailles des cellules ATM permettent de perdre moins dinformations en
cas derreur au prix de codages correcteurs moins performants (augmentation du nombre de bits
de redondance pour un bit utile). LATM a t pendant longtemps le protocole pressenti pour
grer les transferts de donnes sur satellite. Toutefois cette solution a plusieurs dfauts dont la
surencapsulation trs perceptible ici.
3.4.4.4.
Le systme bord DIPCAST
Dans le cadre de nos travaux de dfinition de larchitecture globale DIPCAST, nous avons
tudi la mise en place de la commutation bord. Pour pouvoir tout dabord comprendre la
problmatique de ce travail, le systme bord doit tre examin. Il est compos de diffrents
lments (Figure 3.23), mais on notera toutefois trois principaux lments :
Le OBPC (On-Board Processor Controler) qui gre les mesures effectues sur le
satellite, la gnration des tables de signalisation, et les tables de commutation ;
Le brasseur qui interconnecte les 8 spots montants avec les 8 spots descendants. Le
brasseur est capable de rpliquer les cellules pour pouvoir faire du multicast au niveau 2.
Il se base sur le port dentre et le VPi de la cellule pour la commuter ;
Les formateurs DVB qui encapsulent les cellules ATM dans les paquets MPEG-2 TS
via data-piping, raison de sept cellules ATM pour deux paquets MPEG-2 TS.
Ainsi quand un signal est reu sur lun des spots montants, le MCDDD (Multi-Carrier
Demultiplexer Demodulor Decoder) correspondant restitue le burst de cellules ATM. Ces cellules
sont ensuite brasses par le brasseur embarqu vers le(s) spot(s) de sortie adquate(s). Les cellules
sont ensuite regroupes par le formateur MPEG-2 TS qui les encapsule dans des paquets MPEG2 TS, et les multiplexe ensuite avec les tables SI gnres par le systme (satellite, NCC, GES...).
Finalement les paquets sont cods et envoys en DVB-S sur les faisceaux cibls.
Figure 3.23 Schma de lOBP du systme DIPCAST
3.4.4.5.
Une solution pour la commutation de flux multicast
Une fois la prsentation de lOBP et de son brasseur, nous pouvons aborder la mise en
uvre de la commutation bord et la rsolution dadresse associe des flux IP multicast.
63
LIP multicast sur ATM a t un long sujet de recherche, proposant plusieurs solutions. Une
premire rflexion nous a conduit carter rapidement la solution dite LAN emulation [53].
En effet cette solution ne rpond pas du tout notre objectif puisquelle propose une mthode
diffusante qui ne permet pas dconomiser les ressources du systme et rend la commutation
bord inutile. Une autre solution reposant sur un routeur-commutateur ATM (ATM-switchrouter) [54] nest pas non plus approprie ce systme dans la mesure o il nest pas question
dans ce projet dintgrer un routeur IP bord. Une autre possibilit consiste utiliser les serveurs
MARS (Multicast Address Resolution Server) [55]. Toutefois cette option pose la question de la
localisation du serveur. Lintgration dans la NCC par exemple implique des dlais levs et une
complexit accrue du systme dans la mesure o de nouveaux messages doivent tre mis en
places. Dans notre cas, une solution plus spcifique au systme a donc t envisage.
Dans le but de brasser la cellule ATM nous avons deux possibilits : soit utiliser une
mthode de self-switching, impliquant que la cellule contient en elle-mme toutes les informations
qui permettront de la commuter, soit du label-switching, utilisant un label et une table de
commutation bord pour pouvoir commuter la cellule. Comme il sagit dun brasseur, seul le VPi
est disponible pour commuter la cellule. Dans le cadre dune cellule UNI, celui-ci fait un octet,
alors que pour une cellule de type NNI, ce champ fait douze bits (Figure 3.24). La norme DVBRCS ne propose que dutiliser les cellules de type UNI. Dans le cadre du projet DIPCAST, nous
avons envisag la solution UNI en priorit.
Figure 3.24 En-tte dune cellule UNI et dune cellule NNI
Si lon considre alors le VPi dune cellule UNI : un bit doit tre utilis pour indiquer sil
sagit dun trafic multicast ou pas, deux autres sont utiliss pour identifier le rseau sur lequel
transite la cellule, il ne reste plus que 5 bits pour intgrer les informations multicasts si lon restreint
la gestion de la QoS aux stations sol. Le self-switching multicast sur 5 bits nest pas envisageable
puisquil nest pas possible de faire la correspondance directe entre les spots cibles et les derniers
bits du VPi. Cependant la mthode du label-switching est trs limite et sans aucune mise lchelle
possible dans la mesure o 5 bits noctroient par FAI que 32 groupes possibles. Il est nanmoins
possible de proposer une solution adapte si le systme se prte plusieurs conditions :
le systme peut desservir 1 4 INs (Interactive Network), un IN tant par exemple un

FAI, un FSI ou un groupe de diffrents FAIs.
le nombre de spots accessibles pour un IN ne peut tre suprieur cinq, ce qui est
envisageable pour des applications dpendantes de la gographie.
les GES et UES doivent savoir dans quel spot le prochain routeur se trouve. Cette
condition nest pas trs contraignante dans la mesure o les adresses IP sont des
lments du systme DIPCAST et peuvent donc tre distribues intelligemment.
Une table embarque et statique doit tre implante dans lOBPC. Cette table est lgre
et ne ncessite pas de mcanismes de mise jour rapide Cette table donne la
64
correspondance pour chaque IN entre les cinq derniers bits du VPi et les spots
correspondants (Tableau I).
Tableau I.
TABLE EMBARQUE DE CORRESPONDANCE ENTRE IN, VP ET SPOTS CIBLES
Dans ce cadre une solution mixte est envisageable, utilisant les cinq derniers bits du VPi
pour faire la correspondance avec les spots. Une fois quune station sol (UES ou GES) a reu le
datagramme, le mcanisme suivant est alors mis en place (Figure 3.25) :
(1) Ladresse source et destination du datagramme sont lues. Dans le cas dun
datagramme multicast, la table multicast est interroge.
(2) Si une interface de sortie est linterface air, linterface dentre du datagramme
donne son IN.
(3) Aprs le traitement en QoS du datagramme, ladresse source (sil y a lieu), ladresse
multicast de destination et lIN, donnent les cinq derniers bits du VPi de la cellule.
(4) Aprs le traitement de la couche AAL5, le VPI de la cellule ATM est rempli. Le
premier bit de la cellule est fix 1 pour signaler un trafic multicast, les deux suivants
prennent la valeur de lidentifiant de lIN tandis que les cinq derniers renseignent sur les
spots associs.
65
Figure 3.25 Traitement sol dun datagramme multicast avant mission
Les cellules ATM sont alors rassembles pour former un burst TRF, codes et envoyes au
satellite. bord le MCDDD restitue les cellules. Le brasseur les commute et les rplique en
utilisant une table semblable celle prsente ci-dessus. Ensuite les formateurs DVB encapsulent
les cellules en utilisant un PID correspondant lIN et au spot descendant (5 PIDs max par IN et
par flux multicast). Les GES et UES dans les faisceaux cibls doivent rcuprer ces donnes si elles
appartiennent lIN, et carter les donnes inutiles au niveau IP.
Cette mthode a deux dfauts majeurs : dune part elle peut difficilement tre adapte des
systmes intgrant un grand nombre de spots (16, 32), et dautre part elle implique que toutes
les stations dun mme IN et dun mme spot relvent toutes les donnes reues pour les carter
au niveau IP. Une premire amlioration peut tre apporte en utilisant les VCi pour permettre
aux stations sol de diffrencier leur trafic multicast des autres trafics. Ainsi une station peut trier les
cellules sans avoir reconstituer les paquets IP.
La mthode propose ci-dessus est cependant lgre, nimpliquant aucun message de
signalisation supplmentaire, vu que la table de commutation est quasi fixe. Il ny a donc pas dans
cette solution la complexit induite par une configuration dynamique de lOBP.
Lutilisation de cellules NNI peut aussi tre considre comme alternative aux cellules UNI,
attribuant ainsi 4 bits supplmentaires la gestion de la commutation, permettant la mise en place
dune mthode de type label, mais requerrant un protocole de mise jour de la table embarque.
3.4.4.6.
Configuration des tables du commutateur
Dans le cadre dune solution intgrant du label-switching, nous avons vu la ncessit de

mettre jour les tables de commutation embarque. Ce problme a t pleinement trait dans les
rseaux terrestres, avec par exemple les commutateurs Ethernet [56] ou les adaptations dATM
lIP multicast [57]. Pour le systme satellite les solutions envisages sont essentiellement les
mmes, cest--dire :
lauto-apprentissage par analyse du trafic ;
la dfinition dun protocole spcifique.

En ce qui concerne les techniques dauto-apprentissage, la correspondance entre
datagrammes et trames est bien plus dlicate pour un commutateur ATM ou MPEG quil ne lest
pour un commutateur Ethernet. Sur un rseau local Ethernet reliant un routeur aux clients
multipoints, chaque paquet IP sera en effet vhicul par une trame Ethernet unique et ne subira
en aucun cas de fragmentation. Cette absence de fragmentation, et la forme fixe de l'en-tte d'un
paquet IP vhiculant un message IGMP, permettent d'assurer une analyse suffisamment rapide
des trames pour tre ralise par le processeur d'un commutateur Ethernet. La faible taille des
cellules ATM et MPEG ne permet pas, en revanche, d'assurer une telle simplicit en cas
d'utilisation d'un protocole tel qu'IGMPv3 [58]. L'auto-apprentissage ne semble donc pas tre
une solution acceptable pour le systme DIPCAST rgnratif, mme en se limitant l'utilisation
d'IGMPv2 [59]. De plus la signalisation de niveau 2 doit tre le plus possible indpendante de la
signalisation de niveau 3 pour supporter le plus grand nombre de protocoles multicast. Enfin le
systme OBP DIPCAST na pas les capacits requises pour faire du snooping [60].
Il semble donc plus raliste d'envisager une solution fonde sur un protocole spcifique de
configuration distance des tables de commutation de type CGMP (Cisco Group Management
Protocol) [56]. La gateway ou la NCC sera alors responsable de la mise jour de ces tables en
fonction des abonnements et dsabonnements des rcepteurs aux diffrents groupes. Notons
qu'une telle solution offre galement l'avantage d'tre adapte aux stations uniquement rceptrices
utilisant une voie retour terrestre. Le projet DIPCAST a donc opt pour cette solution, crant un
66
protocole spcifique, nomm SMAP (Satellite Multicast Adaptation Protocol) dont lINRIA a t
le matre duvre de cette solution.
3.4.4.7.
Conclusion sur cette architecture
Le systme propos par le projet DIPCAST met en uvre plusieurs des solutions
techniques envisages pour contribuer lefficacit du satellite comme mdium de lIP et
particulirement de lIP multicast. Le projet a abouti la ralisation dune maquette physique
incorporant les diffrentes solutions cites ci-dessus et supportant lIP multicast via le protocole de
routage PIM-SM. Des tests du systme global ont t mens sous la direction dAlcatel,
dmontrant la faisabilit du systme ainsi que son bon fonctionnement. Ladaptation du
protocole PIM-SM au cas satellite DIPCAST a t teste et valide dans ce cadre.
Toutefois ce travail reste une tude de cas, spcifique une charge utile reposant sur un
brasseur ATM, une technologie limitante pour certaines applications. De plus le systme
DIPCAST propose un support pour plusieurs services particuliers qui restent ce jour
insuffisants pour rentabiliser le prix dun tel systme. Larchitecture DIPCAST rgnrative
reprsente un investissement de 1.5 2 fois suprieur au systme transparent DIPCAST,
rajoutant complexit et limitations. Enfin ce systme est adapt PIM-SM, mais pas un autre
protocole de routage multicast.
3.5. Un problme protocolaire : TCP sur satellite

Nous avons vu ici certains problmes au niveau de linteraction entre IP et la couche accs.
Toutefois, le fonctionnement dun systme passe par dautres niveaux que ces seuls ci. Aussi
pouvoir supporter IP nest pas suffisant, encore faut-il bien supporter les applications qui utilisent
IP comme vhicule au sein des rseaux. Or la grande majorit de celles-ci utilisent TCP, dont le
comportement sur les mdia sans fil, notamment satellite, nest pas des plus probants.
Lune des causes majeures des problmes rencontrs dans lintgration dIP sur satellite
vient, en effet, de la relation dlicate entre TCP et GEO : le satellite nest pas un mdia pour
lequel TCP a t conu [61] [62]. Aussi, lanalyse de TCP fait partie des deux points les plus
tudis dans le cadre dIP sur satellite, lautre axe de recherches tant les mthodes daccs au
systme. Notre travail ne vise pas refaire ce type dtudes, ni proposer une solution dfinitive
ces problmes dlicats. Notre approche ici est plutt tourne vers une authentification des
diffrentes causes de ce problme, et quelles sont les nombreuses solutions que lon peut trouver
dans la littrature, comme dans les implantations relles.
Cette partie observe cette dmarche, en traitant dans une premire section, les diffrents
dfauts de TCP, et leurs causes. Dans la section 3.5.2, un panorama des solutions ces problmes
sera effectu, pour aboutir une conclusion dans une dernire section (3.5.3)
3.5.1.
TCP standard et les limites de son utilisation sur satellite
La raison fondamentale de la mauvaise interaction entre TCP et les systmes satellites vient
de la nature mme de ce type de lien : le fonctionnement global de TCP, qui nest pas rappel ici1,
nest pas prvu pour diffrentes caractristiques de lien. Or les liens GEO cumulent un certain
nombre de ces points :
un dlai de propagation lev,
une asymtrie souvent importante entre la voie aller et retour,
une mthode daccs dynamique dlicate,
Pour une introduction se rfrer [63] ; pour une prsentation complte se rfrer [64].
67
des erreurs physiques.

Chacune de ses raisons ne sont pas vritablement dissocies des autres, mais pour pouvoir
clarifier notre approche, nous avons prfr aborder cette partie en les dissociant dans des
sections distinctes.
3.5.1.1.
Le dlai de propagation
Un long RTT a pour premier effet de diminuer le dbit maximum quune connexion TCP
peut atteindre sur un lien. En effet, au maximum, on ne peut mettre que la fentre maximale du
rcepteur (avertized window) avant de recevoir le premier acquittement de cette fentre mise. Or la
taille maximale de celle-ci est fixe 65535 B [64]. De plus il sagit dune taille maximale qui nest
pas toujours utilise (par exemple le FTP dUnix utilise une maximum de 24 KB). On peut alors
obtenir un majorant du dbit avec la formule suivante (6)
DMax =
(6)
Avertized _ Window
RTT
Avec un RTT de 500 ms, on obtient alors un dbit maximal denviron 1043 Kb/s contre
un dbit de 393 Kb/s dans le cas dune fentre maximale de 24 KB.
Le RTT influence aussi notablement la longueur de la phase de slow start comme celle de
congestion avoidance, entranant sur le lien satellite un dbit limit pour une dure non ngligeable.
Un dernier problme, typiquement li au dlai, est le calcul du RTT par TCP. En effet, le
protocole de transport TCP se base sur lvaluation du RTT pour calculer le RTO
(Retransmission Time Out) [64]. Or lestimation de ce RTT est effectue chaque mission de
nouvelle fentre, ce qui peut poser un certain problme lorsque la taille de cette dernire est
importante, surtout si le RTT fluctue beaucoup.
3.5.1.2.
Lasymtrie
Lasymtrie du lien pose un problme important, comme nous aurons loccasion de le

constater plusieurs reprises par la suite. Diffrentes tudes [42] [65] montrent linfluence du ratio
dasymtrie. En effet si lon note T1 et T2, respectivement le temps dmission dun datagramme
(de taille data) sur le lien aller, et le temps dmission dun acquitement (de taille ack) sur le lien
retour. Notons Dd et Du les dbits respectif de la voie aller (source vers terminal en passant par
une gateway) et de la voie retour. On alors engorgement des acquittements ds que T2 est
suprieur T1, soit, en fonction du dbit du lien et de la taille de la donne :
(7)
T1 < T2
data ack
ack Du
<
>
Dd
Du
data Dd
Or pour un dbit aller Dd de 512 Kb/s, des acquittements de 40 B et une MSS de 1460 B,
on obtient une valeur limite denviron 13.7 Kb/s pour Du. En de de ce seuil, il y a congestion
des acquittements, et le trafic aller est ralenti par le faible dbit retour des acquittements.
Un autre problme intimement li est la notion dautorgulation du flux TCP. En effet le
temps darrive des acquittements va tre dterminant pour le flot de donne aller. Aussi, en
phase stationnaire de la communication TCP, on ne peut mettre quun paquet pour un
acquittement reu. Le nombre dacquittements la seconde est alors une borne suprieure sur le
nombre de datagrammes mis la seconde. Soit une borne sur le dbit maximal de :
(8)
68
DMAX =
data data.Du
=
T2
ack
Lapplication numrique donne la courbe suivante en fonction du dbit de la voie retour

(Figure 3.26). Il semble alors dlicat de pouvoir profiter dun dbit important aller pour une
connexion TCP, si le lien retour a un dbit faible.
Figure 3.26 Borne suprieure sur le dbit aller en fonction du dbit de la voie retour
3.5.1.3.
La mthode daccs
La mthode daccs satellite na une influence que dans le cadre dun retour satellite. En
effet, dans ce cas et par soucis de rentabilit de laccs satellite, la rservation de capacit sur le
lien retour est le plus souvent dynamique pour permettre des prix abordables. Ce type de
mthode entrane alors la mise en place dun temps supplmentaire et variable pour avoir accs
au mdia. Dune part le RTT est augment, influenant de manire ngative la capacit de
ractivit du systme, et diminuant le dbit maximal calcul prcdemment (8). Dautre part, le
RTT devient variable, entranant des difficults pour le calcul du RTO.
3.5.1.4.
Les erreurs physiques
Un dernier obstacle la bonne adquation du satellite TCP est son taux derreur plus
important que sur les rseaux terrestres, dautant plus que les pertes sur satellite suivent
difficilement un quelconque modle1. Pour TCP, une perte de paquet correspond une
congestion dans le rseau, or avec un mdia trs bruit tel que le satellite, il nen est pas
forcment le cas. TCP va alors passer en congestion avoidance aprs lcoulement du RTO.
Cependant, si la perte est due au lien satellite, dune part le dbit va tre diminu pour rien, et
dautre part, il peut y avoir rmission de segments inutiles. Dans le cadre dune communication
quasi point point la congestion avoidance na pas lieu dtre, et la raction de TCP aux erreurs
satellites entrane un fonctionnement bien en dessous des capacits du systme.
Dans ce cadre, lutilisation du fast retransmit/fast recovery va permettre damliorer la dtection
de pertes dues au bruit, grce la rception de duplicata des acquittements : Au troisime
acquittement dupliqu, la source met les paquets sans attendre le time out, entrant alors en phase
de fast recovery, la place du slow start. Ces mcanismes sont implants notamment dans la version
Reno [66] et NewReno [67] de TCP, et permettent de diminuer moins drastiquement le dbit
TCP.
Nous aurons loccasion de parler plus en dtail de ce point dans la partie 5.1.
69
Toutefois du fait du long dlai du mdia satellite, et des erreurs multiples sur une mme
fentre, ce mcanisme nest pas toujours suffisant pour viter le dclenchement du RTO,
entranant un impact dplorable sur le dbit du systme. Le problme des erreurs sur satellite est
donc essentiellement coupl celui du RTT lev et incompressible.
3.5.2.
TCP et ses adaptations au support satellite
Il existe beaucoup doptimisations, de configurations et mme de nouvelles versions de

TCP avec comme volont premire une meilleure adaptation au satellite. Le RFC 2488 [68]
propose dans ce cadre quatre type damliorations : le paramtrage de TCP, les modifications
protocolaires de TCP, les mcanismes dautres niveaux et les passerelles.
Les mcanismes dautres niveaux tant pour la plupart applicatifs (comme il en est le cas
pour XFTP par exemple [69]), leurs spcificits rendent leur prsentation inutile dans le contexte
gnral de cette tude. Nous dcouperons notre expos en un panorama des paramtrages
judicieux de TCP au support satellite dans la section 3.5.2.1, une description des extensions de
TCP avec notamment des versions spcifiques aux mdia de type satellite et sans fil (3.5.2.2), et
enfin une prsentation des modifications dites transparentes (3.5.2.3).
3.5.2.1. Les optimisations comportementales de TCP pour le

support satellite
Une amlioration du comportement de TCP sur satellite peut simplement tre apporte par
un paramtrage plus adapt. En effet, les instanciations de ce protocole de transport partent du
principe quils sont sur un rseau de type terrestre, et leurs paramtres initiaux sont configurs de
manire tre TCP friendly pour les autres communications. Or sur un lien satellite, au dlai lev,
il ne sert rien dattendre une phase de slow start longue avant de pouvoir mettre un rythme
optimal. Ainsi on peut amliorer en partie le comportement de TCP sur satellite par un
paramtrage ad hoc [68].
Parmi ces optimisations on peut noter :
lutilisation dune taille de fentre de congestion initiale plus grande, permettant

damliorer ainsi le temps de la phase de slow start assez longue sur satellite[68][69],
la mise en place de Path MTU Discovery [71] pour permettre lutilisation des segments
les plus grands possibles,
lutilisation dune fentre rcepteur plus grande, avec notamment loption window scale
[68] [70]1.
lestampillage de datagrammes pour un calcul plus ractif du RTT [70],
lutilisation dacquittements retards [72], pour permettre de soulager la charge induite

par les acquittements sur le lien retour2.
Ces optimisations apportent des amliorations certaines, mais implique aussi dautres
problmes. Ainsi laugmentation de la taille maximale de la cwnd (congestion window) permet davoir
un meilleur dbit sur le lien, mais accentue le risque de pertes multiples dans une mme fentre,
tandis que le Path MTU Discovery implique un temps dtablissement de la connexion TCP plus
important. Pour ce qui est de lestampillage des datagrammes, ils ajoutent de loverhead, qui peut
poser problme notamment au niveau de la voie retour. Les acquittements retards, quant eux,
1 Cette solution aurait pu tre traite dans la section sur les modifications protocolaires, mais nous avons
choisi de la prsenter ici dans la mesure o ce mcanisme est suffisamment reconnu.
2 De mme cette solution pourrait tre classifie dans les solutions protocolaires, toutefois elle est assez
commune pour tre traite ici.
70
rduisent le dbit en slow start et congestion avoidance. Il y a donc un choix faire entre le gain que
peut apporter certaines de ces options, et leurs dfauts.
3.5.2.2.
Les volutions protocolaires de TCP
Dans une certaine mesure les optimisations de TCP ne sont pas toujours suffisantes, des
propositions optent alors pour des modifications protocolaires. Il faut noter toutefois, avant de
commencer cette section, que certaines de ces volutions (comme TCP SACK) nont pas t
uniquement cres pour le satellite.
Les modifications protocolaires de TCP sont nombreuses1 [68] [70] [73]. On compte par
exemple des modifications permettant dviter la congestion avoidance, avec notamment le fast
retransmit/fast recovery dont nous avons dj parler prcdemment pour TCP Reno et TCP New
Reno. Dautres modifications proposent des algorithmes pour amliorer les performances des
mcanismes de TCP, comme lalgorithme CANIT (Congestion Avoidance with Normalized
Interval of Time) pour la congestion avoidance [74].
En ce qui concerne les flux dacquittements on trouve des mcanismes au niveau TCP (ou
au niveau physique) : les mcanismes despacements, de compressions, de suppressions
dacquittements. Toutefois ils ne sont pas compltement satisfaisants. La suppression
dacquittements, par exemple, rduit de manire significative la congestion des acquittements en
rduisant le ratio entre acquittements et segments, passant de 1/6 1/15 voire 1/150 [26]. Mais
cette technique a de mauvaises performances sur de courts transferts, notamment parce que le
slow start repose sur le nombre dacquittements reus.
En ce qui concerne les versions de TCP adaptes au satellite, on compte, par exemple, la
version TCP SACK [75] qui permet des acquittements slectifs de paquets. Cette solution
combine au fast retransmit/fast recovery offre la possibilit lmetteur de rpondre des erreurs
multiples directement, en rmettant les paquets manquants. Une autre version de TCP, TCP
Westwood [76] [77] [78] propose une optimisation de la gestion de la cwnd dans le cas de pertes
multiples sur un lien haut dbit, en surveillant le temps dinterarrive des acquittements.
Plusieurs tudes de cette solution sont parues, notamment [76] et [78].
3.5.2.3.
Les solutions de type passerelle
Les optimisations de TCP et encore plus spcifiquement les extensions de TCP impliquent
souvent une mise en uvre de bout en bout, ou tout du moins un impact sur les entits
communicantes. Or il nest pas, dune part, toujours possible davoir la source et le client avertis
quils utilisent un lien satellite, notamment lorsque la source est serveur quelconque sur le web,
et/ou que le satellite est utilis comme lien backbone. Dautre part, si des modifications sont mises
en place, celles-ci vont affecter tout le rseau travers et non pas uniquement le lien satellite, au
risque davoir un comportement indsirable sur la traverse de rseaux terrestres.
Lutilisation dentits intermdiaires est alors une solution pour implanter ses modifications
de manire transparente. Ces passerelles sont alors nommes des PEPs (Performance
Enhancement Proxies) [79] [80]. Grce ce type de solutions, limplantation des mcanismes et
des protocoles prcdemment cits peut tre effectue de manire transparente. Pour une
meilleure gestion du flitrage dacquittements, une technique consiste par exmple rgnrer les
acquittements manquants via un autre proxy, du ct FAI, ou passer dans ce mode quune fois le
slow start termin. Des techniques plus labores existent, comme lagrgation dacquittements
(ack compaction) et offrent de bonnes perspectives [42]. Cependant il reste encore traiter la
mauvaise ractivit de ses solutions face aux erreurs.
Pour une vision plus complte de des recherches sur TCP sur satellite se rfrer au RFC 2760.
71
Il existe un rel besoin de pouvoir intervenir directement au niveau TCP. Une solution
possible utilise les TCP PEPs ; le principe consiste alors isoler le systme satellite des autres
rseaux, en utilisant des proxies pour intercepter les donnes et implanter ce niveau tout
changement pour le lien satellite. la sortie du systme, un autre proxy restitue les donnes
initiales en enlevant les changements effectus pour le satellite. Cette fragmentation de la
connexion TCP entre la source et le destinataire en trois morceaux (Figure 3.27) se nomme
spoofing [81] [82]. Dans une communication utilisant le spoofing, le client et le serveur croient
communiquer directement entre eux, alors quils ne communiquent quavec leur proxy.
Figure 3.27 Principe de spoofing TCP utilisation de proxies
Comme le montre la figure ci-dessus, cette bote noire chez lutilisateur du lien satellite
permet dimplanter toutes les modifications vues prcdemment tout en gardant un interfaage
standard, propice la standardisation. Parmi les modifications que le spoofing peut apporter, on
peut noter les versions spcifiques de TCP, comme par exemple SACK TCP, et TCP Westwood
dont nous avons dj parles. Dautres propositions semblent intressantes dans ce cadre. Ainsi
lutilisation de sessions multiples TCP [81] pour une mme connexion native peut donner de
bons rsultats sur un systme satellite. En effet, le risque dun comportement peu conforme
TCP ne se prsente pas ici o ce type de session est restreint la portion satellite.
Il faut nuancer toutefois lapport des proxies par un ajout notable de complexit dans le
systme, notamment au niveau matriel, puisque les TCP PEP doivent alors tre en mesure de
stocker les donnes pour pouvoir les renvoyer en cas de pertes. Ils peuvent aussi poser problme
dans le cadre de mcanismes de bout en bout, notamment ceux de scurit (IPsec par exemple).
Nanmoins, ces limites ont une influence trs relative compare au gain de performances
que peuvent apporter les PEPs sur un systme satellite. Sur les VSATs, cette technique est
connue depuis longtemps, et les offres pour laccs Internet par satellite ont commenc
proposer ces solutions1. Les PEPs offrent donc de bonnes perspectives pour les systmes
contraintes physiques particulires o le traitement par les couches traditionnelles OSI nest pas
toujours facile. Dans ce cadre, on peut noter des propositions allant jusqu utiliser lintelligence
embarque pour instancier des PEPs bord [83], traitant chaque lien indpendamment des
autres. Bien sr, lintroduction dun niveau 4 bord reste du domaine de la proposition, tant que
le niveau 3 nest pas encore une ralit.
3.5.3.
Conclusion sur le problme de la couche transport TCP
Nous avons clairement rappel ici les obstacles au bon fonctionnement de ce protocole sur
un systme satellite. Or TCP est devenu, de par son lien troit avec IP, un protocole ncessaire
On peut notamment citer www.newtec.be [84]
72
un grand nombre dapplications. Un axe de recherche sest donc dvelopp pour amliorer TCP
en proposant des rglages adapts du protocole, mais aussi des volutions de TCP allant de
mcanismes de gestion des acquittements des versions compltes du protocole. Un type de
solutions, prometteur pour beaucoup de systme, est lutilisation de PEPs. Ces passerelles, si elles
vont lencontre de la connexion de bout en bout, permettent disoler le lien satellite, et dy
apporter les modifications protocolaires adaptes, sans influencer les autres rseaux traverss par
le flux. Cette solution a lavantage remarquable dtre transparente pour les utilisateurs finals, et
peut mme ltre pour les rseaux traverss autres que le systme satellite, avec des mcanismes
tels que la rgnration dacquittements.
3.6. Conclusion
Le satellite comme support dIP est une ralit. Bien sr, contrairement aux rseaux
terrestres, aucune solution ne simpose en matre sur les autres. Mais, dans ce cadre, le DVB-S se
positionne comme un support de choix, de par son succs et donc son internationalit. Nous
avons donc tudi le DVB-S comme support dIP, surlignant les solutions classiques mais aussi
les limites de ces dernires. Nous avons alors observ comment le standard DVB-RCS propose
de palier le manque dinteractivit du DVB-S en offrant une voie retour satellite. Toutefois les
autres limites subsistent, demandant un dveloppement de nouveaux protocoles pour
lencapsulation et lAR, comme de nouvelles technologies.
Ainsi nous avons tudis ces solutions, montrant les possibilits offertes par lOBP et les
multifaisceaux. Toutefois nous avons pu constater un autre problme, li aux couches
suprieures, celui du comportement de TCP sur satellite. Une fois les causes de cette
inadquation rappele, un grand nombre de solutions ont t dnombres, comme notamment
les PEPs.
Ainsi, cette partie a montr les difficults de limplantation dIP sur satellite, mais surtout
quil y avait des solutions techniques comme protocolaires existantes. Toutefois, ce nest pas pour
autant quil ne reste pas de problmes. Ces diffrentes tudes posent une question fondamentale :
la justification du cot du systme. Plusieurs des solutions technologiques proposes (OBP,
multifaiceaux) ont un impact non ngligeable sur la complexit et le cot du systme final. De
plus ces solutions napportent pas toujours une amlioration au systme pour un service donn.
Dans le cadre dun service de diffusion de tlvision numrique chelle continentale par
exemple, le traitement bord et le multi-spots napportent pas un gain assez important pour justifier
un prix si lev.
De plus, mme si ces technologies offrent de bonnes perspectives pour un service, un
systme coteux ddi un unique service est-il vraiment rentable (surtout si les services viennent
changer) ? Ce genre de solutions apporte une trop grande spcificit du systme, dpendant
intgralement dun type dapplications. Le manque dvolution possible dun systme et sa
dpendance un seul service sont des freins notables au dveloppement des solutions satellites.
Lintelligence embarque comme le multi-spots peuvent apporter un souffle nouveau aux
systmes satellites et leurs applications. Mais la trop grande spcificit dun systme, le manque
dapplications ad hoc, ou encore les problmes duniformisation des mthodes de rsolution
dadresse restent des obstacles importants pour les satellites de nouvelle gnration.
Il sagit donc de justifier dans un premier temps lutilit de ces techniques et de montrer
quelles peuvent tre utilises pour plusieurs services porteurs, tout en apportant une solution de
transition entre les satellites actuels et futurs, ouvrant vers une architecture adaptable. Cest ce
travail que nous nous proposons de raliser travers le chapitre 4 et 5 de ce mmoire, en
proposant une architecture hybride et en lvaluant.
73
CHAPITRE 4. PROPOSITION DUNE ARCHITECTURE HYBRIDE
4. PROPOSITION DUNE ARCHITECTURE

HYBRIDE
Ltude des diffrentes solutions, existantes ou venir, de dploiement des protocoles de
lInternet au travers dun lien satellite a clairement montr que les problmes technologiques et
protocolaires sont dsormais clairement identifis et que des rponses existent.
Au-del de ces solutions technologiques, une nouvelle difficult se dessine, celle de
lintgration. Il sagit ici dune intgration au sens large, se dclinant sous diffrents axes :
les diffrents services susceptibles dtre dploys sur un systme satellite (diffusion
vido, (N)VoD, accs Internet, ) seront plus simples mettre en uvre (et donc plus
efficaces) sils le sont sur une base commune aussi large que possible. La rpartition des
ressources entre eux au grs des volutions de la demande en sera galement simplifie.
linteraction avec dautres modes de communication (terrestre en particulier) sera plus

naturelle si elle est envisage ds le dpart. Il peut sagir de lassociation dune voie
retour, dun rseau local avec ou sans fil permettant de partager le lien satellite, etc.
lintgration des technologies en cours de dploiement ou venir sera grandement

facilite par une architecture globale ouverte et clairement dcoupe, comme nous le
prouvent rgulirement les volutions de lInternet.
Le but de ce chapitre est alors de dfinir une architecture globale permettant dintgrer
divers types de services susceptibles dutiliser un maillon satellite et diffrentes technologies
satellitaires.
Au cur de cette architecture se trouve la notion de charge utile hybride, cest--dire
intgrant une partie transparente traditionnelle et une partie rgnrative utilisant une intelligence
embarque plus ou moins volue. Lapparition progressive dune puissance de calcul bord de
plus en plus efficace semble en effet inluctable. Mais il est galement clair que pour des raisons
technologiques comme conomiques, cette capacit ne pourra, au moins dans un premier temps,
suffire raliser des traitements complexes sur lensemble des flux, ce qui serait au demeurant,
inutile, comme nous le verrons.
Ce chapitre est donc structur de la faon suivante. Nous tudierons dans une premire
partie les besoins (vis--vis de larchitecture) des diffrents services. Notre tude reposera pour
cela sur trois exemples de services jugs pertinents et reprsentatifs. Nous dcrirons alors dans la
section suivante les objectifs dune telle architecture. La section 4.3, qui constitue lessentielle de
ce chapitre, sera consacre la description de larchitecture. Signalons ds prsent que de
nombreux choix technologiques seront faits en fonction du contexte actuel du monde satellite,
mais quaucun dentre eux nest critique pour le bon fonctionnement de larchitecture globale.
Nous conclurons alors ce chapitre en montrant comment les services peuvent sintgrer au sein
de larchitecture ainsi dfinie.
4.1. Les besoins des services

De la partie 3 ressort la ncessit danalyser diffrents services, et leurs besoins en termes
darchitecture satellite. Une tude exhaustive des services est toutefois hors du cadre de ce travail.
Nous envisageons ici lanalyse des besoins architecturaux de trois services cibles : la VoD, laccs
74
Internet et linterconnexion de rseaux. Nous observerons les raisons de ce choix en portant

laccent sur lintrt de les dployer sur satellite, et sur la manire dont cela doit tre fait.
Lorganisation de cette partie est donc dcoupe en quatre sections.
La premire propose ltude du service de VoD (4.1.1). Nous y observons aprs une
dfinition de ce que lon entend par ce service (4.1.1.1), comment le satellite est un mdia de
choix pour ce service (4.1.1.2). La section 4.1.1.3 propose diffrentes architectures rseaux dj
existantes ou envisages ici, mettant en uvre la VoD par satellite et les tudie qualitativement.
Les sections 4.1.2 et 4.1.3 tudient respectivement laccs Internet et linterconnexion de VPNs,
en suivant la mme approche que celle utilise pour la VoD. La section 4.1.4 conclut alors cette
tude en soulignant les besoins diffrents de chacun de ces services.
4.1.1.
Vido la demande
Naturellement diffusant et adapt au multimdia, le satellite offre un support de choix pour

la Vido la Demande (VoD). La VoD est donc le premier service prsent ici, faisant le lien
entre les services actuels de tlvision numrique sur satellite et dautres services plus proches
dIP comme laccs Internet.
4.1.1.1.
Quelques lments sur la vido la demande
Les services de VoD sont singuliers, posant plusieurs questions : lutilisateur doit-il recevoir
ce film de manire instantane ou aprs un laps de temps spcifier ? Cette vido doit-elle tre
regardable en instantan ou pouvoir tre stocke ? Quelle est ltendue du choix du mdia ? Dans
ce cadre, on dgage gnralement deux services : la VoD et la NVoD (Near Video on Demand).
La NVoD est un service o la demande nest pas directement considre, puisque reposant sur
une mission en continue et le choix dacheter ou pas une sance. Mais la limite entre VoD et
NVoD se resserre de plus en plus avec lvolution actuelle de ce service.
4.1.1.1.1.
VOD ET NVOD
La NVoD a peut-tre t le plus ancien de ces services. Dabord dploye sur le cble, elle
stend aux satellites commerciaux, avec Kiosque. Il sagit dun service assez cher, quil soit sur
TPS ou Canalsatellite. Ce service propose de la vido en push, c'est--dire lmission de films en
boucle sur plusieurs chanes, offrant un temps dattente de 30 60 minutes pour les mdia les
plus courants. La NVoD a plusieurs dfauts importants :
Monopolisation de canaux de manire permanente pour mettre un film, ce qui conduit

invitablement un choix trs restreint de mdia.
Indpendance de la demande ce qui peut aboutir des missions pertes et donc un

cot lev du mdia.
Ncessit dune voie retour pour commander le film. Le cble a lavantage dtre
bidirectionnel, alors que pour le satellite, lIRD doit utiliser une ligne tlphonique.
Pas de relle marge temporelle pour regarder le film, le client est oblig dattendre la
prochaine session, 60 minutes pour un film courant cela peut tre rdhibitoire. De plus
le mdia est une mission et donc il ne peut tre visionn quen temps rel. Si le client
doit sabsenter, il a gaspill plus de 5 euros.
Les dcodeur-enregistreurs avec Pilotime de Thomson et Platinum de Sagem, offrent un
palliatif rcent ce dernier problme [86].
Lavantage incontestable de la NVoD est la simplicit du systme mettre en place : du
cryptage (ce qui est dailleurs fourni par le cble comme les satellites) et la mise en place dun
mcanisme de commande, li au cryptage.
75
Face ce service, on retrouve la VoD. Au contraire de la NVoD, ce service propose un

vritable choix ses utilisateurs, avec la prsence dun catalogue plus ou moins fourni. Dun point
de vue temporel le service peut tre plus ou moins immdiat, avec une nette rpercussion sur les
prix et/ou la qualit. Les missions immdiates sont trs dpendantes de la connexion de
lutilisateur (en particulier son dbit) et de ltat du rseau entre ce dernier et le fournisseur de
services, puisquil sagit dans la plupart des cas de streaming. Mais le dlai entre la commande et la
rception peut tre plus grand dans la mesure o un moyen de stockage est possible. Ainsi, lon
peut prvoir un tlchargement de nuit, pour avoir le film disponible le lendemain. Ce genre de
services nest certes pas immdiat, mais des systmes de programmation sont alors possibles, la
limite distincte avec la NVoD devenant moins nette.
Lavantage dun tel service rside dans lmission dun mdia que lorsquil est rellement
demand. Puisque certains modes permettent dattendre avant lmission de la vido, diffrents
utilisateurs peuvent la slectionner. Aussi il serait envisageable denvoyer la donne une seule fois
vers tous les utilisateurs. La VoD de ce type trouve de lintrt dans le multicast [87], ce dernier
tant gnralement effectu au niveau applicatif ou transport. Toutefois lutilisation du multicast de
niveau trois coupl un mdia diffusant pourrait prsenter pour ce service un attrait majeur,
offrant une vritable conomie de bande passante, et donc un prix rduit de laccs au mdia.
4.1.1.1.2.
PERSPECTIVES DE LA VOD
En 2002, la VoD se prsentait comme un service de choix pour le cble. Le cble, support
bidirectionnel, facilite la commande des mdia, alors que les systmes satellites offrant une voie
retour directe sont coteux et donc peu rpandus. Des tudes avaient mme prdit que la
tlvision par cble gagnerait sa lutte de march contre les services TV par satellite grce cette
soit disante killer application [88]. Aujourdhui on peut facilement conclure une erreur de
pronostic : le cble et le satellite sont certes en concurrence, mais leurs atouts spcifiques
permettent de cibler des clients diffrents [89]. Ainsi, en milieu urbain lutilisation reste
majoritairement celle du cble, grce au cblage de quartiers entiers. Le satellite est une solution
plus aise et moins chre pour les milieux plus ruraux voire isols, les maisons prives et les
banlieues.
Il faut toutefois noter que la VoD est loin dtre un service trs porteur. En effet la
moyenne de vidos loues par un franais est de six films par an, ciblant de prfrence les 16-34
ans. De plus les rcents dboires des producteurs de disques freinent en grande partie les services
de VoD sur le web, mme si un film est moins volatile quun fichier audio. Dans ce cadre, la
VoD ne peut pas tre considre comme rentable en tant que service unique, mais comme un
complment intressant dautres services. Certains experts considrent mme quun tel service
napportera pas de clients en plus, mais permettra de les fidliser avec un joli complment [90].
Malgr cela la Vido la demande est depuis 2001-2002 au cur des investissements et des
recherches des diffrents groupes axs sur la communication et le multimdia (France Tlcom,
Monaco Tlcom, MC Cble, Tiscali), avec deux pays leaders dans le domaine les Etats-Unis
(MovieLink.com) et la Core du Sud. LEurope et plus particulirement la France ont su aussi
investir dans le domaine. Ainsi la VoD est prsente dans 100% des projets de tlvision sur
ADSL avec notamment TPSL ou MaLigneTV. On peut trouver facilement quelques exemples de
la prolifration de ce service sur les infrastructures terrestres :
Movie-System [91] qui, aprs une exprience peu concluante de tlvision ADSL en
2002 (Szame TV), a fini par trouver une bonne conjoncture avec MaLigneTV.
Lassociation de MC Cble avec NetCin (09/07/03), reprenant le projet Szame TV.
Le projet de Tiscali en Juin 2004 avec la volont dintgrer diffrents services de

manire progressive (domotique, vido surveillance, sant en ligne)
76
NetCin.com qui propose de la VoD via Internet et cela quel que soit le FAI.
La VoD est donc un service en vogue ces dernires annes. Il faut toutefois le considrer,
lheure actuelle, comme un complment et non comme lunique service offert par un systme. La
VoD est donc un candidat parfait lintgration de services.
4.1.1.2.
Le satellite comme support de la vido la demande
La VoD via la diffusion par satellite semble pouvoir avoir un bel avenir. En effet les
spcificits du satellite deviennent vite des avantages pour ce service (large couverture, hauts
dbits, accessibilit, facilit du multicast). Le satellite se prsente de plus comme un mdia
parfaitement adapt au transport de flux multimdia, grce sa compatibilit totale avec le
MPEG-2. La VoD apparat pour lui comme un complment de service pouvant tirer avantage de
son support diffusant. Dans le cadre dun march de plus en plus concurrentiel, elle peut
apporter le plus indispensable au dveloppement des satellites.
La mise en uvre de ce service sur satellite pose quelques questions dont les principales
sont regroupes dans les trois points suivants :
La requte des mdia : cet lment comprend dune part la gestion dune voie retour
pour faire parvenir la requte aux serveurs multimdia, voire le paiement, et dautre part
la consultation du catalogue de mdia disponibles. Cette requte peut tre gre de
diffrentes manires :
indpendante du systme, via par exemple un site web auquel le client accde et
commande le mdia,
semi dpendante, avec mission de catalogue de manire priodique vers lIRD, une
ligne tlphonique pouvant tre utilise pour commander le mdia aprs
consultation,
dpendante, avec une gestion via un lien retour complet intgr dans lIRD.
Except dans le cadre dun besoin de lien retour pour la gestion des erreurs, ce qui reste
rare, la dernire solution napparat pas comme adapte au problme puisquune voie
retour nest pas indispensable pour de tels services.
Le support de transport des flux de donnes : il existe deux solutions potentielles

savoir lutilisation du support MPEG-2 TS du DVB-S ou lutilisation des datagrammes
IP. Dun ct le support MPEG-2 TS est adapt directement la vido, mais il nest
pas sr que le fournisseur ni les clients soient directement connect la gateway. De plus
le MPEG-2 nest pas le seul format possible, sa prennit tant remise en question par
le MPEG-4, idal pour lintgration des mdia. Dun autre ct le support IP propose
une intgration facile au prix dune seule sur-encapsulation. Les flux natifs sont donc
considrs mais comme une simple opportunit.
La gestion des missions de films. Il sagit dune question dlicate qui peut vite
transformer la nature diffusante du satellite en un dsavantage. En effet, dans le cadre
dmission de mdia haute dfinition instantanment aprs une requte, trs peu de
clients peuvent tre servis la fois. De plus mettre sans aucun temps dattente
implique ncessairement de faire du 1 film pour 1 client, sauf si les clients acceptent de
prendre le film en cours. Le service devient alors trs cher mais peut-tre envisag pour
des clients importants tels que des chanes dhtels. Une solution pour offrir ce type de
service des particuliers est la mise en place dun systme de votes. Le film est mis
heure fixe, et correspondra aux choix de la majorit. Lmission peut aussi tre
effectue sous un format plus compress, avant une heure donne. Le film doit alors
tre stock pour tre visionn. Ces dernires solutions paraissent plus rentables et
accessibles dans le cadre de la VoD sur satellite, puisquelles permettent de mettre
profit son support diffusant pour distribuer le mdia plusieurs utilisateurs la fois.
77
Un tel service ne peut alors se dvelopper qu condition dune gestion des requtes de film
et donc de la bande passante satellite. Un dernier point positif pour linsertion du satellite dans la
VoD, est sa nature adapte lvolution des services. Contrairement au cble qui ncessitera
toujours une infrastructure lourde, le satellite se place comme une technologie ouverte lre du
portable et de la mobilit. Son couplage avec les ondes terrestres (DVB-T, WiFi, UMTS) offre
des perspectives encourageantes, comme notamment la distribution sur tlphones portables [9].
Lincrmentation volutive tout comme les diffrentes perspectives prsentes ici peuvent
alors conduire diffrentes architectures.
4.1.1.3. Diffrentes architectures rseaux de vido la demande sur

satellite
Nous nous proposons dtudier dans cette partie lintgration dun service de VoD sur un
systme satellite. La figure suivante (Figure 4.1) prsente diffrents types darchitecture de VoD
via un systme satellite. Ce schma dgage cinq architectures, diffrentes en terme de technologie
utilise, que nous allons dcrire dans les paragraphes suivants.
Figure 4.1 Cinq architectures de VoD sur un systme satellite gostationnaire
Comme on peut le constater premire vue, les architectures de 1 3 proposent un accs

au service par une voie autre que le satellite, alors que les solutions 4 et 5 sont fondes sur un lien
bidirectionnel avec le satellite. Chaque topologie prsente ici implique une mise en uvre
spcifique du service de VoD, soit des services diffrents.
78
4.1.1.3.1.
TOPOLOGIE 1
La topologie 1 met en uvre un service similaire au service classique de NVoD,

disponible de nos jours sans aucun changement sur les satellites de diffusion TV standard, avec
comme diffrence fondamentale la possibilit de choisir la vido plutt que davoir accs un
dfilement de films en boucle.
Figure 4.2 Diagrammes dactivit caractristiques de la topologie 1
79
Le fonctionnement du service est alors dcrit par le mcanisme propos dans la figure
prcdente (Figure 4.2). Ce schma regroupe deux diagrammes dactivit.
Le premier prsente la mise jour des mdia disponibles pour lutilisateur. Ceux-ci sont
consultables par lutilisateur via la lecture des tables prives associes au service de VoD par son
IRD.
Le deuxime retrace la vie dune demande/acquisition/destruction dun mdia : une
transaction complte entre le fournisseur de service et un client. On peut noter diffrents points
sur ce diagramme :
Certains points ne sont pas dtaills par souci de lisibilit dune part, et parce que les
implantations peuvent tre trs diffrentes, comme par exemple le choix du mdia ou la
procdure de paiement.
Un choix particulier a t fait dans cette description, celui dutiliser la mthode de deux
seuils dont un doit tre atteint pour envoyer la donne, un temporel et un en nombre
de requtes.
Il est toujours possible daffiner cette reprsentation en insrant, par exemple, un lien
entre le temps maximal coul entre la requte et lmission du mdia, et le prix final du
service. Cependant, ce travail sloigne trop de notre tude et nest pas prsent ici.
Un certain nombre de points comme la latence entre requte et mission, la qualit du

mdia, ou encore sa forme (MPEG-2, MPEG-4, ) sont des paramtres qui influent
sur la qualit du service et donc son prix.
Les avantages sont surtout dordre technique, puisque le systme sintgre parfaitement
dans les systmes standards de tlvision par satellite, ne demandant quun module logiciel
charger sur le dcodeur. Aucun quipement supplmentaire nest donc ncessaire.
Les inconvnients de cette topologie rsident dans un couplage difficile avec des services
autres comme laccs Internet, la monopolisation de flux pour transmettre la vido, et la gestion
en dlai souvent difficile si le service connat beaucoup dabonns qui souhaitent obtenir leur film
tout de suite. De plus une infrastructure terrestre est ncessaire pour commander une vido.
Enfin, il est trs probable que dans le cadre dun tel systme le choix de films via les tables
prives DVB-SI soit restreint, surtout pour un service reposant sur les votes des clients.
4.1.1.3.2.
TOPOLOGIE 2
La topologie 2 met en avant un type de service diffrenciant les quipements en fonction

du sens de communication. Dun ct un accs Internet permet de choisir et commander un film
et de lautre, hors connexion Internet, le film est reu via le dcodeur. Il sagit donc dune
configuration indpendante, comme prsente dans la partie 4.1.1.2.
Le mcanisme, est alors dcrit par la figure ci-dessous (Figure 4.3). On observe une
diffrence notable avec le cas prcdent : cest le client qui va chercher linformation sur le
serveur de vidos, et non plus le fournisseur daccs qui met jour les informations vhicules
par les tables SI et accessibles aux IRDs.
Une telle architecture propose alors une plus grande manuvre et configuration du service,
offrant une interface plus conviviale et plus fournie pour choisir le mdia, grce au Web et donc
en partie lintgration du service via IP. Comme la topologie prcdente le systme sintgre
parfaitement dans les systmes de tlvision par satellite standard, la connexion ntant utile que
pour la commande et pouvant tre passe de nimporte o via les technologies mobiles (WAP,
UMTS, un accs Internet WIFI, etc.). Tout cela condition que lIRD soit allum. Comme
prcdemment, il ny pas besoin de mettre en place un niveau IP pour encapsuler le mdia, mais
celui-ci peut tre un plus pour recevoir des informations plus varies sur sa tlvision.
80
Les inconvnients cits dans la topologie 1 restent valalables ici. Toutefois un risque
supplmentaire est possible si le client doit disposer dun accs Internet chez lui. Dune part cela
implique un cot supplmentaire pour le service, dautre part cette solution peut vite devenir peu
avantageuse face la concurrence de la VoD via ADSL. En effet si le client est reli Internet via
une connexion illimite, haut dbit, il a peu dintrt utiliser de surcrot labonnement un
systme satellite, sauf si celui-ci lui permet un service complmentaire des tarifs avantageux.
81
4.1.1.3.3.
TOPOLOGIE 3
Cette topologie est totalement similaire la topologie 2, lexception de lutilisation dun

PC pour le choix comme la rception du film.
4.1.1.3.4.
TOPOLOGIE 4
Le service propos ici est radicalement diffrent de ceux des topologies prcdentes dans la
mesure o il met en avant lutilisation de la technologie DVB-RCS. Dans ce cadre, le fournisseur
de services a une entit locale. Cette annexe est quipe dun rcepteur/metteur satellite, dun
cache local (parfois nomm Point of Presence), dun serveur daccs au service et enfin dun rseau
local o sont situs diffrents clients. Lutilisation de cette architecture est alors comparable
lutilisation dun proxy cache dans laccs Internet.
82
Dans cette topologie, lutilisation du protocole IP est prfrable pour viter les problmes
dhomognit entre par exemple MPEG-2 TS, ADSL, Wifi, Ethernet, ou ATM. IP est donc
utilis ici comme support fdrateur.
Les principaux mcanismes de cette architecture de service sont alors reprsents par les
diagrammes dactivit suivant (Figure 4.4), dfinissant la mise jour des mdia disponibles, le
tlchargement des nouveauts sur le cache, et une transaction avec un client du service.
Les avantages de ce systme sont diffrents de ceux prcdemment cits. La prsence dun
cache permet une conomie de bande passante satellite notable. Ainsi lmission de mdia
courants a un prix de revient bien moins important pour le fournisseur de service, qui peut en
retour proposer des promotions (en fonction des films dj prsents dans les caches). De plus ce
systme fonctionne sans aucun accs un autre service (Web, tlphone, WAP, ) et donc
nentrane pas de cots marginaux. Enfin, ce type darchitecture prsente des perspectives
intressantes de couplage avec dautres services.
Ce dernier point est aussi le dfaut majeur dune telle architecture : en elle-mme elle nest
pas rentable pour le seul service de VoD. En revanche coupl un rseau daccs Internet, un
rseau dj prsent comme dans les htels, les hpitaux, les universits ou encore plus
gnralement les zones cbles, cette architecture offre une trs nette orientation lintgration
de services.
4.1.1.3.5.
TOPOLOGIE 5
Cette architecture est la plus volue : elle utilise un lien bidirectionnel DVB-S/DVB-RCS
pour chaque client. Dans son fonctionnement elle est tout fait quivalente la premire
architecture, en liminant le dfaut de la voie retour terrestre. Comme larchitecture
bidirectionnelle prcdente, cette solution de par son cot ne peut tre envisage que pour un
service de VoD. De plus cette topologie est actuellement trs coteuse pour tre dploye chez
un particulier.
Dans le cadre dun seul service VoD o la voie retour est trs peu utilise, une telle
architecture nest pas du tout justifie et napporte donc rien. En revanche, dans le cadre de
lintgration de plusieurs services dont la VoD, elle peut tre envisage, mme si coteuse.
4.1.1.4.
Conclusion sur ces architectures
Nous avons observ diffrentes architectures de service VoD. Parmi ces architectures se
dgage lide fondamentale que le lien retour nest pas une ncessit, puisque lmission en ellemme du mdia ne repose gnralement pas sur une connexion bidirectionnelle. Les topologies 4
et 5 sont donc hors cadre du seul service de VoD, demandant un trop grand investissement pour
peu (voire pas) de gain pour lutilisateur final. La solution qui nous parat la plus envisageable est
la topologie 2 (et donc la 3), reposant sur un accs quelconque au site du fournisseur de services.
Lintgration dun OBP nest donc pas vritablement ncessaire ici, si ce nest pour la
gestion de plusieurs faisceaux. Mais une telle architecture a-t-elle besoin dun systme
multifaiceaux ? Tout dpend du type de service VoD offert.
Un service proposant des vidos en streaming sur satellite na pas un rel intrt sur satellite,
puisque le point fort du satellite est lmission vers un grand nombre dutilisateurs sans que cela
ne lui cote plus cher, alors que le est typiquement de lunipoint, o, sur ce point, il ne peut
efficacement concurrencer le terrestre. Le satellite propose de plus une diffusion haute dfinition,
avec un dbit de 5 6 Mbit/s par film, il peut ainsi en envoyer 6 7 en simultan sur un canal.
Pour un grand nombre dutilisateurs largement dissmins, le multifaisceaux est inutile puisque
quivalent du broadcast un prix suprieur. En revanche, quand les utilisateurs sont
gographiquement regroups, le multi-spots permet dconomiser la capacit sur les spots non
concerns.
83
De tels systmes semblent alors envisageables sur satellite, et font lobjet de premires
offres commerciales [92]. Il revient alors plus un modle de tlchargement de mdia, et
pourrait tre tendu dans ce cadre des sons, des images, des programmes La VoD telle que
nous lenvisageons pour le satellite offre des perspectives favorables lintgration dautres
services sur satellite. Les diffrentes architectures analyses peuvent alors tre considres
diffremment : la clef dune architecture volutive pour intgrer dautres services plus
bidirectionnels. Ce service peut se contenter dun satellite gostationnaire transparent lorsquil
met un grand groupe le mdia. Par contre lutilisation du multipinceaux, peut permettre de
grer des groupes plus concentrs.
4.1.2.
Accs Internet
Laccs Internet a connu une croissance exponentielle et continue de crotre lheure

actuelle. Cest grce lui que le rseau terrestre sest autant dvelopp et il constitue une base
indispensable lintgration de services sur support IP. Le satellite peut-il trouver sa place dans ce
service, et ce malgr les protocoles tels que TCP qui ne le favorisent pas ? Cette partie se propose
de montrer quelle place a le satellite dans ce domaine et avec quel type darchitecture. Nous
tudierons alors le satellite comme un complment au rseau terrestre et non comme un
concurrent, sa cible pour laccs Internet nest pas la mme.
4.1.2.1.
Laccs Internet aujourdhui
En France, lanne 2003 a t marque par une large dmocratisation de laccs au World
Wide Web . Ainsi, fin 2003, ce pays comptait 21 millions dinternautes, soit 42,6% des franais
de onze ans et plus (selon une tude de Mdiamtrie [93]). Cette croissance a engendr la
multiplication des FAIs, augmentant la concurrence et diminuant les prix du service,
principalement pour les offres terrestres haut dbit (cble et ADSL).
Le rseau terrestre est le mdia principal de ce service avec des offres diverses :
le bas dbit (modem 56k, Numris), qui reste trs rpandu surtout en dehors des
grandes villes ;
lADSL qui connat actuellement une envole grce une augmentation des capacits
pour un prix trs rduit ;
le cble, concurrent principal de lADSL, il reste moins dvelopp en France que dans
le restant de lEurope.
Cette croissance a permis le dveloppement dautres services, comme par exemple la vente
via Internet (une croissance de 65% en 2003 et une prvision de plus de 50% en 2004). Ainsi
pour lanne 2004, les acteurs du domaine prvoient [94] :
une croissance leve pour tous les services en ligne (achat, jeux, cinma),
une ouverture importante du grand public au haut dbit,
lenracinement de lInternet dans la vie professionnelle comme personnelle.
4.1.2.2.
Le satellite comme media daccs Internet
Le satellite comme mdia daccs Internet napparat pas encore comme une technologie
assez conomiquement intressante pour concurrencer les rseaux terrestres haut-dbit.
Toutefois, pour les 25% de foyers qui nauront pas encore accs cette technologie en 2005, les
offres commerciales daccs par satellite (unidirectionnelle et bidirectionnelle) propose une
solution. Les offres unidirectionnelles sont compltes par une voie retour modem 56k (de 9.6
28.8 Kbit/s), mais ce systme est peu adapt aux applications type P2P qui fleurissent
actuellement sur la toile. Les offres bidirectionnelles proposent lutilisation dune voie retour
satellite en DVB-RCS, et passent toutes, en France, par Eutelsat.
84
Le satellite propose de nombreux avantages. Sa large couverture permet datteindre un

point trs distant en un seul bond, vitant ainsi les engorgements du rseau terrestre. De plus son
adaptation inne la diffusion permet douvrir laccs Internet vers dautres horizons, comme le
multicast. Enfin, lon peut noter que seul le satellite est capable actuellement doffrir le haut dbit
aux zones loignes des grandes villes, rurales, ou mme enclaves (plate-formes ptrolires,
montagnes, dserts). Le satellite apparat comme un complment laccs terrestre haut dbit.
Toutefois le satellite a deux inconvnients majeurs. Dune part la mise en uvre dIP sur
satellite est plus dlicate, notamment cause du protocole de transport TCP [69]. Dautre part, les
liens satellites unidirectionnels sont loin dtre performants, tandis que les liens bidirectionnels
ont un prix lev qui restent prohibitifs pour un utilisateur priv, voire pour une PME. En effet le
cot dun terminal est de lordre de 1500 2500 , linstallation de lordre de 1000 , et
labonnement mensuel peut aller jusqu plus de 600 par mois pour du 2 Mbit/s descendant et
du 1Mbit/s en monte.
Toutefois, les perspectives offertes par les recherches actuelles pour baisser les cots des
terminaux DVB-RCS [44], la volont dune standardisation dIP sur satellite, ou encore le bon
couplage de la technologie satellite avec les rseaux terrestres ou sans fil, offrent au satellite la
possibilit de se constituer un march.
4.1.2.3.
Diffrentes architectures daccs Internet via satellite
Cette partie propose dtudier diffrentes architectures daccs Internet via un lien satellite,
toutes possibles lheure actuelle. La figure suivante (Figure 4.5) intgre plusieurs types daccs
Internet dans une vision globale et permettra ainsi davoir une rfrence commune pour ltude
de ces diffrentes topologies. Ce schma dgage cinq architectures diffrentes, mettant en valeur
deux types de topologie, lune avec voie retour uniquement terrestre et lautre satellite.
Figure 4.5 Cinq architectures daccs Internet via un systme satellite gostationnaire
85
Le premier type de topologie est une ralit aujourdhui, mme si elle na pas attir
beaucoup de particuliers en France. Le second type est une solution davenir : des offres
commerciales sont actuellement proposes, mais elles resteront chre tant que les technologies
mises en uvre ne seront pas mres1.
4.1.2.3.1.
ARCHITECTURES SATELLITES UNIDIRECTIONNELLES
Analysons tout dabord les offres unidirectionnelles proposes (1 et 2). La topologie 1 est la
solution classique dj expose dans la partie 3.2.2. Elle garde les limites dj prsentes. La
topologie 2 runit les clients dans un rseau daccs (LAN, Wifi, Fibre optique) et utilise un
lien retour terrestre. Cette architecture prsente les mmes limites que la topologie 1. De plus,
parce que le prix dune antenne de rception est trs modique, son partage entre plusieurs
utilisateurs pose plutt un problme de gestion de bande passante, et non une relle conomie.
Enfin cette architecture, en proposant le partage dune seule connexion terrestre entre ses
diffrents clients, prsente un vritable paradoxe : soit la voie retour est du modem 56k ou
Numris, et le systme se situe en milieu rural, mais le partage de ce faible dbit entre tous les
clients pose problme (mme sil ne sagit que de faire passer des acquittements et des requtes),
soit la connexion est en haut dbit, lintrt du satellite comme mdium daccs Internet en ville
reste alors trs mitig.
Par simulation, nous avons obtenu les courbes suivantes (Figure 4.6), prsentant les limites
de la topologie 22. Ainsi on peut constater que le passage lchelle est dlicat surtout pour une
voie de retour faible. Dautant plus que la mise en place dun tel systme implique un cot, ne
devenant rentable qu partir dun nombre certain dutilisateurs.
Figure 4.6 volution du dbit en fonction du nombre dutilisateurs pour la topologie 2
La topologie 1 parat donc une meilleure solution pour laccs Internet via un lien satellite
unidirectionnel. Si elle nest pas exempte de limites, dans le cadre dun service traditionnel,
comprenant mail, navigation web, et tlchargements (FTP, ), elle propose une connexion
intressante, pouvant offrir un bon dbit en voie aller, compare une connexion modem, ou
numris. La topologie 2 peut toutefois tre utilise pour un faible nombre de terminaux si une
infrastructure est dj en place.
1 Il faut noter que des offres commerciales existent dj pour des accs bidirectionnels, comme Thacom, o,
dans les pays dAsie, le satellite est une solution clef pour vaincre lisolement et les reliefs accidents.
2 La simulation a t effectue sous NS 2, avec un lien aller de 10 Mb/s partag entre diffrents utilisateurs
dun rseau local.
86
4.1.2.3.2.
ARCHITECTURES SATELLITES BIDIRECTIONNELLES
Les architectures 3, 4 et 5 utilisent toutes un lien retour DVB-RCS. Un tel quipement

reprsente un investissement trop important pour des particuliers. La topologie 5 ne pourra donc
tre considre comme une solution relle large chelle quavec une baisse du cot des VSATs.
Les architectures 3 et 4 sont trs semblables proposant de regrouper les utilisateurs dans un
rseau daccs, et permettant de supporter ainsi le cot du terminal DVB-RCS entre les diffrents
utilisateurs. Avec un dbit retour plus important, ces rseaux sont plus adapts aux
dveloppements des nouvelles gnrations dapplications sur Internet, plus bidirectionnelles.
Cependant ces solutions restent tout de mme coteuses, dans la mesure o une
infrastructure est requise pour le rseau daccs. De plus un aller retour satellite implique un dlai
relativement long qui peut rebuter lutilisateur lorsquil souhaite uniquement faire de la navigation
web. En effet, cette architecture a un RTT imcompressible de 500 ms, augmentant le temps de
rponse de protocoles de type http, o le dbit est peu important comparativement au dlai. La
figure suivante (Figure 4.7) montre lvolution du temps requis pour transfrer des informations
avec ftp, en fonction de la taille de cette information. Les rsultats sont compars entre une
connexion satellite unidirectionnelle et une connexion satellite bidirectionnelle. Lon saperoit
quil faut avoir transfrer une donne de taille suprieure un seuil (ici 236,6 KB) pour que la
dure de transfert soit moins longue dans le cas bidirectionnel et cette topologie devienne plus
performante1.
Figure 4.7 volution du temps de transfert sur un lien satellite unidirectionnel et bidirectionnel
Toutefois, dans le cadre de transferts plus importants, cette architecture prsente de

meilleures perspectives. Le couplage avec des technologies telles que le Wifi offre alors la
possibilit des collectivits locales de devenir fournisseur daccs, et deffacer la fracture
numrique qui spare les grandes villes des zones plus rurales [95]. Les solutions bidirectionnelles
prsentent enfin une solution daccs haut dbit pour les mobiles. Quils sagissent de bus
fournissant laccs Internet des communes isoles, de trains [96] ou encore mme davion (avec
par exemple loffre Connection by Boeing2), les solutions DVB-S/DVB-RCS ont un avenir. Des
offres commerciales aux particuliers sont mme proposes comme loffre Drive de Sat2Way3.
La valeur prise pour le dbit aller est de 2Mb/s, le dbit retour satellite est de 256 Kb/s tandis que le dbit
modem considr est de 9.6 Kb/s. Les pertes sur le satellite ne sont pas considres. Le dlai de la voie retour
satellite est de 254 ms ajout au 10 ms daccs au serveur, compar une voie retour terrestre de dlai 100ms
1
http://www.connexionbyboeing.com
http://www.sat2way.com
87
Cette solution apparat alors comme un moyen doffrir laccs Internet par satellite des
localits sans accs au rseau terrestre, et plus proches des offres terrestres haut dbit. Bien sr, le
cot dun tel systme le rend non comptitif dans les zones urbaines.
4.1.2.4.
Conclusion sur ces architectures
Ltude de satellite comme support laccs Internet montre lmergence de deux types
darchitecture : lune traditionnelle, qui prsente un rapport qualit/prix satisfaisant pour un accs
Internet asymtrique, lautre reposant sur un rseau daccs permettant daccder un service
plus symtrique, pour des applications de type P2P.
Cette tude a montr des besoins diffrents en fonction du type dutilisation dun service.
Ainsi, un lien unidirectionnel propose une meilleure interactivit pour des donnes de faible
poids, type navigation web, mail, court transfert FTP. Toutefois, son utilisation devient vite
restrictive dans le cadre dapplications plus bidirectionnelles. Le lien bidirectionnel propose certes
un dlai plus grand, mais offre une meilleure accessibilit du systme tout en ouvrant vers des
performances sapprochant des hauts dbits terrestres, pour un cot de revient plus lev.
Cette tude a permis de dgager deux architectures rseaux selon le service daccs Internet
dsir. Ainsi, pour un accs Internet classique, lutilisation des liens unidirectionnels avec une
topologie mono-utilisateur, type architecture 1 est la solution envisage dans cette tude. En
revanche, pour un accs plus volu, cest--dire supportant des applications plus symtriques,
lutilisation des liens bidirectionnels avec regroupement des utilisateurs dans un rseau daccs
(topologie 3 et 4) est conseille. Enfin, il faut noter que les autres architectures ne sont pas
rejeter, mais semblent simplement ne pas pouvoir convenir pour le seul service daccs Internet
lheure actuelle.
4.1.3.
Interconnexion de rseaux distants
Le service de liaison entre rseaux distants a t lorigine de la cration des VSATs :

linterconnexion entre rseaux, notamment bancaires, a su profiter de cette technologie et a
permis doffrir un nouvel horizon aux VPNs (Virtual Private Networks) dentreprise1[23].
4.1.3.1.
Le satellite gostationnaire et les VPNs dentrerprise
Linterconnexion de sites distants ne peut pas toujours tre ralise via un unique rseau
fdrateur. Un cblage priv ou la location dune ligne cote en effet cher. Lide de VPN
dentreprise est ainsi apparue : fdrer des rseaux appartenant la mme entit, mais
gographiquement dissmins, comme des succursales bancaires. Linfrastructure terrestre a
permis la mise en place de solutions passant par des tunnels travers le rseau Internet [63]. Si
cette technique est bien matrise aujourdhui, grce notamment des protocoles tels quIPsec, le
tunnelling reste trs vulnrable aux rseaux quil traverse, pouvant subir congestion, perte, et
variation de gigue. De plus, le rseau terrestre nest pas dvelopp partout, ce qui peut poser un
vritable problme pour des socits dissmines dans les pays fortes contraintes gographiques
ou du tiers monde [21].
Dans ce cadre le rseau satellite a su trouver un crneau, avec lapparition des VSATs [23].
Le satellite se place comme un support de choix pour linterconnexion de plusieurs sites distants.
Son meilleur atout est certainement quavec un ou deux bonds satellites, les rseaux soient
directement connects. Ainsi un tel support permet dviter les alas du passage travers le
rseau terrestre, tout en vitant les mises en place de lignes loues coteuses. Le satellite peut
donc offrir aux VPNs une matrise de la gigue tout comme une assurance sur le dbit offert. La
1 Dans la suite de cette partie, le terme VPN est plus gnralement employ pour les VPNs dentreprise, au
sens donn par la rfrence [61] et peuvent tre des VPNs de niveau 2 ou 3.
88
mise en place de QoS est donc grandement facilite par un tel systme, et ce type de systme
devient rentable avec la baisse du cot des terminaux (location de 7000 en 1995 un cot
dachat de 1500 2500 aujourdhui). Le satellite a de bonnes perspectives pour un tel service1.
4.1.3.2.
Diffrentes architectures dinterconnexion via satellite
Dans le cadre dun service dinterconnexion, il est possible davoir plusieurs structures
comme le montre la figure suivante (Figure 4.8). Ces architectures peuvent aussi bien fonctionner
en monofaisceau quen multifaisceaux (do les spots en pointills).
Lon distingue ainsi quatre topologies :
1Cette architecture nest pas possible dans la plupart des cas, puisquelle met en
uvre plusieurs gateways (au moins deux) pour interconnecter les rseaux. Dune part une
gateway est trs coteuse, et dautre part il ne peut y avoir un grand nombre de gateways pour
un mme systme satellite. Vu son prix cette solution nest envisager que dans le cadre de
regroupements de nombreux VPNs comme par exemple pour linterconnexion de ples
industriels importants.
2Ici une gateway est ncessaire, les autres rseaux sont quips de rcepteurs air, et
utilisent une voie retour terrestre. La gateway nappartient pas obligatoirement au rseau
principal et seulement une plage de bande passante peut tre loue loprateur satellite.
Toutefois cette structure implique un lien terrestre, et donc une perte de contrle sur cette
architecture, si ce lien passe par lInternet.
3Les rseaux dentreprises sont quips de terminaux metteurs/rcepteurs,
permettant ainsi denvoyer directement les donnes vers le satellite. Sans traitement bord,
les flux DVB-RCS sont envoys vers une gateway qui retransmet les donnes dans un canal
logique DVB-S. Le RTT dun tel systme est donc de quatre bonds satellites, soit plus de
une seconde, rendant le systme mal adapt aux changes vocaux, comme aux applications
temps rel avec faible dlai. Cette architecture est donc mieux adapte au transfert de
volume de donnes.
4Comme dans la topologie 3, les rseaux privs sont quips dmetteurs DVBRCS. Toutefois ce systme utilise un satellite avec multiplexage bord, permettant de
navoir quun unique bond satellite entre les rseaux interconnects en transformant les flux
DVB-RCS montant en flux DVB-S descendant. Cette solution plus chre permet doffrir
un meilleur dbit TCP, mais surtout de ramener le systme dans une marge acceptable pour
le transfert de la voix, ou les applications plus multimdia, ou temps rel, du type
tlconfrence ou tlmdecine.
4.1.3.3.
Conclusions sur ces architectures
Pour ces raisons, les architectures 3 et 4 paraissent les plus adaptes linterconnexion de rseaux
privs. Si la solution 3 ne propose pas un dlai suffisamment faible pour permettre la mise en
place dun rseau tlphonique inter-site, avec de la voix sur IP par exemple, elle met en place
une structure peu coteuse comparativement aux autres topologies, et capable de transporter un
grand volume de donnes de manire scurise et fiable. La solution 4 quant elle propose un
service deux fois plus ractif, mais avec un prix plus lev (au moins deux fois plus cher). Les
deux solutions sont donc complmentaires et permettent la mise en uvre dapplications
diffrentes. Larchitecture 4 remplit toutes les fonctionnalits de larchitecture 3, aussi bien, voire
mieux, mais avec un cot bien plus lev.
1Par exemple, le projet FICUS (http://ficus.ups-tlse.fr) met en place une cyber-universit entre lInde et la
France grce linterconnexion satellite, solution meilleure qualit/prix.
89
Figure 4.8 Quatre topologies dinterconnexion via un systme satellite gostationnaire
4.1.4.
Conclusion et ouverture dautres services
Le trois services tudis prcdemment regroupent une large varit dapplications et de

besoins que lon peut retrouver dans la plupart des autres services. Ainsi, pour des services tels
que la vidoconfrence, laudioconfrence, la tlformation, les applications partages, on y
retrouve les diffrents besoins prcdemment cits : multiplexage bord pour rduction des dlais
et accroissement de la QoS, retour sol contre retour air, utilisation de la commutation bord
En revanche, des applications posent dautres problmes que ceux poss par ces trois
services. Si lintgration de la VoIP peut tre considr comme une application envisageable dans
le cadre du service VPN (vidoconfrence, tlphone intra-rseaux,), elle ncessite une QoS
adapte, impliquant lutilisation dintelligence embarque pour viter la gigue et les doubles
bonds. En effet la VoIP ne peut supporter un dlai suprieur 500 ms, borne au-del de laquelle
la qualit rendue nest pas considre acceptable. De plus, des problmes restent aux niveaux
transport comme applicatif ; le couplage du protocole de transport UDP-Lite (Lightweight User
Data Protocol) [98] et RTP (Real Time Protocol) avec les codec AMR (Adaptative Multi Rate)
[99] semblent une solution davenir, impliquant toutefois de pouvoir remonter les erreurs bits au
niveau transport, ce qui nest pas le cas avec un systme DVB-S classique.
Le satellite prsente un intrt majeur pour les services impliquant la mobilit, mais ne peut
tre envisag que pour un groupe dutilisateurs (avion, train, bateau ). Les GEOs permettent
une grande conomie de ressources et un dploiement rapide, tout en offrant une mobilit peu
sujette aux problmes de handovers. Toutefois cette solution met en uvre une technique avance
pour lauto-pointage de lantenne, surtout dans le cadre de mouvements rapides [96].
Le satellite trouve aussi sa place dans les applications multicastes ou broadcastes, o il
devient vite trs concurrentiel des infrastructures de tlcommunications terrestres, avec
notamment la distribution diffrents caches dinformations (services comparables au cas 4 de
VoD prcdemment tudi). Des tudes ont montr que le satellite avait un cot moindre que les
rseaux terrestres au-del dun certain nombre de membres pour un groupe multicast [100].
Cette partie a soulign les besoins diffrents pour chaque service. Au sein mme dun
unique service, selon lutilisation souhaite de ce dernier, un systme satellite diffrent est parfois
90
requis. Cette analyse gros grains peut tre rsume dans le tableau suivant (Tableau II),
montrant la diversit des solutions, et proposant, titre dexemples, des valeurs de dbits aller et
retour.
Tableau II.
LES DIFFRENTS BESOINS DES TROIS SERVICES TUDIS
Chaque service a donc besoin dun systme satellite particulier pour tre performant. En
effet, contrairement au rseau terrestre o les applications se sont construites autour de la
technologie, le satellite doit quant lui sadapter aux services, habitus au rseau terrestre. Cela
explique la tendance avoir des systmes satellites ddis des services particuliers, comme la
tlvision numrique, ou lobservation.
4.2. Les objectifs dune architecture

Le concept dune architecture reposant sur un systme hybride est propos ici pour
rpondre la problmatique pose prddemment : manque dvolutivit, trop de spcificit,
solution propritaire, cot lev, etc De plus lanalyse des diffrents besoins des services a
montr que la demande ntait pas la mme selon le cadre applicatif considr.
partir de ces conclusions, cette partie propose de tracer les objectifs dune architecture
voulant intgrer ces diffrents services tout en sinscrivant dans les principes actuels
duniformisation et de standardisation des systmes satellites. Larchitecture doit proposer une
interface utilisateur indpendante du constructeur pour tre viable et prenne. IP comme niveau
protocolaire fdrateur semble alors la solution. Il nest alors pas question de chercher modifier
les couches suprieures IP dans ce travail, mais de proposer une interface standard lutilisateur
final [85]. Ainsi le lien satellite deviendra transparent pour lutilisateur final comme dans le cadre
dun rseau terrestre.
Les tapes de notre travail dcoulent directement de cet objectif fondamental : ladaptation
au trafic actuel, loptimisation des communications, et ladaptation au trafic venir.
4.2.1.
Adaptation aux trafics actuels
Le trafic actuel est majoritairement de laccs Internet pour des applications de type
consultation de pages web, mail, FTP, peer-to-peer (P2P), etc Le P2P est notamment une
application forte croissance, reprsentant jusqu 80% du trafic Internet total en volume [101].
91
Le trafic Internet a donc volu, passant dun trafic utilisateur largement asymtrique un mode
plus symtrique.
Dans ce cadre, larchitecture doit tre capable dtre ractive, offrant un lien retour adapt
aux besoins des utilisateurs finals et ncessairement aux besoins des diffrents services.
Lmergence actuelle de lintgration des services sur les diffrents rseaux terrestres ne
doit pas tre oublie. Le triple play joue un rle important pour attirer et fidliser les clients, les
FAI devenant aussi des FSI. Pour ne pas rester en marge, une architecture satellite doit offrir
cette capacit dintgration de service. Sil est vrai que la voix sur satellite ne jouit pas de la qualit
du terrestre, le satellite se rattrape par un support de la tlvision parfaitement matris. On
pourra dailleurs noter que dans le cadre de tlvision sur ADSL, celle-ci est parfois achemine
par satellite avant dtre diffuse sur les boucles locales aux utilisateurs finals1. Une architecture
satellite doit permettre un support efficace et transparent de lIP sans pour autant se priver de la
possibilit dmettre en flux natif.
Enfin une architecture se doit dtre flexible et modulable, pour pouvoir offrir aux services
larchitecture rseau qui leur convient le mieux.
4.2.2.
Optimisation du systme satellite
Loptimisation de cette architecture est un deuxime point non ngligeable. En effet il nest
pas question de proposer un systme plus coteux et moins performant quun systme
transparent.Les critres considrs sont notamment :
loverhead qui prend en compte, dune part le poids des encapsulations successives, et
dautre part le poids induit par la signalisation (tables SI, protocoles spcifiques),
le RTT qui est quivalent au dlai de transmission induit par le bond satellite dans la
plupart des cas, avec nanmoins des nuances quant au temps daccs dans le cadre de
systme DVB-RCS,
le dbit utile pour lutilisateur qui dpend souvent de la couche de transport (cf. 3.5.1),
de la configuration du systme et des erreurs satellites,
la rpartition de la charge, qui permet de comparer le nombre de flux que le systme

peut traiter la fois, permettant doptimiser lutilisation de la bande passante du
systme et donc intrinsquement lie la rpartition des utilisateurs dans la couverture
satellite,
la gestion de la QoS qui peut tre plus ou moins fine selon le systme trait.
En plus de ces seuls critres, ce travail prendra essentiellement le gain de dbit introduit
comme critre de cot.
4.2.3.
Adaptation aux trafics futurs
Un objectif fondamental de cette architecture est la prennit. Les volutions du monde

Internet et applicatif sont bien plus rapides que celles des systmes satellites, souffrant dune
inertie justifi par la lourdeur des investissements. La solution que nous envisageons offre une
transition entre les systmes transparents et la nouvelle gnration de satellite2, sans pour autant
devoir tre de courte dure.
1 Pour plus dinformations ce sujet des articles sont consultables en ligne notamment un lURL :
http://www.nwfusion.com/edge/columnists/2003/0728edgecol1.html .
2 Il faut noter que lon entend par nouvelle gnration de satellite gostationnaire, les satellites intgrants OBP
et techniques multi-spots.
92
Dans ce cadre, ce concept doit tre assez souple pour supporter les diffrentes techniques
venir et envisageables sur satellite gostationnaire. Lobjectif est donc de concevoir une
architecture globale, offrant les possibilits suivantes :
lintgration des diffrentes couches de protocoles venir comme notamment lIPv6

[31],
la gestion de lunicast, du broadcast et surtout du multicast qui semble un outil de choix

pour certaines applications futures, et se place comme un lment parfaitement indiqu
pour le satellite,
la gestion de la QoS des diffrents trafics,
la gestion de la scurit (avec notamment une compatibilit avec SatIPsec [102]),
lutilisation dun interfaage normalise,
louverture vers le routage bord,

Tout cela suppose de cette architecture la prsence dune couche fdratrice : le niveau 3,
IP, qui constitue une perspective raliste.
4.3. Larchitecture hybride

Les tudes prcdentes ont mis en vidence deux points : des objectifs qui passent par
lintgration dIP, et des besoins architecturaux spcifiques chaque service. La recherche dune
seule architecture permettant dintgrer ces diffrentes architectures de service via un unique
systme est alors llment fondamental de cette tude.
Lanalyse a montr que les besoins des services diffraient en deux grands points : la voie
retour, et la technologie bord du satellite. Lintgration de diffrentes voies retour est possible
dans une seule et mme architecture, grce notamment UDLR [15]. Lintgration de deux
systmes satellite dans une mme architecture est une solution coteuse, impliquant la
multiplication des quipements du ct oprateur comme utilisateur. Pour permettre une
adaptation ces diffrents services nous proposons dintgrer deux charges utiles dans un
systme satellite ; lune transparente, et lautre proposant un OBP.
Larchitecture qualifie dhybride repose sur cette approche, et reste ouverte aux
perspectives technologiques. Cette proposition comporte la description dune architecture
gnrale, viable permettant doffrir aux services un support adapt, sans pour autant rentr dans
les dtails de dimmensionnement.
Cette partie prsente dune part une proposition qui semble faisable et rentable avec les
hypothses actuelles, et dautre part une ouverture vers des volutions futures. Le plan de cette
solution se dcoupe de la manire suivante : la section 4.3.1 propose de jeter les bases de cette
proposition : le systme hybride. La description du maillon physique (le satellite) est labore ici
en prsentant le concept hybride, une proposition et des perspectives. Toujours en suivant une
approche similaire, nous observons ensuite dans la section 4.3.2 les autres entits du systme.
Puis la troisime section (4.4.3) place les diffrents lments de larchitecture protocolaire de cette
solution, tout en gardant une ouverture vers des volutions possibles. Cette partie a un rle
fondamental, celui de faire lintgration entre le niveau IP et le systme hybride. Enfin la section
4.4.4 termine cette proposition.
4.3.1.
Description de la charge utile hybride
Le cur de cette architecture repose sur le maillon satellite. Cest en effet llment central
qui permettra larchitecture de sadapter aux diffrents besoins des services.
93
La section 4.3.1.1 prsente la notion de systme hybride, donnant lieu la section 4.3.1.2 et
4.3.1.3 prsentant respectivement les propositions pour une charge utile transparente et une
charge utile rgnrative, ainsi que les perspectives envisageables. La dernire section (4.3.1.4)
traite alors de lintgration de ces deux charges utiles dans un unique satellite, concluant sur les
consquences au niveau de larchitecture protocolaire.
4.3.1.1.
La notion de systme hybride
Le systme hybride tel quil est envisag ici dfini un systme satellite o cohabitent deux
charges utiles diffrentes : une transparente et une rgnrative.
La charge utile rgnrative du systme peut varier de 0% 100%, et cela en fonction de
plusieurs points : la mise en oeuvre, la matrit des technologies, Ce point comme le
dimensionnement est donc laiss la discrtion du constructeur.
Notre dmarche est ici oriente sur les besoins et la flexibilit. Ce systme reste donc
ouvert, et nous insisterons particulirement sur sa mise en uvre dans un contexte applicatif.
4.3.1.2.
La charge utile transparente
Dans un premier temps nous dcrivons le systme transparent de notre proposition

(4.3.1.2.1) puis nous nous intressons diffrentes perspectives (4.3.1.2.2).
4.3.1.2.1.
LA DESCRIPTION DE LA CHARGE UTILE
La charge transparente du systme hybride est un simple rpteur ou hub spatial. Ce

systme est divis en deux grandes parties, lune rgnrant les signaux DVB-S au niveau
physique et les retransmettant sur toute la couverture, lautre soccupant des signaux DVB-RCS et
les mettant vers un spot resserr sur gateway.
La voie aller est en DVB-S et est compose de ma_t transpondeurs, chacun avec un dbit de
35 45 Mb/s au niveau physique. Pour notre tude nous fixerons un dbit commun par
transpondeur 38 Mb/s.
La voie retour est en DVB-RCS, sparant mr_t transpondeurs de la mme capacit que
prcdemment entre les diffrents RCSTs du systme. Toutefois, pour des raisons de tailles les
RCSTs utilises ne seront pas capables dmettre au-del de 8 Mb/s.
Lutilisation de la bande Ka (27 40 GHz) pour des raisons de saturation de la bande Ku
(12 18 GHz) est choisie pour ce systme. Ce choix apporte une augmentation de lattnuation
du signal, qui sera considr comme une perte de PLR moyen 10-3.
4.3.1.2.2.
DES VOLUTIONS
Le systme transparent offre peu de perspectives dun point de vue systme bord. Il est
toutefois possible damliorer la capacit transparente en intgrant des nouveauts
technologiques.
Une premire volution rside dans lintgration du DVB-S2 [103]. Celui-ci permet
damliorer de manire significative les performances du mdia satellite sur la bande Ka. Cette
perspective implique du systme une modification de la mthode dencapsulation. Si celle-ci reste
compatible avec lutilisation dULE, et utilise toujours des PIDs, la transition vers ce type de
solution nimplique pas de modifications majeures dans larchitecture propose (notamment au
niveau protocolaire), les changements restant majoritairement dordre physique et matriel.
Un autre point est lutilisation du multifaisceaux pour le mode transparent. Celui-ci, sil
nest pas considr dans notre proposition pour une question de cot du systme, est envisager
comme perspective. En fonction de la technologie et dun intrt pour les services, rduire la
couverture en diffrentes zones peut savrer conomiquement intressant. Dans ce cadre,
94
linterconnexion peut se faire soit par une gestion physique bord (transponder hopping), soit par le
passage par des gateways de transition.
4.3.1.3.
La notion dOBP, dans ce travail, est utilise ds quun protocole de niveau 2 apparat
bord du satellite. Cette partie suit la mme dmarche que prcdemment. On notera toutefois que
le systme rgnratif offre beaucoup plus douvertures que la charge utile transparente.
4.3.1.3.1.
LA DESCRIPTION DE LA CHARGE UTILE
Comme pour le systme transparent, la charge utile rgnrative utilise le mme type de
voie aller et de voie retour. On notera cependant ma_r le nombre de transpondeurs sur la voie
aller, mr_r le nombre de transpondeurs sur la voie retour.
Le systme transparent utilise aussi la bande Ka et propose dutiliser la technologie
multifaisceaux, avec n faisceaux descendants comme montants. Dans le cadre de notre systme,
lon pourra envisager des faisceaux couvrant un pays, pour les services nationaux, notamment.
Dun point de vue technologique, nous avons pris en compte ce qui est fait actuellement
les systmes actuels comme le systme AmerHis lanc en aot 2004 [104]. Aussi lintelligence
embarque se propose comme un lment central de larchitecture de niveau liaison, intgrant
commutation bord, multiplexage et signalisation. Le systme rgnratif nintgre donc aucune
fonctionnalit de niveau 3 bord.
4.3.1.3.1.1.
Dans le plan utilisateur
La charge utile rgnrative propose deux fonctionnalits sur le plan utilisateur : du

multiplexage et de linterconnexion des faisceaux via un commutateur.
La premire fonctionnalit consiste multiplexer sur chaque voie descendante les diffrents
flux MPEG-2 TS originaires des voies montante ou de la signalisation.
La seconde utilise la commutation des paquets MPEG-2 TS pour interconnecter les
diffrents faisceaux1 entre eux. Un tel commutateur est capable de grer les communications
points multipoints, comme le broadcast en rpliquant les donnes bord.
Lutilisation dun multiplexage bord implique une relation entre la somme des dbits
montants sur la voie aller et sur la voie retour, et le dbit descendant, parce que les flux DVBRCS sont multiplexs en flux DVB-S. Si on note md_r le nombre de transpondeurs sur la voie,
ds_down le dbit de ce transpondeur, ds_up le dbit dun transpondeur DVB-S sur voie montante et
drcs_up le dbit dun transpondeur DVB-RCS, on a lingalit suivante :
(9)
n ( ma _ r .d s _ up + mr _ r .d rcs _ up ) md _ r .d s _ down ma _ r .d s _ up + mr _ r .d rcs _ up
Cette relation repose sur le fait quil ny a pas de connaissance a priori des types de flux. En
effet si tous les flux sont diffuss sur tous les spots, lingalit de gauche devient une galit, tandis
que pour uniquement des flux unicast, cest celle de droite qui le devient.
La notion de multifaisceaux introduit un coefficient k lien le dbit montant DVB-S et le
dbit descendant sur les spots. Ce coefficient est au maximum gal 1, et est li W, le coefficient
de rutilisation de frquence divis par n, le nombre de spots2 [105]. Ainsi si le nombre de gateways
est assez limit pour permettre au dbit montant DVB-S de rester 38 Mb/s, il nen est pas le cas
1
Si n prend la valeur 1, alors il ny a pas de commutation bord.
n est not Z dans la rfrence.
95
pour drcs_up, ni pour ds_down. Ces deux dbits se voient appliquer un coefficient k par rapport
ds_up. Ce problme reste au niveau du dimensionnement du systme et nest pas abord plus
avant.
4.3.1.3.1.2.
Dans le plan de contrle
Des fonctionnalits dans le plan contrle sont prsentes bord. Une partie de la
signalisation DVB-SI est gnre par le satellite pour les flux descendants (tables de signalisation
sur la voie descendante des flux DVB-S originaires des bursts DVB-RCS). De plus la mise jour
des tables de commutations est aussi effectue bord. Enfin, une gestion de la QoS est mise en
place bord grce au commutateur. Celle-ci prend en compte deux niveaux de priorit. Dautres
fonctions du plan de contrle seront proposes en perspectives.
4.3.1.3.1.3.
Dun point de vue matriel
Les performances de lOBP sont considres comme adaptes aux capacits du systme. Le
dlai introduit est donc faible compar au bond satellite, et est major 1 ms1. Diffrents
lments du processeur bord seront prsents dans la section suivante (cf. 4.3.1.4, Figure 4.9).
Nous en donnons un rsum ici :
le commutateur : il sagit dun commutateur de type circuit, commutant les paquets

MPEG-2 TS en utilisant leurs PIDs. Ce commutateur a un nombre dentres
correspondant au nombre de spots, ajout des entres spcifiques aux gateways (si elles
ne correspondent pas un spot) et une entre spcifique lOBPC et au NCC
(Network Control Center). Pour les sorties, on retrouve une sortie par faisceau, et une
spcifique lentre de lOBPC. Le commutateur possde des tables reconfigurables via
linterface prcite. Il gre la rplication de paquets pour le multicast et le broadcast.
les multiplexeurs qui sont chargs de multiplexer les paquets en sortie du commutateur
avec les tables de signalisation dans un flux unique DVB-S. Ces multiplexeurs font du
bourrage pour remplir le flux MPEG-2 TS quand il ny a rien mettre. Ils sont
capables de faire de la translation de PID si ncessaire.
lOBPC (On-board-Processing Controler) qui a comme tche de grer les mises jour
des tables de commutation, et la gnration de la signalisation. Cest ce niveau que
dautres algorithmes et fonctionnalits peuvent tre implantes.
les dmultiplexeurs qui, partir des signaux bruts, restituent les paquets MPEG-2 TS.
4.3.1.3.2.
DES VOLUTIONS
Le systme rgnratif offre un grand nombre de possibilits dont nous traons les grandes
lignes ici.
4.3.1.3.2.1.
Dans le plan utilisateur
Au-del du multiplexage bord, lOBP peut dsencapsuler et formater les flux montants en
de nouveaux flux descendants. Un exemple de ces techniques a t utilis dans DIPCAST (cf.
3.4.4.4). Dans ce cadre on peut imaginer dmultiplexer les flux MPEG-2 TS pour obtenir les
SNDU (SubNetwork Data Unit), voire les datagrammes IP. Dans le premier cas, des techniques
de commutation de niveau 3 sont alors possibles, cest--dire dextraire des informations de
niveau IP (adresse source, adresse destination) dans les SNDUs pour raliser la commutation. Le
second cas permet de mettre directement en place du routage bord. Le satellite se comporte
alors comme un routeur IP, aiguillant les datagrammes et mettant en uvre un certain nombre de
protocoles de routage et de rsolution dadresse. On peut toutefois noter que si lanne 2003 a vu
1 En 1996, les commutateurs ATM arrivaient majorer ce temps 1.2 ms [106]. Avec les avances techniques
actuelles on peut raisonnablement esprer ce type de performances.
96
son premier routeur dans le ciel [107], le routage bord doit encore faire ses preuves avant de
pouvoir tre considr comme une relle possibilit. Lintrt majeur dun routage bord est alors
une pleine intgration du niveau 3 dans le systme, permettant dallger de manire significative
les tables au sol comme la signalisation, amliorant le temps de rponse du systme et son
interoprabilit, au prix dune charge utile lourde, complexe et coteuse.
Dans ce cadre, certaines recherches vont plus loin, en proposant la mise en place de PEP
TCP bord [83], restant toutefois une perspective, puisque le routage bord nest quun projet
pour le moment.
4.3.1.3.2.2.
Dans le plan de contrle
Dans ce cadre, le systme rgnratif propose dintgrer bord certaines fonctionnalits du

NCC (Network Control Center), voire son intgration complte dans le satellite. Ce centre a pour
rle de grer notamment laccs au systme satellite. Il sera dcrit dans la section 4.3.2.3. Nous
noterons simplement ici que cette intgration permettrait qualitativement damliorer le temps de
rponse du systme en vitant les allers-retours nombreux entre le satellite et cette entit.
Une gestion plus complte de la qualit de service peut tre envisage bord, surtout dans
le cas dun routeur embarqu. La mise en place de services diffrencis ou encore une gestion par
IPsec est alors facilite.
4.3.1.4. Lintgration des deux charges utiles dans le systme

hybride
Aprs avoir dcrit les deux charges utiles et leurs perspectives, leur intgration dans un seul
systme est le sujet de cette partie.
4.3.1.4.1.
LE SYSTME HYBRIDE
Figure 4.9 Stucture de la charge utile hybride
97
Un schma complet du systme hybride est propos dans la figure prcdente (Figure 4.9).
Dun point de vue satellite, les deux charges utiles sont totalement dissocies et il nexiste aucune
interaction entre elles au niveau du satellite. On dfinit alors deux modes, une pour chaque
charge utile. Lon parlera alors de mode transparent pour lutilisation de la charge utile
transparente, et de mode rgnratif pour lutilisation de lOBP.
4.3.1.4.2.
LE PARTAGE ENTRE LES MODES
Le problme du systme hybride nest pas uniquement dans lintgration de deux charges
dans un systme mais aussi dans le choix du mode utilis, et celui-ci seffectue plusieurs
niveaux.
Dans le cadre de cette partie nous nous placerons uniquement au niveau du systme
satellite et donc des signaux quil reoit. Les modes sont clairement indpendants bord, aussi
pour pouvoir les diffrencier, une mthode analogique est indispensable (nous rappelons que le
mode transparent ne gre que des singnaux). Les deux sections suivantes proposent alors une
solution pour les flux DVB-S (4.3.1.4.2.1) et pour les flux DVB-RCS (4.3.1.4.2.2).
Notre objectif ici est de montrer la possibilit dune diffrenciation des deux modes,
dautres mthodes pouvant tre envisages.
4.3.1.4.2.1.
Partage entre les deux modes pour des flux DVB-S
Les flux DVB-S montant sont gnrs par les gateways. Nous proposons une mthode
simple qui consiste diffrencier les flux sur lattribution des frquences. La diffrenciation est
directement faite sur les transpondeurs grce un filtre bord.
La figure ci-dessous (Figure 4.10) illustre par un exemple cette mthode. Le FDMA
(Frequency Division Multiple Access) est ici utilis entre les diffrentes gateways. Le TDMA (Time
Division Multiple Access) peut tre utilis uniquement pour la charge rgnrative. En effet, si du
TDMA tait utilis, le mode transparent devrait remultiplexer les signaux sur le flux descendant,
ce qui nest pas possible sans une charge rgnrative dans ce systme. Dans ce cadre, le schma
ne reprsente pas le TDMA pour ne pas surcharger la figure. Un filtre de frquence est utilis
pour aiguiller les canaux vers la charge utile qui leur est associe. Dans le cas dun flux
transparent, le signal est simplement rgnr et sa frquence dcale. Pour le mode OBP, le
signal est dmodul, les paquets sont commuts et de nouveaux multiplexes descendants sont
forms par spot, venant cohabiter avec les canaux transparents. On ne retrouvera pas alors, sauf
dans de rares exceptions, un multiplexe montant rgnratif sur un flux descendant.
Figure 4.10 mission de deux gateways vers le systme hybride
98
4.3.1.4.2.2.
Partage entre les deux modes pour des bursts DVB-RCS
Lutilisation dun partage frquentiel en fonction des transpondeurs nest pas une solution
adapte au cas DVB-RCS, puisquelle empche un mme RCST dutiliser les deux modes. Dans
ce cas, nous envisageons une diffrentiation des modes en fonction des slots utiliss.
Figure 4.11 mission de RCSTs situes dans des spots diffrents vers le systme hybride
La figure prcdente (Figure 4.11) prsente le partage frquentiel entre mode transparent et
mode rgnratif pour des RCSTs. Comme dans le cadre DVB-S, ce partage se fait en FTMA,
c'est--dire que pour une mme frquence, le mode doit tre soit rgnratif soit transparent.
Toutefois, le flux rgnratif DVB-RCS montant tant incorpor dans le flux rgnratif DVB-S
descendant, il est possible ainsi possible de rutiliser les frquences DVB-RCS sur le lien
descendant.
4.3.1.4.3.
CONCLUSION SUR LINTGRATION DES DEUX CHARGES UTILES
Le systme hybride intgre deux charges utiles, proposant chacune un service propre
qualifi de modes. Nous avons vu dans cette partie que lintgration de ces deux charges utiles
pouvait tre mise en uvre sans souci majeur. Plusieurs lments manquent toutefois cette
proposition, dont les plus notables sont la place des autres entits du systme, le choix des modes
ou encore la gestion des flux IP. Nous traiterons ces points dans la suite de cette partie.
4.3.2.
Description des autres entits du systme hybride
La figure suivante (Figure 4.12) propose une vision globale de larchitecture hybride,
organise autour du satellite. On y notera tout dabord que la notion de multi-spots est trangre au
systme transparent, puisque dans ce mode, tous les terminaux sont regroups sous le mme
faisceau. Cette figure souligne aussi les diffrentes entits qui seront traites dans les sections
suivantes, savoir les gateways (cf. 4.3.2.1), les terminaux (cf. 4.3.2.2), le NCC (cf. 4.3.2.3) et le
MNMC (cf. 4.3.2.4).
99
Figure 4.12 Vision densemble des diffrentes entits spcifique larchitecture hybride
4.3.2.1.
Les gateways
Cette partie dcrit les gateways de larchitecture hybride.

4.3.2.1.1.
POSITION DUNE GATEWAY
Mme si cet lment nest pas reprsent sur la figure ci-dessus par soucis de clart, une
gateway se situe a priori dans un spot. Cette entit est en bordure du systme satellite dans la mesure
o elle est connecte un rseau terrestre.
4.3.2.1.2.
FONCTIONS DEMISSION DUNE GATEWAY
Les gateways sont les centres dmission en DVB-S. En effet elles seules sont habilites
mettre du trafic en DVB-S sur le lien montant, et sont ainsi les gnratrices du lien aller
montant. Elles peuvent mettre en flux transparent ou en flux rgnratif en fonction des
transpondeurs dont elles disposent.
4.3.2.1.3.
FONCTIONS DE RCEPTION DUNE GATEWAY
Les gateways sont les seuls rcepteurs des bursts DVB-RCS utilisant le mode transparent. La
gateway a alors la fonction de faire suivre ce trafic dans un canal DVB-S montant, si ncessaire.
Cest ce qui explique le double bond satellite dans le cas dune interconnexion entre deux RCSTs
via un systme transparent.
Vu sa position la gateway peut aussi recevoir le flux DVB-S transparent (pour les
communications entre gateways) et les flux DVB-S spcifiques un spot (pour les retours en mode
rgnratif et les communications entre gateways).
100
4.3.2.1.4.
FONCTIONS PROTOCOLAIRES
Les gateways sont des entits intgrant des fonctions de niveau 1, 2 et 3. Il sagit donc de
routeurs, passerelles daccs aux rseaux de cur des FAIs, aux fournisseurs de services, et
lInternet plus gnralement.
La gateway doit faire un aiguillage des trafics IP vers le bon mode, il sagit de la mise en place
dun routage qualit de service.
4.3.2.2.
Les terminaux
Ils sont de deux types : les terminaux uniquement rcepteurs (en blanc sur la figure) et les
RCSTs.
4.3.2.2.1.
TERMINAUX RECEPTEURS
Les rcepteurs sont constitus dune antenne parabolique actuellement de 60 cm de

diamtre, lOutdoor Unit, et dun Indoor Unit simple qui peut tre un IRD, ou dans la majeure partie
des cas pour un systme hybride, des modems-routeurs (PEPs) ou des ordinateurs quips de
carte DVB. Ces rcepteurs sont capables de recevoir les flux DVB-S, en traitant en gnral 32
PIDs 1 en simultan.
Pour les rcepteurs, les flux proviennent la fois du mode transparent et du mode
rgnratif, de manire quasi transparente, puisque que seule la frquence permet de dterminer
le mode pour le rcepteur.
4.3.2.2.2.
TERMINAUX RECEPTEURS/METEURS
Les rcepteurs/metteurs, nomms par la norme DVB des RCSTs, sont un type de VSAT
quip dun Outdoor Unit de 80 120 cm de diamtre. LIndoor Unit est toujours un routeur quip
dune carte DVB. Ce routeur peut trs bien tre le terminal de lutilisateur final, dans ce cas il met
aussi en uvre des protocoles de plus haut niveau.
Un RCST met en DVB-RCS en utilisant quelques PIDs. Il est capable dmettre sur les
deux modes, et une slection doit se faire ce niveau. Dun point vue rception, il a les mmes
capacits quun terminal classique (cf. 4.3.2.2.1).
Le RCST peut tre situ en tte de pont dun rseau daccs local, dun rseau priv ou chez
un utilisateur final. Il a des fonctions correspondant aux trois couches basses du modle OSI.
Mais nous verrons plus tard, dans la partie 5 (cf. 5.4.4.2) que des fonctionnalits de niveau
suprieur peuvent tre mises en place de manire garder la transparence du systme tout en
amliorant ses performances.
4.3.2.3.
Le NCC Network Control Centre
Le NCC est lentit de contrle de laccs au systme. Il soccupe de toutes les demandes
dmissions, dallocations de capacit, mais aussi de la distribution des PIDs et de la QoS du
trafic. Cest donc une entit centrale pour le choix du mode.
Le NCC est quip comme une gateway, mais ne soccupe que de la signalisation et du
contrle des flux. Cest donc une entit du plan de contrle. Pour cette raison, le NCC est
communment intgr dans une gateway (surtout lorsquil ny en a quune seule) pour pouvoir
mettre les tables SI directement dans le flux DVB-S. Nous envisageons ce cas ici, tout en
considrant que certaines fonctions du NCC peuvent tre transfres au satellite court terme
(cf. 4.3.1.3.2.2)
Valeur couramment observe dans les spcifications techniques.
101
4.3.2.4.
Le MNMC Mission and Network Management Centre
Le MNMC contrle le systme satellite en terme de position, dalimentations, dtat de la

charge utile, dtats de pertes dues aux perturbations atmosphriques Ce centre est parfois
regroup avec le NCC, et ils ne font alors plus quun. Toutefois dans le cadre du systme hybride,
nous diffrencions ces deux lments.
Le MNMC utilise les liens TM/TC (TeleMetry/TeleCommand) pour communiquer avec le
satellite.
4.3.3.
Description de larchitecture protocolaire
Aprs avoir tudi les diffrents lments constituant le cur de cette architecture, un
point capital reste dfinir : son architecture protocolaire qui montre dune part comment IP est
intgr, et dautre part comment la slection entre les deux modes seffectue.
Pour mieux traiter ces points nous aborderons la structure protocolaire de ce systme
niveau par niveau, en soulignant la relation entre le niveau 2 et 3. Nous traiterons donc ici les
couches 3 et 2, puisque les points intressants du niveau physique ont t traits dans la partie
4.3.1, et que les niveaux suprieurs ne sont pas directement concerns ici.
Cette partie se dcoupe alors en cinq parties : Une premire section (4.3.3.1) prsente
larchitecture protocolaire gnrale, et souligne les points durs traiter. Une deuxime section
(4.3.3.2) aborde le niveau 3, et particulirement le mcanisme de slection des modes. Une
troisime section (4.3.3.3) propose dtudier linteraction entre le niveau 3 et le niveau 2. Une
quatrime section (4.3.3.4) traite le niveau 2, insistant sur la mthode daccs trs lie la
diffrentiation des modes et la rsolution dadresse, des fonctionnalits dpendantes de
linteraction avec le niveau 3. La section 4.3.3.5 propose une vision densemble de la signalisation
des flux IP dans le systme, dun point de vue utilisateur uniquement, en discutant du
multiplexage des flux dans un mme PID. Cette section est alors loccasion douvrir vers la
commutation des SNDUs bord. Enfin, la dernire section (4.3.3.6) conclut les diffrents
lments prsents dans cette partie en proposant une vision densemble de la signalisation des
flux.
4.3.3.1.
Les couches protocolaires
Avant de pouvoir traiter les diffrents lments protocolaires de cette architecture, une
vision densemble est ncessaire, et cest lobjectif de cette partie.
4.3.3.1.1.
VISION DENSEMBLE
Lagencement protocolaire dans le plan utilisateur est prsent dans la figure suivante
(Figure 4.13). Ce schma se veut simple et ne rentre pas dans la reprsentation matrielle sousjacente, notamment le nombre de spots (tude a dj t effectue prcdemment). Le schma
propose un aperu des couches protocolaires dun RCST, dune gateway, et du systme hybride.
Nous ne nous revenons pas ici sur la charge transparente puisquelle ne recouvre que la
premire couche de notre architecture (cf. 4.3.1.2). On rappelle ici quaucune interaction bord
entre les deux charges nest prvue.
La charge utile rgnrative, comme nous lavons vu prcdemment (cf. 4.3.1.3), se
compose dun niveau 1 et 2, mme si on peut envisager plus long terme dintgrer un niveau 3.
Cest le MPEG-2 TS qui est le protocole de niveau liaison et gre la commutation (Figure 4.9). Ce
choix a t fait dans la mesure o cette commutation se prsente comme une manire
duniformiser le niveau 2 sur les systmes DVB, et semble raliste puisquune telle technologie est
tudie par Acaltel Espacio, avec des tests sur le systme IBIS [27], et que le systme AmerHis
[104], lanc rcemment, met en oeuvre un commutateur MPEG-2 TS.
102
Le multiplexage des flux est aussi ralis ce niveau.

On pourra noter lhomognit des couches protocolaires de la charge utile hybride. En
effet lutilisation du MPEG-2 TS pour le DVB-RCS, permet davoir un traitement similaire celui
du DVB-S.
Figure 4.13 Les couches protocolaires de larchitecture hybride dans le plan utilisateur
Pour les gateways comme les RCST, les couches protocolaires sont celles proposes pour
lencapsulation ULE (cf. 3.4.1). Ainsi les piles de protocoles pour ces deux entits sont similaires
sur le plan utilisateur.
Les choix faits ici ont t guids par les diffrents aspects prsents prcdemment,
proposant un systme qui se veut la fois performant et ralisable dans un cadre actuel.
4.3.3.1.2.
LES POINTS DURS
Cette structure gnrale ne pointe pas directement sur les points qui demandent une tude
approfondie, et pourtant un certains nombres de difficults doivent tre releves pour aboutir
une architecture protocolaire parfaitement intgre.
4.3.3.1.2.1.
Niveau 3
Lintgration du niveau 3 dans le systme soulve quelques difficults, essentiellement des

problmes dinteraction entre le niveau 3 et 2 (dcrits dans la section suivante).Toutefois, deux
points importants au niveau 3 sont la slection des modes, et la mise en uvre de multicast IP.
4.3.3.1.2.2.
Interaction entre le niveau 3 et 2
Si lencapsulation propose dans cette architecture ne pose pas de problme

(puisquutilisant ULE), il nen reste pas moins de nombreuses questions quant la rsolution
dadresse, et notamment le lien entre adresse IP, adresse MAC et PID dans un cadre unipoint
comme multipoint. La slection du mode est aussi envisager ce niveau.
4.3.3.1.2.3.
Niveau 2
Lallocation de ressources et la commutation bord sont les deux problmes essentiels

traiter au niveau 2, et le seront dans la section 4.3.3.4.
103
4.3.3.1.3.
CONCLUSION
Un certain nombre de questions poses dans cette partie doivent trouver des solutions
protocolaires. Ces problmes sont majoritairement lis lintgration et la signalisation. Cest en
se concentrant sur ces points que nous proposons de traiter les niveaux 3 et 2 de larchitecture.
4.3.3.2.
Le niveau rseau
Cette section reprend les points durs abord prcdemment, savoir la slection du mode
et le multicast IP, et propose lapproche choisie pour larchitecture hybride.
4.3.3.2.1.
AIGUILLAGE ENTRE LES DEUX MODES DU SYSTME HYBRIDE
Une notion spcifique au systme hybride est laiguillage des flux vers le mode du systme
adapt. Pour une station comme une gateway ou un RCST, la couche de niveau 3, IP, considre les
deux modes du systme hybride comme deux interfaces airs distinctes, avec des caractristiques
diffrentes. Le choix entre ses deux interfaces est alors fait en fonction dune part des besoins des
donnes routes, et dautre part de la source de la donne (plus exactement de son accord pass
avec loprateur du systme).
Il faut toutefois noter que la qualit de service offerte par le lien est connue a priori, il ny a
donc pas besoin dajouter des mcanismes qui permettent de dterminer ltat du lien, puisque
ces informations sont centralises par le NCC. Inform, le routeur est capable dutiliser une
forme de routage qualit de service (aiguillant les flux vers linterface correspondant aux
demandes de lutilisateur et ses droits, mettant en uvre du partage de charge). Dans le cadre
de cette proposition, nous avons choisi dutiliser du marquage de flux. La section 4.3.3.2.1.1
propose une mise en uvre avec lutilisation de tags, la section 4.3.3.2.1.2 prsentent des
ouvertures pour une gestion plus globale de cet aiguillage.
4.3.3.2.1.1.
Les techniques de marquage des flux IP pour le systme
hybride
Dans le cadre du systme hybride, le routage des flux peut prendre en compte diffrents
lments comme ladresse source, ladresse destination ou encore un tag spcifique, indiquant quel
mode utiliser.
Une slection du mode uniquement en fonction de lmetteur restreint ce dernier un
service statique, tandis que laiguillage par adresse destination implique un seul mode possible
entre deux entits de niveaux IP (au moins dans un sens).
Le marquage du flux apparat alors comme une solution plus flexible et moins
contraignante pour les couches suprieures. Cest donc la solution pour laquelle nous avons opt
ici.
Plusieurs possibilits sont alors offertes. Toutefois, il nest pas dans lintrt du systme
hybride de statuer sur une mthode. En effet, cette structure doit pouvoir sintgrer dans un
rseau IP proposant une architecture de QoS plus large chelle. Le satellite hybride peut ainsi
tre incorpor dans un domaine DiffServ [108], chacune de ses gateways et chacun de ses RCSTs
agissant comme un nud DS, soccupant alors de lagrgats de flux. De mme, le systme peut
tre intgr dans un environnement IntServ [109], donnant une garantie de service un nombre
limit de flux. Dans le cadre dune architecture plus vaste, on peut considrer que le systme
propose deux profils de QoS, spcifiques chacun de ses modes.
Dans le cadre dun systme o la qualit de service plus large chelle nest pas prsente,
comme il en est le cas pour notre exemple, ce marquage peut tre ralis en utilisant lancien
champ ToS (Type of Service) des paquets IPv4, ou loctet de classe de trafic pour les paquets
IPv6. Ce champ peut tre rempli directement par lapplication, ou par lanalyse du port source et
destination de len-tte TCP. La solution applicative ne convenant pas notre approche
104
transparente, cest le routage qui soccupe de ce marquage. Son automatisation est envisage par
lutilisation des PEPs intgrant les fonctionnalits de modems routeurs qui utilisent, par exemple,
un noyau Unix, et plus prcisment les fonctions iptables. Ce systme de bote noire permet
alors de ne pas impliquer lutilisateur final dans le processus. Si le client triche sur sa qualit de
service, cest le niveau 2 qui cartera le flux.
Ce marquage est effectu par le premier routeur de bordure habilit de larchitecture. Ce
routeur peut directement tre celui dun FAI ou dun FIS, ou une gateway. Dans le cadre dun
RCST, cest son PEP qui soccupe du marquage.
Comme pour tout routeur IP, des techniques dordonnancement, comme des politiques de
contrle de flux peuvent tre mises en place, avec laide de protocoles tels que RSVP (Resource
reSerVation Protocol) [110].
4.3.3.2.1.2.
Des perspectives pour laiguillage au niveau 3
Dans un cadre similaire, le routeur IP, en plus deffectuer du marquage et du routage

QoS, peut intgrer des fonctionnalits de policing voire de mise en forme des flux, entrant ainsi en
interaction avec les lments de dfinition des contrats et de ladmission au systme. Ainsi le
niveau 3 peut devenir une entit de contrle, vrifiant les droits des diffrents flux et les
dclassant loccasion.
Ces fonctions sont particulirement intressantes quand le routeur daccs au systme nest
pas celui qui gre le marquage des flux, comme il peut en tre le cas pour une gateway, mais sont
prendre avec prudence pour des RCSTs, par soucis de scurit.
4.3.3.2.2.
MULTICAST IP
Dans le cadre de cette partie nous tudierons comment lintgration du multicast IP est
envisage dans cette architecture. La premire section (4.3.3.2.2.1) prsentera le multicast IP dans
cette architecture. Puis la section 4.3.3.2.2.2 proposera dtudier son intrt pour la rplication
bord. Enfin cest avec la section 4.3.3.2.2.3 que nous observerons quelques perspectives de cette
architecture pour le dploiement du multicast IP.
4.3.3.2.2.1.
Le multicast IP sur larchitecture hybride
Le multicast IP est intgr dans larchitecture hybride. Tous les routeurs intrinsquement
dpendants de celle-ci (gateways et RCST) mettent en uvre un protocole de routage multicast IP,
savoir PIM-SM [111], et un protocole de gestion de groupe, IGMP v2 [59]. Ces choix ne sont en
rien exclusifs et sont en grande partie dues aux tudes menes dans le cadre du projet DIPCAST.
Ici, la version 2 dIGMP a t prfre sa troisime version pour la taille de ses messages
qui permet denvisager des techniques de type snooping bord court terme (cf. 3.4.4.6).
Une solution quant au multicast sur cette architecture peut consister observer le rseau
satellite comme un rseau local avec comme routeur de bordure les gateways. Lmission sur le
satellite est alors gre par le protocole IGMP qui permet la gateway de savoir si un lment du
groupe est sur son rseau. Cette solution est nanmoins limite au cas du service Internet et de la
VoD. Dans un service dinterconnexion, IGMP ne suffit pas, et la mise en place dun protocole
de routage multicast est ncessaire.
Il faut noter que les protocoles multicast au niveau IP nimpliquent rien quant aux niveaux
infrieurs. Nanmoins, pour la commutation de niveau 2, un lien doit tre fait avec ces
protocoles.
105
4.3.3.2.2.2.
Le multicast IP et son intrt pour la rplication bord
La prsence de la rplication bord une influence directe sur la mise en oeuvre du

multicast IP.
Sans rplication bord, on peut considrer pour un terminal quelconque, quil dispose en
mode rgnratif de n interfaces, une pour chaque spot. Ainsi pour envoyer vers m spots diffrents
un datagramme, celui-ci doit tre mis m fois par le terminal.
Avec la rplication bord, le systme rgnratif propose une seule interface. Le
datagramme sera envoy une seule fois sur le satellite par le terminal et sera ensuite rpliqu
bord.
La figure suivante (Figure 4.14) permet dillustrer ce propos. La rplication bord permet
une intgration plus naturelle du multicast dans le systme, au prix dune complexit plus grande
au niveau 2. La rplication implique, en effet, lutilisation dune seule interface IP, cest au niveau
2 de savoir vers quels spots aiguiller les flux.
Figure 4.14 Distinction pour le multicast entre un systme avec et sans rplication bord
4.3.3.2.2.3.
Des perspectives pour le dploiement du multicast IP
Un certain nombre de questions se pose quant la mise en uvre des protocoles de

multicast IP sur satellite [112]. Dans ce cadre, des configurations et des adaptations peuvent leur
tre apportes, comme il en a tait dailleurs le cas dans DIPCAST [113]. Pou un systme satellite,
il est en effet prfrable de prserver la bande passante en introduisant des modifications. La
configuration des points de rendez-vous, ou encore lmission sur le lien satellite que lorsquil y a
au moins une source prsente, sont autant doptimisations pour mieux grer la ressource satellite.
Toutefois, ces modifications ne doivent pas intervenir sur le protocole directement, sous
peine de rompre la transparence du systme. ce niveau, les PEPs semblent encore la solution
pour maintenir cette transparence, tout en apportant des optimisations spcifiques au lien
satellite.
4.3.3.3.
Linteraction entre le niveau rseau et le niveau liaison
Ce point joue un rle capital pour lintgration dIP dans larchitecture hybride. Nous
verrons dans cette partie la relation entre laiguillage de niveau 3 et celui de niveau 2 (section
4.3.3.3.1). Aprs quelques mots sur lencapsulation qui ne pose pas de question ici (section
4.3.3.3.2), nous proposerons dobserver la mthode de rsolution dadresse dans la section
4.3.3.3.3, intrinsquement lie laccs au systme, une fonction traite dans le niveau 2.
106
4.3.3.3.1.
RELATION ENTRE LAIGUILLAGE DE NIVEAU 3 ET LE NIVEAU 2
Une fois le marquage effectu au niveau 3, deux mthodes sont alors envisages pour faire
le routage, soit vers une unique interface, en impliquant une rsolution dadresse prenant en
compte le tag, soit lutilisation de deux interfaces distinctes de niveau 2, une pour chaque mode du
systme.
Lutilisation dune rsolution dadresse prenant en compte le tag pose diffrents problmes.
Dune part sa relation avec un marquage spcifique, rend la mthode dpendante du systme.
Aussi un changement de la mthode daiguillage des flux implique une modification des
mcanismes dAR. Dautre part, lAR est dj un point critique dans les systmes IP sur DVB (cf.
3.4.1.3).
La mthode utilise est donc la mise en uvre de plusieurs interfaces, une pour chaque
mode. Cette mthode utilise deux instanciations des couches de niveaux 2 (Figure 4.15).
Figure 4.15 Exemple de relation entre laiguillage de niveau 3 et les couches infrieures pour une
RCST
Pour linterface du mode rgnratif comme transparent, la couche ULE peut vrifier le tag,
pour attribuer une priorit la SNDU, cette priorit sera directement envoye la couche
MPEG-2 TS qui utilisera son bit de priorit pour tous les paquets contenant la SNDU. Toutefois
lutilisation de files diffrentes entre IP et ULE permet de circonscrire cette gestion au niveau 3,
sans impliquer un lien supplmentaire entre ces deux niveaux.
Chaque interface ayant ses propres PIDs, correspondants au mode auquel elle est associe,
la relation se fait naturellement ce niveau. Il existe alors deux niveaux 1 virtuels, utilisant la
mme structure physique. Cette solution nest pas sans rappeler lutilisation des interfaces
virtuelles permettant la mise en uvre de VLANs.
Lattribution des PIDs est alors un lment clef de la rsolution dadresse et de laccs au
systme.
4.3.3.3.2.
ENCAPSULATION DES DATAGRAMMES
Lencapsulation ULE est utilise ici. Nous avons dj prsent ce protocole dans la partie
3.4.1, et nous ne revenons pas dessus ici. Les datagrammes sont encapsuls dans une SNDU en
utilisant un champ optionnel de 6 octets pour une adresse MAC (cf. Figure 3.14 p. 55).
4.3.3.3.3.
RSOLUTION DADRESSE
Un lien doit tre mis en place entre ladressage de niveau 3 et les adressages de niveau 2
(adresse MAC et PID). Cest ce que nous entendons ici par le terme rsolution dadresse (AR).
107
LAR est une tche dlicate sur satellite. Au cur des dbats actuels en particulier dans le
cadre du groupe de travail IP sur DVB, sa normalisation semble poser problme. Larchitecture
hybride nchappe pas cela, ajoutant mme des questions particulires la slection entre ses
deux modes.
Dans notre cadre la rsolution dadresse se rsume trois points centraux :
la correspondance entre PID, MAC et adresse IP ;
la mthode de rsolution, proprement parler (protocole spcifique, gnral (ARP) ou

mthode statique) ;
la correspondance avec les deux modes du systme.

Cette tude suivra alors cette dmarche. Dans un premier temps nous discuterons sur les
diffrents choix quant la correspondance dadressage (4.3.3.3.3.1). Puis nous observerons la
solution propose ici (4.3.3.3.3.2). Dans un troisime temps nous proposerons la mthode dAR
utilise pour les adresses MAC (4.3.3.3.3.3) et pour les PIDs (4.3.3.3.3.4). Enfin nous conclurons
avec le lien avec les deux modes du systme (4.3.3.3.3.5).
4.3.3.3.3.1.
Les choix de la correspondance entre PID, adresse MAC et
adresse IP
Notre solution utilise le protocole ULE. Avant de choisir dutiliser le champ MAC
optionnel, nous devons nous interroger sur lintrt dintgrer un tel champ. La rponse dpend
principalement de deux critres : dune part la technologie de commutation, et dautre part le
nombre dutilisateurs du systme.
Dans notre cas la commutation est faite sur les courts paquets MPEG-2 TS. Il nest alors
pas possible davoir accs pour chaque paquet ladresse MAC bord, puisque les SNDUs sont
fragmentes. Il nest pas non plus question dajouter au paquet MPEG-2 TS de loverhead avec un
champ dadaptation supplmentaire. Les PIDs sont la seule information disponible ce niveau.
Ladresse MAC peut paratre inutile dans ce cas, mais cest sans prendre en compte le
nombre dutilisateurs. Sans chercher dimensionner le systme hybride, lutilisation du seul PID
comme seul identifiant de niveau 2 peut poser deux limites pour un nombre dutilisateurs
important. Dune part, il devient vite impossible dattribuer un PID par destinataire dans la
mesure o la signalisation DVB en utilise dj un grand nombre. Dautre part, les PIDs sont plus
reprsentatifs dune source que dun rcepteur, puisque deux sources ne peuvent mettre
directement avec le mme PID vers un mme destinataire en mme temps. En effet, le
destinataire ne peut pas diffrencier les flux dans ce cas, et reconstituer les SNDUs.
Lutilisation dune adresse MAC permet alors dutiliser un PID par source, par mode et par
spot, sans introduire la notion spcifique de destinataire. Ladresse MAC permet alors de faire le
lien avec le destinataire.
4.3.3.3.3.2.
La correspondance entre PID, adresse MAC et adresse IP
Dans le cadre de cette architecture, nous avons opt pour une attribution de ladresse MAC
en fonction de ladresse destinataire, dans le cadre des flux unipoint, et de ladresse de groupe
dans le cadre multipoint.
Les PIDs sont spcifiques la fois un mode, une source et, dans le seul cadre du mode
rgnratif, un groupe de faisceaux utilis bord (1 seul spot pour le mode unipoint, plusieurs
spots pour la diffusion et le multipoint).
Cette solution permet dviter lutilisation des PIDs seuls qui peut soit ne pas supporter le
passage lchelle, soit engendrer un travail important de la couche IP pour carter les paquets
dont elle nest pas destinataire.
108
Le rcepteur peut donc faire un premier filtrage au niveau PID, puis vrifier quil est bien le
destinataire avec ladresse MAC. Un dernier filtrage est toujours fait au niveau IP, dans la mesure
o ladresse une MAC multicast peut correspondre plusieurs adresses IP multicast.
4.3.3.3.3.3.
Les mcanismes mis en place pour la rsolution dadresse
pour les adresses MAC
Plusieurs types de mcanismes existent pour la mise en uvre de lAR : des solutions
statiques, et des solutions dynamiques. On peut envisager dutiliser une rsolution dynamique
pour les adresses MAC, de type ARP. Toutefois, de tels mcanismes prennent un temps non
ngligeable sur un systme satellite (Tableau III), et il serait dommage de ne pas prendre en
compte lavantage dun systme satellite : la distribution des adresses IP est effectue par les FAIs
grant le systme, ou par loprateur satellite lui-mme. Dans ce cadre tous les quipements ayant
un accs direct au satellite ont t configurs par une seule entit.
Tableau III. DLAI DALLER RETOUR DUNE REQUTE DE TYPE ARP SUR UN SYSTME HYBRIDE
Pour les adresses MAC unipoints, deux mcanismes sont alors envisageables :
Un mapping entre ladresse IP et ladresse MAC. Par une simple translation toute gateway
ou RCST peut trouver ladresse MAC correspondant ladresse IP destinataire.
Une table de correspondance centralise au niveau du NCC, faisant la correspondance

entre adresse IP et adresse MAC. Pour les gateways, une image de cette table est
disponible. Pour les RCSTs, chaque demande de nouvelles missions, lmetteur, sil
ne connat pas ladresse MAC de la cible peut demander celle-ci au NCC, via un
message de type priv, ou cette table peut tre mise sa disposition, via une mission
priodique du NCC.
Nous avons choisi la premire mthode pour notre systme, dans la mesure o les adresses
MAC peuvent tre configures pour les cartes ULE/DVB. Dans le cas contraire, la seconde
mthode sera utilise.
Pour les adresses MAC multipoints, le mapping de ladresse du groupe IP multicast permet
dobtenir ladresse MAC multicast correspondante (Figure 4.16).
Figure 4.16 Mapping dune adresse IP multicast sur une adresse MAC
109
4.3.3.3.3.4.
Les mcanismes pour la rsolution dadresse pour les PIDs
Deux mcanismes sont ncessaires pour la rsolution dadresse au niveau des PIDs :
un mcanisme pour que la source sache quel PID utiliser pour mettre son flux ;
un mcanisme pour que le rcepteur sache quel PID couter pour recevoir le flux qui
lui est destin.
Le premier mcanisme est diffrent selon quil sagisse dune gateway, ou dun RCST.
Dans le cas dune gateway, les PIDs sont attribus a priori. La gateway a alors un ple de PIDs
attribu par IN (Interactive Network). Ce ple est constitu de :
un nombre limit de PIDs1 pour le mode transparent. Ces PIDs peuvent mme tre
rutiliss sur les autres transpondeurs, transparent comme rgnratif (mais une seule
fois sur tous les transpondeurs rgnratifs) ;
n PIDs pour les flux unipoints en mode rgnratif (n est le nombre de spots) ;
4n PIDs pour les flux multipoints en mode rgnratif, il faut noter que si cela ne
permet pas de traiter toutes les possibilits, une allocation de PIDs supplmentaires
peut tre faite par demande auprs du NCC.
Les PIDs sont utiliss au grs du service en mode transparent. Pour les flux rgnratifs,
chaque PID est utilis en fonction des faisceaux utiliss. Cette correspondance est obtenue
directement par un adressage judicieux du prochain hop, chaque adresse IP contenant
linformation sur le faisceau dans lequel le destinataire se situe. Pour le multicast, la table de
routage doit garder jour les diffrents routeurs qui ont rejoint larbre multicast. Avec ses adresses,
la gateway est capable de faire la relation.
Dans le cas dun RCST, les PIDs peuvent tre distribus la demande dallocation de
ressource par la table TBTP mise par le NCC sur le flux aller DVB-S. En mode transparent un
RCS aura un seul PID pour tout son trafic transparent (le partage de la ressource entre les
diffrents flux transparents est donc gre par le RCST). En mode rgnratif, les PIDs sont
toujours attribus par le NCC dans la TBTP, mais ces derniers correspondent une destination
prcise. Ces lments sont stocks dans une table, comme lexemple suivant (Tableau IV).
Tableau IV. EXEMPLE DE TABLE DE CORRESPONDANCE DUN RCST
Il faut toutefois noter que la table TBTP na pas t faite pour corrler des slots un PID.
En revanche la norme propose avec le Channel_ID une alternative quil conviendra danalyser
plus en dtail dans de futurs travaux. Cette partie reste malgr tout un problme ouvert pour
lheure.
1 Un seul PID peut tout fait convenir, facilitant lagrgation de flux et donc rduisant la signalisation SI.
Toutefois un seul PID risque dinduire un travail notable pour les rcepteurs. On lui prfrera 10 20 PIDs en
fonction du nombre de transpondeurs.
110
Le second mcanisme, consistant informer les rcepteurs des PIDs quils doivent couter,
utilise les tables INT prcdemment expos (cf. 3.2.2.3). Ces tables sont gnrs soit directement
par les gateways (pour la voie aller), soit par le NCC en fonction des demandes daccs.
4.3.3.3.3.5.
Le lien entre la rsolution dadresse et le choix des modes
Dun point de vue aller, ce lien na pas lieu dtre puisque linterface choisie par le niveau 3
conduit vers des transpondeurs dun mode ou de lautre. Cest dailleurs pour cette raison quun
mme PID peut tre utilis sur lun et lautre.
Dans le cadre de la voie retour, ce lien est fait par le PID. En fonction du PID attribu au
flux donn par la table TBTP, le RCST sait o mettre ses bursts, respectant ainsi le partage de
frquence propos dans la section 4.3.1.4.2.2.
4.3.3.4.
Le niveau 2
Ltude du lien entre le niveau 3 et 2 a permis de montrer le lien troit entre la rsolution
dadresse et lallocation de ressources. Cette partie permet de conclure sur la signalisation du
systme en reprenant le niveau 2 dj pleinement abord dans la partie prcdente.
Nous traiterons ici laccs au systme (4.3.3.4.1) et la commutation bord (4.3.3.4.2).
4.3.3.4.1.
MTHODE DACCS
Laccs au systme comprend deux parties intrinsquement lies : dune part la mthode
daccs proprement parler et dautre part la diffrentiation entre les flux de mode transparent et
de mode rgnratif. Nous avons dj trait ce dernier point dans les parties prcdentes et nous
traitons donc ici le point de la mthode daccs en deux points : au niveau des gateways dans la
section 4.3.3.4.1.1 et au niveau des RCST dans la section 4.3.3.4.1.2.
Avant de commencer cette description, notons quune tude des techniques daccs reste
hors du cadre de ce travail. Nous ne proposons pas ici de nous interroger sur les mcanismes
daccs eux-mmes, mais sur les fonctionnalits qui y sont mis en uvre. Les mthodes daccs
restent spcifiques au systme et aux besoins de celui-ci, apportant un niveau de dtail non
souhait ici puisque notre analyse se situe dans un cadre de normalisation, et non de maquettage.
4.3.3.4.1.1.
Laccs au systme des gateways
Laccs au niveau des gateways se fait en deux points :
Les flux IP sont grs au niveau 3 en fonction des SLAs (Service Level Agreements), et
de la bande passante loue. Il sagit souvent dun simple contrle par linterface du flux
rentrant, le trafic tant trait par les FAIs et les FISs auparavant. Les flux IP sont traits
au pralable par le FAI, ou le FSI.
Laccs au niveau 2 na pas besoin de demandes dallocations puisque la gateway a

lexclusivit de lmission sur des transpondeurs spcifiques. Le partage de la ressource
se fait donc par transpondeur au niveau de la gateway.
Nous rappelons que chaque multiplexe correspond un seul mode, le choix est donc fait
au niveau de linterface IP utilise et non pas au niveau de laccs.
Le niveau accs peut alors vrifier la validit du droit dmission dun flux, la qualit de
service du flux. Si cela ne correspond pas le flux est soit supprim, soit dclass. Ces
fonctionnalits peuvent cependant tre ralises au niveau 3, tant alors facilites par
lintroduction de QoS au niveau IP dans larchitecture.
111
4.3.3.4.1.2.
Laccs au systme des RCSTs
Les RCSTs accdent au multiple DVB-RCS via la mthode prsente dans la section 2.4.4.
Que lmission se fasse par CAC ou par DAMA, ou quelle que soit la rservation de flux choisie,
laccs au systme se fait en quatre tapes :
Le RCST vrifie selon un SLA donn que le flux a bien le droit dmettre,
Le RCST envoie une demande dallocation de ressources au NCC via sur un canal
contention spcifique ces demandes (les bursts SYNC). Cette demande nest pas la
mme en mode transparent et en mode rgnratif. En effet dans ce premier cas, il ny
a pas lieu de prciser la destination, puisque les donnes iront la gateway alors que dans
le second cas, la destination a une influence sur le PID utilis et la commutation bord.
Cette demande peut tre de diffrents types : CRA (Continuous Rate Assignment),
FCA (Free Capacity Assignment), RBDC (Rate-Based Dynamic Capacity) et VBDC
(Volume-Based Dynamic Capacity) [114].
Le NCC analyse les demandes des diffrentes RCSTs et attribuent un nombre de slots
spcifique ce flux. Cette affectation est plus dlicate calculer dans le cas rgnratif
car les capacits sur chaque faisceau montant et descendant doivent tre prises en
compte1. Cette information est vhicule dans la table TBTP o un PID est associ
linformation dun slot dans notre cas. Si la table TBTP ne vhicule une information sur
le PID associ chaque slot, une table prive peut tre utilise par le NCC pour faire la
correspondance entre PID et flux mettre.
Le RCST reoit cette table. Grce elle il est capable dmettre son flux dans les slots
correspondants avec le PID associ.
On peut noter dans cette mthode que, dans le cadre transparent uniquement, le PID
associ au flux est toujours le mme. Le lien entre slots et PIDs na pas vritablement lieu dtre.
Dans ce cas, le PID peut tre distribu une fois pour toute en phase de logon du terminal, comme
spcifi dans [16]. Lattribution des PIDs transparents est donc effectue par le NCC via les logon
initialize descriptors.
4.3.3.4.2.
GESTION DE LA COMMUTATION BORD
Le dernier point traiter ici est la commutation bord. Aprs la description densemble faite
en 4.3.3.4.2.1, nous observerons comment la table de commutation est mise jour dans le cadre
unipoint (4.3.3.4.2.2) puis dans le cadre multipoint (4.3.3.4.2.3). Enfin nous conclurons sur les
volutions ventuelles de cette commutation et sur son influence trs importante sur la gestion
des PIDs et des adresses MAC (4.3.3.4.2.4).
4.3.3.4.2.1.
Une vision densemble de la commutation bord
Le commutateur de la charge utile rgnrative permet dagir directement sur les paquets
MPEG-2 TS, commutant en fonction du PID et du port de celui-ci. Les PIDs tant reprsentatifs
dun canal logique, la commutation utilise une table pour savoir sur quel(s) faisceau(x) envoyer les
donnes. Il sagit donc dune mthode de type label switching. Le commutateur est lui-mme
capable de rpliquer les paquets vers diffrents spots de sorties pour permettre le multicast de
niveau 2.
Nous avons dj observ que dans une architecture proposant des services comme laccs
Internet ou de la VoD, la topologie du rseau a une forte tendance au changement. Ce
dynamisme implique la mise jour de la table de commutation embarque. Ce problme est
1 Pour une allocation de type FCA, nous nutiliserons pas pour un mme slot une allocation plusieurs RCST
via contention. Ainsi on peut associer un PID ces slots.
112
comparable celui de la configuration dun commutateur de niveau 2 (de type ethernet) utilis
dans le cadre de communication IP unipoint et multipoint dans un environnement terrestre. On
peut donc considrer les solutions envisages pour le cas terrestre :
lauto-apprentissage par analyse du trafic,
la dfinition dun protocole spcifique.

Cependant, comme dans le cas DIPCAST prcdemment tudi (cf. 3.4.4.6), lautoapprentissage nest pas une solution envisageable ici, puisque les paquets commuts sont de trop
courtes pour permettre le snooping.
Il semble donc plus raliste d'envisager une solution reposant sur un protocole spcifique
comme CGMP [56] ou SMAP [113]. Un protocole de mise jour de la table de commutation est
donc utilis par le NCC. Il sagit alors pour chaque source de trafic, unipoint comme multipoint,
de transmettre le port dentre (correspondant au spot de la source), le PID du flux et les ports de
sortie (correspondant aux spots descendants). Ce protocole interagit avec lOBPC via un port de
sortie privilgi du commutateur. LOBPC peut utiliser un port dentre spcifique pour envoyer
de la signalisation vers les diffrents faisceaux du systme (Erreur ! Source du renvoi
introuvable.). Celui-ci peut tre utilis pour reconfigurer toute la table dans le cas dun
changement majeur de topologie.
4.3.3.4.2.2.
La mise jour des tables de commutation pour lunipoint
Pour la voie aller, les PIDs des flux unipoints sont tous prdfinis (cf. 4.3.3.3.3.2), la table
de commutation est donc fixe est na pas besoin dtre mise jour.
Pour la voie retour, le PID est attribu au flux par le NCC. ce niveau, le NCC met jour
la table de commutation bord, si besoin, en mme temps quil attribue ce PID en utilisant un
protocole priv (tel celui SMAP, propos dans DIPCAST par lINRIA).
4.3.3.4.2.3.
La mise jour des tables de commutation pour le multipoint
Pour la voie aller, comme la voie retour, les flux multicast demandent une gestion
dynamique de la table de commutation bord.
Un unique PID est utilis par groupe multicast. En effet si le mme PID est utilis pour
deux groupes diffrents qui alimentent les mmes spots un instant donn, et en provenance
dune mme gateway ou dun mme terminal, le rajout de la desserte dun nouveau faisceau pour
un de ses groupes, implique une rattribution de PID, et une mise jour de la table de
commutation. Nous prfrons limiter les modifications entranes la seule mise jour de la
table de commutation.
Dans le cadre dune source place dernire une gateway, lattribution du PID pour ce flux,
la gateway connat les diffrentes adresses des prochains noeuds sur le lien satellite, et peut donc
faire la correspondance entre ceux-ci et les faisceaux concerns. La gateway envoie alors un
message au NCC via un protocole priv, qui va elle-mme mettre jour la table de commutation.
Quant un nouveau noeud rejoint larbre multicast, la gateway vrifie grce ladresse de ce nud si
le faisceau de ce dernier est dj desservi. Si cest le cas, aucun changement nest effectu, sinon,
une demande de modification de la table de commutation est envoye au NCC.
Pour une source place derrire un RCST, cest au moment de lallocation de ressources
que le NCC configure la table de commutation. Lajout dun nud larbre dans un spot nouveau
entrane une demande de ressource sur ce spot, et le NCC met alors jour la table de
commutation.
4.3.3.4.2.4.
Des perspectives
La norme DVB-S2 est une volution probable du systme satellite (cf. 4.3.1.2.2). Or DVBS2 utilise des conteneurs de niveau 2 de taille plus importantes que les paquets MPEG-2 TS du
113
DVB-S. Un datagramme IP a alors peu de chance dtre fragment, permettant la mise en uvre
de mthodes dauto-apprentissage bord, comme celles voques dans la partie 3.4.4.6.
Une autre perspective est lintgration dune intelligence bord plus volue, capable de
rassembler les SNDUs pour les commuter en fonction des adresses MAC. Cette solution
propose un gain important en terme de signalisation, notamment au niveau du multiplexage de
diffrents flux IP dans un mme PID, et est au cur de la partie suivante.
4.3.3.5.
Le multiplexage des flux
La signalisation propre aux flux, cest--dire dans le plan utilisateur, a t dcrite au cours
de cette partie. Nous proposons toutefois de revenir ici sur ce point pour, dune part, avoir une
vision globale de larchitecture protocolaire et, dautre part, introduire la notion dagrgation de
flux, cest--dire lutilisation dun seul PID et/ou dune seule adresse MAC pour plusieurs flux de
niveau IP. Il sagit l dune notion de multiplexage qui peut avoir son intrt dans la mesure o les
PIDs sont cods sur 13 bits, et ne permettent pas toujours une unique association point point.
Cette partie propose danalyser ce multiplexage pour larchitecture hybride dans la section
4.3.3.5.1, puis daborder les perspectives offertes notamment par la commutation au niveau des
SNDUs (4.3.3.5.2).
4.3.3.5.1.
CAS DE LARCHITECTURE PROPOSE
Aprs avoir trait les diffrentes couches protocolaires, une vision densemble des flux
transitant sur le systme est donne dans cette partie. Dans ce cadre nous considrerons la
topologie prsente dans la figure ci-dessous (Figure 4.17). Ici, nous avons deux sources de flux
A, et F. A met en mode rgnratif vers B, vers C, vers D et vers le groupe M, et en mode
transparent vers C, vers E et vers F. F met en mode rgnratif vers B et D, et en mode
transparent vers A et C.
Figure 4.17 Topologie dtude du traitement des flux IP sur larchitecture hybride
Dans le cadre larchitecture hybride, les flux mis par A et F sont reprsents dans la figure
ci-dessous (Figure 4.18). On y remarque quune source en mode transparent utilise toujours le
mme PID, alors quen mode rgnratif le PID utilis correspond la source et au spot cible (cf.
4.3.3.3.3.2). Le multiplexage agrge alors tous les flux unicast transparents dune mme source
dans un seul PID, tandis que cet agrgat se fait en fonction de la source et du faisceau cible pour
le cas de lunicast rgnratif.
114
Figure 4.18 Organisation des diffrents flux sur le lien montant en provenance de A et de F
Sur le spot 2 descendant, les flux engendrs par ces deux sources sont reprsents cidessous. Ici on notera une diffrence entre le mode rgnratif et transparent. Dans le cadre de
notre architecture les flux doivent tre imprativement diffrencis si ils proviennent de
terminaux diffrents, par des PIDs diffrents. Ainsi le flux destination de D se retrouve dans
deux PIDs rgnratifs diffrents, lun provenant de A, lautre de F. En revanche, dans le cas
transparent1, la gateway mettrice de transition dsencapsule les donnes jusquau niveau 3. Les
datagrammes sont ensuite multiplexs sur la mme interface, utilisant alors la mme adresse
MAC, puis le mme PID. Cest au niveau 3 de C de diffrencier les flux
Figure 4.19 Organisation des diffrents flux sur le spot 2 descendant en provenance de A et de F
4.3.3.5.2.
PERSPECTIVES
Une solution permettant de multiplexer les flux descendants rgnratifs sur des PIDs
identiques est lintgration dune commutation bord au niveau MAC.
La prsence dune commutation bord au niveau MAC change le multiplexe rgnratif du
spot 2. Parce que les adresses MAC sont utilises bord, le flux doit tre encapsul nouveau sur
chaque spot (notamment ici sur le spot 2). Dans ce cadre, toutes les donnes dun mme IN
1 Cet exemple prend comme hypothse que les flux DVB-RCS transparents en provenance de A et F utilisent
la mme gateway.
115
peuvent tre multiplexer dans le mme canal logique (utilisant donc le mme PID). Les flux sont
alors diffrenci au au niveau MAC, puis au niveau 3, comme lillustre la figure suivante (Figure
4.20).
Figure 4.20 Organisation des diffrents flux rgnratifs sur le spot 2 descendant en provenance
de A et de F dans le cadre dune commutation MAC bord
Cette perspective, en plus de permettre une meilleure gestion de la commutation bord,

offre une rduction du nombre de PIDs utiliss, permettant larchitecture hybride de pouvoir
supporter un trs grand nombre de flux.
Dautres perspectives sont aussi envisageables dans ce cadre, comme le routage bord,
permettant aussi dallger la signalisation de niveau 2, dallger les tables de routage au sol, etc
4.3.3.6.
Conclusion sur larchitecture protocolaire
Au cours de cette partie nous avons propos une architecture protocolaire utilisant la
couche IP comme un niveau unificateur et intgrateur. Larchitecture envisage ici offre un grand
nombre de perspectives. Dune part, le niveau IP sest en effet rvl comme un fort lment
dintgration dans les rseaux, permettant dassurer une relative prennit larchitecture quant
son adquation aux protocoles futurs. Dautre part, cette proposition a mis en valeur des
techniques pouvant apporter des solutions protocolaires adaptes. Dans ce dernier cadre, nous
avons remarqu les PEPS qui proposent disoler de manire transparente le systme satellite pour
optimiser les mcanismes qui y sont dploys. Une autre opportunit est fonde sur lintgration
dune intelligence bord permettant un traitement plus volu, comme une commutation
directement au niveau des adresses MAC, ou mieux un routage bord.
Larchitecture hybride se positionne avec sa structure protocolaire comme un systme
ouvert pouvant supporter IP et donc tout ce quil intgre.
4.4. Conclusion
Nous avons vu dans ce chapitre que chaque service a des besoins prcis, qui peuvent mme
varis au sein dun mme service. Une classification gros grains de ces besoins a t effectue
dans ce cadre (Tableau II). Fort de cette analyse, lide dun systme hybride, cest--dire intgrant
deux charges utiles dans un mme systme satellite, est apporte comme rponse ces diffrents
besoins. Le concept darchitecture hybride est alors propos pour rpondre ces demandes.
Nous avons dessin cette solution en dfinissant les diffrentes entits du systme, leurs
fonctions, et la mise en uvre protocolaire. Mme si des dtails de dploiement comme de
dimensionnement ne sont pas abords ici, cette architecture est envisageable dans ltat actuel des
technologies. Lintgration des diffrents services sur cette architecture dcoule alors
naturellement, puisque le concept a t construit autour des diffrents besoins, mettant en avant
sa flexibilit.
Ainsi lon peut proposer une intgration avec une seule et mme architecture. La figure cidessous (Figure 4.21) propose un exemple titre illustratif. Le schma dcoupe le cadre de
116
larchitecture en deux zones distinctes : une zone dite urbaine o linfrastructure terrestre est trs
dveloppe, et une zone dite isole parce que la connexion terrestre maximale est une liaison par
RTC classique. Cette architecture propose alors un support pour :
Laccs Internet dans les zones isoles uniquement. Celui-ci est de type traditionnel
pour la majorit des utilisateurs privs, utilisant alors le mode transparent et un lien
retour terrestre. Un utilisateur sans voie retour terrestre accessible, peut aussi squiper
dun terminal metteur. Enfin des regroupements dutilisateurs autour dun RCST,
comme des villages par exemple, peuvent obtenir laccs Internet via le systme, en
utilisant un rseau local de type Wifi. Ce type de rseaux utilise prfrentiellement le
mode transparent.
Des services de VoD utilisent le systme pour fournir des mdia aux rgions isoles
comme urbaines. Ainsi des rseaux locaux urbains (htels, hpitaux, ) comme des
utilisateurs privs reoivent la VoD moindre cot en utilisant une simple parabole. Ils
peuvent utiliser par exemple une connexion Internet indpendante pour commander le
mdia quil dsire. La VoD se couple naturellement avec les accs Internet via satellite,
et peuvent mme sassocier un fournisseur daccs pour offrir des services de caches
locaux, comme dans le cadre de la topologie 4 (cf. 4.1.1.3.4). Les modes du systme
utilis dpendent fortement de la demande des utilisateurs comme le montre le tableau
suivant (Tableau V).
Tableau V. DPENDANCE ENTRE LES REQUTES VOD POUR UN MDIA ET LE MODE DU SYSTME
Linterconnexion entre des rseaux privs reste un service fortement intress par le
systme satellite. Linterconnexion seffectue via RCST, et utilise le mode transparent
communment, le mode rgnratif tant rserv aux applications telles que la vido
confrence ou le tlphone dentreprise. Ainsi dans le cadre dune application de cours
distance, la plus grande partie des donnes comme les documents de cours et la
prsentation prenregistre, utilise le mode transparent et est stocke lavance dans
des caches au niveau de chaque rseau participant. Pendant la session, des donnes
faible dbit vont tre changes (le scnario de la prsentation), mais avec la garantie
dune faible gigue, le mode rgnratif est alors utilis. De mme les interventions
actives des diffrents lves avec le formateur requirent un faible RTT et passent
donc par le mode rgnratif.
117
Figure 4.21 Exemple dintgration de services dans une architecture hybride
Une telle architecture prsente donc les aspects requis pour intgrer diffrents services,
allant jusqu sadapter aux diffrents flux dune mme application. Nous avons trac ici les traits
fondamentaux du principe hybride, prsentant un exemple de systme avec une vision assez
large. Cet exemple reprsentatif de la notion hybride ouvre la voie lvaluation dune
architecture hybride, objet du prochain chapitre.
118
119
CHAPITRE 5. VALUATION DE LARCHITECTURE HYBRIDE
5. EVALUATION DE LARCHITECTURE
HYBRIDE
Cette tude a, dans les parties prcdentes, soulign les diffrentes problmatiques du
dploiement dIP sur satellite. Il a t montr quelles taient les limites et quels taient les moyens
technologiques et protocolaires pour y parvenir. Toutefois, un point important a t soulev, le
manque dune architecture globale et flexible, capable de faire le lien entre les systmes actuels et
venir pour intgrer diffrents services porteurs. Nous avons montr que lutilisation dune
charge hybride comme support dintgration pouvait tre une solution. La partie prcdente sest
donc centre sur la description du concept darchitecture hybride, et la proposition dune
architecture mettant en application les principes exposs.
Il est maintenant ncessaire dvaluer cette proposition, cest--dire danalyser en quoi elle
rpond aux besoins des diffrentes applications, et les apports quelle propose par rapport des
systmes plus classiques. Cette architecture ne saurait, en effet, tre complte sans une validation
de son fonctionnement, notamment avec les trois services dont elle se propose dtre le support.
Notre choix pour ltude de cette architecture sest port sur loutil mathmatique et les
simulations. En effet, dans le cadre du projet DIPCAST, un maquettage a t ralis permettant
dmuler le comportement du systme DIPCAST et de valider certains lments de notre travail,
tel que la signalisation.
Lanalyse du systme hybride suit naturellement la dichotomie entre les systmes
rgnratif et transparent, puisquun de ses points forts est la flexibilit offerte par la coexistence
de ces deux modes et la possibilit de choisir pour chaque type de trafic celui qui permet les
meilleurs performances. Nous prsenterons cependant cette analyse conformment une
dcomposition plus traditionnelle en couches pour les raisons suivantes :
Il sagit bien dune architecture globale, et non simplement de la cohabitation de deux

sous-systmes, dont lanalyse individuelle ne permettrait pas denvisager leur
interaction.
Seule une analyse en couches permet de mettre clairement en vidence les points
communs de larchitecture globale utiliss par les deux sous-systmes, mais aussi les
diffrences.
Ce chapitre est donc structur comme suit.
Nous dcrivons dans la section 5.1 les caractristiques importantes de la couche physique.
La modlisation des erreurs fait presque exclusivement lobjet de cette tude. Le but de nos
travaux est en effet de dfinir une architecture reposant sur des technologies existantes, et non
den proposer de nouvelles.
La seconde partie abordera le niveau deux de notre architecture. Aprs avoir discut en
5.2.1 du temps daccs au mdia et de notre position quant son impact sur le systme, cette
partie reposera sur la question centrale du poids de la signalisation du systme hybride. On peut
en effet craindre que la prsence de deux charges bord nengendre une surcharge de
signalisation. Dans ce cadre, la section 5.2.2 offrira une tude de lencapsulation mise en place ici,
compare des encapsulations plus classiques. Dans 5.2.3, ltude de la signalisation des flux IP
sur le systme sera mene. La section 5.2.4 proposera dobserver le temps de rponse de notre
architecture, en fonction de la rpartition bord/sol de certaines fonctionnalits. Enfin, la dernire
120
partie (5.2.5) fera le point sur la signalisation, observant que cette architecture ne propose pas une
solution plus lourde quune autre, dans la mesure o un soin important a t port sur ce point
dans la partie 4.3 de notre tude.
La partie 5.3 sera alors consacre au niveau 3. Nous montrerons comment IP peut sinsrer
naturellement dans une telle architecture et en devenir un maillon central. Cest notamment sa
prsence au cur de larchitecture qui dote celle-ci dune cohrence globale et dune certaine
prennit vis--vis des volutions technologiques.
Nous consacrerons alors la fin de cette tude aux trois services prcdemment prsents.
Chaque service donnera lieu une comparaison des performances dun systme transparent face
celles dun systme rgnratif, concluant sur comment une architecture hybride peut permettre
la meilleure optimisation (et donc intgration) de ces services grce la flexibilit quoffre
lalternative entre les deux modes.
Ainsi la section 5.4 analysera le service daccs Internet sur satellite, et son lien critique avec
le protocole TCP. Dans un premier temps, aprs quelques mots sur la modlisation du trafic
Internet (5.4.1), nous montrerons quun satellite intgrant IP peut se rvler un mdium plus
performant quun lien bas dbit terrestre. Ainsi les performances des satellites seront tudies
dans le cadre dapplications web classiques (5.4.2), et dapplications plus symtriques (5.4.3). Dans
les deux cas, nous pourrons observer que, outre lapport du systme hybride en tant que support
dIP, son intrt est directement li lutilisation du multi-spots. Un autre point important pourra
tre dgag de ces analyses : les performances de ces applications sont limites par la mauvaise
adquation du satellite et du protocole de transport le plus couramment utilis, TCP. Nous
tudierons cette influence plus prcisment dans la section 5.4.4, montrant dune part comment
chaque version de TCP ragit diffremment sur le satellite, et dautre part le vritable enjeu que
peut reprsenter les PEPs pour larchitecture hybride. La section 5.4.5 conclura la fois sur la
lgitimit dun service daccs Internet sur satellite et sur la validit du systme hybride pour un
tel service.
La section 5.5 propose une approche du service de VoD et de sa relation troite avec
lutilisation du multi-spots. Nous verrons dans ce cadre les limitations du systme transparent
comme du systme rgnratif, et comment larchitecture hybride permet dapporter une rponse
des plus adaptes au FIS.
Dans lavant-dernire section (5.6), linterconnexion de rseaux privs est tudie, montrant
limportance de lutilisation du multiplexage bord. En effet, le systme rgnratif permet dune
part dviter linfluence nfaste du double bond sur le RTT, et donc sur les performances des
applications utilisant TCP comme des applications fortes contraintes temporelles. Dautre part,
le double bond a un impact non ngligeable sur le PLR, puisqu la place dun passage par un lien
satellite, la communication utilise deux liens, donc un risque double de pertes.
Enfin, la dernire section conclura cette valuation, montrant comment le systme hybride
permet lintgration de diffrents services.
5.1. Le niveau physique et son influence sur le systme

Comme nous lavons not prcdemment, il ne sagit pas pour nous de proposer une
couche physique satellite. En effet, le satellite est avant tout caractris par son niveau physique
qui implique des technologies spcifiques, dpassant largement le motif de cet expos.
Au contraire cette partie sinterroge sur les lments prendre en compte pour ltude de
notre architecture. Pour valuer un systme il faut se donner des outils et une modlisation de
celui-ci. Un modle prenant en compte la totalit du systme est rarement une bonne solution,
puisquil est inconcevable de connatre toutes les caractristiques dun systme satellite dans le
cadre de cette tude. De plus, les dtails ne sont pas toujours ncessaires dans un modle dtude
121
et risque mme dengendrer un comportement inopportun. Aussi nous ne modlisons pas le

systme dans son intgralit, mais uniquement les lments qui ont une influence relle sur notre
tude.
Si un certain nombre dlments nont pas lieu dtre reprsents, dautre notamment du
niveau physique ont leur importance. On notera ainsi la diffusion, les erreurs physiques et le dlai.
Chacun de ces lments fera alors lobjet dune section dans cette partie.
5.1.1.
Diffusion du mdium satellite
La diffusion est un lment inhrent au satellite : toute donne mise sur un spot est reue
par tous les clients sur le spot sans aucun besoin dune quelconque rplication. Cet lment
important sera pris en compte de la manire suivante :
pas de surcot du mdia pour plusieurs utilisateurs sur le mme faisceau,
utilisation dune fraction de la bande passante totale pour chaque message,
rplication ncessaire entre diffrents spots.

Comme le systme nest pas au cur dun problme de dimensionnement, le facteur
dchelle ne sera donc pas tudi, permettant de simplifier cet lment dans ltude. Ainsi dans le
cadre des simulations, la diffusion ne sera pas modlise le plus souvent puisque lon tudiera la
communication entre une source et un puits.
5.1.2.
Dlai dun bond satellite
Le dlai dun bond satellite varie en fonction de la position du satellite, de la gateway et du

terminal. Dans notre cas, o la conception matrielle nous est indiffrente, nous ne prendrons
pas en compte cette lgre variation. Un aller vers le satellite comme une descente sera de 127
ms, soit un dlai pour un bond de 154 ms pour un systme totalement transparent.
5.1.3.
Pertes sur le support physique
Sur un rseau terrestre, les pertes viennent pour la plupart des congestions et trs rarement
du support physique. Pour les rseaux satellite, le contrle daccs limite grandement les pertes
dues aux congestions dans le systme. En revanche, leur canal physique trs bruit provoque des
erreurs bits qui peuvent devenir nombreuses et entraner des pertes au niveau paquet.
Linfluence de ces erreurs nest pas problmatique pour la comparaison de deux systmes
satellites. Il est en effet possible de faire abstraction des pertes sur lun et lautre des systmes, si
lon suppose quelles sont identiques. Cela implique que la reprise derreur est la mme pour
chaque systme. Cette supposition ne peut donc tre faite pour ltude de codes correcteurs, de la
diffrence entre un bond et deux bonds satellite, ou encore pour la comparaison avec un systme
terrestre. Les pertes doivent alors tre prises en compte, dune manire ou dune autre.
Le taux derreur binaire (BER) sur satellite est trs variable, et dpend du bilan de liaison.
Puisque notre proposition ne comprend pas le niveau physique et notamment la mise en place de
codes correcteurs, cest le taux de pertes de paquets qui nous intresse. Toutefois, le lien entre le
BER et le PLR (Packet Loss Rate) reste toujours trs dpendant de la technologie comme des
codages utiliss pour reprendre les erreurs. Traditionnellement pour un systme satellite on
trouve un taux de disponibilit du systme de 95% et 99.9%, ce qui correspond un PLR entre
10-4 et 10-2 [115]. Cependant, ces pertes sont loin dtre uniformment rparties, et cest l le
problme de la modlisation. Les liaisons satellites sont en effet le jeu derreurs en rafales,
couples des erreurs ponctuelles plus classiques. Si les erreurs ponctuelles peuvent tre corriges
facilement grce des techniques de codages adaptes, les erreurs en rafale entranent quant
elles, des pertes de paquets en rafale ou pas. Ces erreurs tant corrles aux perturbations
atmosphriques, les lois dapparitions de pertes deviennent alors trs difficiles exprimer. Des
122
modlisations tentent de sapprocher de la ralit (loi de Pareto, source on/off, modles tats
) mais ne peuvent tre adaptes qu des conditions prcises. Une solution commune est alors
dutiliser des traces relles de pertes, les rejouant au cours de ltude [116]. Il reste difficile
toutefois davoir accs ce type de rsultats, et rien ne prouve quelles sont reprsentatives.
Enfin, les pertes causes par les perturbations du canal sont certes les plus communes mais pas
les seules (erreur de pointage, dtrioration de lantenne, etc).
Aucun modle nest donc ce jour valide pour reprsenter les erreurs satellites en gnral.
Nous essayerons toutefois davoir une ide de linfluence de ces erreurs sur le trafic en utilisant
soit un taux derreur uniforme, soit un modle deux tats, dit de Gilbert.
5.1.3.1.
Taux de pertes selon une loi de Bernoulli
Dans un premier temps, il est possible de modliser les pertes satellites de manire trs
simplifie en utilisant une loi de perte au niveau paquet de type Bernoulli, de 10-3. Cette
modlisation, si elle est trs simple, permet davoir dj une ide des limites du lien satellite.
5.1.3.2.
Modle de Gilbert deux tats
Ce premier modle ne permet pas de prendre en compte la nature en rafales des pertes
satellites, or le satellite a peu derreurs ponctuelles [76] [117].
Une chane de Markov deux tats (modle de Gilbert-Elliot [118]) peut tre utilise pour
modliser la forte tendance des erreurs sur satellite survenir en rafale [119]. On a alors un tat
sans perte, ltat 0, et un tat 1 o tous les paquets sont perdus. chaque nouveau paquet, on
oscille entre ces deux tats suivants un tirage de Bernoulli de probabilits p et q (Figure 5.1). En
effet, il est courant sur le satellite dobserver des pertes en rafale, et le reste du temps aucune
perte.
Figure 5.1 Modlisation des pertes de paquet selon une chane de Markov deux tats
Quelque soit le PLR, si on note donnant la probabilit pour que le nieme paquet soit perdu
ou non. Soit P sa limite en rgime stationnaire. On a :
(10)
Pn = [1 PLR, PLR ] = P
Si on note A, la matrice de transition, on a alors :
(11)
P = P . A
Soit la relation entre p, q et le PLR :
(12)
p=
PLR
.q
1 PLR
Pour un PLR de 10-3 et un q donn, on a la valeur de p par lexpression (12).

123
On se propose de calculer la taille moyenne des rafales pour ce modle, Er. Lexpression
(13) donne lesprance du nombre du temps pass dans ltat 1, cest--dire lesprance du
nombre de paquet perdu dans une rafale :
Er = 1 + n (1 q ) .q
(13)
n=0
Une mise en forme donne lexpression (14), conduisant une suite entire classique :
d
n
(1 q )
n =1 dq
Er = 1 + q (1 q )
(14)
Les conditions de convergence tant vrifies, on a :
(15)
Er = 1 + q (1 q )
d 1
1
dq 1 q
On obtient alors :
(16)
Er = 1 +
q (1 q )
(1 q )
1
q
q est donc directement li au nombre moyen de paquets perdus dans une rafale. Si lon
considre un PLR plus important, de 10-2 par exemple : soit lon garde la mme valeur de q, lon
aura alors des rafales en moyenne de mme taille, mais plus frquentes, soit lon peut baisser q et
avoir des rafales aussi frquentes, mais plus importantes.
Ainsi ce modle, bien quencore loin de la ralit, peut retracer un peu plus fidlement le
profil des pertes satellitaires, notamment pour les rafales.
5.2. Le niveau liaison

Une fois les caractristiques du niveau physique tudies, le niveau liaison est abord ici.
Encore appele niveau accs, cette couche a t lobjet dune proposition pousse dans la partie 4
de ce mmoire. En effet, ce niveau doit tre capable de vhiculer des flux IP, donc de les
encapsuler comme de les rfrencer dans le systme.
Cette partie se focalise alors sur ltude de ce niveau, en corrlation avec les flux IP quil
transmet. Dans cette analyse un accent particulier est port sur le poids de la signalisation dun tel
systme. En effet, linquitude pourrait tre le poids de la signalisation du systme hybride
comparativement des systmes purement transparents ou rgnratifs.
Pour rpondre cette question, et ainsi montrer la viabilit de la proposition hybride, nous
proposons de suivre la dmarche suivante :
Dans une premire section (5.2.1), nous proposerons de ne pas tudier limpact du temps
daccs au support satellite dans la mesure o il est extrmement dpendant de limplantation et
donc du dimensionnement du systme, point qui nest pas du tout lobjet de notre tude.
La section 5.2.2 tudiera la comparaison entre le poids de lencapsulation choisie pour
notre solution et une encapsulation plus classique. Cette tude de loverhead donnera lieu de
constater le choix judicieux que peut reprsenter la solution ULE, comme lintrt dutiliser la
commutation MPEG-2 bord plutt quune commutation ATM.
124
Ensuite, la lumire sera faite sur la signalisation induite par les flux IP (5.2.3), et le poids
rel que ces messages reprsentent par flux IP vhicul. Nous dcouperons la signalisation en
quatre points (table DVB pour indexer les flux, messages de mise jour des tables de
commutation, messages de rsolution dadresse, et messages daccs au systme), permettant de
prendre en compte toute la signalisation de niveau 2 spcifique aux flux IP.
Une dernire tude sur le niveau 2 sera mene dans la section 5.2.4, tudiant linfluence de
la rpartition bord/sol sur le temps de rponse du systme. Cette partie permettra, notamment,
de mettre en valeur la solution hybride par sa capacit intgrer des fonctionnalits bord,
permettant de gagner en ractivit globale du systme, et cela mme pour des flux transparents.
Enfin, la section 5.2.5 conclura cette analyse du niveau 2 en notant lintrt de la solution
hybride dans la mesure o celle-ci ninduit pas une signalisation plus importante, et permet de
gagner en temps de rponse comme dallger loverhead induit par lencapsulation.
5.2.1.
Le temps daccs au support
Parmi les lments du niveau 2 qui influencent directement les performances applicatives,
on trouve la mthode daccs. Cette partie statue sur la manire dont le temps induit par laccs
au mdium est pris en compte dans notre tude.
Si le partage de la ressource est en MF-TDMA, cest la mthode daccs (cest--dire de
rpartition de la ressource) qui induit un temps daccs au support. Or ces mthodes sont
nombreuses et souvent spcifiques une implantation donne. Il est nanmoins possible de les
subdiviser en deux classes : une classe oriente connexion et une classe plus dynamique.
Les mthodes de type CAC (Connexion Admission Control) reposent sur une demande
du RCST qui peut tre accepte ou rejete en fonction de son SLA et de la bande
passante disponible. Une fois accepte, cette requte ninduit plus aucun dlai
puisquun certain nombre de slots est ainsi allou au seul RCST pour une priode de
temps donne. Si cette priode est suffisamment grande, ce temps daccs peut tre
nglig. introduisent un dlai au dbut de la connexion et plus aucun par la suite. Cest
le cas de laccs sur la voie aller et des mthodes CAC, pour des trafics de type CBR
(Constant Bit Rate) sur la voie retour. Le CAC peut notamment tre mis en uvre pour
des demandes de type CRA (Continuous Rate Assignment) dun RCST.
Les mthodes plus dynamiques sont les plus courantes sur la voie retour car elles
permettent dviter le gaspillage de bande passante. Lavantage dun accs de type
connect avec lexemple classique du RTC (Rseau Tlphonique Commut), est la
rservation des ressources. Toutefois ce type daccs nest rentable que dans le cadre
dun trafic constant, sans rafale ni silence. Or les applications web classiques ou encore
les applications multimdia ont un trafic irrgulier, donc peu propice un mode daccs
connect. Dans ce cadre les RCSTs peuvent faire des requtes sous diffrentes formes :
le FCA (Free Capacity Assignment), le RBDC (Rate-Based Dynamic Capacity) et le
VBDC (Volume-Based Dynamic Capacity) [114]. Aussi il est souvent dlicat davoir
une ide du temps daccs au systme pour un utilisateur donn. Un grand nombre
dtudes essaie de trouver la mthode daccs la plus adapte, comme par exemple des
mthodes ractives, prdictives, ou encore combinant les deux [120]. Mais le dlai
dassignement de slots dmission dpend toujours de deux facteurs distincts : dune
part le temps daller-retour au NCC, et dautre part le temps de calcul de lassignement
par lalgorithme de DAMA (Demand Assignment Multiple Access), qui dpend
naturellement du nombre de terminaux connects. Comme le montre [121], ce temps
peut tre malgr tout assez important, et il devient alors difficile mme de borner le
dlai pris par la mthode daccs. Le temps daccs sur la voie retour est alors
difficilement modlisable et trs dpendant de la technologie.
125
Ici nous ne modliserons donc pas le temps induit par lalgorithme dallocations, le
considrant comme faible compar au temps daller-retour dune requte au NCC. De plus dans
la plupart des simulations, ce facteur, trs spcifique une implantation particulire du systme,
napporte rien notre analyse : une allocation statique et donc sans dlai sera convenue.
5.2.2.
tude et comparaison de lencapsulation
Un point notable de larchitecture est sa structure protocolaire, avec notamment ses

mcanismes dencapsulation. Nous avons dj prsent diffrentes encapsulations possibles pour
des datagrammes sur DVB-S (cf. partie 3.2.1 et 3.4.1) et DVB-RCS (2.4.2). Notre choix pour le
systme hybride sest arrt sur lutilisation de ULE pour le DVB-S comme le DVB-RCS, et donc
sur des conteneurs uniquement MPEG-2, et non ATM. Par souci dhomognit et
dimplantation, le mode rgnratif et le mode transparent utilisent tous les deux ULE pour
encapsuler les donnes sur la voie retour.
Nous proposons dans cette partie dtudier ce point, comparativement aux mthodes
classiques que sont MPE sur la voie aller et AAL5/ATM sur la voie retour.
La premire section (5.2.2.1) de cette partie compare loverhead1 engendr par lencapsulation
sur la voie aller, tandis que la section 5.2.2.2 tudie cela sur la voie retour. Enfin, la partie 5.2.2.3
conclut par une analyse de linfluence globale de cet overhead sur le systme.
5.2.2.1. La comparaison de loverhead engendr par lencapsulation

sur la voie aller DVB-S
Cette partie repose sur de nombreux lments proposs dans le chapitre 3 de ce mmoire.
Nous ne rappelons pas ici en dtail lencapsulation via MPE et ULE (cf. figures pages 43 et 55).
Cette analyse prend comme hypothse le cas idal o le section packing est toujours possible.
Parce que nous comparons deux encapsulations utilisant cette technique, les remarques restent
comparables pour un taux de section packing plus faible que 100%.
Nous avons dj eu un aperu du gain apport par ULE dans la partie 3.4.1.2. Cette partie
propose une approche un peu plus fine, en prenant en compte des dtails dimplantation.
Soit TMP(s) et TU(s), les tailles de donnes ncessaires pour encapsuler un datagramme de
taille initiale s + 20 octets respectivement par MPE et ULE avec section packing. Cette
encapsulation est effectue en deux tapes dans les deux cas : lencapsulation dans le(s) section(s)
datagramme(s) pour MPE ou une SNDU pour ULE (section 5.2.2.1.1), puis lencapsulation dans
le(s) paquet(s) MPEG-2 TS (5.2.2.1.2)
5.2.2.1.1.
ENCAPSULATION AU NIVEAU SECTION
Commenons par lencapsulation de niveau intermdiaire. Celle-ci nest pas la mme dans
le cadre MPE et ULE.
5.2.2.1.1.1.
Lencapsulation via MPE
Soit TS(s), la taille requise par une ou plusieurs sections pour encapsuler un datagramme IP
de taille s + 20 octets (on considre un segment TCP de s octets). La MTU de MPE tant de
4080 octets, au-del de cette valeur, la couche IP doit scinder le paquet en deux rajoutant 20
octets supplmentaires den-tte IP2. Une encapsulation dans une section datagramme rajoute 12
octets den-tte et 4 de CRC. On obtient alors lexpression de TS(s) (17) :
Une hypothse noter pour ces calculs est lutilisation dune taille de segment TCP s. Pour chaque calcul
doverhead, on considre des segments de taille identique s, pour pouvoir avoir une base de comparaison commune.
1
Lutilisation de Path MTU Discovery permet de limiter cette fragmentation [71].
126
s
TS ( s ) = s +
( 20 + 12 + 4 )
4060
(17)
Cette expression simple considre un segment de taille s, et lajout de 36 octets par

datagrammes. On peut la dcomposer en (18), comme la somme des n(s) sections compltes de
taille totale 4096 octets et dune dernire section (qui peut tre vide), de taille TS(s).
(18)
s
TS ( s) = ( s 4060) + min(1, s 4060).(20 + 12 + 4) +
( 4096 )
4060
TS ( s ) = TS ' ( s ) + 4096.n( s )
5.2.2.1.1.2.
Lencapsulation via ULE
Comme prcdemment, on pose TSN(s), la taille dune section encapsulant un segment TCP
de taille initiale s. La taille maximale dune donne encapsule dans une SNDU ULE tant code
sur 15 bits, on peut alors encapsuler des datagrammes de plus de 32 Kbits (en incluant le champ
optionnel dadresse et le CRC dans le dcompte). Il ny a donc pas de fragmentation ici.
Lencapsulation dans une SNDU ULE rajoute, dans notre cas, 4 octets den-tte obligatoire, 6
den-tte optionnel correspondant ladresse MAC destination et 4 de CRC (19).
TSN ( s ) = s + 20 + 4 + 6 + 4
(19)
5.2.2.1.2.
ENCAPSULATION AU NIVEAU MPEG-2 TS
Une fois les datagrammes encapsuls dans un ou plusieurs conteneurs, ces derniers sont
encapsuls dans les flux MPEG-2 TS. Si dans les deux cas ces encapsulations se ressemblent, il
existe certaines spcificits, notamment au niveau de linsertion du pointeur et des cas limites du
section packing.
5.2.2.1.2.1.
Lencapsulation via MPE
Chaque section datagramme est ensuite encapsule dans un ou plusieurs paquets MPEG-2
TS. Toutefois le section packing naura lieu que sil reste strictement plus de 7 octets dans le paquet,
sinon il y aura bourrage. En effet, ces 7 octets de seuil permettent de ne pas tronquer le champ
longueur de la section MPE. On alors :
(20)
(21)
TMP ' ( s ) = TMP '' (TS ' ( s )) + n( s ).TMP '' (4096)

TMP '' (4096) =
4096 + 4
.188 4189.13
184
Si (TS ' ( s ) = 0 ) alors {TMP '' (TS ' ( s)) = 0}

SinonSi ( (TS ' ( s ) + 4) 184 < 177 ) alors
(22)
(TS ' ( s ) + 4)
TMP '' (TS ' ( s )) =
.188
184
Sinon
(TS ' ( s ) + 4)
.188
TMP '' (TS ' ( s )) =
184
FinSi
127
(21) est une application particulire de (22) pour 4096 octets. On peut noter dans (22), la
prise en compte du pointeur de 4 octets dans le calcul pour identifier le dbut de la section dans
le paquet MPEG-2 TS.
5.2.2.1.2.2.
La SNDU est ensuite encapsule dans des paquets MPEG-2 TS. Dans ce cadre, deux cas
limites sont prendre en compte pour le calcul de TU en fonction de TSN :
le cas o plus dun paquet peut tre encapsul dans un seul paquet MPEG-2 TS. Cest
possible lorsque TSN est infrieur 184 octets. Alors le poids de ce message est de :
T ( s)
TU ' ( s ) = SN
.188
183
(23)
sauf quand il ne peut y avoir le dbut dune nouvelle SNDU dans le paquet, c'est--dire
sil reste uniquement 1 octet. Dans ce cas, la taille MPEG-2 TS utilise pour
lencapsulation de la SNDU est de 188 octets diviss par le nombre de SNDU de mme
taille que lon peut mettre dans le paquet (183 octets), soit :
1
183
TU ' ( s ) =
.188
TSN ( s )
(24)
le cas o il ne reste quun ou deux octets dans le paquet MPEG-2 TS pour encapsuler
la donne suivante. Ici du bourrage doit alors tre introduit.
Cela donne alors :
Si (TSN ( s ) < 184 ) alors
(25)
TSN ( s )
Si (183 TSN ( s ) > 1) alors TU ' ( s ) =
.188
183
183
=
T
(
s
)
.188
Sinon
U'
TSN ( s )
FinSi
Sinon
TSN ( s ) + 1
Si ( (TSN ( s ) + 1) 184 < 182 ) alors TU ' ( s ) =
.188
184
TSN ( s ) + 1
Sinon TU ' ( s ) =
.188
184
FinSi
FinSi
5.2.2.1.3.
CONCLUSION SUR LENCAPSULATION DE LA VOIE ALLER
On peut alors reprsenter le rapport entre TU(s) et TMP(s) (Figure 5.2). Cette courbe
reprend lallure gnrale de la Figure 3.17, puisque ce prcdent calcul proposait une analyse
rapide de lencapsulation ULE compare MPE. Cette tude plus prcise met en valeur plusieurs
points :
128
lencapsulation ULE est plus performante pour des paquets plus petits ;
des creux et des pics sont observables, correspondant lintroduction de bourrage

quand un pointeur ne peut tre insr. Les creux tant plus prononcs que les pics, le
bourrage a plus dimpact sur les performances de MPE. Cela sexplique par
limportance relative du bourrage dans MPE qui peut aller jusqu 7 octets, alors que
dans ULE, seul 2 octets sont introduits au maximum ;
au del de 4060 octets rentre en jeu la fragmentation du datagramme IP pour MPE,

tandis que la mthode ULE ne scinde pas le datagramme. Le ratio tend alors vers 99%.
Figure 5.2 Comparaison de lencapsulation MPE et ULE sur le lien montant DVB-S dans le
systme hybride
Cette analyse de lencapsulation de datagrammes sur la voie aller montre comment ULE,
utilise dans le cadre de notre architecture, propose un gain dans tous les cas. Il est certain que
pour des paquets importants ce gain reste assez faible, oscillant entre 0.1 % et 2%. Pour des
paquets plus faibles nanmoins, les performances de cette solution sont nettement suprieures
celles dune encapsulation plus classique de type MPE. Ainsi obtient-on jusqu 14% de gain pour
des paquets de trs petites tailles, 9.5% pour les acquittements TCP (s pris 20 octets), ou encore
4% 8% pour des segments de signalisation de quelques dizaines doctets.
Ainsi, sur la voie aller, le systme hybride prsente une encapsulation des flux IP moins
lourde que les solutions classiques, notamment sur les paquets de petites tailles comme les
messages de signalisation grce lintgration de la proposition ULE.
5.2.2.2. La comparaison de loverhead engendr par lencapsulation

sur la voie retour
Lutilisation de paquet MPEG-2 TS comme conteneurs pour le DVB-RCS a t choisie
pour conserver lhomognit entre les flux DVB-S montants et les flux DVB-RCS descendants.
De plus une approche homogne permet un agencement des couches protocolaires plus lger,
induisant qualitativement une encapsulation moins lourde.
Dans ce cadre, cette partie propose de vrifier quau lieu dinduire un surcot
dencapsulation sur la voie retour, la solution hybride propose une encapsulation plus lgre.
129
Puisque dans le mode rgnratif, les flux montants sont dmultiplexs bord puis
multiplexs en de nouveaux flux descendants, une encapsulation peut tre utilise ici, notamment
pour le formatage des cellules ATM en paquet MPEG-2 TS. Cette tude est alors divise en deux
sections : dabord le lien montant (5.2.2.2.1), ensuite le lien descendant (5.2.2.2.2).
5.2.2.2.1.
ANALYSE SUR LE LIEN MONTANT
Le cas ATM, au contraire de la voie aller, nencapsule pas successivement dans deux
conteneurs diffrents les datagrammes. Pour le DVB-RCS, lutilisation de paquets MPEG-2 TS
nest pas obligatoire. En revanche lencapsulation ULE reste identique celle de la voie aller (25).
Toutefois, la mise en place de cette encapsulation est trs lie des notions de codage
canal, puisque les conteneurs de niveau 2 sont assembls sous la forme de bursts, et cods dune
manire diffrente. Cet lment est directement intgr dans cette analyse, qui se dcoupera alors
en la prsentation des hypothses dencapsulation, lanalyse de lencapsulation AAL5/ATM
jusquau niveau des bursts, et de celle utilisant ULE. Enfin nous comparerons les deux approches.
5.2.2.2.1.1.
Les hypothses dencapsulation
Pour lencapsulation via les cellules ATM, ltude repose sur notre exprience dans
DIPCAST. Ainsi une cellule ne pourra contenir plus dun morceau de segment TCP. Le bourrage
sera alors de rigueur.
Les bursts TRF seront forms dau maximum 4 cellules ATM, et nous considrons dans les
calculs que ce maximum est toujours atteint. Le taux de codage des cellules sera de 2/3 et un entte de 4 octets sera rajout par burst, sans prambule SAC optionnel.
Pour les paquets MPEG-2 TS, dans le cas ULE, nous considrerons aussi 4 paquets par
burst, avec un codage 3/4 et un en-tte de 4 octets, toujours sans prambule SAC optionnel.
5.2.2.2.1.2.
Lencapsulation via AAL5/ATM
Comme prcdemment, notons TAup(s), la taille des bursts TRF ncessaires lencapsulation
dun segment TCP de taille s. On a alors NA(s), le nombre de cellules ATM ncessaires pour
encapsuler les s + 20 octets :
s + 20
N A (s) =
48
(26)
Ces cellules sont ensuite regroupes par 4 pour former un burst. Un codage de 2/3 et un
prambule de 4 octets sont utiliss. On a alors une taille totale de :
TAup ( s ) =
(27)
5.2.2.2.1.3.
N A (s)
.(4 + 4 53 3 2)
4
La formule (25) restant valable, on peut regrouper les paquets en quadruplets, ajoutant un
prambule de 4 octets. On obtient alors lexpression de TUup(s) en fonction de TU(s) (23).
TU ' ( s )
(28)
TUup ( s ) =
5.2.2.2.1.4.
188 .(4 4 188 4 3)
La comparaison entre les deux encapsulations
Nous proposons danalyser lefficacit de ces deux encapsulations, en tudiant le rapport

entre TUup(s) et TA(s) (Figure 5.3).
130
Il est naturel de retrouver ici au minimum le facteur d aux taux de codage diffrents, cest-dire environ 11% de gain pour la solution ULE. Or, ici, on observe une limite vers 0.815, soit
un gain de 18.5%. Cette partie va donc analyser les diffrentes causes responsables de ce gain.
Une premire raison pourrat tre le bourrage introduit dans les cellules ATM, mais la
figure suivante dment cette conclusion. En effet, sil est vident que le bourrage a un effet
notable pour des valeurs de s peu leves, laugmentation de s estompe cette diffrence qui se
traduit par un amortissement des oscillations sur la courbe. Le bourrage a donc peu dimpact
pour s lev.
Une autre cause de ce gain vient de la formation des bursts. En effet, si un burst est compos
de 4 lments dans tous les cas, 4 cellules ATM font uniquement 318 octets (codage inclus)
contre environ 1003 octets pour les paquets MPEG-2 TS. Or, chaque burst, 4 octets sont
rajouts, donnant un gain denviron 1% pour lencapsulation ULE.
La dernire raison de cette diffrence est le total des en-ttes ULE contre ATM. En effet
ATM rajoute 5 octets pour 48 octets, tandis que ULE/MPEG-2 rajoute 14 octets en-tte et CRC,
1 octet de pointeur, et 4 octets par 184 octets. Par un calcul approch, considrant 48*184 octets
encapsuler, on obtient la formule (24) pour le ratio entre la taille des donnes une fois
encapsule par ULE et la taille obtenue par ATM. Soit un gain pour ULE de 7.3%.
(29)
15
+ 48 .188
184
0.927
184 53
Figure 5.3 Comparaison de lencapsulation ATM et ULE sur le lien montant DVB-RCS dans le
systme hybride
Cette partie a montr que sur la voie retour, le systme hybride propose un overhead plus
faible, gagnant de lordre de 18.5 % dont 7.3 % sont intrinsquement lis lencapsulation. Ce
gain est dautant plus apprciable quil est plus important pour les paquets de petite taille, plus
courants sur le lien retour.
131
5.2.2.2.2.
ANALYSE SUR LE LIEN DESCENDANT EN MODE RGNRATIF
Nous proposons de terminer cette analyse par lencapsulation sur le lien descendant en
mode rgnratif. Ce nest, en effet, que dans le cadre du mode rgnratif que le multiplexage en
flux DVB-S descendant implique le formatage des cellules ATM en paquet MPEG-2 TS. Dans le
cas de larchitecture hybride, ce problme na pas lieu, puisquil sagit dj de paquets MPEG-2.
Aprs avoir pos les hypothses dencapsulation dans 5.2.2.2.2.1, nous tudierons le cas
AAL5/ATM, puis le cas ULE, et enfin nous conclurons avec le ratio entre ces encapsulations.
5.2.2.2.2.1.
Les hypothses dencapsulation
Dans cette partie, puisquil sagit de comparer deux modes DVB-S, le codage est le mme
dans les deux cas. Nous ne le prenons donc pas en compte ici.
bord, dans le cas AAL5/ATM, les cellules sont multiplexes dans des paquets MPEG-2
TS. Pour un flux ATM de cellules de mme segment TCP dorigine, on encapsule 7 cellules pour
2 paquets MPEG-2 TS. Par contre, lencapsulation de cellules ATM dun datagramme diffrent
nest pas autoris dans un mme paquet MPEG-2 TS. Cette encapsulation utilise du data piping.
5.2.2.2.2.2.
Lencapsulation via AAL5/ATM
Soit TAdown(s), la taille des paquets MPEG-2 TS utilises pour encapsuler les cellules ATM
encapsulant elles-mmes un segment TCP de taille s. Les hypothses ci-dessus impliquent
lexpression suivante pour TAdown(s) :
(30)
s +4820
s +4820 7
TAdown ( s ) =
.2 188 +
188
3
7
5.2.2.2.2.3.
Encapsulation via ULE
Pour ce qui concerne TUdown(s), lencapsulation bord reste la mme que prcdemment,
on a donc la mme expression que TU(s) (25).
5.2.2.2.2.4.
La comparaison entre les deux encapsulations
Figure 5.4 Comparaison de lencapsulation ATM et ULE sur le lien descendant DVB-S dans le
systme hybride
132
La figure ci-dessus (Figure 5.4) prsente le rapport entre TUdown(s), et TAdown(s), sans
prendre en compte cette fois les critres de codage, puisquils sont exactement les mmes. Cette
courbe montre un gain pour la mthode ULE tendant vers 9%.
Nanmoins il faut nuancer quelque peu cette valeur dans la mesure o lon compare ici une
mthode utilisant du section packing contre une solution avec bourrage. Or, la solution ULE se
place dans le cas idal dun section packing. Toutefois, les tudes telles que [47] montre que lon
peut envisager dans les 70% de section packing. Aussi mme si ce gain peut tre un peu moins
grand, on peut conclure sur de meilleures performances de lutilisation de MPEG-2 TS comme
support pour DVB-RCS dans le cadre rgnratif, mme lorsquil y a un peu de bourrage.
Plus doscillations sont observs ici que prcdemment. Celles-ci proviennent du double
bourrage, dans les paquets MPEG-2 TS dune part, et dans les cellules ATM dautre part pour la
solution AAL5/ATM. Une amlioration de la solution ATM peut cependant tre apporte en
utilisant MPE ou ULE la place du data piping. Mais dans lensemble, lencapsulation ULE reste
plus avantageuse, car cette technique ne fait que gommer les oscillations.
Le systme hybride propose dutiliser une encapsulation plus lgre que les mthodes
classiques, permettant de gagner en capacit sur le lien retour descendant, surtout pour des
paquets courts. Dans ce cadre, le gain oscille entre 10% et 50%, pouvant mme atteindre 80%
pour des paquets de trs petites tailles.
5.2.2.3.
Des conclusions sur ltude de loverhead
Cette analyse a permis dobserver plusieurs lments. Dans un premier lieu, ULE reste la
plus performante que les solutions communes tudies ici, et cela sur le lien aller comme retour.
De plus, ULE est mieux adapt aux paquets de petite taille. Enfin loverhead dULE reste le plus
lger, mme pour des paquets de trs grande taille (10 KB) puisque le champ longueur de cette
mthode permet de les encapsuler sans la ncessit dune fragmentation au niveau IP (par
exemple sur gigabit Ethernet).
Figure 5.5 Part moyenne de dbit utile en fonction de la taille moyenne des segments TCP
vhicul sur le systme hybride
133
Larchitecture hybride propose donc une mise en uvre spcifique et performante dULE,
offrant notamment une meilleure rentabilit de la voie retour en limitant le gaspillage de dbit
engendr par les encapsulations successives.
La figure ci-dessus donne un aperu du pourcentage rel de bande passante utile sur la voie
aller (Figure 5.5)1, comme la voie retour descendante en mode rgnratif. Cette figure montre
clairement que pour un systme utilisant des segments moyens de 1000 octets, lencapsulation
prend moins de 4% du dbit, contre 4.4% dans le cadre dune encapsulation Ethernet.
La nature hybride de larchitecture na donc pas une influence ngative sur le poids de
lencapsulation du systme. Les solutions proposes sont mmes plus performantes que les
mthodes classiques.
5.2.3.
tude du poids des messages de signalisation
Ltude prcdente a permis de montrer que larchitecture hybride, loin dentraner une
surcharge dencapsulation, proposait une encapsulation loverhead lger, comparativement des
solutions satellites classiques. Cependant, lencapsulation nest pas seule pouvoir engendrer un
poids certain au niveau 2. La spcificit du systme hybride, savoir lintgration de deux charges
utiles diffrentes dans un mme systme, prsente un risque : celui dune signalisation lourde.
Lobjet de cette partie est donc davoir une ide des pertes de capacit introduites par les
messages de signalisation. Bien sr, il est utopique dobtenir un calcul trs prcis de ces valeurs,
mais une valuation du poids des messages par flux IP est envisageable.
Si lon reprend les chapitres 2, 3 et 4 de ce mmoire, il est possible de rfrencer les
messages de signalisations spcifiques la communication des flux IP, savoir les tables SI pour
les flux IP, les messages induits par la rsolution dadresse, les messages grant le contrle daccs
et les messages de mise jour des tables de commutation. On peut ainsi rsumer les quatre types
de messages spcifiques aux flux IP, et donc larchitecture hybride. Par contre il est plus dlicat
de connatre le poids de ces messages par rapport aux flux IP. Cest l lobjectif de cette partie.
Pour suivre cette dmarche, les quatre premires sections tudieront ces signalisations,
alors que la dernire fera le point sur limpact de la signalisation sur le systme.
5.2.3.1.
Le poids de la signalisation DVB-SI pour les flux IP
Le systme hybride se propose dutiliser la mthode INT pour rfrencer les flux IP
vhiculs au niveau MPEG-2 TS. Cette solution est conseille par la norme DVB-S, et se
prsente pour le moment comme lunique solution standard sur systme DVB-S.
Tableau VI. TABLES SI CONSULTES POUR AVOIR ACCS AU PID DUN FLUX IP
Ici nest pris en compte que le dbit utilis par lencapsulation, et donc aucune autre signalisation.
134
Comme nous lavons vu prcdemment (cf. 3.2.2.3), le standard DVB-S prvoie de faire le
lien entre les adresses IP destination, unipoint comme multipoint, et les PIDs. Cette solution
utilise les tables INT pour faire le lien entre une adresse, et un numro de programme. Le tableau
prcdent rcapitule les tables consulter pour avoir accs au PID des paquets transportant le
flux IP recherch (Tableau VI).
Comme ce tableau le montre, seuls deux types de tables sont spcifiques au service IP sur
satellite : la table INT, et les tables PMT des programmes lis IP. Nous ngligerons ici le poids
des lignes correspondant des flux IP ajouts dans les tables NIT, ou PAT, puisque
comparativement au nombre de flux, elles reprsentent quelques octets. On alors :
Un ajout dun numro de programme pour la table INT dans la table PAT. Ce qui
correspond un ajout de 4 octets (program_number et network_PID).
Une table PMT pour indiquer le programme INT. La table PMT dune table INT se
dcompose en :
un en-tte de 12 octets [4],
un bloc compos dun octet de stream_type, de 3 bits rservs, de 13 bits de
delementary_PID [1], et dun data_broadcast_Id_descriptor [13] de 10 octets incluant un
champ spcifique INT [10], lIP/MAC_notification_info (6 octets),
un CRC de 4 octets.
Deux blocs dans la table INT pour traiter une adresse IP donne. La table INT est ellemme compose dun en-tte de 12 octets, suivi dune platform_descriptor_loop, puis dune
boucle de deux blocs composs, lun du target_descriptor_loop, lautre de
loperational_descriptor_loop, et enfin un CRC de 4 octets. Seuls les deux blocs sont
spcifiques une adresse IP (ou un regroupement dadresses). La figure ci-dessous
(Figure 5.6) prsente de manire plus prcise la composition de la table INT.
Figure 5.6 Taille dune table INT en fonction du nombre de flux IP traits
135
Un ajout dun numro de programme pour le flux IP dans la table PAT1, qui prend
donc 4 octets (program_number et program_map_PID).
Une table PMT associe un flux IP. Il sagit toujours dune table de 12 octets dentte, avec un bloc de 10 octets contenant le data_broadcast_id_descriptor, et dun CRC de 4
octets.
Le tableau suivant (Tableau V) propose alors une valuation du poids de la signalisation SI
ramene un flux IP. Les valeurs prises pour la priode dmission des tables sont celles
proposes par le guide dimplantation de DVB-SI [122], et un guide produit par EUTELSAT
pour HOT BIRDtm [123]. En revanche, il ny a pas dinformations quant la priodicit de la
table INT. Comme cette table parat aussi importante que la table PMT, nous avons fix sa
priodicit 100 ms. Nous avons opt pour des chanes de caractres de 8 octets.
Tableau VII. VALUATION DU POIDS DE LA SIGNALISATION POUR UN FLUX IP
Ainsi si lon utilise un seul PID par adresse IP et flux multicast on obtient un poids total de
signalisation de (740/n + 400) octets par seconde par flux unipoint et (740/n+420) octets par
seconde par flux multipoint. Pour un multiplex de 38 Mbit/s, on peut offrir 38 communications
simultanes 1 Mbit/s. On a alors au minimum 419.5 octets utiliss pour un flux unicast, soit
0.34% du dbit. Toutefois, sur la voie DVB-S, il ne sagit pas de connexions garanties, mais de
communications concurrentes, avec certaines garanties de services pour les utilisateurs. On peut
garantir le dbit pour les premiers gigaoctets tlchargs, ou encore un minimum de dbit. Dans
notre cas, pour permettre lvaluation, on garantit un minimum de 10% du dbit maximum
offert. La figure suivante (Figure 5.7) prsente alors lvolution du poids de la signalisation SI en
fonction du nombre de clients simultans sur le systme.
Lutilisation dun PID par flux IP peut engendrer une gnration de signalisation de tables
SI plus de 3% du dbit attribu pour ce flux. Lutilisation dagrgation de flux par PID permet
de rduire cette consommation de la bande passante dun facteur 10. Ainsi si lon utilise 1 PID
pour 100 flux (ce qui peut tre moins encore dans le mode transparent), le dbit par flux est
diminu environ 0.37% pour la signalisation SI spcifique ce flux. Lutilisation dun unique
PID pour tout le trafic et la rsolution dadresse au niveau MAC permettent de rduire les
messages SI leur plus simple expression. Toutefois, dans un tel cas, le flux IP na plus aucune
signification au niveau MPEG-2 TS, et tout le travail est report sur le niveau MAC ULE.
Un flux IP peut partager un mme programme avec dautres flux IP, cest--dire un mme PID.
136
Cependant, nous avons vu dans la partie 4 que lagrgation de flux propose par
larchitecture hybride tait limite sur le lien rgnratif, pour viter le dsquencement introduit
par la commutation bord. Ainsi, lagrgation des PIDs est possible au niveau des gateway, mais
pas en mode rgnratif pour les flux de deux RCST diffrents.
Toutefois, le trafic engendr par les gateways est plus important que celui des RCSTs. Aussi
lagrgation des PIDs utilise par larchitecture hybride permet sur la voie aller davoir une perte
comprise entre 0.08% et 0.37%. Le poids augmente sur la voie descendante rgnrative par
lajout des flux en provenance des RSCTs, puisque dans le cas dune commutation sur les PIDs,
lutilisation du mme PID reste restreinte au couple (RCST, spot). Ce couple est associ
gnralement un seul flux IP quand la destination est un autre RCST, et plusieurs pour une
gateway. Ces flux, de dbit plus faible, introduisent une signalisation plus importante. Si lon
considre quils utilisent 10% du dbit total du multiplexe descendant, soit 3.8 Mb/s, on a alors
de 14 148 flux circulant avec un dbit de 25.6 256Kb/s, soit un poids dencapsulation variant
de 1.4 12.6 % du dbit du flux. Il est naturel, toutefois, dobserver une augmentation du poids
de lencapsulation relatif quand le dbit dcrot.
Figure 5.7 volution du poids de la signalisation SI en fonction du nombre de clients simultans
Au niveau de la signalisation DVB-SI, le systme hybride introduit la mme signalisation

quun systme utilisant la mthode INT. Pour les flux de la voie aller, cette signalisation a un
faible poids, grce notamment lagrgation des PIDs utilise par les gateways. Ce poids devient
plus important pour la voie retour rgnrative, surtout pour des faibles dbits. Toutefois un
poids de 12.6 % reste celui propos par la mthode INT, et une spcificit de notre architecture.
137
5.2.3.2.
Le poids de signalisation induite par la rsolution dadresse
Dans cette partie nous proposons une discussion sur le poids de la signalisation induite par
lAR. Nous verrons ce cas dans larchitecture telle quelle est propose ici (section 5.2.3.2.1), ainsi
que quelques perspectives (section 5.2.3.3.2).
5.2.3.2.1.
DANS LARCHITECTURE HYBRIDE
La rsolution dadresse peut introduire un poids de signalisation en dbut de

communication. Toutefois, ce nest pas le cas de notre architecture (cf. 4.3.3.3.3) o la
correspondance entre ladresse MAC et ladresse IP se fait automatiquement.
La demande dun PID reste un cas trs rare de la part de la gateway et, pour une RCST,
celle-ci est faite en mme temps que lallocation de ressources, si besoin. Il ny a donc pas de
message particulier prendre en compte ici, donc aucun impact sur larchitecture hybride.
5.2.3.2.2.
OUVERTURES VERS UNE AUTRE MTHODE DAR
Dans le cadre du systme hybride, on peut envisager une autre mthode de rsolution
dadresse : lutilisation de messages de type ARP pour, dune part, communiquer aux rcepteurs
dun flux quel PID les concerne et pour, dautre part, leur demander leur adresse MAC. Cette
mthode introduit des messages supplmentaires mais plus ponctuels que la mthode INT,
rendant la signalisation INT prcdemment tudie inutile. Cependant, nous navons pas propos
cette mthode ici dans la mesure o rien nest encore normalis pour le satellite sur ce point
tandis que la mthode INT est incluse dans le standard DVB, et permet une cohabitation des flux
IP avec des flux MPEG-2 (ce qui peut tre un atout pour la VoD).
5.2.3.3.
Le poids de la signalisation induite par la mthode daccs
Dans le cadre du systme hybride, la mthode daccs est lie en partie la rsolution
dadresse, parce que le NCC est le matre duvre de lattribution des PIDs et le contrleur de
laccs au systme. Ainsi, le NCC profite des demandes daccs pour attribuer les PIDs la
station mettrice, correspondant ses besoins.
La signalisation induite est trs variable en fonction de la voie et du mode. Pour ltude de
cette signalisation, nous dcouperons alors lanalyse en deux sections : la signalisation induite par
la mthode daccs sur la voie aller et la signalisation induite par la voie retour.
5.2.3.3.1.
LA
SIGNALISATION INDUITE SUR LA VOIE ALLER
La mthode daccs sur la voie aller est assez simple pour le mode transparent, elle est
gre par les gateways elles-mmes (cf. 4.3.3.4.1.1). Aucune signalisation nest donc induite ce
niveau. Comme la plupart des systmes, larchitecture hybride ninduit pas de signalisation lie
laccs sur la voie aller qui puisse avoir une quelconque influence sur le dbit dune gateway.
5.2.3.3.2.
LA
SIGNALISATION INDUITE SUR LA VOIE RETOUR
Il sagit ici dtudier limpact de laccs au support satellite des RCSTs dans larchitecture
hybride.
La mthode daccs a un rle essentiel au niveau de la voie retour. Dans le cadre dune
allocation dynamique, de type DAMA, tous les terminaux voulant mettre sur la prochaine
supertrame doivent communiquer leur demande au NCC via un canal contention (le plus
souvent de type aloha). Le NCC calcule la meilleure attribution possible en prenant en compte les
ressources du systme (le calcul est donc plus complexe en mode rgnratif) et envoie cette
distribution sous la forme des messages (table SI) TBTP (cf. 4.3.3.4.1.2). La signalisation se
dcoupe en deux parties : les messages sur la voie retour et la table TBTP sur la voie aller.
138
5.2.3.3.2.1.
Sur la voie retour
Comme la signalisation sur le lien retour utilise un canal rserv contention, le poids de la
signalisation est donc naturellement contrl et limit, sans impact sur les bursts de type TRF. La
signalisation peut toutefois utiliser le champ SAC optionnel des bursts TRF, mais lvaluation de
limpact de cette signalisation revient alors prendre en compte un overhead supplmentaire
moyen dans la formation des bursts. Larchitecture hybride nutilise pas cette mthode. Il ny a
donc aucune influence de laccs la voie retour sur la voie retour elle-mme.
5.2.3.3.2.2.
Sur la voie aller
Sur la voie aller, en revanche, les tables TBTP se rajoutent au dbit utilis par la
signalisation SI. La frquence des tables TBTP dpend grandement de la taille de la supertrame,
qui peut aller jusqu 93.2s [124]. Toutefois, dans ce cas, la TBTP est dcoupe en morceaux,
distribus au fur et mesure en fonction des numros de trame. Un exemple dimplmentation
donne une priode de 140 ms [84], mais il sagit dun cas mettant en uvre ATM. En prenant
appui sur des exemples proposs pour ATM [121][124], nous avons choisi de prendre pour
exemple dtude la rpartition propose dans le tableau suivant (Tableau VIII)1, o nTRF est le
nombre de bursts TRF par trames :
Tableau VIII.
COMPOSITION DUNE SUPERTRAME
Tst
Tst / Tt
Wst / Wt
1.3 s
nTRF
256
16
2
La TBTP peut utiliser un numro de PID fixe, ou un numro de programme pour tre
trouve. Si lon considre ce dernier cas (quivalent celui de la table INT), on a alors 28 octets
de table PMT, et 4 octets dans la table PAT pour indiquer ce programme. La TBTP a un en-tte
de 11 octets, une boucle sur les trames comprenant 3 octets et une boucle sur les slots, et un CRC
de 4 octets. La boucle sur les slots est compose dun bloc de 5 6 octets. Si lon veut introduire la
notion de PID par slot, on peut le faire ce niveau en rajoutant un champ de 2 octets. Le dbit
offert au terminal est alors du nombre de slots qui lui est allou, multipli par la taille dun burst en
capacit utile (cest--dire 4 paquets MPEG-2 TS), ramen la dure dune supertrame. Dans cet
exemple un slot correspond alors environ 4.62 Kb/s pour le terminal. Puisque lon peut calculer
le poids par slot avec (31), on en conclut ici une utilisation par slot de 7.01 octets.
(31)
PSlot =
n
11
+ 3. Trame + 7
nSlot
nSlot
Si lon considre le poids par slot ramen en b/s, on a la formule suivante (32), soit une
valeur dans notre cas denviron 43.18 b/s, pour un dbit de 4.62 Kb/s. Pour un dbit de 128
Kb/s sur sa voie retour, un terminal va utiliser ainsi sur sa voie aller environ 1.2 Kb/s, ce qui
reste assez faible pour le dbit de la voie aller.
(32)
11
8 28 + 4
n
+ 3. Trame + 7 . +
PSlot / s =
.10
nSlot
nSlot
1.3 nSlot
Dune manire plus globale, sur une voie aller de 38 Mbit/s, on a une consommation, pour
un transpondeur de 38 Mbit/s sur voie retour, de 354 Kb/s, soit environ 0.93% du dbit total.
1
Nous rappelons que les notations ont t introduites dans la Figure 2.13, page 38.
139
5.2.3.3.3.
CONCLUSION
Cette partie a montr linfluence assez faible du contrle daccs sur le poids de la
signalisation. En effet un canal spcifique lui est rserv sur la voie retour. Ainsi seule la voie aller
voit une faible part de son dbit consomme par lintroduction de la table TBTP, de lordre de
0.93% de la capacit totale de la voie aller. Le systme hybride, l encore, nintroduit aucune
augmentation de la signalisation, le calcul restant valable dans le cadre transparent comme
rgnratif.
5.2.3.4. Le poids de la signalisation induite par la mise jour des

tables de commutation
La mise jour des tables de commutation, comme la rsolution dadresse, a une frquence
lie aux nouvelles communications, et aux changements de topologie. Ainsi les messages sont de
nature ponctuelle. De plus, une partie de ces messages est lie au NCC qui utilise un canal rserv
pour sa communication avec le satellite, et une autre partie se situe entre le NCC et les terminaux,
et est le plus souvent couple avec les messages dAR, ou daccs au systme. Le poids des
messages uniques de mise jour des tables de communication est donc ngligeable et ninfluence
en rien le dbit du systme. Comme pour lAR, le problme est au niveau du dlai requis par une
mise jour, cest--dire du temps de rponse du systme un changement.
5.2.3.5.
Conclusion sur le poids des messages de signalisation
Nous avons vu dans cette partie que la signalisation ncessaire aux flux IP pouvait avoir de
limportance sur un systme satellite, surtout sur le lien aller, o le DVB-S nest pas toujours trs
adapt au support dIP. Toutefois, lutilisation dagrgats de flux IP dans un seul PID permet de
diminuer cette perte de ressources.
Ainsi, cette tude a permis de montrer que la signalisation des flux IP sur le systme
hybride nengendrait pas un poids de signalisation suprieur idendique celui dun systme
utilisant la mthode INT. Pour les flux mis par une gateway, cette signalisation est au maximum
de 3%. Cette borne suprieure peut tre diminue par lutilisation dagrgation de flux, jusqu
valoir 0.37% par flux. La voie retour induit plus de signalisation par son aspect dynamique, et cela
sur la voie aller elle-mme. Une constatation importante est que le systme hybride nintroduit
aucun ajout de signalisation sur le mode transparent qui nest pas directement li ce mode, ainsi
le systme reste au minimum quivalent, en terme de signalisation, un systme DVB-S utilisant
des solutions classiques.
5.2.4.
tude du temps de rponse du systme en fonction de la

rpartition bord/sol des fonctionnalits du NCC
Nous avons pu constater dans la partie prcdente quune partie de la signalisation est
ractive aux changements dans le rseau. Aussi son poids ramen une communication peut tre
considr comme ngligeable puisque li la vie dune communication. En revanche, le temps de
rponse de cette signalisation a une influence directe sur les performances du systme. En effet,
les messages qui ne sont pas priodiques reprsentent des changements de topologie (arrive de
nouvelles sources, de nouveaux membres de groupes, changement de la nature dun flux) ou des
demandes dmission. On compte pour les flux IP trois messages de ce type :
les requtes daccs principalement sur la voie retour : le flux nest pas mis tant quune
rponse, le plus souvent une attribution de slots, na pas t reue ;
les messages de rsolution dadresse MAC : ceux-ci sont les seuls ne pas tre
centraliss par le NCC. Ils ne sont donc pas tudis ici ;
140
les demandes de PIDs : ces dernires sont souvent traites de manire instantane,
notamment pour les gateways, ou en mme temps que la connexion des terminaux, ou
encore par le contrle daccs. Sans PID attribu, lmission nest pas possible ;
la mise jour des tables de commutation, sans cette dernire les flux ne sont pas
aiguills correctement. Aussi un flux unipoint nest pas permis tant que ce changement
nest pas effectu, et lattribution de PID est dailleurs effectue en mme temps, tandis
que pour lajout dun membre de groupes, cette modification influence le temps au
bout duquel le nouveau membre reoit les donnes du groupe.
Nous proposons dans cette partie dtudier linfluence de la rpartition bord/sol de
certaines fonctionnalits du NCC, et dobserver comment le systme hybride propose des
perspectives intressantes, mme pour le systme transparent. La gestion du systme tant
principalement du ressort du NCC, la rpartition de ses fonctionnalits est alors un lment clef
de loptimisation du temps de rponse du systme. Positionne traditionnellement dans une
gateway (ou quelquefois encore dans une entit ddie), le NCC a une relation troite avec le
systme satellite, si bien quil apparat comme une solution envisage dans les systmes
intelligence embarque dintgrer certaines fonctionnalits du NCC bord.
Cette partie abordera cela en analysant linfluence successive de la rpartition bord/sol de
lallocation de ressources (5.2.4.1), de lattribution des PIDs (5.2.4.2) et de la gestion des tables de
commutation (5.2.4.3). La section 5.2.4.4 conclura cette partie.
5.2.4.1.
Lallocation de ressources
Pour la voie aller, la mthode la plus simple pour le contrle daccs est dattribuer les
fonctionnalits du NCC chaque gateway. Si dans le cadre transparent, cette politique est
naturelle, dans le cadre rgnratif, cela peut poser quelques problmes dont notamment le
dimensionnement de la charge utile embarque pour quil ny ait pas de conflit avec les autres flux
des diffrentes gateways et des RCST utilisant le mode rgnratif. De plus cette mthode implique
une perte potentielle de bande passante. Toutefois pour la gestion de lallocation des ressources,
elle reste conforme au DVB-S, et est instantane. Cest la mthode choisie ici.
Pour le contrle daccs en DVB-RCS, on peut considrer que le temps de rponse
correspond au temps daccs au NCC, via un canal contention, ajout au dlai entre le RCST et
le NCC, au temps dtablissement de la TBTP (v) et au dlai retour, ce qui peut sexprimer sous la
forme1 :
(33)
TAccs = TAloha + RTTNCC + v(TST )
Nous avons dj parl prcdemment du problme de la mthode daccs (cf. 5.2.1). Le

temps daccs au support contention fait partie de ce problme (TAloha). Toutefois, nous
resterons conforme notre discussion prcdente et ne le prendront pas en compte.
Si lon note Tmin, le temps minimum requis pour qu larrive dune requte la NCC, ce
dernier ait le temps de lintgrer dans le calcul de la prochaine TBTP, on a alors un temps daccs
pouvant varier entre RTT + Tmin et le RTT + Tmin + 1.3 s.
Dans le cas idal o Tmin est ngligeable, une rapide analyse permet de conclure que
lintgration de la fonctionnalit dallocation de ressources dans lOBP peut entraner une
diminution du dlai de 14% 50%. Dans le cas o Tmin nest plus ngligeable, il y a toujours un
gain, mais un peu moindre.
Ici v est une fonction du temps dtablissement dun TBTP, directement lie la priode dune supertrame,
TST (comme nous lavons vu dans la partie 5.2.3.3)
1
141
Le temps de rponse du systme est amlior par lintgration des fonctions de contrle
daccs bord. Il faut noter cependant que ces fonctions peuvent tre lourdes mettre en oeuvre,
comme notamment lalgorithme de DAMA, et donc augmente le prix de la charge utile du
systme.
Larchitecture hybride offre donc la possibilit dintgrer les fonctionnalits dallocations de
ressource dans son mode OBP. Cette solution permet de gagner en temps de rponse pour le
mode rgnratif sur la voie retour, mais aussi de faire passer le contrle daccs de la voie retour
transparente par ce mode, gagnant alors sur les deux fronts.
5.2.4.2.
Lattribution du PID
Dans cette partie nous discutons de la fonctionnalit dattribution du PID.

Pour les gateways, si ce sont elles-mmes qui grent cette attribution, comme dans le cas de
cette proposition, ce temps est nul.
Pour les RCSTs, cette attribution est faite la demande dallocation de ressources, si
besoins. La dissociation de ces deux fonctionnalits du NCC (allocation de ressources et
attribution de PIDs) est malvenue et rajoute un temps supplmentaire. Lattribution du PID a
donc tout intrt se faire en mme temps que lattribution des slots, en donnant par exemple
dans la table TBTP le PID utiliser.
5.2.4.3.
La mise jour de la table de commutation
Ce dernier mcanisme est li la distribution de nouveaux PIDs, comme lajout dun

nouveau spot desservi par un groupe multicast. Ainsi ds quun changement est not, le NCC doit
mettre jour la table de commutation. Si cette fonctionnalit est intgre dans chaque gateway,
cette technique peut poser un problme rel de scurit, et une entit de contrle doit tre mise
en place bord.
Si le NCC est situ dans lOBP, pour le lien retour aucun dlai supplmentaire nest
introduit, le dlai est lui invitable pour les gateways, qui doivent de toute manire contacter le
satellite si elles utilisent un nouveau PID. Toutefois cette mthode permet de dcharger lOBP
dun surplus de fonctionnalits. De plus les gateways peuvent profiter de lenvoi de leur premires
donnes pour envoyer cette information lOBPC.
5.2.4.4.
Conclusion
Lattribution dun PID et le contrle daccs ne semblent pas pouvoir tre dissocis. Le
tableau suivant (Tableau IX) montre que lintgration de certaines fonctionnalits du NCC dans
lOBP amliore le temps de rponse du systme notamment pour la voie retour. On peut noter
que la mise en uvre au niveau des gateways est la meilleure solution pour le lien aller. Dans tous
les cas, lutilisation dun systme ddi uniquement au NCC nest pas la solution : autant rpartir
ces fonctionnalits dans des gateways.
La solution hybride prsente la perspective dintgrer un certain nombre de fonctionnalits
du NCC bord, grce son mode rgnratif. Si cet lment nest pas prvu dans un premier
temps dans le systme tudi prsentement, il est possible de le raliser ds que les technologies
seront suffisamment mres et abordables sur ce point. En effet lapproche hybride propose de ne
pas figer le dbat sur un systme, en proposant une architecture incrmentale.
On peut enfin noter que lutilisation du mode rgnratif pour la signalisation de la voie
retour transparente peut apporter une amlioration notable des performances du systme
transparent. En effet, le systme hybride propose, en agrgeant lallocation de ressources avec
lattribution de PID et la mise jour des tables de commutations, de rduire le nombre de bonds
satellites, et donc damliorer le temps de rponse global du systme.
142

Tableau IX. LINFLUENCE DE LA RPARTITION BORD/SOL SUR LA RACTIVIT DU SYSTME
5.2.5.
Conclusion sur la signalisation de larchitecture hybride
Au travers de cette tude, nous avons pu montrer comment larchitecture hybride

nintroduit pas une gestion plus lourde en termes de messages de signalisation quune solution
classique utilisant la mthode INT. De plus lutilisation dune encapsulation adapte reposant sur
ULE permet au systme de proposer un faible overhead d lencapsulation. Au niveau de la
signalisation, larchitecture introduit une perte de dbit aller de lordre de 1% 3%, perte qui na
rien de spcifique au systme hybride et reste semblable tout systme DVB. Enfin le systme
hybride offre des perspectives intressantes quant lamlioration du temps de rponse du
systme dans la mise en place de nouvelles communications.
Cette solution nest pas plus lourde quune autre solution DVB, et le mode rgnratif na
aucun impact ngatif sur le systme transparent. Un souci particulier a donc t port sur une
signalisation lgre, proposant mme dallger les changes au sol en introduisant une gestion
bord du satellite dun certain nombre de fonctionnalits.
5.3. Le niveau rseau

Une fois le niveau liaison tudi et sa spcificit IP analyse, le niveau 3 peut tre
considr ici. Cette partie propose dobserver lapport IP dun point de vue fonctionnel, et donc
ncessairement qualitatif.
Dans cette tude, IP se positionne comme un lment fondamental de larchitecture grce
ses deux forces : sa nature fdratrice et sa souplesse.
IP est un lment fdrateur par essence. Son historique et sa mise en uvre universelle lui
permettent de se placer comme un passage incontournable pour linterconnexion de rseaux
diffrents et pour le dploiement dapplications. IP est capable de vhiculer tout type de donnes,
certes avec plus ou moins de succs. Ainsi, mme aprs des annes de controverse sur les limites
dIPv4, il reste au cur des solutions actuelles. Malgr les difficults envisages, la VoIP sinstalle
peu peu sur le march1, et le triple play connat un grand succs avec les offres de Free, de France
Tlcom, du Neuf, etc Il en va de mme avec les propositions darchitecture de QoS ou de la
mise en uvre de la scurit.
1 On peut par exemple noter le sercice SkypeTM gratuit qui offre pour un dbit symtrique de 40 50 Kb/s
une qualit surprenante.
143
Larchitecture hybride profite de ce pouvoir fdrateur pour intgrer naturellement

diffrents services. De plus, comme il sagit dun cadre restreint, on peut facilement envisager des
architectures QoS telles que du routage QoS, de lIntServ, du DiffServ, etc Ainsi, il sera
possible de tirer plus aisment profit de la nature hybride de cette architecture.
IP est un protocole ouvert et souple, capable de sadapter nimporte quel support
puisquil ne demande presque rien aux niveaux infrieurs, si cela nest de pouvoir vhiculer des
datagrammes. Nous avons pu constater dans cette tude que cela pouvait impliquer plus ou
moins dadaptations des niveaux infrieurs, mais quau final, cela fonctionnait et des
optimisations taient mme possibles. Cette souplesse permet IP dtre adaptable des
changements au niveau des couches basses. Dans ce cadre, des ides comme celles proposes par
BSM consiste construire une interface standard IP pour tous les systmes satellites.
Il semble alors cohrent de pousser cette dmarche jusqu proposer une interface IP
standard lutilisateur, en intgrant directement le niveau IP dans larchitecture.
Il faut noter que le lien entre le niveau 3 et 2 a t cr de telle sorte quil laisse le champ
libre la cohabition entre des flux IP et des flux natifs, MPEG-2 TS. En effet, notre proposition
garde la signalisation DVB-SI, mme pour les flux IP, permettant aux RCSTs de recevoir les deux
types de flux. Cette solution serait apprciable notamment dans le cadre de services de VoD.
5.3.1.
IP et son conomie
La solution IP prsente une conomie intressante : celle dutiliser des technologies

prouves pour des systmes de nature spcifique, comme les systmes embarqus par exemple,
en vitant les difficults poses par les systmes propritaires. Cette dmarche sinscrit dans une
tendance actuelle du monde industriel pour lintgration de composants sur ltagre dans des
systmes propritaires.
Cest le cas de projets du monde satellite comme DIPCAST avec son brasseur ATM, mais
aussi des rseaux embarqus comme lA380 et son utilisation dEthernet pour lAFDX (Avionics
Full DupleX) [125].
5.3.2.
Conclusion sur le niveau 3
Lintgration dIP en tant qulment fdrateur de larchitecture hybride permet cette

dernire de profiter des capacits dIP pour intgrer diffrents services, comme pour sadapter
aux couches infrieures. Cette souplesse permet cette proposition de se positionner comme une
solution capable de supporter, avec plus ou moins de qualit, les services supports par IP,
proposant par l mme une certaine prennit.
Dun autre point de vue, larchitecture a t conue avec un certain nombre de
perspectives, qui permettent notamment dintgrer des volutions futures comme IPv6 (avec
lutilisation de ULE), et lintgration dun routeur bord. Elle prvoit donc des volutions
potentielles dIP pour rester adaptes aux trafics futurs.
5.4. Laccs Internet

La mise en uvre dIP sur satellite conduit naturellement au service daccs Internet sur
satellite. Mais ce service est aussi le premier service poser problme sur satellite. Dune part le
lien retour peut avoir un impact sur linteractivit du systme, et dautre part le protocole TCP
nest pas adapt au support sans fil et notamment le satellite (cf. 3.5.1).
Sil est un fait que le satellite noffre pas les mmes performances que les rseaux terrestres
hauts dbits, il est intressant de savoir jusqu quel point son comportement est diffrent. Cette
partie a alors un double objectif : valider les architectures de services proposes dans la partie
4.1.2.3, en montrant que mme sans modification, le satellite peut tre un support plus
144
performant quun accs bas dbit terrestre pour Internet, et observer comment le systme
hybride vient sinscrire, en jouant de sa flexibilit, dans lintgration de se service.
Cette partie sera donc dcoupe en cinq sections.
Aprs quelques mots sur la reprsentation du trafic Internet et de notre approche ici (5.4.1),
nous tudierons laccs Internet satellite dit classique dans la section 5.4.2. Ce service regroupe les
utilisations les plus communes de laccs Internet (navigation web, FTP, mail), caractre
grandement asymtrique. Cette partie argumentera sur le choix dune architecture de service avec
un lien retour terrestre.
La section 5.4.3 prsente ltude de larchitecture pressentie pour le service daccs Internet
que nous avons appel ici volu dans la mesure o il considre des applications plus rcentes,
aux changes plus symtriques, comme le P2P. Nous tudierons dans cette partie lintrt dune
topologie voie retour satellite.
Les parties 5.4.2 et 5.4.3 permettent de montrer lintrt de certaines architectures de
service, comme du satellite hybride pour pouvoir limiter grce aux multi-spots le gaspillage de
ressources. Toutefois, les performances du systme ne sont pas toujours les meilleures,
notamment cause du mauvais comportement de TCP sur satellite. Cette partie proposera
dobserver quelles influences peuvent avoir diffrentes versions de TCP sur un lien satellite, et
surtout dintgrer la solution de PEP notre architecture pour permettre dassurer au systme de
meilleures performances tout en respectant la transparence.
Enfin la partie 5.4.4 conclura cette tude, montrant comment le systme hybride peut
profiter des solutions PEPs pour permettre un accs haut dbit, sans contraintes sur les
utilisateurs finals, et totalement conforme aux principes de normalisation dj abords dans les
parties 2, 3 et 4.
5.4.1.
Reprsentation du trafic Internet
Il est dlicat de modliser le trafic Internet, mme dun seul utilisateur, car la diffrence
des trafics conventionnels tels que ceux induits par les communications tlphoniques, ce trafic
chappe au rseau lui-mme et dpend principalement des applications utilises par les
utilisateurs finals [126][127]. Or les applications voluent trs rapidement et se dissminent une
grande vitesse sur le web. Lvaluation de laccs Internet est dautant plus difficile que la
caractrisation prcise du trafic Internet dpend aussi du routage entre diffrents rseaux, de ltat
de ces rseaux et du partage des ressources. Le lien entre le trafic utilisateur, les performances du
rseau et la perception de ces performances par lutilisateur reste encore une question. Dans ce
cadre, des tudes plus globales ont russi montrer lautosimilarit du trafic Internet [128] en
analysant des traces de nombreux trafics sur des liens de backbone.
Dans notre tude les limitations du trafic utilisateur d au rseau Internet ne nous concerne
pas : il sagit doffrir un accs suffisant lutilisateur pour quil ne soit pas brid par ce dernier,
mais par les limites inhrentes Internet. Ltude se fera donc en ne considrant uniquement
larchitecture hybride.
5.4.2.
Accs Internet standard
La premire topologie propose dans la partie 4.1.2.3.1 se propose comme solution pour
laccs Internet que nous qualifions ici de standard , proposant un support des applications
largement asymtriques. Cette asymtrie entre le trafic aller et le trafic retour peut tre fixe pour
des applications de type web et email un ratio denviron 6 pour 1 [26]. Un rseau satellite
unidirectionnel, utilisant un lien retour de 28.8 kb/s, contre un lien aller de 512 kb/s, offre un
ratio denviron 17.8. Un tel rapport peut donc poser problme.
145
Nous nous proposons ici dtudier ce service, en insistant dans un premier temps sur une
comparaison avec les rseaux terrestres (5.4.2.1). Cette tude sera dailleurs loccasion de prendre
en compte pour la premire fois le modle de pertes prsent dans la partie 5.1.3.2.
La section 5.4.2.2 proposera une approche en fonction du lien retour. Ici nous pourrons
observer le phnomne de congestion des acquittements qui est un facteur limitant important de
ce type architecture de service.
La section 5.4.2.3 propose une tude de lintrt dun systme rgnratif dans le cadre de
ce service. Nous verrons ainsi quil peut tre intressant dutiliser du multi-spots pour conomiser
la bande passante, et donc que le concept dhybride sa place ici.
La conclusion de cette partie sera traite dans la conclusion dans la partie 5.4.4.
5.4.2.1.
Une comparaison au rseau terrestre
Cette comparaison avec le rseau terrestre seffectuera en trois temps : une premire
comparaison avec un modle trs simple, une seconde prenant en compte les pertes et une
dernire sur la ractivit du systme dans le cadre dune navigation web.
5.4.2.1.1.
UNE PREMIRE COMPARAISON
Dans un premier temps, une courte tude propose de comparer le service daccs Internet
via une liaison terrestre avec un lien asymtrique satellite/terrestre. Loutil de comparaison est la
simulation sous NS 2 [129], et le rseau est modlis comme suit (Figure 5.8).
Figure 5.8 Scnario de comparaison entre un accs Internet via une connexion terrestre et le
mme service via un systme satellite unidirectionnel
Dans cette comparaison, on notera que pour le lien retour, le dlai considr est de 100 ms,
puisque cette valeur nous semble reprsenter le dlai moyen dune communication client/serveur
sur le rseau Internet [42]. Nous considrons le dbit du rseau daccs comme le dbit limitant ;
il est donc utilis pour la communication de bout en bout. Dans le cas satellite, le dlai du serveur
la gateway est de 10 ms, le dlai satellite de 254 ms, et le dlai engendr par laccs au mdium
dans ce sens est nglig. Dans un premier temps la communication est effectue par temps clair.
Toutes les pertes ponctuelles du canal physique satellitaire sont considres comme corriges par
les FEC. La figure suivante propose un aperu des rsultats obtenus (Figure 5.9).
Cette comparaison montre dans un premier temps la supriorit des rseaux hauts dbits
terrestres pour laccs Internet. Toutefois pour les longs transferts, le dlai devient moins
sensible, et les performances du systme satellite se rapprochent de celles dun accs haut dbit
comme lADSL. Par contre, la comparaison avec un lien bas dbit, et notamment RTC, fait
ressortir le lien unidirectionnel asymtrique comme une alternative intressante.
Toutefois deux points viennent nuancer cette premire analyse :
146
Le trafic dit standard est plutt constitu de petits messages comme des pages web, des
mails, etc Cest donc la ractivit du systme pour les petits paquets qui est en jeu.
Dans ce cadre, on remarque que le satellite est le moins performant, pour des donnes
de trs faibles tailles (moins de 1 KB), voire en dessous dune liaison 9.6/9.6 Kb/s.
Cette comparaison pourrait tre pousse en tudiant une navigation web, utilisant le
protocole http.
Le satellite est un mdia avec un BER bien plus lev que les rseaux terrestres
classiques. Or, cette comparaison na pris en compte ce facteur.
Figure 5.9 Observation du dlai dun transfert FTP en fonction de la technologie daccs
Internet
5.4.2.1.2.
LINTRODUCTION DE PERTES DANS LA COMPARAISON
Nous proposons ici dobserver dabord une tude avec une modlisation par pertes
uniformment rparties et une autre par pertes en rafales.
5.4.2.1.2.1.
Modlisation de type Bernoulli
Dans un premier temps nous avons ajout au lien satellite une loi de perte au niveau paquet
de type Bernoulli, tel que le PLR soit de 10-3. La loi propose dans [130] donne dj une valeur
maximale pour le trafic denviron 106 paquets la seconde (34)1, soit un total de 1.24 Mb/s pour
des paquets de MSS 1460 octets.
(34)
B ( PLR ) =
1
3
RTT
2.PLR
Avec un lien satellite de 512 Kb/s, ce dbit ne peut tre atteint. Mais cette expression ne
prend pas en compte lasymtrie du lien, tant au niveau dbit que diffrence de PLR. Nous avons
donc ralis une simulation calculant lesprance du dbit utile maximale au niveau applicatif pour
un PLR de 0, de 10-3 et de 10-2, avec une seule connexion TCP. Ltude repose sur un seul
1
On note ici B, le dbit en paquets par seconde.
147
transfert FTP dune dure comprise entre 50 5000 secondes et utilisant le dbit maximal offert
par la connexion au FAI. On peut comparer cet accs en fonction de la version de TCP utilise et
de la dure du transfert (Tableau X).
Tableau X. COMPARAISON DU DBIT MOYEN OBSERV SUR UN TRANSFERT FTP EN FONCTION DE
LA DURE DOBSERVATION MODLE DERREUR UNIFORMMENT RPARTIE
On observe ici diffrents lments. Dune part, plus le temps du transfert est important,
plus le dbit offert lapplication devient stable, sauf dans le cas dun taux de perte trop lev.
Dautre part, les dbits proposs, mme pour 10 secondes de transfert dans des conditions trs
bruites, restent suprieurs ceux dune connexion RNIS 64 Kb/s ou 128 Kb/s. Enfin on peut
noter avec ce tableau la lgre amlioration que peut apporter TCP NewReno compar TCP
Reno, surtout quand il y a beaucoup derreurs. Dans le dernier cas, on peut remarquer un meilleur
dbit pour 10 secondes de transfert. Lexplication est ici assez simple : vu le faible taux de pertes,
il ny a pas eu beaucoup de pertes sur ce court temps. A partir dun certaine dure de transfert, le
support satellite unidirectionnel est donc plus intressant quun lien terrestre bas dbit, mme de
type Numris.
Tableau XI. COMPARAISON DU DBIT MOYEN OBSERV SUR UN TRANSFERT FTP EN FONCTION DE
LA DURE DOBSERVATION MODLE DERREUR DEUX TATS
148
5.4.2.1.2.2.
Modlisation de type Gilbert
Toutefois, le modle derreur utilis ici nest pas trs raliste. Le modle propos dans la
partie 5.1.3.2 est donc utilis ici pour avoir une ide de limpact de pertes en rafale sur le service.
Dans ce cadre, les simulations ont t ralises en prenant successivement un PLR de 10-4,
de 10 et de 10-2, tout en gardant des rafales de mme taille en moyenne (4 paquets), soit une
valeur de q gale 0.25 (Tableau XI).
-3
Lobservation reste dans les grandes lignes la mme que prcdemment. Toutefois on peut
noter que les pertes en rafales ont une influence moindre sur le transfert que les pertes
uniformment rparties : le dbit est dans lensemble plutt meilleur. Ce principe vient du fait que
pour une seule erreur, TCP tend considrer une rafale derreur, entranant la rmission dun
grand nombre de donnes dj reues. Lors de rafales, TCP se comporte de la mme manire, or
le modle de rafales peut introduire une perte de plus de 10 paquets conscutifs (Figure 5.10).
Ainsi un mme taux de pertes global, TCP se comporte mieux sur un mdium o les pertes de
paquets se produisent en rafales, car les rmissions se font de manire plus efficace.
Figure 5.10 Exemple de pertes en rafale pour un PLR de 10-3 avec le modle de Gilbert
5.4.2.1.2.3.
Conclusion
Lintroduction de pertes dans la modlisation baisse certes les performances du systme,

mais celles-ci restent suprieures aux rseaux bas dbit. De plus, les pertes de type rafale sont
mieux supportes par les applications de type FTP. Pour la suite de cette tude, nous utiliserons
alors, quand cela est ncessaire, le modle deux tats pour reprsenter les pertes.
Ce type darchitecture de service est donc envisageable dans le cadre du systme hybride.
5.4.2.1.3.
UNE COMPARAISON REPOSANT SUR LE PROTOCOLE HTTP
Une troisime tude mene dans ce cadre repose sur le protocole HTTP. Avec un profil
dutilisateur identique dans chaque cas, nous proposons dobserver le nombre de pages
consultes pendant une priode de consultation dun quart dheure, soit 900 s. Ltude reprend la
topologie prsente prcdemment. Nous comparons ici un accs unidirectionnel satellite avec
retour terrestre diffrentes accs terrestres. Ltude satellite utilise le modle derreur en rafale
prsent prcdemment, avec un PLR de 10-3. Le comportement de lutilisateur est modlis par
un intervalle entre deux requtes suivant une loi de Poisson, de moyenne 5 s (aprs que la
prcdente requte ait t traite). La rpartition des tailles de pages web suit une loi exponentielle
dont la variation de la moyenne est un critre dtude ici. Les rsultats (Figure 5.11) sont obtenus
via la mthode du batch mean, soit une moyenne sur 100 blocs de 900 secondes. Pour un quart
149
dheure, nous considrons les rsultats suffisamment dcorrls. Les simulations ont t ralises
sous NS 2.
Figure 5.11 volution du nombre de pages http consultes en un quart dheure en fonction de la
taille moyenne de ces pages
Les figures ci-dessus reprsentent cette volution. On peut constater que la ractivit dun
accs satellite unidirectionnel, contrairement aux a priori, est presque comparable celle dun
accs ADSL. En effet si lon considre que la taille moyenne des pages web sont de 50 KB [130],
en un quart dheure un utilisateur accdant Internet via un systme satellite unidirectionnel, aura
consult en moyenne 94.1 pages (retour 9.6 Kb/s), contre 117,5 pour un accs ADSL. De plus
on peut noter que, mis part pour des pages en moyenne trs petites, laccs par satellite
unidirectionnel a de trs bonnes performances. Pour des pages de tailles importantes, il dpasse
de loin les accs terrestres bas dbit, tous types confondus. Lvolution de la courbe montre
comment le dbit du lien influence plus directement la navigation web estompant limpact du
dlai, quand les pages ont une tendance tre importantes.
La navigation web sur un accs satellite unidirectionnel propose des performances
satisfaisantes, pouvant avoir un gain sur un accs trs bas dbit de lordre de 900 % pour des
pages en moyenne de 50 KB.
150
5.4.2.1.4.
CONCLUSION
Ces premires tudes permettent de conclure positivement sur le support dun service
daccs par satellite. Larchitecture propose pour laccs Internet standard est une solution
meilleure que les solutions de type terrestre disponibles dans des zones isoles.
5.4.2.2.
Linfluence du lien retour
Nous avons valid prcdemment cette architecture de service comparativement aux accs
terrestres. Toutefois, comme nous lavons not prcdemment, un lien retour modem est
susceptible de poser problme, mme pour un trafic asymtrique. Une solution purement satellite
peut-elle tre meilleure ?
Nous proposons dans un premier temps dobserver limpact de la nature du lien retour
dans la section 5.4.2.2.1, puis dobserver comment un lien terrestre est une solution plus adapte
au service daccs Internet standard, avec notamment ltude dune consultation de pages web
(5.4.2.2.2). Enfin la section 5.4.2.2.3 conclura cette tude.
Dans ce cadre nous avons ralis plusieurs expriences sous NS 2 mettant en jeu un
utilisateur connect Internet via le systme hybride sur la voie aller, et une connexion terrestre
sur la voie retour. Nous considrons un client avec un dbit aller garanti 512 Kb/s, la
signalisation tant ngligeable. La figure suivante (Figure 5.12) trace lvolution de trois ratios
entre les dlais ncessaires pour vhiculer une donne en fonction de la taille de cette donne.
Parce quil est question dune comparaison entre plusieurs liens satellite, ltude est effectue sans
lintroduction dun modle de pertes.
5.4.2.2.1.
UNE COMPARAISON SUR UN TRANSFERT FTP
Figure 5.12 Comparaison de lvolution du dlai requis pour tlcharger un fichier via FTP en
fonction du dbit offert par le lien retour pour un lien aller de 512 Kb/s
Mis part pour un lien retour de 9.6 Kb/s, ce trac montre que, limpact du lien retour est
peu notable pour un lien aller de 512 Kb/s. En revanche pour un lien retour de 9.6 Kb/s, on
peut mettre 1 acquittement de 40 B toutes les 33.3 ms, soit un dbit maximal sur le lien aller
denviron 350.4 Kb/s au niveau applicatif. Pour un dbit retour de 28.8 Kb/s, le dbit maximal
aller est atteint. Pour un dbit aller plus lev, la congestion des acquittements sur le lien retour
est relle, et donc ce ratio devient bien plus significatif. Cependant dans le cadre dune connexion
151
de type standard, il ne semble pas envisageable dutiliser un lien aller satellite de 2 Mb/s, avec un
lien retour terrestre de 9.6 Kb/s.
5.4.2.2.2.
UNE COMPARAISON SUR UNE CONSULTATION DE PAGES WEB
Dun autre point de vue, le lien terrestre offre gnralement un meilleur temps de rponse,
comparativement au lien retour satellite. Ainsi pour une seule navigation web, le transfert dun
fichier http de 50 KB1 demande la transmission de 35 segments TCP de MSS 1460 B. La
communication stablit alors selon la poigne de main classique de TCP :
le client demande louverture dune connexion TCP avec le serveur via un SYN.
Posons alors TSYN le temps dmission du SYN sur le lien retour.
le serveur met lacquittement du SYN (SYNACK), soit TSYNACK le temps dmission

du SYNACK sur le lien aller.
le client acquitte louverture de connexion en envoyant un ACK au serveur. Soit TA le

temps dmission dun ACK sur le lien retour.
Une fois la connexion TCP ouverte, avec un temps total not TConnexion, le client peut
entamer sa requte HTTP :
le client envoie un GET au serveur. Nous noterons TGET le temps requis lmission
du GET sur le lien retour ;
le serveur rpond en envoyant le premier segment, not S1, avec un temps dmission
TS1 ;
la rception du segment, le client renvoie un ACK ;
chaque rception dACK par le serveur, deux nouveaux segments sont envoys par ce
dernier, jusquau dernier segment ;
la fin de la communication, le serveur clos la connexion.

Dans le cadre de cette tude, nous considrons quil ny a aucune perte sur le transfert.
Nous notons TSA, le dlai introduit par le temps de propagation du serveur au client, et sur TCR, le
dlai sur le lien retour. La figure suivante2 (Figure 5.13) rsume ces premires considrations. Le
dbit des liens est pris constant, ainsi que le dlai.
Pour pouvoir calculer la dure totale dune communication HTTP, il faut sassurer que la
pause est bien suprieure 0 (Figure 5.13), soit :
n
(35)
T
i =0
S (i + k )
TSi + TSA + TACK + TCR
Dans le cas o le MSS est constant, le dernier segment pouvant tre la limite plus court,
cela donne la majoration suivante :
(36)
n.TS TS + TSA + TACK + TCR
Pour des acquittements de 40 B, des datagrammes de 1500 B, on obtient alors une valeur
de n pour le cas unidirectionnel de 17 segments, et de 23 segments dans le cas bidirectionnel. Or,
dans le cas de 35 segments et avec une fentre initiale fixe 1, il ny aura pas plus de 16
segments envoyer dun seul coup.
1
Taille moyenne prcdemment utilise dans la partie 5.4.2.1.3
Cette figure nest pas lchelle.
152
Figure 5.13 Diagramme simplifi dune communication HTTP
Si on note TTU et TTB, le temps total requis pour que lutilisateur reoive la page web,
respectivement dans le cas unidirectionnel et bidirectionnel, on a alors :
TT = TConnexion + TGET + TCS + 5.(TS + TSA + TACK + TCR ) + TFIN
(37)
Avec
TConnexion = TSYNC + TCS + TSYNACK + TSA + TACK
(38)
Et, o TS(400) est le temps requis pour mettre les 400 octets restants.
TFIN = 3.TS + TS (400) + TSA
(39)
Soit aprs applications numriques, un TTU de 2.847 s contre un TTB de 3.914 s. On

constate donc un gain de lordre de 27.3 % entre le cas bidirectionnel et le cas unidirectionnel. Le
lien retour terrestre est donc mieux adapt que le retour satellite pour les applications de type
navigation web. Il faut noter cependant que pour le lien retour terrestre, surtout dans les cas de
faibles dbits (9.6 28.8 Kb/s), la liaison aller peut tre bride par la congestion des
acquittements sur le lien retour. Toutefois comme cette tude a pu le montrer, pour un dbit aller
de 512 Kb/s, cet effet est limit, et peut donner des performances tout fait suffisantes quand le
dbit retour est de 28.8 Kb/s ou plus.
5.4.2.2.3.
CONCLUSION
Nous avons not ici la difficult que peut reprsenter un lien retour trs faible dbit, cest-dire 9.6 Kb/s. Toutefois ce bas dbit permet, dune part, au systme de mieux fonctionner
153
quun accs de type Numris et, dautre part, une faible augmentation de ce dernier est suffisante
pour pouvoir atteindre le dbit maximum du lien aller.
On peut tout de mme noter ici un avantage utiliser un lien retour de type Numris
lorsque le satellite peut offrir ponctuellement un dbit important sur la voie aller (jusqu 4
Mb/s), avec des techniques de type Turbo Button 1.
Enfin cette tude a montr la plus grande ractivit dun lien retour terrestre, mme trs
bas dbit, pour la navigation web. Lutilisation dun architecture de service reposant sur un lien
aller DVB-S et un retour terrestre est donc une solution satisfaisante pour un accs Internet
standard, car plus adapte quun retour satellite en terme de ractivit et de cot.
5.4.2.3.
Linfluence de lutilisation de lintelligence embarque
Dans cette dernire partie de ltude de lintgration du service daccs Internet standard,
lintrt de lutilisation du satellite hybride est soulev. En effet, nous avons montr au cours de
cette partie que laccs Internet standard pouvait tre support par le systme hybride aussi bien
que nimporte quel autre systme satellite. En soi cette conclusion est importante, impliquant
quelle peut tre intgre avec dautres services dans larchitecture hybride. La nature flexible du
systme hydride peut offrir un gain supplmentaire ce service grce son mode rgnratif.
En effet, ltude prcdente ne prend jamais en compte une charge rgnrative. Il est vrai
que pour un accs Internet par voie satellite unidirectionnelle, lintrt de lOBP nest pas a priori
dans le traitement bord en lui-mme, mais dans lapport de lutilisation des techniques
multifaisceaux. Aussi, le satellite offre une perspective conomique qui peut apparatre dintrt
pour loprateur satellite : conomiser la capacit des spots non concerns par la communication.
Considrons une gateway mettant sur un satellite hybride des flux unipoints. La
configuration et les notations pour le mode transparent et rgnratif sont prsentes ci-dessous.
Figure 5.14 Utilisation du monofaisceau et du multifaisceaux pour la voie aller DVB-S
On peut considrer le problme par deux points de vue : soit en fixant un dbit Du_t ou
Du_r pour le FAI, et en observant combien loprateur satellite peut conomiser de bande
passante sur la couverture, soit en laissant libre Du_t ou Du_r et en observant quel est le maximum
que peut obtenir le FAI dans lun et lautre cas. Nous allons considrer la premire proposition
qui nous parat la plus abordable.
1 Par exemple les propositions de BellSouth Turbozone, avec des proposition de DSL 56k, avec des
augmentations jusqu 3 Mb/s. On peut aussi trouver dautres propositions comme celles de Laurel :
http://www.telecomweb.com/news/1088046617.htm.
154
Dans le cadre transparent, si lon octroie un multiplexe complet au FAI, on retrouve ce

mme multiplexe sur le lien descendant, do Du_t est gal Dd_t. Dans le cas rgnratif, si lon
fait la mme supposition, on doit retrouver au total le dbit dun multiplexe sur les diffrents
spots. Supposons que les clients soient uniformment rpartis parmi les faisceaux, Du_r est alors
galement rparti sur chaque faisceau. On a alors lexpression suivante (40), o DDi est le dbit
engendr par la gateway sur le spot i, et DD est ce mme dbit lorsquil devient indpendant de i.
n
Du _ r = DDi = n.DD
(40)
i =1
On peut alors considrer le dbit restant sur le spot i (41), not Di, o la deuxime galit
nest valable que dans le cas dune rpartition uniforme.
Di = DDi _ r DDi = DDi _ r
(41)
Du _ r
n
Dans un cadre multifaisceaux, on peut considrer que, par spot, le dbit du multiplexe
descendant est gal la valeur du dbit sur le multiplexe montant multipli par un facteur k,dfini
en 4.3.1.4.2. On a alors lexpression suivante :
Di = k .Du _ r DDi = k Du _ r
n
(42)
Do un gain, compar au cas monofaisceau, de :

n
(43)
G=
D
i =1
DD _ t
n k Du _ r
n
=
= nk 1
Du _ r
Ainsi par rapport au cas transparent, loprateur du systme peut faire passer nk-1 fois plus
de dbit montant sur son systme. Soit pour une valeur de k comprise entre 0.7 et 0.8, le tableau
suivant (Tableau XII), qui donne une ide de la bande passante rutilisable par loprateur.
Tableau XII. GAIN DU MULTIFAISCEAUX POUR LA VOIE ALLER EN MODE UNIPOINT
16
32
0.7
1.8
4.6
10.2
21.4
0.8
2.2
5.4
11.8
24.6
Dans lensemble, on peut noter quil pourra toujours rutiliser n*DD - Du_r, soit toujours
lexpression (43) qui peut ainsi se gnraliser au cas de rpartition non uniforme.
Pour des communications haut dbit de type unipoint, il semble dommage dutiliser un
lien transparent, utilisant ce dbit sur la totalit de la couverture du satellite pour un seul
utilisateur. La couverture multifaisceaux est donc intressante si le gain pour loprateur justifie le
cot dutilisation de la technologie, typiquement pour les dbits importants, et non les
communications avec un faible poids de donnes (comme la consultation de pages webs). En
effet, lutilisation du mode rgnratif introduit une signalisation plus complexe, qui est certes
ngligeable pour les flux importants, comme nous lavons montr dans la partie 5.2.3, mais pas
pour un grand nombre de flux faible dbit. Comme les notions de cot rel sont des donnes
hors de notre atteinte, ltude est une analyse a priori et ne peut tre poursuivie plus loin.
155
Cette analyse montre quil y a un gain potentiel utiliser une charge rgnrative, mais que
cette utilisation est rserve plutt aux flux importants. Larchitecture hybride sintgre alors
parfaitement dans cette optique par la flexibilit daiguillage entre ses deux modes.
5.4.3.
Accs Internet volu
Dans un premier temps nous avons vu laccs unidirectionnel. Celui-ci est justifi pour un
service dit classique, mlant les applications les plus courantes de laccs Internet (navigation,
web, FTP,). Ce profil dapplication est particulirement asymtrique, privilgiant les accs types
serveurs/clients, o lupload est important, mais la voie retour nest utilise que pour les requtes
et les acquittements. Dans ce cadre nous avons montr comment le systme hybride pouvait
contribuer au dploiement dun tel service.
Lapparition dapplications dchanges de donnes, telles que le P2P, a cr une nouvelle
demande sur le march : celle dun accs plus symtrique. Le terme accs volu englobe ici
ces nouveaux services. Dans ce cadre limpact plus important du lien retour, nous a fait
considrer laccs satellite bidirectionnel comme la solution privilgie ce type de service.
Comme la partie prcdente, cette tude vise montrer la validit de cette architecture de
service, et lintrt dutiliser un systme hybride. Toutefois, cette partie prsentera un intrt
particulier montrer comment un paramtrage diffrent peut apporter une nette amlioration des
performances du systme.
Ainsi nous comparerons cet accs avec la solution terrestre dans la section 5.4.3.1,
montrant que ce dbit reste suprieur un accs terrestre bas dbit. Pour palier ces problmes,
nous observerons tour tour des amliorations qui peuvent tre introduites au niveau applicatif
par un comportement commun des utilisateurs (5.4.3.2), ou par des gestions particulires au
niveau liaison/physique (5.4.3.3). La section suivante (5.4.3.4) propose une comparaison avec
larchitecture de service prcdente. Enfin la section 5.4.3.5 traite lintrt des deux modes du
systme hybride.
5.4.3.1.
Une comparaison avec laccs terrestre
La comparaison faite prcdemment pour laccs unidirectionnel par satellite reste en partie
valable. Toutefois, trois points importants sont noter : laugmentation du RTT, le taux de perte
non ngligeable sur la voie retour, et le temps daccs sur cette mme voie qui peut savrer lev.
Figure 5.15 Scnario de comparaison entre un accs Internet via une connexion terrestre et le
mme service via un systme satellite bidirectionnel
Nous partons sur le principe que laccs satellite sur voie retour utilise une rservation de
type CBR, le temps daccs au systme est alors ngligeable. La modlisation prsente dans la
figure ci-dessus (Figure 5.15) permet dobtenir sous NS 2 lvolution du dbit en fonction du
156
temps de transfert (Figure 5.16)12. Il faut noter que la version de TCP utilise est TCP Reno.
Quant au modle de pertes, il sagit de celui prsent prcdemment (5.1.3.2.). Les buffers
dmission du client et du serveur sont fixs 150 KB dans cette simulation. Les MSS sur le lien
aller et le lien retour sont de 1460 B.
Figure 5.16 volution du dbit applicatif observ sur le lien aller et retour en fonction du temps
Comme on peut le noter dans la figure prcdente (Figure 5.16), les performances du lien
aller sont affectes par le transfert upload qui a lieu sur le lien retour. En effet, lorsque lon
compare le dbit pour le transfert download sans et avec un transfert sur le lien retour, on obtient
une rduction du dbit de plus de 70% ( 5000 s).
La raison principale de ce gaspillage de ressources provient de lattente importante des
acquittements dans le buffer dmission sur le lien retour du client, le temps que les datagrammes
destination du serveur soient mis. Cest ce qui explique lapparition de variations sur la courbe
ci-dessus. Toutefois il faut noter que ce nest pas lunique cause, puisquune partie de ces
variations est aussi due aux pertes de paquets en rafale, comme on peut le noter dans la courbe
suivante (Figure 5.17). En effet lorsque lon regarde la simulation, on se rend compte que les 16
premiers paquets perdus sont en fait des acquittements de la communication aller.
Ce dbit reste toutefois quivalent au meilleur accs terrestre possible dans les zones
isoles, le RNIS (on obtient un dbit applicatif aller comme retour de 121.24 Kb/s 5000 s
contre 131.5 Kb/s et 118.5 Kb/s pour un accs satellite).
La solution satellite, mme non optimise, reste donc une solution admissible compare
aux solutions de type terrestre. Cependant, son cot est peut-tre lev pour proposer des
performances de la sorte. Si le lien retour est effectivement utilis pleine capacit, le lien aller
reste dans ce cadre peu rentabilis.
1 Il faut noter que ce dbit est le dbit moyen calcul de 0 t, et non pas le dbit moyenn sur une seconde,
qui lui tmoigne plus directement de limpact des pertes, mais est plus difficile comparer. Ainsi si lon considre la
valeur t = 100s, le dbit reprsent est la moyenne sur lintervalle [0,100].
2
Nous ne reprsenterons ici que lvolution pour le cas satellite.
157
Figure 5.17 Profil de pertes au cours de la simulation sur la voie aller et retour
5.4.3.2.
Une optimisation au niveau applicatif
Il existe plusieurs mthodes pour remdier ce problme. En effet cet amoindrissement

sur du dbit sur la voie aller est caus par lengorgement des acquittements dans la file dattente
du buffer dmission, devant attendre lmission de la fentre TCP de la communication sur la voie
retour.
Une premire solution consiste sattaquer directement la cause du problme, et donc
sinterroger sur le fonctionnement du protocole TCP sur satellite (cf. 3.5.2). Toutefois, il existe
des possibilits de remdier ce problme, notamment au niveau applicatif.
La limitation de lupload est une de ces solutions. Cette limitation peut se faire plusieurs
niveaux, dont le plus simple est certainement le niveau applicatif. Mais encore ici la notion de
transparence peut tre malmene, sachant que cest lapplication utilisateur qui doit limiter ce
dbit. De plus, il est rare que lutilisateur, voire lapplication, ait conscience quun dbit important
sur sa voie retour risque dentraner une diminution de son dbit aller.
Nanmoins la plupart des logiciels de ce type permettent de fixer un seuil sur ce dbit
dupload, et un grand nombre dutilisateurs lutilise pour pouvoir continuer naviguer sans
problme, et limiter les accs disques leur systme. Dans ce cadre, nous avons fix
successivement le dbit maximum utilisable par le transfert retour 80 Kb/s et 100 Kb/s, et
constat lvolution du dbit aller et retour (Figure 5.18). Une limitation de 83 % du dbit retour,
donne une augmentation de lordre de 333 % pour le transfert aller, le cas 100 Kb/s donnant
dailleurs daussi bonnes performances que le cas 80 Kb/s. Il suffit donc de rserver un dbit
suffisant pour les acquittements pour retrouver les performances dun transfert unidirectionnel1.
1 Notons que ce type de solution est aussi valable pour les accs asymtriques terrestre, tel que laccs
512/128 Kb/s ADSL qui souvre de ce mme problme.
158
Figure 5.18 volutions du dbit applicatif observ sur le lien aller et retour en fonction du temps
de simulation avec limitation 80 Kb/s et 100 Kb/s du dbit de type upload
5.4.3.3.
Des optimisations au niveau liaison
Le niveau MAC offre aussi des solutions ce problme. En effet lengorgement du buffer
dmission est la raison physique de la baisse du dbit dmission des acquittements sur le lien,
entranant implacablement la chute du dbit en download. Pour palier cela, nous avons envisag
trois solutions : rgler la taille du buffer dmission, appliquer une politique de service en fonction
des flux, ou limiter le MTU sur le lien1.
5.4.3.3.1.
LINFLUENCE DE LA TAILLE DES BUFFERS DMISSION
Linfluence de la taille des buffers sur les deux communications est le premier point trait ici.
Nous proposons de faire varier la taille de ces buffers et dobserver les rsultats donns par
simulation. Dans un premier temps, observons ces rsultats pour des buffers dmission 50 KB, et
de 100 KB. Pour donner une ide de linfluence du modle de pertes choisi, nous prsentons les
rsultats sans et avec pertes (Figure 5.19).
Cette figure souligne deux points. Tout dabord cette optimisation a bien une influence
similaire sur un modle avec et sans perte. Pour un buffer plus petit, les paquets de 1500 octets sur
la voie retour ont une plus grande chance dtre limins que les acquittements de 40 octets. Les
mcanismes de TCP dtectent alors de la congestion dans le systme, et diminuent le dbit
dmission sur le lien retour, laissant alors champ libre aux acquittements. La seconde conclusion
que lon peut tirer de cette tude est la plus dlicate stabilit du systme dans ce cas, qui donne
des rsultats moins performants que la solution applicative prcdente. Enfin on peut noter que
la prsence derreur na pas toujours un impact ngatif sur le systme, puisquil peut permettre de
diminuer le dbit en upload, et ainsi augmenter le dbit sur le lien retour. Toutefois on ne peut
sappuyer vraiment sur cette constatation pour optimiser le systme.
Pour constater quel point cette influence est sensible, nous avons fait varier la taille des
buffers de 3 KB 200 KB pour une simulation de 5000 s. La figure suivante (Figure 5.20)
reprsente alors lvolution du dbit moyen obtenu pour le transfert aller et le transfert retour en
fonction de la taille du buffer dmission aller et retour (nous affectons la mme taille aux deux
buffers pour la simulation).
Cette dernire solution est souvent mise en uvre sur les accs asymtriques terrestre bas dbit.
159
avec un buffer dmission de 50 KB et de 100 KB
On peut observer ici linfluence relle de la taille des buffers dmission sur le dbit moyen
aller et retour. Cet impact est bien plus important sur le flux destination, que celui en partance.
En effet la variation peut aller jusqu prs de 700 % sur le lien aller, alors que pour le flux en
upload, on observe une variation de moins de 100 % (au maximum). La taille optimale pour la
voie aller semble tre de 41 KB, avec un dbit aller moyen de 338.65 B, contre un dbit retour de
85.6 KB.
Cette variation surprenante est essentiellement due la rgulation des changes TCP. Dans
un change bidirectionnel comme celui l, aucun tat stationnaire nest vraiment possible, il sagit
alors plutt dun cycle de remplissage des buffers. Ainsi lorsque le buffer dmission du client arrive
saturation, les paquets mettre, acquittements comme donnes, sont rejets. Toutefois, les
donnes tant plus volumineuses que les acquittements, elles ont plus de chance dtre
supprimes. Le flux upload TCP sautorgule alors, baissant son dbit, et laissant la voie libre aux
acquittements de la voie descendante. On arrive alors dans un tat cyclique de remplissage du
buffer. Un tat optimal peut alors tre trouv.
160
Plus la taille du buffer dmission du serveur augmente, plus celui-ci peut mettre
efficacement vers le client, entranant une augmentation du dbit aller.
Plus la taille du buffer dmission du client augmente, plus il est possible dmettre de
paquets en upload, augmentant le temps dattente des acquittements dans la file dattente, et
dgradant ainsi le dbit de la voie aller.
Puisque cette courbe reprsente lvolution en simultane des deux buffers, il est normal
dobserver cette double volution. Les oscillations sont dues en grande partie ce phnomne,
cumul limpact des variations de la taille du buffer, qui entrane la perte ou non dacquittements,
et donc une dgradation potentielle du dbit du lien aller.
Figure 5.20 volution du dbit moyen applicatif sur 5000 s en fonction de la taille des buffers
dmission
On peut enfin noter un seuil qui correspond une taille dcisive de la file dattente, au-del
de laquelle le RTO de TCP se dclenchera dans tous les cas. Aucun paquet nest perdu par des
files dattente suprieures 87 KB, mais cest TCP qui sautorgule alors, entranant une baisse du
dbit, et donc une diminution de la taille de la file dattente. Ce qui explique que lors dune telle
communication, le buffer dmission ne pourra jamais dpasser une certaine taille (ici 87 KB), et
donc le comportement de TCP sera identique au-del de cette valeur.
5.4.3.3.2.
LINFLUENCE DE LA POLITIQUE DE SERVICE DES BUFFERS

DMISSION
Une autre mthode consiste grer le buffer dmission au niveau de linterface IP, ou
MAC. Ainsi il est possible dimplanter ici une politique diffrente du FIFO, permettant de
donner une priorit quivalente voire plus grande aux acquittements. La politique de service sur la
file peut ainsi tre change, mais dautres files peuvent aussi tre introduites, une pour les trafics
prioritaires, de type temps rel par exemple, et une autre pour les autres.
Nous proposons ici dobserver lamlioration apporte par ces techniques sur le dbit
applicatif du systme. Les figures suivantes prsentent respectivement la mise en oeuvre dune
politique de diminution du nombre de paquet en attente dans la file pour un type de flux donn
(cette politique est introduite en NS sous de nom de Deficient Round Robin) (Figure 5.21), et du Fair
Queueing (Figure 5.22) reposant sur un Round Robin prenant en compte la taille des donnes.
161
avec une politique de Deficient Round Robin sur le buffer dmission de 150 KB
avec une politique de Fair Queueing sur le buffer dmission de 150 KB
Sur ces deux courbes, on peut constater lamlioration trs nette apporte par une gestion
de la file dmission du client. On pourra noter une meilleure performance du Fair Queueing pour
le dbit applicatif aller. En effet, son utilisation fonde sur la distribution dtiquette en fonction
du trafic transmis, permet dassurer aux acquittements un passage rapide en tte de la file, nayant
qu attendre tout au plus lmission du datagramme en cours du flux dupload (le mode premptif
tant rarement conseill). De plus, lattribution des tiquettes se fonde sur la taille des donnes,
permettant pour des paquets de MTU 1500 B, denvoyer entre 37 et 38 acquittements pour un
datagramme dupload. Dans le cas du Deficient Round Robin, lamlioration est notable, mais le flux
des acquittements a encore souffrir de grandes variations, ce qui explique de moins bonnes
expriences (Figure 5.23).
162
Figure 5.23 Aperu de lvolution de la file dattente dmission dans le cas DRR et FQ
5.4.3.3.3.
LINFLUENCE DE LA MTU
Une dernire solution propose ici est la diminution de la MTU sur le lien retour. Ce type
de problme a dj t rencontr sur les rseaux terrestres qui, pour permettre une meilleure
ractivit, fixent la MTU sur le lien retour 576 B (valeur plus communment utilise sur
Internet), soit une MSS de 536 B.
Lavantage de ce type de solution est tudi ici, montrant linfluence dun dcoupage en
plus petits paquets sur la voie retour. Il faut noter quil nest pas tout fait dans lintrt de la voie
retour dutiliser une MTU plus petite que 1500 B, puisque cela gnrerait un grand nombre
dacquittements supplmentaires sur la voie retour, ainsi quune diminution du trafic TCP dans la
priode de slow start et de congestion avoidance (priode trs sensible sur le satellite).
Figure 5.24 volution du dbit applicatif observ sur le lien aller et retour en fonction du temps et
de la MSS du lien retour.
Les figures ci-dessus proposent dobserver lvolution du dbit moyen en fonction du

temps. Nous avons fait cette tude pour diffrentes valeurs de la MSS, et nous proposons ici les
163
courbes obtenues pour des MSS de 88, 216, et 536 et 1460 B. Le cas 1460 B est prsent
prcdemment dans cette partie (Figure 5.16), les autres sont tracs dans la figure ci-dessus.
On observe dans ces courbes une trs nette corrlation entre laugmentation du dbit aller
et la diminution du dbit retour. Ainsi pour le passage dune MSS de 216 B 88 B, on observe
une diminution de plus de 50 % pour le dbit applicatif retour, contre peine une augmentation
de 10 % sur la voie aller.
Cependant si lon compare les rsultats obtenus pour une MSS de 1460 B et ceux pour 536
B, on a une baisse sur le lien retour de quelques pourcents pour une augmentation entre 100% et
150 % pour le dbit applicatif retour. On peut donc conclure que cette mthode peut apporter
un gain rel de performance condition de garder une MSS de lordre de 500 B sur la voie retour,
pour ne pas dgrader le dbit en upload.
5.4.3.3.4.
CONCLUSION SUR CES OPTIMISATIONS
Nous pouvons noter dans cette partie quun grand nombre de ces optimisations permettent
damliorer le dbit aller au dtriment plus ou moins important de la voie retour. Toutefois, la
majeure partie de ces solutions permet de gagner plus que lon ne perd. Une solution comme
lapplication dune politique de service du buffer dmission permet doffrir de trs bons rsultats,
sans une baisse trop importante du dbit applicatif sur la voie retour.
Ces amliorations nous semblent trs utiles pour obtenir un service performant, et doivent
donc tre prises en compte dans le systme hybride, dautant plus que des modifications au
niveau liaison restent transparentes pour lutilisateur final.
5.4.3.4. Une comparaison entre laccs unidirectionnel et laccs

bidirectionnel satellite
Le choix de larchitecture de ce type est justifi pour avoir un dbit retour important.
Lutilisation dun accs unidirectionnel pour avoir ces capacits doit utiliser un lien retour dbit
important. Hors le maximum est une ligne Numris de 128 Kb/s, au dbit difficilement
augmentable contrairement au satellite, o une simple demande loprateur permet de porter ce
dbit jusqu 1, 2 ou 4 Mb/s.
MSS voie retour 536B
MSS voie retour 1460 B
Figure 5.25 volution du dbit moyen sur 5000 s en fonction de la taille des buffers dmission
pour un lien retour terrestre de 28.8 Kb/s et une MSS de 476 et 1460 B
Un autre type de lien retour, typique entre 9.6 Kb/s et 28.8 Kb/s a de srieuses limites
pour ce type de service. Une rapide tude permet de le montrer. On retrouve une autre chelle
les difficults dasymtrie voques prcdemment. Des amliorations similaires peuvent alors
tre apportes, mais leur marge daction est plus restreinte dans la mesure o la voie retour reste
164
trs limite en dbit. La figure prcdente (Figure 5.25) propose un aperu des dbits applicatifs
aller et retour, en fonction de la taille du buffer dmission du client, montrant comment le systme
reste limit par son dbit maximum, inhrent au lien retour. On notera que ces simulations ont
t ralises sans lintroduction de pertes dues au canal physique, pour pouvoir observer
uniquement linfluence dsire.
La courbe ci-dessous montre un comportement identique au lien satellite bidirectionnel :
linfluence de la taille du buffer dmission client a un impact important sur la communication aller
comme retour. On peut observer que pour des segments de plus grande taille sur la voie retour, la
courbe de dbit est plus instable, puisque la perte dun paquet sen ressent davantage. En
revanche, des paquets de petites tailles sur le lien retour avantagent le lien aller.
Le seuil observ nest pas non plus tout fait le mme selon les MSS : il est plus lev dans
le cas dune MSS plus leve, sexpliquant par le fait que ce seuil corresponde au nombre de
paquets quil peut y avoir dans le buffer avant que le RTO ne sactive.
Enfin on peut noter que le lien retour terrestre bas dbit, de type modem 28.8 Kb/s, peut
poser problme par sa forte asymtrie pour un trafic de type FTP important (Figure 4.7).
Larchitecture satellite bidirectionnelle se justifie donc parfaitement dans un cadre applicatif plus
symtrique, ou mme pour dimportants trafics aller.
5.4.3.5.
Linfluence de lutilisation de lintelligence embarque
Cet impact reste le mme que celui tudi pour le cas dun accs satellite unidirectionnel
(cf. 5.4.2.3), encourageant lintgration de ce service dans une architecture hybride.
5.4.4.
Intgration doptimisations dans larchitecture hybride
Dans les parties prcdentes nous avons constat que si le service daccs Internet avait de
meilleures performances que dans les rseaux bas dbit, les rsultats affichs taient loin des
dbits maximaux proposs par le service. Plutt que de laisser lutilisateur svertuer optimiser
sa connexion Internet, larchitecture hybride propose dintgrer des optimisations dans sa
structure mme. Nous avons dailleurs dj vu dans les sections 5.4.3.2 et 5.4.3.3 des
amliorations potentielles. Mais la question dintgration reste en suspend, surtout que des
optimisations de type applicatif semblent difficilement tre la solution.
Lun des points fondamentaux de ces problmes repose sur le mauvais comportement de
TCP sur satellite (cf. 3.5.1). Un grand nombre de solutions ont t proposes et nous en avons
dj fait un tat de lart dans la partie 3.5.2. Toutefois beaucoup de ces mthodes altrent le
systme au niveau utilisateur, ce qui est contraire lide de transparence de notre proposition.
Pour palier ce fait, nous proposons dtudier lintgration de ces techniques via des mthodes
transparentes, et essentiellement en utilisant lapport des PEPs (3.5.2.3).
partir de l, nous dcoupons cette partie en quatre points. La section 5.4.4.1 proposera
dobserver dans un premier temps le comportement des versions TCP sur un accs Internet,
montrant que dans lensemble, mme si les comportements sont diffrents sur les pertes, les
problmes dasymtrie et mme de reprises derreurs ne peuvent tre rsolus par une version
classique de TCP. La section suivante (5.4.4.2) proposera daborder lintgration de passerelles
dans larchitecture hybride pour rpondre dune part aux problmes doptimisation, mais aussi au
souci de transparence du systme. Ensuite, un exemple de mise en uvre sera tudi, montrant
comment les PEPs peuvent avoir une influence des plus bnfiques sur le systme (5.4.4.3). La
conclusion de cette partie sera faite dans la conclusion gnrale sur laccs Internet.
165
5.4.4.1. Une comparaison du comportement des versions classiques

TCP sur un lien satellite
Nous avons dj utilis dans les parties prcdentes TCP pour faire nos simulations. Nous
proposons ici de revenir sur les versions de TCP les plus communes et dobserver comment elles
se comportent sur un systme satellite.
Dans ce cadre nous proposons comme test un change FTP entre un serveur et un client
connect directement par un lien satellite de RTT 508 ms. Le lien aller est 512 Kb/s, tandis que
le lien retour est 128 Kb/s. Un PLR de 10-3 est introduit sur le lien aller avec des rafales en
moyenne de 4 paquets. Sur le lien retour, le PLR est aussi fix 10-3. Toutefois cette hypothse
est un cas des plus dfavorables, puisque les acquittements sont de plus petites tailles. La MSS est
fixe 1460 B, les acquittements 40 B. Nous proposons ici la comparaison de TCP Tahoe,
Reno, et NewReno.
Tout dabord lobservation montre quau bout dun transfert de 2000 s, le segment maximal
transfr nest pas le mme dans les trois cas (Tableau XIII).
Tableau XIII.
SEGMENT MAXIMAL TRANSFR AU BOUT DE 2000 S
Type de TCP
Tahoe
Reno
NewReno
Segment maximal
83097
81097
83445
Figure 5.26 Observation du comportement de TCP Tahoe et Reno sur un lien satellite face une
perte ponctuelle.
166
Dans le cadre derreurs ponctuelles, on observe de meilleures performances pour TCP

Reno. Son comportement est dailleurs identique celui de TCP NewReno dans ce cas. Le Fast
Retransmit est dclench dans les deux cas (Tahoe comme Reno). Toutefois la rception de
lacquittement de ce segment, TCP Tahoe passe en congestion avoidance, tandis que TCP Reno
utilise le fast recovery, vitant ainsi de faire repasser sa fentre la taille initiale (Figure 5.26).
La figure suivante montre le comportement de TCP Tahoe et Reno dans le cadre de pertes
multiples (Figure 5.27). Contrairement TCP Tahoe, il passe dabord en phase de fast retransmit,
mais comme lacquittement ne concerne que le dernier segment, il est contraint de passer en
congestion avoidance, repartant avec sa fentre initiale. Il perd donc en efficacit face TCP Tahoe
qui a dj entam cette phase un RTT auparavant.
Figure 5.27 Observation du comportement de TCP Tahoe et Reno sur un lien satellite face des
pertes en rafales.
Contrairement TCP Reno, TCP NewReno supporte mieux les pertes en rafales en
permettant une phase de fast retransmit plus longue. La figure suivante (Figure 5.28) propose un
aperu de ce comportement face des pertes en rafales. On peut remarquer que le traitement des
pertes est plus long que pour les autres. Toutefois une fois les pertes traites, les paquets sont
mis directement au mme rythme quavant la perte. NewReno rcupre donc plus vite que les
deux autres implantations de TCP.
167
Figure 5.28 Observation du comportement de TCP NewReno sur un lien satellite face des
pertes en rafales.
Cette partie montre les diffrences de comportements entre diffrents protocoles TCP. Le
protocole NewReno semble alors le plus adapt au satellite, parmi les variantes couramment
implantes de TCP. Cest pour cette raison quil sera utilis par la suite. Toutefois, cette utilisation
namliore pas de manire effective les performances du systme. Il faut passer par une
optimisation relle du comportement sur satellite.
5.4.4.2.
Lenjeu de lintgration de PEPs dans larchitecture hybride
Des solutions sont envisageables pour amliorer le comportement de TCP sur satellite (cf.
3.5.2). Toutefois, pour larchitecture hybride, il nest pas question que les contraintes techniques
influencent dune part les utilisateurs du systme et dautre part les rseaux terrestres constituant
la Toile. Or un type de solution permet de garder une transparence pour les utilisateurs de bout
en bout : les PEPs. Ces solutions mettant en uvre des passerelles, ont t lobjet de la section
3.5.2.3.
Pour larchitecture hybride, lintgration des PEPs reprsente un vritable enjeu.
Dune part ils permettent une optimisation du comportement de TCP sur lien satellite, en
incorporant de manire transparente les modifications telles que celles prsentes dans la partie
3.5.2, sans influencer le systme de bout en bout, mais uniquement sur le systme satellite
(spoofing).
Dautre part, le PEP peut devenir lentit idale pour unifier laccs satellite. En effet, il ne
sagit pas uniquement dutiliser ces systmes pour TCP, mais comme un lment dinterfaage
fondamentale de larchitecture, prsentant une interface IP standard. En effet, les PEPs ntant
pas limit au niveau TCP, sont considr comme des modem-routeurs dans notre architecture,
traitant la fois la slection du mode, laccs au systme, la mise en place de FEC, la rsolution
dadresse, lencapsulation des flux IP Cette solution permet alors disoler la spcificit de
larchitecture dans une boite noire , rendant ainsi totalement transparent son utilisation par les
utilisateurs finals. Ainsi les protocoles qui nont pas t prvus pour le satellite, alors que leur
implantation sur un tel systme est souhaitable comme la gestion de groupe avec le protocole
IGMP (Internet Group Management Protocol) ou les protocoles de routage multicast IP, comme
PIM-SM (Protocol Independant Multicast Sparse Mode), peuvent trouver dans le proxy une
mthode pour implanter un protocole optimis au systme, en respectant la transparence.
168
Cette utilisation des PEPs se place comme un atout de choix pour larchitecture hybride,
rentrant pleinement en accord avec les travaux de lETSI recherchant un interfaage standard des
systmes satellite, BSM (Broadband Satellite Multimedia) [132] [133].
5.4.4.3.
Lutilisation de PEP pour un accs Internet par satellite
Pour conclure cette partie, nous proposons dobserver lamlioration de la mise en place de
PEP pour un accs Internet unidirectionnel, avec un lien retour de dbit utile estim 9.6 Kb/s
et une voie aller 1 Mb/s. La modle de perte reste le mme que prcdemment, ainsi que les
dlais des diffrentes liaisons. Toutefois nous considrons que les traitements effectus au niveau
des PEPs ajoutent 2 ms de dlai dans chaque sens. Nous analyserons dans ce cadre lvolution du
dbit dun transfert FTP au cours dun temps simul de 200 s.
On peut tout dabord noter que cette liaison un fort coefficient dasymtrie, de lordre de
1/100 contre 1/37 pour le rapport acquittement sur datagrammes. Il est donc naturel que sans
changement, le dbit aller soit trs limit. Une srie de simulations a alors t mise en place pour
observer comment un PEP pouvait amliorer cette communication.
Les dbits moyens observs pour un temps simul de 200 s sont reports dans le tableau
suivant (Tableau XIV). On notera :
(0) - Aucune modification, TCP NewReno.
(1) - Augmentation de la fentre initiale et maximale.
(2) - Utilisation de TCP SACK.
(3) - Utilisation dacquittements retards.
(4) - Utilisation de filtrage dacquittements (au niveau du buffer dmission).
(5) Sessions Multiples (ici 2).

DBIT MOYEN OBSERV SUR 200 S EN FONCTION DU TYPE DAMLIORATION
APPORT PAR LE PEP
Tableau XIV.
Type
damlioration
Dbit moyen
sur 200s (Kb/s)
2+3
(PEP 1)
337
339.1
346.1
662.1
868.2
348.3
666
1+2+3
1+2+3+4
1+2+3+4+5
(PEP 2)
(PEP 3)
(PEP 4)
682.1
880.2
903.7
Ces exprimentations montrent que lamlioration qui a le plus de poids dans ce type
daccs est le coefficient dasymtrie, savoir le poids des acquittements par rapport aux donnes
reues. Ainsi lorsque lon utilise des acquittements retards, ou mieux, du filtrage dacquittement,
les performances du systme sont tout de suite grandement augmentes (augmentation de 158%
par rapport 0).
On retrouve notamment les rsultats tracs dans la figure ci-dessous (Figure 5.29),
reportant plusieurs quatre des amliorations, nommes PEP 1, 2, 3 et 4.
Cette courbe permet de montrer les diffrentes amliorations. On peut ainsi noter trois
grandes familles de courbes.
Celles qui ne touchent pas fondamentalement au flux dacquittements (sans PEP et

PEP n1). Le dbit reste alors infrieur DMAX (36), cest--dire 360 Kb/s.
Celles qui implantent les acquittements retards (PEP n2). Le flux dacquittement
tant peu prt divis par deux, le dbit maximum est alors denviron 720 Kb/s.
Celles qui utilisent des techniques de filtrage/suppression dacquittements (PEP n3 et

n4). Dans ce cas le dbit maximum atteignable peut avoisiner le dbit du lien aller.
169
Figure 5.29 Comparaison entre lutilisation une connexion sans PEP et une connexion avec PEP
sur un lien satellite unidirectionnel 1 Mb/s avec lien retour terrestre de 9.6 Kb/s
Cependant quelques lments viennent nuancer cette tendance gnrale. On peut

remarquer tout dabord, linfluence de TCP SACK sur les pertes qui permet de rtablir la
connexion TCP plus rapidement que TCP NewReno. Dans ce cadre TCP SACK peut savrer
une solution de choix pour limplantation dune solution sur un mdium trs bruit.
On peut noter ensuite que la suppression dacquittement, comme elle est ralise ici, une
influence nfaste sur la ractivit du systme face aux pertes. En effet la suppression
dacquittement par gestion de la taille des buffers peut induire en cas de perte une grande latence
quant au rtablissement dune communication plein rgime. En effet suite une perte, il est
possible que la suppression dacquittement limine ceux contenant les paquets manquants,
induisant malgr tout un time out et le dbut dune phase de congestion avoidance. Or la suppression
dacquittement couple aux acquittements retards implique une phase de slow start longue qui
peut tre amliorer au dbut de la communication en choisissant une fentre initiale plus grande.
Mais dans ce cas, celle-ci repart 1, et le rtablissement dune communication plein rgime en
est grandement affect. Plusieurs solutions ce problme existent, la rgnration des
acquittements dtruits, ou lutilisation de sessions multiples (PEP n4), qui peuvent limiter voire
rsoudre ce dfaut.
Les PEPs offrent une amlioration adapte du comportement de TCP, permettant de
rentabiliser le lien, mme dans le cadre dune asymtrie de 1/100.
5.4.5.
Conclusion sur laccs Internet
Cette partie a justifi les deux architectures de service choisies pour les accs Internet
standard et volu. Toutefois, un point na pas t abord pour laccs Internet volu, celui de
laccs multiple. En effet nous avons considr dans cette tude que le dimensionnement du
systme ntait pas notre priorit. Ltude sest donc concentre sur dutilisation dun lien satellite
unidirectionnel et dun lien bidirectionnel. Si les performances obtenues aux cours de nos
diffrentes simulations sont encore loin des dbits optimaux, laccs Internet par satellite reste, de
170
loin, suprieur un accs classique bas dbit, pouvant mme se rapprocher parfois dun accs de
type ADSL.
Larchitecture hybride a ainsi un vritable intrt intgrer un tel service, basique pour la
plupart des zones sans accs haut dbit1. De plus sil est vrai que le mode privilgi pour laccs
Internet reste le mode transparent, le systme hydride peut jouer de sa capacit rgnrative multispots pour conomiser une partie de la bande passante pour les transferts de donnes importants.
Pour un retour via satellite, le mode transparent est conseill dans la mesure o les dbits
sont relativement faibles et le transparent offre un simple bond pour laccs la gateway. Le mode
rgnratif offre toutefois des perspectives quant une allocation dynamique se fait bord,
gagnant en temps de rponse du systme, ce mode pouvant tre utilis uniquement pour la
signalisation.
Tout au long de cette tude, nous avons propos un certain nombre de solutions
augmentant les performances du trafic en particulier sur la voie aller. Il ressort en effet que le
satellite nest pas un mdium adapt TCP, comme nombre dtudes le constate. Lutilisation des
PEPs semble tre alors une solution de choix pour assurer la fois ladquation au service daccs
Internet et la transparence de la solution hybride (cest--dire napporter aucune contrainte sur les
utilisateurs du systme). Les PEPs se positionnent comme la clef de vote de larchitecture
hybride, proposant dintgrer les fonctionnalits spcifiques du systme en dehors du systme
utilisateur, devenant par la mme un modem daccs au lien satellite, et offrant ainsi une interface
IP standard.
5.5. La vido la demande

La vido la demande est un service trs loign de laccs Internet. Mme si elle peut tre
facilement couple ce dernier dans le cadre daccs hauts dbits, il nen reste que ces besoins
sont trs diffrents : une voie aller fort dbit, une voie retour non indispensable, un support
physique fortement diffusant, ou mieux supportant le multicast. Or, ces caractristiques sont celles
proposes par larchitecture hybride.
Cette partie propose dtudier lintrt dun tel service pour la solution hybride. Pour cela
nous comparerons un systme transparent un systme rgnratif, montrant comment le
systme hybride propose un compromis fructueux.
La premire section (5.5.1) prsente une comparaison entre le multi-spots et le mono-spot, qui
est en fait lintrt majeur du systme rgnratif compar au systme transparent pour ce service.
La section 5.5.2 discute brivement de lintrt dune voie retour pour la VoD.
5.5.1.
Comparaison entre multi-spots et mono-spot
Comme nous avons pu le constater dans ltude de ce service (4.1.1), les besoins de la VoD
sont trs dpendants de deux facteurs : le type de service propos, et la rpartition de leurs
clients.
Les demandes instantanes forment un type de service trs coteux et inaccessible pour des
particuliers. Sil sagit dun film de bonne qualit, il faut observer que le dbit peut avoisiner alors
4 Mb/s 5 Mb/s (lquivalent dune chane tlvise). Lutilisation du mode rgnratif est donc
conseille pour viter un gaspillage de ressources excessif. Un tel service peut tre envisag pour
des chanes tlvises dhtels, de navires de plaisance, ou encore pour des avions. Dans ce cas,
lunique client est un groupe de rcepteurs, la vido doit tre distribue tous les membres du
Ce type de rgions reprsentera en France et en 2005, 75% des foyers.
171
groupe. Le choix du mode peut alors devenir un critre important de ce service. Pour cela cette
analyse doit donc prendre en compte la rpartition des diffrents rcepteurs du flux vido.
Les services de quasi VoD semblent plus appropris un utilisateur particulier. Nous avons
dj discut du dlai dmission de la vido dans ce cadre (cf. 4.1.1.2), lassociant des seuils : un
seuil temporel au-del duquel le mdia doit tre envoy, et un seuil de requtes partir duquel il
est possible denvoyer le mdia, car rentable pour le fournisseur de services (FSI). Ainsi, pour des
mdia rcents et/ou forte popularit, le seuil de requtes est souvent atteint avant le seuil
temporel, tandis que pour des mdia moins communs, cest ce dernier qui sera a priori atteint en
premier. Grce aux rglages spcifiques pour chaque vido de ces deux seuils, le fournisseur de
services pourra rentabiliser son mission de mdia. Toutefois, un autre critre a une importance
dans une architecture hybride : la position des diffrents clients.
En effet sil savre que pour certains mdia, les clients sont quitablement rpartis dans la
zone couverte du satellite, il est aussi possible que ces derniers soient concentrs sur des zones
prcises, et il est alors dommage de diffuser la vido sur la totalit de la couverture du satellite
alors quune faible zone de celle-ci est concerne. Cest dans ce cadre que le multi-spots rentre en
jeu, et que le mode rgnratif peut avoir un intrt pour le service de VoD.
Observons tout dabord diffrentes raisons qui peuvent pousser les clients dun service
tre gographiquement concentrs :
Une notion temporelle : les services de VoD sont bien plus utiliss en soire aprs le
dner. Dans ce cas on peut dcouper la couverture en bandes longitudinales avec une
plus forte probabilit davoir une demande dans une bande donne, cette probabilit
variant avec lheure effective dans la bande.
Une notion nationale : en fonction de la lgislation des sorties de films dans diffrents
pays, il est trs possible quun mdia ne soit disponible que pour un groupe de pays.
Dans ce cas, on connat directement quels sont les spots concerns ou pas. De plus
peuvent tre prises en compte ici des notions de langues pour les mdia, ou encore des
considrations de nouveauts pour certaines rgions, etc.
Une notion douverture de services : il est possible que le FSI noffre pas son service
sur toute la couverture du satellite, pour des raisons de restriction de march, de
fiscalit, etc Ces zones sont alors des zones mortes pour le FSI. Il est aussi possible
que le service soit nouveau dans certaines rgions, le nombre dabonns tant alors
moins important.
Dans ces cas, deux possibilits soffrent au FSI : ne pas se soucier de cette rpartition et
mettre quand le seuil de clients est atteint en mode transparent, ou considrer que le mode
rgnratif est plus rentable, et envoyer ainsi sur les spots uniquement concerns. Dans cette
dernire possibilit, il est alors concevable dtudier les seuils par faisceaux, et de dcider de ne
pas envoyer sur un spot donn sil ny a pas assez de clients dans ce dernier.
Pour cette tude, il est trs difficile davoir des donnes ralistes et relles sur le cot
dutilisation de telles technologies. En effet ce cot dpend intrinsquement du nombre total de
faisceaux du systme, et du nombre de faisceaux utiliss pour un flux donn. Toutefois, il est
possible de faire une comparaison sur le gain en dbit descendant, de la mme manire que
lanalyse mene dans la partie 5.4.2.3. Observons donc du point de vue de loprateur systme
quel gain en dbit il peut obtenir en utilisant un systme transparent, un systme rgnratif
multifaisceaux, ou un systme hybride.
Dans ce cadre notons d, le dbit utilis par lmission dune vido. Soit xt et xr, le nombre
maximal dmission de vidos en simultanes respectivement pour un systme transparent et
172
rgnratif. Pour que le service soit rentable, on considrera que le nombre de vidos mis en
simultanes est le nombre maximal.
Dans un cas purement transparent, le dbit consomm sur la couverture est donc toujours
de xt*d.
Pour un systme purement rgnratif, le dbit consomm sur la couverture dpend de la
rpartition des clients sur les diffrents spots. Si lon note ni, le nombre de spot utilis par le ieme
flux vido, on peut noter le dbit restant de la forme, o DMAX est le dbit maximum utilisable par
le FIS :
(44)
n
Di = n DD ni .d = n k Du _ r
i =1
n D
ni . MAX
i =1 xr
Dans un premier temps, si les clients du service sont uniformment rpartis pour chaque
flux vidos, on a alors la relation suivante :
(45)
Di = n k Du _ r xr n
DMAX
= n ( k Du _ r DMAX ) 0
xr
Soit une valeur maximale pour DMAX de k*Du_r, valeur infrieure au cas transparent, gal
Du_r. De plus dans ce cas, le FIS paie bien plus cher sa bande passante que dans le cas
transparent, sans avoir la mme capacit.
Si lon considre le cas inverse, o les clients pour chaque flux sont concentrs dans un seul
spot, on retrouve le cas unipoint tudi dans laccs Internet, avec lexpression (46):
(46)
Di = n k Du _ r xr
DMAX
= ( nk 1) Du _ r
xr
Entre ces deux extrmes, on retrouve toutes les variations dues la rpartition des
diffrents clients intresss par un mme mdia. Parmi elles certaines rendent le systme
transparent plus intressant (comme le premier cas), et dautres favorisent le multi-spots rgnratif
(comme ce dernier cas), puisque lutilisation dun nombre de spots restreints permet de
sauvegarder une grande partie de la capacit du satellite, et donc de baisser le prix de lutilisation
du lien.
Deux donnes importantes manquent toutefois pour poursuivre cette tude de manire
plus pousses : le cot du systme rgnratif en fonction du nombre de spots total et utilis, et
des donnes sur la rpartition des groupes dutilisateurs. Toute tude plus pousse ne saurait tre
alors quun exemple sans fondement concret.
Nanmoins, il est possible de considrer lalternative propose par le systme hybride. En
effet, nous venons de voir quil y a des cas o le systme transparent est plus rentable, et dautres
o cest au contraire le systme rgnratif. Toutefois, la dcision de quel systme doit tre utilis,
en fonction des donnes du service et des cots relatifs de lutilisation de la liaison satellite doit
tre effectue une fois pour toutes. Si le cot du systme est une ralit qui risque peu de changer,
le comportement des clients est plus difficile prvoir. Ainsi il peut arriver que le systme choisi
ne soit pas toujours le mieux pour une priode donne. Le systme hybride permet doffrir une
approche plus fine du problme. En fonction des donnes de rpartitions des diffrents clients, le
choix du mode peut ainsi tre fait pour chaque mdia, profitant du mme coup du prix le plus
avantageux.
Le systme hybride propose alors une mthode flexible et rentable pour un service de
VoD.
173
5.5.2.
Influence du lien retour
Le lien retour na pas toujours lieu dtre pour un service de VoD. Mme si certains
protocoles de niveau transport ou applicatif utilise le lien retour pour une distribution fiable des
donnes, il est aussi possible dutiliser un codage FEC fort pouvoir correcteur pour assurer
cette fiabilit, au prix dune consommation de bande passante accrue. En effet, lorsquil sagit de
VoD instantane, la distribution de la vido revient de la distribution tlvise, et il nest pas
possible alors de mettre en place des mcanismes de retransmissions au niveau transport.
Enfin, si un lien retour nest pas un prrequis au service de VoD, son couplage commun
avec un accs Internet est un lment important, permettant denvisager la mise en place de
mcanismes de reprises derreurs. Si ces considrations dpassent en partie le cadre de notre
expos, nous pouvons noter que ces mcanismes impliquent une faible consommation de la voie
retour, utilisant souvent des systmes de NACK suppression. Ainsi la fiabilisation de la VoD
na pas une influence majeure sur la voie retour, lexception des solutions utilisant des rseaux
P2P, o le trafic engendr risque de rentrer en conflit avec laccs Internet, et mme de
lutilisation de PEPs.
5.5.3.
Conclusion sur la Vido la Demande
Nous avons vu prcdemment que les services de VoD proposent une attrayante
perspective pour le satellite. Ainsi, des offres commerciales sont en place depuis quelques annes.
De plus, un tel service semble vouloir stendre rapidement sur le satellite la distribution plus
gnrale de contenu. Des services commerciaux proposent alors de tlcharger plusieurs types de
contenus (DVD, jeux, MP3...) via un systme satellite [92]. Ces offres ont tout intrt exploiter
le satellite comme un outil de diffusion. Elles mettent donc en place un systme de timers et de
seuils, quivalents ceux proposs prcdemment. Le multicast apparat ici un outil de choix, et
son intgration est un atout de choix pour une meilleure gestion des ressources du systme.
Le systme hybride se positionne comme une opportunit. Dune part il permet de choisir
au cas par cas le meilleur mode utiliser en fonction de la rpartition des diffrents clients sous la
couverture satellite. Dautre part, la gestion du multicast par le mode rgnratif permet doffrir
une adquation parfaite du systme aux besoins du FIS.
5.6. Linterconnexion de rseaux privs

Nous avons tudi, au cours de ces diffrentes parties, un grand nombre de caractristiques
du systme. Pour finir cette tude nous proposons daborder le dernier service propos dans le
cadre de cette intgration : linterconnexion de rseaux privs.
Cette partie est essentiellement loccasion daborder le principe de multiplexage bord, qui
est lintrt majeur de lutilisation dun systme rgnratif, puisquil permet dviter le double
bond dans une communication inter RCST. Dans ce cadre larchitecture hybride se positionne
comme une solution clef, permettant de basculer dun mode lautre en fonction du type de
trafic traiter.
La section 5.6.1 abordera ce point. La partie 5.6.2 tudiera limpact dune couverture
multifaiceaux et enfin la partie 5.6.3 conclura cette tude, avec notamment quelques lments sur
la gestion de la QoS bord.
5.6.1.
Performances du multiplexage embarqu
Une des diffrences fondamentales entre un systme transparent et un satellite rgnratif

dans linterconnexion de VSATs est la ncessit de passer par une gateway ou non. On nomme
gnralement rseau toil (star network) une architecture centralise par une gateway, et rseau
maill (mesh network) lautre cas.
174
Dans cette tude trois facteurs vont intervenir : le cot du systme, le dlai, et les pertes
dues au support physique. Le cot du systme sera trait dans la prochaine partie avec ltude du
lintrt du multi-spots, et nous nous focaliserons ici sur ltude des deux autres facteurs.
5.6.1.1.
Les hypothses dtude
Nous considrons dans cette partie une interconnexion entre deux rseaux. Ces rseaux
seront modliss par une unique station. Le dlai dun bond satellite sera pris 254 ms pour un
lien transparent et 255 ms pour un lien rgnratif (le traitement bord tant major 1 ms).
Les dbits des liens sont fixs 2 Mb/s dans les deux sens.
Linfluence de la mthode daccs dynamique ne sera pas tudie ici, puisque si elle doit
tre mise en place, elle le sera dans les deux cas, et le mme nombre de fois1.
Le modle de pertes restera celui propos dans la partie 5.4.2.1.2, avec des rafales de
moyenne quatre paquets et un PLR de 10-3 par liaison satellite, et ne sera introduit que dans
ltude de linfluence des erreurs. TCP Reno est utilis ici, et aucun PEP na t mis en place pour
comparer ces architectures.
La figure suivante (Figure 5.30) prsente ce modle.
Figure 5.30 Topologie toile et maille
5.6.1.2. Linfluence du dlai sur la communication entre les deux

rseaux
Limpact du choix du rseau sur le dlai est des plus notable. Le systme de type star
propose un dlai de 508 ms entre les deux terminaux, tandis que le rseau mesh propose un dlai
de 255 ms. Ainsi si lon considre la formule (34), on obtient dans un cas un dbit maximum avec
TCP denviron 516 Kb/s dans le cas toil, contre un peu plus de 1 Mb/s dans lautre cas. Nous
avons dj observ quavec lutilisation de PEPs, et notamment laugmentation de la taille
maximale de ladvertized window, ce dbit peut tre dpass.
Toutefois, cette observation tmoigne dun autre problme, limpact du RTT sur la
ractivit du systme. Ainsi les applications fortes contraintes temporelles telles que la VoIP ne
peuvent tre implantes sur un systme proposant un RTT de 1016 ms, quand la borne maximale
du dlai envisageable pour le confort utilisateur est de lordre de 500 ms [97].
1 En effet, dans le cas dun systme toil, la gateway a accs directement au support. Le seul problme quil
peut advenir est de la congestion lmission. Nous considrerons que la rservation de bande passante pour le flux
est suffisante, et que les autres trafics ninfluencent pas alors sur la communication entre les deux rseaux.
175
Ce RTT lev introduit un temps important de mise en place dune communication haut
dbit. Ainsi la simulation suivante compare ces deux accs pour le temps moyen dun transfert
FTP, en fonction de la taille de ce transfert (Figure 5.31).
Figure 5.31 Comparaison du temps de transfert FTP entre une topologie star et mesh sans perte
Ces deux courbes montrent clairement un facteur voisin de deux entre les dbits du rseau
toil et maill. Cette relation est directement lie au rythme des acquittements TCP qui
autorgule de dbit du flux. La mise en place dune fentre initiale plus grande et dune fentre
maximale plus grande permet damliorer les performances des deux flux, mais resserre lcart
que pour un transfert trs important.
5.6.1.3.
Linfluence du taux de pertes paquets sur les deux systmes
Un autre facteur influence grandement les performances de ces architectures, les pertes. En
effet, nous avons vu dans ltude de TCP sur satellite limpact que pouvait avoir les pertes sur le
dbit maximum du lien, cette influence tant dautant plus importante que le RTT est lev (21).
La figure suivante (Figure 5.32) trace lvolution du dbit applicatif maximum en fonction du
PLR pour le cas dune topologie star et dune topologie mesh. Sur cette figure, on constate le
coefficient li au RTT qui lie ces deux courbes. Toutefois, le passage par deux liens satellites,
implique deux fois plus de pertes dans le cas star que dans le cas mesh, soit un dbit denviron 315
Kb/s pour le rseau toil, contre 887 Kb/s dans lautre cas.
Figure 5.32 Comparaison de lvolution du dbit applicatif maximum en fonction du PLR pour
une architecture toile et une architecture maille
176
Nous proposons alors dobserver dans un dernier temps les rsultats observs aprs
simulations sur lvolution des dbits dans un et lautre cas (Figure 5.33).
Figure 5.33 volution du dbit moyenn sur une seconde au cours du temps pour une topologie
de type star et mesh
Bien que cette courbe ne trace quun exemple, elle permet de montrer la nature
incompressible de la diffrence du RTT entre ces deux rseaux. Une topologie toile met alors
plus de temps pour se rcuprer son dbit aprs une perte, tandis que le RTT plus faible du
rseau maill offre une meilleure ractivit aux pertes.
Dans ce cadre, lutilisation du mode rgnratif du systme hybride est une meilleure
solution pour les transferts demandant un dlai plus court. De mme, il apparat que ce mode
peut apporter un gain important en dbit sur un mdium trs bruit.
5.6.2.
Intrt du multi-spots pour linterconnexion
Dans la mesure o lon utilise le mode rgnratif pour faire du simple bond, le multi-spots
prsente un intrt vident pour conomiser la bande passante.
De mme pour des communications dbit lev entre uniquement deux ou trois sites, ce
mode peut apporter une conomie certaine.
En revanche, lorsquil sagit de lourd transfert entre un grand nombre de rseaux privs, la
slection du mode rgnratif nest pas toujours souhaitable dans la mesure o dune part il ne
sagit pas dapplications pour lesquelles le dlai de limportance, et dautre part il y a peu
dintrt dun point de vue cot choisir le mode rgnratif pour conomiser quelques
faisceaux, voire aucun.
5.6.3.
Conclusion sur le service dinterconnexion
Nous avons vu ici que linterconnexion de rseaux privs pouvait trouver des opportunits
relles dans lutilisation dun systme rgnratif, notamment pour des applications contraintes
temporelles. Lutilisation dune interconnexion de type star prsente toutefois un intrt
conomique pour les communications mettant en place des transferts importants de donnes
un grand nombre de rseaux dissmins sur une large partie de la couverture.
Le systme hybride trouve donc parfaitement sa place dans un tel service, jouant de sa
dualit pour convenir aux diffrents besoins du service dinterconnexion.
177
Un autre atout important du mode rgnratif est sa capacit grer la QoS. Sil est vrai
que dun point de vue dlai, le systme ne permet pas de gagner une quelconque marge
significative, la QoS bord peut toutefois tre une notion clef pour trier les flux et permettre de
grer dautres paramtres du trafic, comme la gigue. Ce point reste toutefois hors cadre de cette
tude, et ne saurait tre abord plus avant ici.
5.7. Conclusion sur cette valuation

Au cours de cette tude nous avons montr que le systme hybride ntait pas une solution
plus lourde mettre en place quune quelconque autre. Au contraire, les choix effectus
notamment pour lencapsulation, ou encore la possibilit dagrger les PIDs permet au systme
davoir une signalisation efficace, pouvant mme jouer de son mode rgnratif pour gagner en
temps de rponse du systme (notamment pour lallocation de ressources).
Nous avons propos tout au long de cette partie une tude de lintgration de diffrents
services sur le systme hybride. Cette tude a permis de montrer dune part que ces services
avaient leur place dans une architecture telle que la ntre, et que larchitecture hybride, en plus de
pouvoir intgrer des services diffrents sur le mme systme, propose par ses deux modes une
grande flexibilit. Cest cette flexibilit qui permet au systme de sadapter de la meilleure faon,
tant dun point de vue performances que cot, aux diffrents besoins des trois services tudier.
Au cours de cette tude, nous avons pu souligner une solution permettant de grer la
transparence de larchitecture. En plus damliorer le comportement des nombreuses applications
utilisant TCP, ils offrent une interface transparente et standard aux utilisateurs, permettant
disoler le lien satellite et sa gestion dans un modem.
Cette tude na pas la prtention dtre complte, dans la mesure o larchitecture hybride
est flexible, dpendante du choix technologique de son implantation. Il ntait pas question ici de
faire une tude de protocoles ou de dimensionnement spcifique. En revanche, cette analyse a su
montrer dune part la validit de notre approche, et dautre part les apports du concept hybride
peut apporter : flexibilit et adaptabilit. Nous proposons ici une architecture qui sadapte aux
besoins des services et des utilisateurs finals, vitant le pige de la spcificit des solutions,
comme de leur non-transparence. Cette solution ne peut tre envisage quen traitant IP comme
un lment fdrateur de larchitecture, et non dun point de vue extrieur et applicatif.
178
179
CHAPITRE 6. CONCLUSIONS ET PERSPECTIVES
6. CONCLUSION ET PERSPECTIVES
Nous proposons dans ce chapitre de rsumer notre tude et ses contributions, puis de
proposer, dans un dernier temps, diffrentes perspectives ces travaux, concluant sur une vision
long plus terme du couplage entre le monde des tlcommunications spatiales et celui des
rseaux terrestres.
La conclusion
La problmatique de lintgration des systmes satellites dans les rseaux terrestres sest
construite autour du succs des satellites GEO avec la diffusion de la tlvision numrique, et de
la vague actuelle dintgration de services dans les rseaux terrestres. Dans un monde o IP se
prsente comme une solution de convergence forte, de nombreux travaux envisagent le
dploiement de rseaux IP intgrant un lien satellite gostationnaire, notamment au travers des
systmes DVB. Des propositions propritaires existent, manant directement des constructeurs.
Les limites de ces systmes ddis font deux des solutions difficilement adaptables des besoins
plus gnraux des utilisateurs. Les communauts satellite (ETSI avec BSM) et Internet (IETF
avec le groupe de travail IP sur DVB) tentent de permettre une cohabitation efficace et prenne
de ces deux architectures de communication trs diffrentes.
Dans ce contexte nous nous sommes interrogs sur la dfinition dune architecture capable
de prendre en compte les caractristiques des deux domaines, et de les unifier dans une seule
architecture, grce la souplesse mais aussi au fort pouvoir fdrateur dIP, dmarche que nous
avons prsente dans le premier chapitre de ce mmoire.
Aprs avoir rappel les caractristiques des systmes spatiaux de type DVB, un second
chapitre a dcrit des normes DVB-S, DVB-SI et DVB-RCS dans leur ensemble.
Nous avons alors tudi et analys dans le chapitre 3 les technologies disponibles pour la
dfinition dune telle architecture. Nous avons observ dans un premier temps comment la
norme ETSI propose de vhiculer dautres flux que ceux de type MPEG-2. Une solution
classique utilisant MPE a alors t analyse, concluant des limites que le DVB-RCS, le protocole
dencapsulation ULE et la nouvelle gnration de satellite se proposent de rsoudre. Pour illustrer
ce point, larchitecture rgnrative DIPCAST a alors t tudie. Si dautres problmes
protocolaires subsistent, comme le comportement de TCP mal adapt au satellite, nous avons
observ quil existait un nombre important de solutions chacun de ces problmes (notamment
les PEPs). La conclusion de ce chapitre a mis en vidence une problmatique centrale : si les
solutions existent, il y a un manque dune architecture fdratrice et prenne, apportant une
solution entre les satellites actuels et futurs et intgrant diffrents services porteurs.
Aprs avoir analys les besoins architecturaux de diffrents services ainsi que leur
adquation avec le support satellite, le chapitre 4 a dfini les objectifs dune architecture
rpondant cette problmatique. Sur ces bases, nous avons propos et dcrit une solution,
larchitecture hybride. Celle-ci prsente une grande flexibilit grce lintgration de deux charges
utiles dans un seul systme satellite. Elle propose une interface IP rendant lutilisation du systme
satellite transparente pour lutilisateur final et permettant de slectionner le mode du systme
utilis. De nombreux choix technologiques ont t faits dans cette proposition, justifis par le
180
contexte actuel du monde satellite. Lune des forces majeurs de cette architecture (ctait un
objectif fondamental) est cependant que chacun de ces choix peut tre remis en question au grs
des volutions technologiques.
Le chapitre 5 a t consacr lanalyse de cette architecture en considrant son adquation
aux diffrents services et ses apports par rapport des solutions plus classiques. Une tude par
niveau de service a t mene pour cela. Aprs lanalyse du niveau 1 et de son influence sur le
reste de larchitecture, ltude du niveau liaison a permis de montrer le cot relatif de la
signalisation des flux IP, concluant sur labsence dun ajout doverhead induit par la nature hybride
du systme, et mme sur de meilleures performances que les solutions classiques grce
lencapsulation ULE et des volutions possibles de la charge utile rgnrative. Aprs linsertion
naturelle dans larchitecture dIP comme llment fdrateur, la fin de ce chapitre a t consacre
lanalyse du dploiement des trois services prcdemment tudis. Laccent a t mis sur laccs
Internet, dmontrant quil offre une vritable perspective pour les zones sans laccs au haut
dbit. Au-del de lintgration manire transparente ces services, larchitecture hybride offre une
grande souplesse dans leur dploiement, leur proposant une alternative conomiquement
intressante, et adapte chacun de leur flux.
Notre contribution se situe donc sous deux formes distinctes :
Une synthse autour de la mise en uvre dIP sur satellite, couplant tat de lart et
analyse critique. Mis part le savoir-faire quil reprsente, ce point a voulu souligner le
fait que, si le satellite est souvent considr comme une technologie de niche, il se
positionne comme une des technologies quil faudra intgrer pour rpondre aux
besoins des utilisateurs sans un accs haut dbit dans les temps venir (25% des foyers
en France en 2005).
Une proposition dcrivant le concept de systme hybride. Cette architecture est

dtaille dans ce mmoire et intgre diffrents mcanismes (diffrentiation des modes,
rsolution dadresse, etc.) et des volutions possibles. Un autre lment important de
cette proposition est son inscription dans une dmarche duniformisation du monde
satellite, en proposant IP comme la couche fdratrice de larchitecture.
Les perspectives
Dans un cadre plus global, une perspective fondamentale pour le monde satellite est la
normalisation, ou tout du moins luniformisation. Pour cela, lintgration dIP comme un lment
central des architectures satellites nous semble une tape ncessaire comme nous lavons dcrit
dans cette tude. Des travaux tels que BSM ou ULE, sinscrivent parfaitement dans ce sens en se
focalisant sur linteraction entre les niveaux protocolaires liaison et rseau.
Cette optique gnrale touche intrinsquement les systmes matriels satellites, la
normalisation conduisant des cots moindres (par exemple le projet SATLABS, visant
linteroprabilit des VSATs). Dans ce cadre, notre proposition sinsre parfaitement. En offrant
un systme hybride, cette solution permet denvisager un dveloppement plus massif des
systmes charge utile rgnrative, et donc une potentielle baisse des prix. La notion de cot
nous semble un point capital pour ltude dune architecture satellite telle que la proposition
dcrite ici, et doit tre mene dans un cadre industriel.
Toujours dans ce cadre de normalisation, nous avons suggr au cours de cette tude
lutilisation des PEPs comme une solution la mise en uvre dune telle architecture, permettant
disoler les spcificits inhrentes au support satellite. Lintgration de ces lments et leur
description architecturale constitue une suite naturelle nos travaux.
181
Les volutions technologiques laissent penser que lapparition dune intelligence bord est
inluctable, et que cette intelligence sera de plus en plus volue. Larchitecture propose ici a, par
essence, la capacit dintgrer ces volutions qui constituent donc des perspectives dtudes.
Ainsi, lopportunit de faire de la commutation bord au niveau SNDU savre un axe de
recherches, ouvrant la voie des tudes orientes systme de commutation bord (de type ATM,
Ethernet, AFDX, etc. ou spcifique), des protocoles de mise jour des tables de
commutation utilisant lauto-apprentissage, ou de la gestion de QoS plus labores.
Si la mise en place dun routeur bord reste actuellement prmature, CISCO a dj fait
une premire exprience sur un LEO [107], et Alcatel travaille sur lintrt dIP bord.
Lintgration dIP bord se constitue en vritable enjeu du monde satellite : savoir si la
technologie embarque est suffisamment fiable pour supporter des fonctionnalits de routage
sans aucune maintenance matrielle pendant des annes. Ds que ce cap sera franchi, le satellite
deviendra un lment parmi dautres des rseaux IP, soulageant de ce fait la signalisation terrestre
du systme satellite. Notre travail se place comme un prambule cette intgration en prenant en
compte IP comme un lment part entire de larchitecture et non comme un simple
interfaage.
Dautres points peuvent encore tre traits dans le prolongement de cette tude, comme
des tudes de la mise en uvre de cette architecture dans une architecture de QoS plus fine, ou
encore linfluence du DVB-S2 sur un tel systme. Notre proposition darchitecture globale,
offrant une flexibilit par sa technologie comme ses protocoles, devra donc tre enrichie par des
tudes futures comme un dimensionnement pour un dploiement rel.
182
183
LISTE DES COMMUNICATIONS
Liste des communications

Confrences Internationales avec actes (2)
J. Fasson, E. Chaput, C. Fraboul, IP Multicast Architectures over NextGeneration GEO Satellites, VTC Spring 2004, 06/2004 ( paraitre).
J. Fasson, E. Chaput, C. Fraboul, GEO Satellites and their applications : service

integration over DVB systems, WCC 2004, BSCS workshop, p 67-76, 08/2004 (
paratre chez Kluwer).
Autres Confrences (1)
J. Fasson, La nouvelle gnration de satellites gostationnaires comme support

dIP , EDIT 2004, 03/2004.
Rapports de Recherche et de contrats (5)
Riadh Dhaou, Julien Fasson, Farid Jaddi, Mahamadou Issoufou Tiado, Andr-Luc
Beylot, Report on Performance Modelling and Congestion Control Applications
: Performance issues of routing in ad-hoc networks and IP over GEO satellite

links, Rapport de contrat, Network of Excellence NoE EURONGI : Livrable
D.JRA.5.5.1 N2, 06/2004.
J. Fasson, E. Chaput, C. Benassy-Foch, C. Faure, F. Filali, Architecture systme

transparent pour le projet DIPCAST , WP 1421, 2002
J. Fasson, E. Chaput, Intgration du protocole IP multicast au systme DVBRCS/OBP , WP 2820, 02/2003
J. Fasson, E. Chaput, C. Fraboul, volutions d'architectures IP multicast sur
satellite, rapport interne , 02/2003
A. Duverdier, J. Fasson, E. Chaput, F. Filali, C. Oustric, C. Benassy-Foch, Systme
satellite hybride DVB-RCS : Charge utile transparente et rgnrative , WP
1422, 08/2003.
184
LISTE DES COMMUNICATIONS
185
RFRENCES
Rfrences
[1]
[2]
[3]
[4]
[5]
[6]
G. Dicenet, Le RNIS : techniques et atouts, ed. Masson, Collection CNET, 1990.

D.R. Glover, NASA Experimental Communications Satellites, http://roland.lerc.nasa.gov/~dglover/sat/.
Site historique de la NASA, http://www.hq.nasa.gov/office/pao/History/.
Generic coding of Moving Pictures and Associated Audio Information, Ref: ISO/IEC 13818-16.
Site officiel du DVB, http://www.dvb.org.
Advanced Television Systems Committee, ATSC Data Broadcasting Standard, Ref: Doc A/90,
26/07/2000.
[7]
H. Benoit, Digital television : MPEG-1, MPEG-2 and principles of the DVB system, Ed. Focal Press, 2
ed, ISBN 0240516958, 2002.
[8]
J.Yoshida, DVB-X spec to deliver TV on cell phones, EE Times, www.eetimes.com, 10/03/2003.
[9]
Digital Video Broadcasting, Digital Video Broadcasting (DVB);Transmission System for Handheld
Terminals (DVB-H), ETSI EN 302 304, 06/2004.
[10] Digital Video Broadcasting, Digital Video Broadcasting ; DVB specification for Data Broadcasting,
ETSI EN 301 192 v1.3.1, 01/2003.
[11] H. D. Clausen, H. Linder, B. Collini-Nocker, Internet over Direct Broadcast Satellites, IEEE
Communication Magazine, Vol. 37, p. 146-151, 06/1999.
[12] Digital Video Broadcasting, Digital Video Broadcasting; Framing structure, channel coding and
modulation for 11/12 GHz satellite services, ETSI EN 301 421, 08/1997.
[13] Digital Video Broadcasting, Digital Video Broadcasting; Specification for Service Information in DVB
systems, ETSI EN 300 468, 06/2004.
[14] Digital Video Broadcasting, Digital Video Broadcasting; DVB specification for data broadcasting,
ETSI EN 301 192, final draft, 06/2004.
[15] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, A Link Layer Tunneling Mechanism for
Unidirectionnal Links, RFC3077, 03/2001.
[16] Digital Video Broadcasting, Digital Video Broadcasting; Interaction Channel for Satellite Distribution
Systems, ETSI EN 301 790, 03/2003.
[17] C. Berrou, A. Glavieux, P. Thitmajshima, "Near Shannon limit error-correcting coding and
decoding:turbo-codes," in IEEE Int. Conf. on Communications, (Geneva, Switzerland), pp. 1064-- 1070,
05/1993.
[18] D. Giancristofaro, A. Bartolazzi, Novel DVB-RCS standard Turbo-Code : details and performances of a
decoding algorithm, Seventh International Workshop on Digital Signal Processing Techniques for Space
Communications (DSP 2001), 10/2001.
[19] F. Ananasso and G.L. Verde, Networking Solutions for the 90's: Which Role for Satellites ?, AIAA,
pages 148--157, 1994.
[20] T. Inukai, D. Shyy, F. Faris, On-Board Processing Satellite Network Architectures for Broadband
ISDN, 14th AIAA International Communication Satellite System Conference, Washington, 03/1992.
[21] E. Altman, A. Ferreira, J. Galtier, Les rseaux satellitaires de tlcommunication, Ed. Dunod, ISBN
2100048252, 1999.
[22] I.F Akyildiz, S.H. Jeong, Satellite ATM Networks: A Survey., IEEE Communications Magazine, vol
35, p 30 43, 07/1997
[23] G. Maral, VSAT networks, John Wiley and Sons, 1995
[24] R. Goodings, IP over Satellite: Standardisation activities in ETSI/TC-SES,ITU Workshop on Satellites
in IP and Multimedia, 12/2002.
[25] Spacebridge, DVB-RCS: Satellite Industry Needs, Opportunities and Issues, 2001,
http://www.spacebridge.com/documents/appnotes/WP-DVBRCSIN-DB.pdf.
[26] N. Abramson, Internet Access Using VSATs, IEEE Communications Magazine, p60-68, 07/2000.
[27] S. Chacn, J.L. Casas, A. Cal, R. Rey, J. Prat, J. de la Plaza, G. Monzat, P. Carrere, C. Miguel, F. J. Ruiz,
Networking over the IBIS System, IST Mobile & Wireless Telecommunications Summit, 2002.
[28] DIPCAST, projet RNRT, http://www.dipcast-satellite.com.
[29] GEOCAST,projet EC IST, http://www.ee.surrey.ac.uk/CCSR/IST/Geocast
[30] SATIP6 project, IST-2001-34344, http://satip6.tilab.com
[31] Tachyon commercial web page, http://www.tachyon.net
[32] Digital Video Broadcasting, Digital Video Broadcasting; Implementation guidelines for Data
Broadcasting, ETSI TR 101 202, 03/2003
[33] IETF working-group IP/DVB, http://www.erg.abdn.ac.uk/ip-dvb
[34] U. Reimers, Digital Video Broadcasting. The International Standard for Digital Television, Ed.
Springer, ISBN 3540609466, 2001.
186
RFRENCES
[35]
G. Fairhurst, M.J. Montpetit, Address Resolution for IP datagrams over MPEG-2 networks, Internet
draft, 07/2004.
[36] Digital Video Broadcasting, Digital Video Broadcasting; Multimedia Home Platform (MHP)
Specification 1.03, ETSI ES 201 812, 12/2003.
[37] H.D. Clausen, B. Collini-Nocker, G. Fairhurst, H. Linder, Simple Encapsulation for transmission of IP
datagrams over MPEG-2/DVB networks, Internet Draft, 04/2002, Expir.
[38] G. Fairhurst, B. Collini-Nocker, Ultra Lightweight Encapsulation (ULE) for transmission of IP
datagrams over MPEG2/DVB networks, Internet Draft, 05/2004.
[39] M. Sooriyanbandara, M. Forrest, G. Fairhurst, Predicting performance of ROHC over Ultra Lightweight
Encapsulation protocol, WCC 2004, Broadband Satellite Communication Systems, p 57-66, 27/08/04
[40] G. Gebler, W. Fritshe, K. Mayer, A. Ritoux, Standardisation Support enhanced IETF IP Encapsulation
Techniques, Final Report, European Space Agency, n 177477/03/NL/ND, 2004.
[41] F. Filali, G. Aniba, W. Dabbous, Efficient Support of IP Multicast in the Next-Generation of GEO
Satellites, IEEE Journal on Selected Areas in Communications (JSAC), p 413-425, Vol 22, n2, 02/2004.
[42] N.K.G. Samaraweera, Return Link Optimization for Internet Service Proposition Using DVB-S
Networks, ACM SIGCOMN Computer Communication Review, Vol. 29, n3, 07/1999.
[43] J. Fasson, E. Chaput, C. Benassy-Foch, C. Faure, F. Filali, Architecture systme transparent pour le
projet DIPCAST, WP 1421, 2002.
[44] X. Lobao, SATLABS group: Leading the DVB-RCS standard to a commercial success, WCC 2004,
Broadband Satellite Communication Systems, p 11-16, 27/08/04
[45] M. Degermark, B. Nordgren, S. Pink, IP Header Compression, RFC2507, 02/1999.
[46] C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T.
Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng,
RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed, RFC3095, 07/2001.
[47] M. Montpetit, M. Schmidt, G. Fairhurst, B. Collini-Nocker, H. Linder, H. Tork, IP over DVB: Study of
Encapsulation and Protocol Performance, Final Report, 2004.
[48] Global Communication & Services (GCC), produit Highflex converter, http://www.gcs-salzburg.at/ .
[49] M.J. Montpetit, G. Fairhurst, B. Collini-Nocker, H. Linder, A Framework for transmission of IP
datagrams over MPEG-2 networks, Internet Draft, 07/2004.
[50] J. Fasson, E. Chaput, Intgration du protocole IP multicast au systme DVB-RCS/OBP, WP 2820,
02/2003
[51] J. Fasson, E. Chaput, C. Fraboul, IP Multicast Architectures over Next-Generation GEO Satellites, VTC
2004 Spring, 06/2004.
[52] J. Fasson, La nouvelle gnration de satellites gostationnaires comme support dIP, EDIT 2004,
03/2004
[53] H.L. Truong, W.W. Ellington, J.Y. LeBoudec, A.X. Meier, J.W. Pace, LAN Emulation on an ATM
Network, IEEE communications Magazine, Vol 33, N5, p 70-85, 05/1995.
[54] C.W. Chao, Y.S. Chu, W.L. Shyu, Design and Implementation of IP Multicast over ATM Network,
http://citeseer.nj.nec.com/570654.html, 2001.
[55] T. Braun, S. Gumbrich, H. J. Stuttgen, Comparison of concepts for IP multicast over ATM, IEEE
ATM'96 Workshop, San Francisco.
[56] Cisco,
Multicast
in
a
Campus
Network:
CGMP
and
IGMP
Snooping,
http://www.cisco.com/warp/public/473/22.html, 03/2003.
[57] W. Milliken, IP Multicasting over ATM: System Architectures Issues, Internet Draft, 07/1995.
[58] B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, Internet Group Management Protocol,
Version 3, 10/2002.
[59] B. Fenner, Internet Group Management Protocol, Version 2, 11/1997.
[60] M. Christensen, K. Kimball., F. Solensky, Considerations for IGMP and MLD Snooping Switches,
Network Working Group MAGMA, 03/2003.
[61] I.F. Akyildiz, S.H. Jeong, Satellite ATM networks: A survey, IEEE Communications Magazine, 1997.
[62] D. Roddy, Satellite communications, 3eme edition, ISBN 0-07-137176-1. 2001
[63] G. Pujolle, Les Rseaux, Ed Eyrolles, 2003.
[64] W. R. Stevens, TCP/IP Illustrated Volume 1 The Protocols, Ed. Addison-Wesley, ISBN 0201633469,
2001.
[65] S. Oueslati-Boulahia, A. Serhouchni, S. Tohm, S. Baier, M. Berrada,TCP Over Satellite Links:
Problems and Solutions, Telecommunication Systems, ed. Kluwer, vol. 13, p. 199-222, 2000.
[66] M. Allman, V. Paxons, W. Stevens, TCP Congestion Control, RFC 2581, 04/1999.
[67] S. Floyd, T. Henderson, The NewReno Modification to the TCPs Fast Recovery Algorithm, RFC 2582,
04/1999.
187
RFRENCES
[68]
M. Allman, D. Glover and L. Sanchez, Enhancing TCP over Satellite Channels using Standard
Mechanisms, RFC 2488, janvier 1999.
[69] M. Allman, S. Ostermann, Multiple Data Connection FTP Extensions, Technical Report TR-19971,
Ohio Universityn 02/1997.
[70] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High Performance, RFC 1323, 06/1992.
[71] J. Mogul, S. Deering, Path MTU Discovery, RFC 1191, 11/1990.
[72] R. Braden, Requirements for Internet Hosts Communication Layers, STD 3, RFC 1122, 10/1989.
[73] N. Chaher,C. Barakat, W. Dabbous, E. Altman, Improving TCP over Geostationary Satellite Link,
INRIA Research Report RR-3773,10/1998
[74] H. Benadoud, A. Berqia, N. Mikou, Enhancing TCP over satellite links using CANIT algorithm,
International Journal of SIMULATION, Vol. 3 No. 3-4. pp 81-91, 2002.
[75] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective Acknowledgment Options, RFC 2018,
10/1996.
[76] G. Yang, R. Wang, F. Wang, M.Y. Sanadidi, and M. Gerla, TCP Westwood with Bulk Repeat for Heavy
Loss environments,UCLA CSD Technical Report #020023, 2002.
[77] Site de TCP Westwood, http://www.cs.ucla.edu/NRL/hpi/tcpw .
[78] G. Giambene, M. Marandola, Internet Access in ybrid Terrestrial and Satellite Mobile Communication
Systems, VTC 2004 Spring, 06/2004.
[79] J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby, Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations, RFC 3135, 06/2001.
[80] L. Wu, F. Peng, V.C.M. Leung, Dynamic Congestion Control for Satellite Networks Employing TCP
Performance Enhancement Proxies, IEEE PIMRC04, 09/2004.
[81] N. Ghani, S. Dixit, TCP/IP Enhancement for Satellite Networks, IEEE Communications Magazine, p.
64-72, 07/1999.
[82] S. Oueslati-Boulahia, A. Serhouchni, S. Tohm, S. Baier, M. Berrada, GACK : A Spoofing Mechanism
for Enhancing TCP Performance over Satellite, IFIP, Africom98, Tunisie, 1998.
[83] M. Luglio, J. Stepanek, M. Gerla, TCP performance using splitting over the satellite link, 8th Ka Band
utilization conference, p. 45-52, 09/2002.
[84] G. Adams, DVB-RCS; Enabling 2way-sat broadband communications, www.newtec.be, vol. 2,
06/2002.
[85] R. Goodings, M.J. Montpetit, Broadband Satellite Multimedia (BSM) Architectures, WCC 2004,
Broadband Satellite Communication Systems, p 1-10, 27/08/04.
[86] C. Guillemin, Thomson livre Canal Satellite un dcodeur enregistreur, ZDNet France,
http://www.zdnet.fr/actualites/technologie/0,39020809,2132447,00.htm, 25 mars 2003.
[87] K. Almeroth, M. Ammar, The Role of Multicast Communication in the Provision of Scalable and
Interactive Video-On-Demand Service, Proc. 5th Intl. Workshop on Network and Operating System
Support for Digital Audio and Video, p. 267-270, 04/1995.
[88] J.
Bernoff,
How
Cable
TV
Can
Beat
Satellite,
Forrester
Research,
http://www.forrester.com/ER/Research/Report/Summary/0,1338,14566,FF.html, avril 2002.
[89] T. Watts, Outside the box : Satellite Vs. Cable Coexistence, but not peacefull, skyreport.com , janvier
2003.
[90] K.C. Neel, VOD: Satellite Killer or Bundle Filler?, CableFAXs CableWORLD,
http://www.cableworld.com/cgi/cw/show_mag.cgi?pub=cw&mon=030804, 08/03/2004.
[91] http://www.moviesystem.com .
[92] http://www.europeonline.com .
[93] http://www.mediametrie.fr .
[94] Le Journal du Net, Ce que lon peut attendre de 2004, http://www.journaldunet.com, enqute fin 2003
dbut 2004.
[95] R. Tran Van Lieu, Le Haut dbit, 01 Rseaux n138, avril 2004.
[96] V. Schena, F. Ceprani, FIFTH Project Solutions Demonstrating New Satellite Broadband
Communication System for High Speed Train, TC 2004 Spring, 06/2004.
[97] M. A. Vasquez Castro, F.J. Gonzalez Serrano, A. Martinez Fernandez, G. Mohedano Moya, Quality of
service of VoIP over DVB-RCS, Sixth Baiona Workshop on Signal Processing in Communications,
09/2003.
[98] L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, G. Fairhurst, The Lightweight User Datagram
Protocol (UDP-Lite), RFC 3828, 07/2004.
[99] J. Sjoberg, M. Westerlund, A Lacaniemi, Q. Xie, Real-Time Transport Protocol (RTP) Payload Format
and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMRWB) Audio Codecs, RFC 3267, 06/2002.
188
RFRENCES
[100] F. de Belleville, L. Dairaine, C. Fraboul, J. Lacan., Une Approche Hybride Satellite/Terrestre pour le
transport fiable multipoint frande chelle, Colloque Francophone sur l'Ingnierie des Protocoles, 2003.
[101] N. Ben Azzouna, F. Guillemin, Experimental analysis of the impact of peer-to-peer applications on
traffic in commercial IP networks, European transactions on Telecommunications: Special issue on P2P
networking and P2P services, ETT 15(6),12/2004.
[102] L. Duquerroy, S. Josset, O. Alphand, P. Berthou, T. Gayraud, SatIPSec: an optimized solution for
securing multicast and unicast satellite transmissions, 22nd AIAA International Communications Satellite
Systems Conference (ICSSC), Monterey (USA), 9-12 Mai 2004.
[103] Digital Video Broadcasting, Digital Video Broadcasting; Second generation framing structure, channel
coding and modulation systems for Broadcasting, Interactives Services, News Gathering and other
broadband satellite applications., ETSI EN 302 307, 06/2004.
[104] European
Space
Agency,
AmerHis:
first
switchboard
in
space
launched,
http://www.telecom.esa.int/telecom ,08/2004.
[105] E. Lutz, M. Werner, A Jahn, Satellite System for Personal and Broadband Communications, Ed.
Springer, ISBN 3 540 66840 3, 2000.
[106] D. Present, Architecture dInterconnexion de cartes de commutation ATM par bus optique, tse de
doctorat de lUniversit de Versailles-ST Quentin en Yvelines, 12/1996.
[107] D. M. Elwatt, Cisco Shoots For The Stars Satellite. Company uses off-the-shelf Cisco router in space; networks
could extend to the cosmos, informationweek.com, 2003
[108] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated
Service, RFC2475, 12/1998.
[109] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview,
RFC1633, 06/1994.
[110] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol (RSVP) -Version 1 Functional Specification, RFC2205, 09/1997.
[111] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L.
Wei, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification, RFC 2362,
06/1998.
[112] F. Filali, W. Dabbous, Issues on the IP Multicast Service Behaviour over the Next-Generation SatelliteTerrestrial Hybrid Networks, IEEE ISCC2001, 07/2001.
[113] F. Filali, J.P. Pomies, T. Meynadier, N. Douchin, C. Benassy Foch, DVB comme support de l'IP
multiCast : Adaptation de PIM-SM pour un systme satellite GEO transparent DVB, CFIP 2003, 10/2003
[114] Digital Video Broadcasting, Digital Video Broadcasting; Interaction channel for Satellite Distribution
Systems; Guidelines of the use of EN 301 790, ETSI TR 101 790, 01/2003.
[115] F. Arnal, A. Bolea Alamaac, L. Castanet, L. Dairaine, M. Bousquet, L. Claverotte, G. Maral , R.
Guttirez, Reliable Multicast Transport Protocols performances in emulated satellite environnement taking
into account an adaptative physical layer for GEOCAST system, International Workshop of COST Actions
272 and 280, 06/2003.
[116] M.W. Koyabe, G. Fairhurst, Performance of reliable multicast protocols via satellite at EHF with
persistent fades, 7th Ka-Band Utilization Conference, 09/2001.
[117] C. Casetti, M. Gerla, S. Mascolo, M. Y. Sanadidi, R. Wang, TCP Westwood: Bandwidth Estimation for
Enhanced Transport over Wireless Links, Mobicom 2001, Rome,Italy, 07/2001.
[118] E. N. Gilbert, Capacity of a burst-noise channel, Bell System Technical Journal, Vol. 39, pp.1253-1265,
09/1960.
[119] M. Yajnik, J. Kurose, D. Towsley, Packet loss correlation in the MBone multicast network: Experimental
measurements and Markov chain models UMASS COMPSCI Technical Report 95-115, 1996.
[120] L. Chisci, R. Fantacci, F. Francioli, T. Pecorella, Multi-terminal dynamic bandwidth allocation in GEO
Satellite Networks, VTC 2004 Spring, 06/2004.
[121] K.D. Lee; Y.H. Cho; H.J. Lee; H. Jeong Optimal scheduling for timeslot assignment in MF-TDMA
broadband satellite communications, VTC 2002-Fall, Vol: 3, p. 1560-1564, 09/2002.
[122] Digital Video Broadcasting, Digital Video Broadcasting; Guidelines on implementation and usage of
Service Information, ETSI TR 101 211, 05/2004.
[123] EUTELSAT, Recommanded transmission parameters for DVB broadcasters and operators of DVB
multiplexes using the EUTELSAT HOT BIRDtm system, guide technique, http://www.eutelsat.com
07/06/99.
[124] Digital Video Broadcasting, Digital Video Broadcasting; Interaction channel for Satellite Distribution
Systems, Guidelines for the use of EN 301 790, ETSI TR 101 790, 01/2003.
[125] J. Grieu, Analyse et valuation de techniques de commutation Ethernet pour linterconnexion des
systmes avioniques, thse de doctorat, 2004.
[126] V. Paxon, S. Floyd, Wide area traffic: The failure of Poisson modeling, IEEE/ACM Transaction on
Networking, vol. 3, n. 3, p. 226-244, 06/1995.
189
RFRENCES
[127] W.E. Leland et al., On the Self-Similar Nature of Ethernet Traffic, IEEE/ACM Transaction on
Networking, vol. 2, p. 1-15, 1994.
[128] M.E. Crovella, A. Bestavros, Self-similarity in World Wide Web traffic: evidence and possible causes,.
Networking, IEEE/ACM Transactions, n 6, Vol. 5, p. 835-846, 12/1997.
[129] Site de NS 2, http://www.isi.edu/nsnam/ns .
[130] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP Throughput: A Simple Model and its
Empirical Validation, ACM SIGCOM98, 1998.
[131] J. Neale, A. Mohsen, Impact of CF-DAMA on TCP via satellite performance, IEEE Globecom'01,
11/2001.
[132] SESBSM, Satellite Earth Stations and Systems (SES);Broadband satellite multimedia;Part 1: Survey on
standardization objectives, ETSI TR 101 374-1 V1.2.1, 10/1998.
[133] SESBSM, Satellite Earth Stations and Systems (SES);Broadband Satellite Multimedia;Overview of BSM
families, ETSI TR 102 187 V1.1.1, 05/2003.
[134] F. de Belleville, L. Dairaine, C. Fraboul, J.Y. Tourneret, Group size estimation for hybrid
satellite/terrestrial reliable multicast, WCC 2004, Broadband Satellite Communication Systems, p 57-66,
27/08/04.
190
Rsum
Cette thse aborde les problmes relatifs l'intgration des satellites gostationnaires dans les
rseaux IP. Une premire tape de ce travail consiste en une analyse critique des systmes utilisant le
Digital Video Broadcating pour vhiculer des flux IP. Cette tude souligne les faiblesses des solutions
actuelles : tandis que les solutions classiques souffrent de limites inhrentes la technologie et aux
protocoles utilises, les propositions reposant sur les satellites de nouvelles gnration impliquent un
systme spcifique et fortes contraintes financires. Ces limites engendrent des difficults
dinteroprabilit, tmoignant de la ncessit dune dmarche plus globale qui viserait dessiner une
architecture plus large qui ne reposerait pas sur des contraintes techniques. La thse propose alors de
suivre cette dmarche, et de concevoir une architecture pour intgrer ces diffrentes solutions dans un seul
systme et pouvoir supporter des services porteurs comme laccs Internet, la vido la demande et
linterconnexion de rseaux privs. Au cur de cette architecture se trouve la notion de charge utile
hybride, cest--dire intgrant une partie transparente traditionnelle et une partie rgnrative utilisant une
intelligence embarque plus ou moins volue. Ses objectifs sont alors dassurer lintgration de services
porteurs sur satellite, doffrir une transition entre les systmes transparents et les satellites de nouvelle
gnration, et enfin de sadapter aux volutions protocolaires. Dans ce contexte, cette proposition est
dcrite plusieurs niveaux, en insistant sur le lien entre le niveau rseau et la couche liaison. Cette
description implique des choix technologiques tmoignant des solutions actuelles, mais reste ouverte aux
technologies venir par son intgration dIP comme un lment fdrateur. Enfin lanalyse du systme
hybride permet de lgitimer les services choisis, et de souligner sa flexibilit offerte par la coexistence de
ces deux modes et la possibilit de choisir pour chaque type de trafic celui qui permet les meilleurs
performances.
Title
STUDY OF AN IP ARCHITECTURE INTEGRATING A GEOSTATIONARY LINK
Abstract
This thesis studies issues related to the integration of geostationary satellites in IP networks. A first
part of this work presents an analysis of today and future DVB systems for IP support. The limits of
standard solutions are underlined. However new technologies and protocols adaptations allow satellite
systems to be more compliant to IP services, but at several costs: high complexity and specificity. As there
is a real need of a global solution, an architecture based on two different payloads (a transparent one and
an on-board-processing) in a same system is proposed for service integration. This solution, called a
hybrid system, is defined according to different service needs. It proposes to undertake the transition
between today systems and next generation satellites, as to integrate different services and protocols. The
study describes such a solution, underlining that the technologic choices have been made according to
today solutions, and may be changed in future days. Eventually this architecture is evaluated. The analysis
of the system overhead for IP support shows that the architecture proposes a light way to manage IP
streams and hybrid mode. The study of service integration concludes on the flexibility of managing two
modes for different traffic streams, allowing the best performances for each one.
Discipline
RSEAUX ET TLCOMMUNICATIONS
Mots-cls
Satellite gostationaire, DVB-S, DVB-RCS, intgration de services, routage, tranparence,
normalisation.
Intitul et adresse du laboratoire:

TSA, 2 rue Charles Camichel F-31071 Toulouse, Cdex 7, BP 7122, FRANCE.

Fasson

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Fasson

Transféré par

Droits d'auteur :

Formats disponibles

n ordre 2187

COLE DOCTORALE INFORMATIQUE ET TLCOMMUNICATIONS

TUDE DUNE ARCHITECTURE IP INTGRANT

Thse pour le doctorat en Rseaux et Tlcommunications de

Soutenue le 15 dcembre 2004 devant le jury compos de

LISTE DES ACRONYMES

Liste des acronymes

ATM Adaptation Layer 5

LISTE DES ACRONYMES

Forward Link Signalling

LISTE DES ACRONYMES

Program Specific Information

LISTE DES ACRONYMES

LISTE DES FIGURES

Liste des figures

LISTE DES FIGURES

LISTE DES FIGURES

LISTE DES FIGURES

LISTE DES TABLEAUX

Liste des tableaux

Table embarque de correspondance entre IN, VP et Spots cibles

Les diffrents besoins des trois services tudis

Exemple de table de correspondance dun RCST

Dpendance entre les requtes VoD pour un mdia et le mode du systme

Tables SI consultes pour avoir accs au PID dun flux IP

VALUATION du poids de la signalisation pour un flux IP

Composition dune supertrame

Linfluence de la rpartition bord/sol sur la ractivit du systme

Gain du multifaisceaux pour la voie aller en mode unipoint

Segment maximal transfr au bout de 2000 s

LISTE DES TABLEAUX

Digital Video Broadcasting :

TABLES DES MATIRES

Table des matires

DVB COMME NORME DE COMMUNICATION SPATIALE

LE SATELLITE COMME SUPPORT DIP

PROPOSITION DUNE ARCHITECTURE HYBRIDE

TABLE DES MATIRES

EVALUATION DE LARCHITECTURE HYBRIDE

CHAPITRE 1. INTRODUCTION ET PROBLMATIQUE

1.2. Le satellite, un outil de communication

Source mdiamtrie, www.mediametrie.fr .

CHAPITRE 1. INTRODUCTION ET PROBLMATIQUE

1.3. Une coexistence problmatique

lintgration dIP aussi efficace que possible sur un systme satellite ;

lintgration homogne et cohrente de diffrents services ;

CHAPITRE 1. INTRODUCTION ET PROBLMATIQUE

lutilisation et la pertinence des nouvelles technologies dans un cadre IP.

1.4. Le plan de ltude

CHAPITRE 1. INTRODUCTION ET PROBLMATIQUE

CHAPITRE 2. DVB COMME NORME DE COMMUNICATION SPATIALE

2. DVB COMME NORME DE

2.1. La norme DVB

CHAPITRE 2. DVB COMME NORME DE COMMUNICATION SPATIALE

Telecommunications Standards Institute). Un nouveau standard, le DVB-S2 est dailleurs dans sa

Les standards de transmission qui traitent de limplmentation du transport des ES

Les standards dinterfaage et de codage avec notamment le DVB-CI (DVB Common

CHAPITRE 2. DVB COMME NORME DE COMMUNICATION SPATIALE

Figure 2.1 Deux types de multiplexage pour MPEG-2

CHAPITRE 2. DVB COMME NORME DE COMMUNICATION SPATIALE

2.2. La norme DVB-S

Figure 2.2 DVB-S et ses concurrents dans le monde1

Pile de protocoles DVB-S

La pile de protocoles du DVB-S sappuie majoritairement sur la norme MPEG-2. La figure