Performances des applications IP dans les systèmes de

communications par satellite : cas du DVB-RCS et du

DVB-S2
Nizar Jegham

To cite this version:

Nizar Jegham. Performances des applications IP dans les systèmes de communications par satel-
lite : cas du DVB-RCS et du DVB-S2. Autre [[Link]]. Université Paris-Est, 2008. Français. �NNT :
2008PEST0218�. �tel-00495622�

HAL Id: tel-00495622

[Link]
Submitted on 28 Jun 2010

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 Thèse
Présentée en vue de l’obtention du titre de

Docteur
de
L’Université Paris-Est, Marne-La-Vallée

ECOLE DOCTORALE : Information, Communication, Modélisation, Simulation (ICMS)

Paris, Marne-La-Vallée
SPECIALITE : Télécommunications et Réseaux

Par

Nizar JEGHAM

Performances des applications IP dans les systèmes de

communications par satellite : cas du DVB-RCS et du DVB-S2

Soutenue le 12 novembre 2008 devant le Jury

Guy PUJOLLE Professeur université Paris VI Président

Michel BOUSQUET Professeur ISAE Rapporteur
Thierry GAYRAUD Maître de conférences, UPS Rapporteur
André-Luc BEYLOT Professeur INPT, ENSEEIHT Co-directeur de thèse
Gilles ROUSSEL Professeur Paris-Est Directeur de thèse
Stéphane LOHIER Maître de conférences, Paris-Est Examinateur
Nicolas LEROUGE Ingénieur EADS Astrium Membre invité
Remerciements

Les travaux présentés dans ce mémoire ont été réalisés dans le cadre d’une thèse
CIFRE menée en collaboration entre l’institut Gaspard Monge de l’université Marne-la-
Vallée, le laboratoire IRIT-ENSEEIHT à Toulouse et la société EADS Astrium.
Les remerciements sont une partie incontournable du mémoire qui ne demeure pas pour
autant une tâche aisée. Ce travail a été enrichi au fil des trois années de thèse par des
contributions directes et indirectes de tellement de personnes que je crains d’en oublier
certaines au moment des remerciements. Je me lance tout de même.
Je commencerai par remercier monsieur Guy Pujolle pour avoir accepté de présider le jury
de thèse. Je voudrais également dire que j’étais honoré que messieurs Michel Bousquet et
Thierry Gayraud aient accepté d’assumer les fonctions de rapporteurs et de commenter mon
travail avec leurs remarques pertinentes.
Je remercie, notamment, monsieur Gilles Roussel pour avoir dirigé mes travaux de thèse
ainsi que l’ensemble des membres de l’Institut Gaspard Monge de l’université Marne-La-
Vallée, et en particulier Stéphane Lohier.
Mes vifs remerciements à l’ensemble des membres du laboratoire IRIT-ENSEEIHT, à
Toulouse pour m’avoir accueilli et intégré dans leur équipe.
Pendant ces trois ans, j’étais basé dans les locaux d’EADS Astrium à Toulouse. J’ai eu la
chance de travailler avec des personnes très compétentes qui ont toutes, quelque part, eu un
apport dans mon travail.
Je remercie tout d’abord monsieur Hervé Uchard, chef de la division télécommunications et
segments sols et monsieur Patrice Pessah chef du département VSAT, qui ont su à tous les
moments me fournir les moyens et le support nécessaire pour mener à bien mes travaux. Je
remercie et salue au passage l’ensemble de l’équipe, Bertrand, Christian, Jean Christian,
Pierre-Yves, Raphaël, Lucas, Sophie, Hilarion, Romuald, Didier, Nasser, Muriel sans oublier
Nicolas Girault auprès de qui j’ai énormément appris.
Aussi je voudrais témoigner de ma gratitude et de ma reconnaissance à deux personnes en
particulier et sans qui ce travail n’aurait probablement pas été achevé.
La première est Nicolas Lerouge pour sa disponibilité, pour m’avoir aidé à orienter mon
travail, pour le recul qu’il a et le pragmatisme de ses commentaires mais aussi pour ne pas
avoir fait défaut à mes requêtes incessantes et parfois insistantes. Sur un plan technique, je
dirai même qu’il m’a presque tout appris.
La deuxième personne est certainement André-Luc Beylot, mon co-directeur de thèse. Il a
accepté de diriger mes travaux en début de troisième année de thèse ce qui représentait un
pari risqué. Il a toutefois su m’encadrer, être très disponible et patient pour m’orienter et
m’aider à retrouver confiance dans les moments de doute.
Je tiens aussi à remercier tous mes amis et mes proches pour leurs encouragements. Je
remercie notamment Imen pour avoir passé de longues heures à lire mon texte et à le
corriger.
Enfin, je dirai tout simplement MERCI à mes parents, à qui je dois tout et pour qui j’ai
décidé d’aller au bout de ce travail.

ii
 « Chacun vaut ce que valent les objectifs de ses efforts »
Marc-Aurèle

iii
Abstract

Despite of a number of IP satellite networks developed and deployed, only a limited

number of studies and feedbacks about the performance is available. IP over satellite systems
raises several constraints. One of the main reasons is the lack of adaptation of IP protocol,
initially designed for terrestrial wired networks, to the large bandwidth delay product of the
satellite media. Another reason is a lack of coordination between the IP protocol stack upper
layer and the satellite MAC and physical layer.
The purpose of this PhD study is to evaluate and assess the behaviour of IP
applications when conveyed over satellite systems. We mainly focus on the IP quality of
service performance, bandwidth encapsulation efficiency as well as IP applications metrics.
Through the observation, we try to find how it’s possible to modify the IP satellite systems
configuration in order to improve IP applications performance. We also suggest some ideas
about the way to refine these technologies with regards to the design aspects.
Experimentations have been performed over test beds implementing both
standardised satellite technologies such as DVB-RCS as well as proprietary systems such as
iDirect in addition to the new normalised technology DVB-S2.

Key words DVB-RCS, DVB-S2, ACM, QoS, IP encapsulation

Résumé

Les retours et les études dont on dispose sur les réseaux IP par satellite ne
permettent pas d’apprécier les performances dont ils sont capables. Pourtant, les difficultés
de transmettre de l’IP par satellite persistent encore. L’inadaptation du protocole IP,
initialement conçu pour des réseaux terrestres, au large produit délai-bande du média
satellite est une raison. Le fonctionnement souvent dé-corrélé entre les niveaux supérieurs
de la pile TCP/IP et les couches physique et MAC du média satellite, est une autre.
Dans le cadre de ce travail de thèse nous adoptons une démarche expérimentale basée sur
l’observation, l’analyse et l’évaluation de systèmes implantant des technologies IP par
satellite tels que le standard DVB-RCS, la technologie propriétaire iDirect ou la nouvelle
norme DVB-S2. Nous étudions l’impact des règles de qualité de service IP sur les
performances des applications dans un contexte de bande limitée. Nous nous penchons
notamment sur l’évaluation des efficacités de l’encapsulation IP en termes de consommation
de bande. Notre premier objectif est de déceler les niveaux auxquels un opérateur peut agir
en vue d’optimiser la configuration d’un système IP par satellite et en accroître les
performances.

Mots clefs DVB-RCS, DVB-S2, ACM, QoS, Encapsulation IP

iv
Liste des acronymes

ACK Acknowledegment
ACM Adaptive Coding and Modulation
ADSL Asymetric Digital Subscriber Line
AES Advanced Encryption Standard
AF Assured Forwarding
AH Authentification Header
ATM Asynchronous Transfer Mode
AVBDC Absolute Volume Based Capacity
AWGN Additive White Gaussien Noise
BB Frame Base Band Frame
BCH Bose-Chaudhuri-Hocquenghem
BDP Bandwidth Delay Product
BE Best Effort
BER Bit Error Rate
BoD Bandwidth on Demand
BPSK Binary Phase Shift Keying
BSM Broadband Satellite Multimedia
CAC Call Admission Control
CAT Conditional Access Table
CBWFQ Class Based Weightened Fair Queues
CCM Constant Coding and Modulation
CDMA Carrier Dense Multiple Access
CIR Committed Information Rate
CRA Constant Rate Assignment
CSC Common Signalling Burst
DAB Digital Audio Broadcasting
DAMA Dynamic Assignment Multiple Access
DES Data Encryption Standard
DFL Data Field Length
DG Demand Header
Diffeserv Differentiated Services
DRA Dynamic Rate Assignment
DSCP Differentiated Service Code Point
DSM-CC Digital Storage Media – Command and Control
DTH Direct To Home
DVB-C Digital Video Broadcasting - Cable
DVB-H Digital Video Broadcasting - Handled
DVB-RCS Digital Video Broadcasting - Return Channel Satellite
DVB-S Digital Video Broadcasting - Satellite
DVB-SH Digital Video Broadcasting - Satellite Handled
DVB-SNG Digital Video Broadcasting Satellite News Gathering

v
ECP Emulateur de Canaux de Propagation
EF Expedited Forwarding
ES Elementary Stream
ESP Encapsulation Security Payload
ETSI European Telecommunication Union
FCA Free Capacity Assignment
FCT Frame Composition Table
FDMA Frequency Division Multiple Access
FLS Forward Link Subsystem
FMT Fade Mitigation Techniques
FSA Free Shared Capacity
FSS Fixed Satellite Service
FTP File Transfer Protocol
GSE Generic Stream Encapsulation
GSM Global System for Mobile
HDTV High Defintion TV
HTTP Hyper Text Transfer Protocol
IETF Internet Engineering Task Force
IKE Internet Key exchange
INT IP/MAC Notification table
Intserv Integrated Services
IP Internet Protocol
IPsec IP security
ITU International Telecommunication Union
LAN Local Area Network
LDPC Low Density Parity Check
LEO Low Earth Orbit
MAC Media Access Control
MEO Middle Earth Orbit
MF-TDMA Multi Frequency Time Division Multiple Access
MOS Mean Opinion Score
MPE Multi Protcol Encapsulation
MPEG-TS Moving Picture Expert Group - Time Slot
MPLS MultiProtocol Label Switching
MSS Maximum Segment Size
MSS Mobile Satellite Service
MTU Maximum Transfer Unit
n-APSK n Amplitude Phase Shift Keying
NCC Network Control Center
NCR Network Clock reference
NGN Next Generation Network
NIT Network Information Table
OSI Open Systems Interconnections
PABX Private Automatic Branch eXchange

vi
PAD Packet Assembly and Deassembly
PAT Program Association Table
PCR Program Clock Reference
PDU Packet Data Unit
PEP Performance Enhancement Proxy
PER Packet Error Rate
PES Packet Elementary Stream
PHB Per Hop Behaviour
PID Packet IDentifier
PL Frame Physical Layer Frame
PLR Packet Loss Rate
PMT Program Map Table
PSI Packet Elementary Stream
PSTN Public Switched Telephone Network
QEF Quasi Error Free
QoS Quality of Service
QPSK Qudrature Shift Phase Keying
RBDC Rate Based Dynamic Capacity
RCST Return Channel Satellite terminal
RLSS Return Link Subsystem
RMT Retrun Channel Map Table
ROHC RObust Header Compression
RRA Radio Resource Allocator
RRM Radio Resource Manager
RRR Radio Resource Requester
RTO Retransmission Time Out
RTP Real Time Protocol
RTT Round Trip Time
SAC Satellite Access Control Descriptor
SACK Selective Acknowledgment
SAR Segmentation And Reassembly
SCT Superframe Composition Table
SDAF Satellite Dependent Adaptation Function
SDT Satellite Description Table
SDTV Simple Definition TV
SIAF Satellite Independent Adaptation Function
SIP Session Initiation Protocol
SI-SAP Satellite Independent Service Access Point
SLA Service Level Agreement
SLS Service Level Specification
SNIR Signal to Noise plus Interference Ratio
SPI Security Parameter Index
SYNC Synchronisation Burst
TBTP Terminal Burst Time Plan

vii
TCP Transport Control Protocol
TCT Time Slot Composition Table
TDM Time Division Multiplex
TDMA Time Division Multiple Access
TEB Taux D'Erreurs Binaires
TIM Terminal Information Message
TPC Turbo Code
UDP User Datagrams Protocol
ULE Ultra Lightweight Encapsulation
UMTS Unified Mobile Telecommunication System
UPC Uplink Power Control
VBDC Volume Based Dynamic Capacity
VCM Variable Coding and Modulation
VLAN Virtual Local Area Network
VoD Video on Demand
VoIP Voice over IP
VPN Virtual Private Network
VSAT Very Small Aperture Terminal
WAN Wide Area Network

viii
Liste des figures

Figure I.1 Convergence fixe-mobile, télécommunications-technologies d’informations [9].......................7

Figure I.2 Convergence des réseaux et des services vers le tout IP ...................................................................8

Figure I.3 Segmentation des acteurs dans le modèle NGN ..................................................................................9

Figure I.4 Evolution de la charge (Voix, vidéo, data) d’un satellite Eutelsat [16] ........................................9

Figure I.5 Architecture générale d’un réseau en étoile........................................................................................ 11

Figure I.6 Topologie en étoile .................................................................................................................................... 11

Figure I.7 Topologie maillée ...................................................................................................................................... 12

Figure I.8 Couverture mono faisceau et multifaisceaux ...................................................................................... 13

Figure I.9 Les différentes bandes de fréquences satellite .................................................................................... 14

Figure I.10 Atténuations dues à la pluie (A), au brouillard (B) ,aux gaz atmosphériques (C) [23] .......... 15

Figure II.1 Réseau d’accès BSM (Broadband Satellite Multimedia) [3]............................................................. 18

Figure II.2 MF-TDMA, Multiplexage en temps et en fréquence ..................................................................... 21

Figure II.3 Débit en fonction de la taille de la fenêtre [18] .............................................................................. 26

Figure II.4 Comportement des algorithmes Slow_Start et Congestion_Avoidance dans TCP..................... 27

Figure II.5 Implantation des proxies PEP sur une liaison satellite.................................................................... 30

Figure III.1 Chaîne de transmission DVB ................................................................................................................ 38

Figure III.2 Pile de protocole DVB............................................................................................................................. 39

Figure III.3 Structure d’un paquet MPEG-TS........................................................................................................ 40

Figure III.4 Les tables DVB-SI.................................................................................................................................... 42

Figure III.5 Structure générique d’un multiplex DVB .......................................................................................... 42

Figure III.6 Les méthodes d’encapsulation............................................................................................................... 43

Figure III.7 Structure d’un en-tête MPE .................................................................................................................. 44

Figure III.8 Insertion d’un octet additionnel en en-tête en mode sans bourrage........................................... 44

Figure III.9 Encapsulation MPE MPEG avec section packing activée............................................................ 45

Figure III.10 Efficacité IP sur MPEG avec et sans Section Packing [12] ........................................................ 45

Figure III.11 Pile protocolaire DVB-RCS................................................................................................................... 47

Figure III.12 Chaîne de transmission DVB-RCS ...................................................................................................... 48

Figure III.13 Trame, super-trame et Time slots ....................................................................................................... 49

Figure III.14 Pile protocolaire signalisation DVB-RCS.......................................................................................... 50

Figure III.15 Echanges de signalisation dans une session DVB-RCS ................................................................. 51

Figure IV.1 Architecture globale du réseau IP DVB-RCS................................................................................... 56

ix
Figure IV.2 Architecture du segment utilisateur..................................................................................................... 56

Figure IV.3 Architecture du segment opérateur...................................................................................................... 57

Figure IV.4 Le sous système Forward ou Aller (DVB-S) ..................................................................................... 58

Figure IV.5 Architecture du Hub DVB-RCS ............................................................................................................ 60

Figure IV.6 Bande passante à la demande.................................................................................................................. 62

Figure IV.7 Répartition des Times Slots au sein des trames................................................................................ 63

Figure IV.8 Solution d’accélération et de chiffrement (Source Udcast) ............................................................. 64

Figure IV.9 Spoofing sur le lien satellite ..................................................................................................................... 65

Figure IV.10 Tunnel VPN & accélération TCP .......................................................................................................... 65

Figure IV.11 Chiffrement IPsec ESP en mode Tunnel ............................................................................................. 66

Figure IV.12 Pile de protocole DVB-RCS & Accélération TCP et Chiffrement ................................................ 67

Figure IV.13 Architecture générale de la plate forme IP DVB-RCS..................................................................... 71

Figure IV.14 Encapsulation RTP, UDP , IP................................................................................................................ 75

Figure IV.15 Etapes d’encapsulation successives IPsec, MPE, MPEG................................................................ 76

Figure IV.16 Architecture du réseau IP DVB-RCS après intégration des sous-systèmes............................... 77

Figure IV.17 Gigue de la VoIP chiffrée et en “clair” sur la voie retour ................................................................ 79

Figure IV.18 Rythme des allocations des bursts trafic dans les cas chiffré et clair ........................................... 79

Figure IV.19 Niveau des requêtes de capacités adréssées par le terminal............................................................ 80

Figure IV.20 Délais de la VoIP en chifré et en “clair” avec du trafic de fond sur la voie Retour ................... 81

Figure IV.21 Délais de la VoIP en chiffré et en “clair” avec trafic de fond sur la voie Aller ........................... 81

Figure IV.22 Durée du chiffrement IPsec en fonction de la taille des paquets IP.............................................. 82

Figure V.1 Segmentation And Réassemblage (SAR) .....................................Error! Bookmark not defined.

Figure V.2 Efficacité des taux de codage sur le lien Aller et Retour ......... Error! Bookmark not defined.

Figure V.3 Structure de trame MAC sur le lien Aller ...................................Error! Bookmark not defined.

Figure V.4 Structure MAC lien Aller (champ de données) .......................... Error! Bookmark not defined.

Figure V.5 Structure de trame MAC sur le lien retour ................................Error! Bookmark not defined.

Figure V.6 Structure de trame de bande passante ..........................................Error! Bookmark not defined.

Figure V.7 Ordonnancement des paquets .........................................................Error! Bookmark not defined.

Figure V.8 QoS IP et ordonnancement des paquets.......................................Error! Bookmark not defined.

Figure V.9 Accélération TCP sous iDirect .......................................................Error! Bookmark not defined.

Figure V.10 Pile protocolaire iDirect ................................................................... Error! Bookmark not defined.

Figure V.11 Courbe d’efficacité spectrale fonction de Es/No sans Roll-OffError! Bookmark not
defined.

x
Figure V.12 Pertes de paquets et niveau d’énergie par bit..............................Error! Bookmark not defined.

Figure V.13 BER Vs Eb/No pour TCC 2/3 DVB-RCS ..................................Error! Bookmark not defined.

Figure V.14 Encapsulation IP sur MAC iDirect & DVB-RCS ...................... Error! Bookmark not defined.

Figure V.15 Architecture des plateformes de tests ...........................................Error! Bookmark not defined.

Figure V.16 Débit MAC sur lien Aller.................................................................Error! Bookmark not defined.

Figure V.17 Débit Mac RL sans trafic de fond & Débit Mac RL avec trafic de fondError! Bookmark
not defined.

Figure V.18 Comportement de la gigue sur le lien Retour.............................Error! Bookmark not defined.

Figure VI.1 ModCod et Eb/No [5] ............................................................................................................................ 85

Figure VI.2 Schémas de modulations DVB-S2......................................................................................................... 86

Figure VI.3 Efficacité spectrale théorique en présence d’un bruit gaussien [6] ............................................. 87

Figure VI.4 Efficacité spectrale et Rapport signal sur bruit [3]........................................................................ 87

Figure VI.5 Fonctionnement schématiques du DVB-S2 ACM [7] .................................................................... 89

Figure VI.6 Encapsulation IP MPE avec le mode Section Packing (Sans bourrage)....................................... 90

Figure VI.7 Format d’un paquet GSE (PDU complet) [8]..................................................................................... 91

Figure VI.8 L’air interface DVB-S2 avec ACM [8]................................................................................................ 92

Figure VI.9 La plateforme de test DVB-S2 Experiment pour le profil professionnel par satellite............... 93

Figure VI.10 Blocs fonctionnels du banc de tests DVB/S2-RCS .......................................................................... 94

Figure VI.11 La pile de protocole DVB-S2.................................................................................................................. 95

Figure VI.12 Encapsulation et ordonnancement ....................................................................................................... 95

Figure VI.13 Nombre maximal de paquets IP par BB Frame et par ModCod................................................... 98

Figure VI.14 Efficacité IP sur BB Frame..................................................................................................................... 99

Figure VI.15 Bits IP par symbole ................................................................................................................................ 100

Figure VI.16 IP sur MPE et GSE pour code 3/5 .................................................................................................... 101

Figure VI.17 Fading naturel par satellite observé sur trois antennes................................................................ 103

Figure VI.18 Événement de Fading expérimental................................................................................................... 103

Figure VI.19 TCP non accéléré en présence d’un événement de Fading et d’une boucle ACM ................. 104

Figure VI.20 TCP accéléré en présence d’un événement de fading et d’une boucle ACM............................ 105

Figure VI.21 Les courbes de débit IP, MPEG et BB Frame en fonction de la durée de la trame voix .... 107

Figure VI.22 Efficacité VoIP(utile)/BB Frame ....................................................................................................... 107

Figure VI.23 Débit IP, délai, pertes de paquets et gigue pour les communications VoIP........................... 108

Figure VI.24 Débit IP, délai, perte de paquet et gigue pour le traffic de fond sur le lien DVB-S2 ........... 108

xi
Liste des tableaux

Tableau III-1 Eb/No et Es/No requis pour un TEB de 2.10-4 ............................................ 39

Tableau IV-1 Principaux codecs utilisées pour les communications VoIP par satellite.. 70
Tableau V-1 ModCod et Eb/No (BER = 10-9)................. Error! Bookmark not defined.
Tableau V-2 Types de modulation utilisées...................... Error! Bookmark not defined.
Tableau V-3 Taille des blocs de données ............................ Error! Bookmark not defined.
Tableau V-4 ModCod .............................................................. Error! Bookmark not defined.
Tableau V-5 Modèle de répartition du trafic. .................... Error! Bookmark not defined.
Tableau V-6 Délai moyen Aller et Retour pour iDirect et DVB-RCSError! Bookmark
not defined.
Tableau VI-1 Les facteurs de Roll-off en DVB-S2 ................................................................... 88
Tableau VI-2 Nombre maximal de cellules MPEG en fonction du ModCod...................... 97

xii
Table des matières

INTRODUCTION……………………………………………………………………………1
I. LES RESEAUX SATELLITE DANS UN CONTEXTE DE CONVERGENCE IP.. 4
I.1. INTRODUCTION ...........................................................................................................................4
I.2. LES SATELLITES DE TELECOMMUNICATIONS ET LA CONVERGENCE IP ..........................4
I.2.1 Un peu d’histoire ..................................................................................................................4
I.2.2 Les services de télécommunications par satellite.................................................................5
I.2.3 La fin des réseaux dédiés et l’avènement d’Internet...........................................................6
I.2.4 Le satellite comme composant de l’infrastructure NGN ...................................................9
I.3. SYSTEMES SATELLITES BIDIRECTIONNELS ......................................................................... 10
I.3.1 Architecture générale ..........................................................................................................11
I.3.2 Topologies ...........................................................................................................................11
I.3.3 La couverture du satellite...................................................................................................12
I.3.4 Le traitement à bord...........................................................................................................13
I.3.5 Bande de fréquences et bande Ka.......................................................................................14
I.4. CONCLUSION ............................................................................................................................. 16
II. LE SATELLITE COMME SUPPORT DE L’IP, DIFFICULTE DE LA MISE EN
ŒUVRE........................................................................................................................................ 17
II.1. INTRODUCTION ........................................................................................................................ 17
II.2. CADRE DE REFERENCE DES SYSTEMES SATELLITES ETUDIES ........................................ 17
II.2.1 Préambule ...........................................................................................................................17
II.2.2 Le modèle architectural BSM fondé sur IP .....................................................................17
II.3. GESTION ET ACCES AUX RESSOURCES AUX NIVEAUX DES COUCHES BASSES................ 18
II.3.1 Introduction.........................................................................................................................18
II.3.2 Accès aux ressources............................................................................................................19
II.3.3 Allocation de ressources ......................................................................................................21
II.3.4 Le niveau physique et les techniques de contre-mesure (FMT).......................................22
II.4. CONTRAINTES ET SOLUTIONS A LA MISE EN ŒUVRE DE L’IP SUR SATELLITE ............ 25
II.4.1 TCP/IP adapté au satellite ..............................................................................................25
II.4.2 TCP et son adaptation aux communications par satellite ..............................................28
II.4.3 La qualité de service et la gestion de la bande passante ..................................................30
II.4.4 Architectures de qualité de service existantes....................................................................31
II.4.5 L’effet de la signalisation et de l’encapsulation................................................................36
II.5. CONCLUSION ............................................................................................................................. 36
III. DVB-RCS, UN STANDARD POUR LA TRANSMISSION DE L’IP
BIDIRECTIONNEL PAR SATELLITE. ............................................................................... 37
III.1. INTRODUCTION .................................................................................................................... 37
III.2. LA NORME DVB ................................................................................................................... 37
III.3. LA VOIE ALLER DVB-S....................................................................................................... 37
xiii
 III.3.1 La couche physique DVB-S ...............................................................................................38
III.3.2 L’accès au canal ..................................................................................................................39
III.3.3 Le standard DVB-S et la norme MPEG-2 ....................................................................39
III.3.4 Les méthodes d’encapsulation de l’IP sur DVB ...............................................................42
III.3.5 La résolution des adresses ..................................................................................................46
III.4. LA VOIE RETOUR DVB-RCS.............................................................................................. 47
III.4.1 Pile protocolaire..................................................................................................................47
III.4.2 La couche physique..............................................................................................................47
III.4.3 Accès et Allocation des ressources.......................................................................................48
III.5. CONCLUSION ......................................................................................................................... 52
IV. LA PLATEFORME IP DVB-RCS, ARCHITECTURE ET
EXPERIMENTATIONS........................................................................................................... 53
IV.1. INTRODUCTION .................................................................................................................... 53
IV.2. LA PLATEFORME IP DVB-RCS ........................................................................................ 53
IV.2.1 Introduction.........................................................................................................................53
IV.2.2 Principaux critères de spécification...................................................................................54
IV.2.3 Architecture générale de la plate forme IP DVB-RCS. ..................................................55
IV.2.4 Fonctionnement du système DVB-RCS............................................................................59
IV.2.5 Architecture finale de la plateforme ..................................................................................71
IV.3. EXPERIMENTATIONS, RESULTATS ET ANALYSES .......................................................... 71
IV.3.1 Pour un service VoIP sur DVB-RCS de bonne qualité ..................................................72
IV.3.2 Scénarios des tests et interprétations .................................................................................77
IV.4. CONCLUSION ......................................................................................................................... 82
V. IDIRECT ET DVB-RCS, COMPARAISON DES PERFORMANCES...... ERROR!
BOOKMARK NOT DEFINED.
V.1. INTRODUCTION ............................................................ERROR! BOOKMARK NOT DEFINED.
V.2. PRESENTATION DE LA TECHNOLOGIE IDIRECT ....ERROR! BOOKMARK NOT DEFINED.
V.2.1 Introduction.................................................................. Error! Bookmark not defined.
V.2.2 Couche physique............................................................ Error! Bookmark not defined.
V.2.3 Allocation de bande passante et accès au canal......... Error! Bookmark not defined.
V.2.4 Qualité de service ......................................................... Error! Bookmark not defined.
V.2.5 Les fonctionnalités niveau transport .......................... Error! Bookmark not defined.
V.2.6 Architecture et aspects non abordés............................. Error! Bookmark not defined.
V.3. ETUDE COMPARATIVE IDIRECT DVB-RCS...........ERROR! BOOKMARK NOT DEFINED.
V.3.1 Aperçu de la plateforme............................................... Error! Bookmark not defined.
V.3.2 Couche physique et couche MAC................................. Error! Bookmark not defined.
V.3.3 Tests applicatifs de voix sur IP.................................. Error! Bookmark not defined.
V.4. CONCLUSION .................................................................ERROR! BOOKMARK NOT DEFINED.
VI. LE NOUVEAU STANDARD DVB-S2 ET LES APPLICATIONS IP PAR
SATELLITE ................................................................................................................................ 83
VI.1. INTRODUCTION .................................................................................................................... 83
VI.2. LE STANDARD DVB-S2 ...................................................................................................... 83

xiv
 VI.2.1 Introduction.........................................................................................................................83
VI.2.2 Les principaux apports du standard .................................................................................85
VI.2.3 Les méthodes d’encapsulation ............................................................................................89
VI.2.4 L’interface air du standard DVB-S2...............................................................................91
VI.3. LE PROJET DVB-S2 SATELLITE EXPERIMENT ET LES EXPERIMENTATIONS ......... 92
VI.3.1 Introduction.........................................................................................................................92
VI.3.2 La plateforme de tests.........................................................................................................93
VI.3.3 Les évaluations théoriques .................................................................................................96
VI.3.4 Les tests applicatifs et l’ACM ......................................................................................... 102
VI.4. CONCLUSION ....................................................................................................................... 109
VII. CONCLUSION ET PERSPECTIVES .......................................................................110
VII.1. CONCLUSION ....................................................................................................................... 110
VII.2. PERSPECTIVES .................................................................................................................... 111

xv
Introduction Générale

Contexte et motivations

Depuis une dizaine d’années, le monde des services de télécommunications montre un

mouvement de convergence qui ne cesse de s’amplifier. La multiplication des offres triple et
quadruple play des fournisseurs d’accès à Internet, la télévision proposée sur les téléphones
mobiles et l’unification des systèmes d’information voix et données au sein des entreprises,
en représentent quelques exemples significatifs. En particulier, de plus en plus de réseaux de
communication de nature physique différente proposent les mêmes types de services
(transferts de données, voix, vidéo.). C’est un changement fondamental qui a atteint la
manière avec laquelle on conçoit les réseaux. Nous étions confinés, jusque là, dans une
perception segmentée (les réseaux d’opérateurs fixes ou mobiles pour la voix, le satellite
pour la télévision...) qui définit chaque réseau en fonction du service qu’il fournit. On évolue
désormais vers une vision globale qui associe l’ensemble des systèmes de transmission de
données multimédia au sein d’une infrastructure globale appelée désormais NGN (Next
Generation Network) ou réseaux de nouvelle génération.
L’un des principaux catalyseurs de ce mouvement est l’avènement de techniques
pouvant contenir et transmettre toutes les formes que peut prendre l’information (données,
voix, vidéo). Le choix semble désormais trancher en faveur des technologies « paquet »
issues des réseaux informatiques, en particulier au travers des solutions provenant du monde
de l’Internet. IP (Internet Protocol) est le protocole qui prédomine en raison de sa capacité à
contenir et à acheminer des données indépendamment de leur nature et des caractéristiques
physiques des réseaux qu’il emprunte.
Historiquement les réseaux de transmission par satellite ont été dotés de leurs propres
protocoles et technologies de transmission. Toutefois, et dans la foulée du mouvement de
convergence des services, les acteurs du monde satellite ont pris conscience de l’avantage
qu’ils peuvent tirer en suivant cette tendance. En effet, le satellite est désormais vu comme
un composant à part entière de l’ensemble de la chaîne de transmission de l’information.
Même si l’ADSL est encore une technologie d’accès indétrônable à nos jours, le satellite, de
part ses qualités intrinsèques de large couverture et de facilité d’installation, occupe
pleinement sa place au sein de l’infrastructure globale des réseaux de nouvelle génération.
Forts de ce constat, les acteurs du monde satellite ont œuvrés pour favoriser
l’intégration de ce média au sein de la nouvelle chaîne de transmission. Un des principaux
efforts fournis est celui de l’adaptation des systèmes satellites au transport du protocole IP.
Des projets de recherche et développement ont étudié la faisabilité et proposé des solutions
techniques à mettre en œuvre pour le support de l’IP par satellite. Plus récemment encore,
nous avons vu arriver sur le marché de nouvelles technologies pour le transport de l’IP par
satellite. En parallèle, nous observons une croissance du nombre des réseaux IP par satellite
opérationnels.
Pourtant, le travail de l’adaptation de l’IP aux réseaux de transmission par satellite est loin
d’être achevé. Les contraintes persistent en raison des principes même de conception des
technologies satellite d’une part, et du protocole IP d’autre part. Les premières ont été
pensées pour des services de diffusion de télévision. Quant au protocole IP, il a été développé
pour des réseaux terrestres filaires, non sujet à des limitations au niveau des ressources, ni à
de longs délais de transmission et encore moins aux erreurs de transmission que subissent
les liaisons hertziennes.

1
Toutefois, et hormis quelques notes techniques d’opérateurs, nous manquons d’évaluations
en vraie grandeur des performances des technologies IP par satellite.
C’est justement le thème que nous nous proposons d’aborder dans le cadre de cette thèse.
Les observations que nous pourrons formuler dans un cadre expérimental varié seront utiles
afin de développer les techniques permettant de combler les lacunes qui persistent encore et
limitent ainsi les performances.
Cadre de l’étude et contributions
L’étude des performances des technologies de transmission de l’IP par satellite a été
menée dans le cadre d’une convention CIFRE dans les locaux d’EADS Astrium. Le travail a
porté sur un panel assez large et représentatif de technologies IP par satellite. Nous nous
sommes intéressés, tour à tour, au standard DVB-RCS, à la nouvelle norme DVB-S2 ainsi
qu’à des technologies propriétaires présentes sur le marché comme iDirect.
La volonté est de fournir des réseaux IP par satellite offrant des services voix et
données. Un travail préalable d’évaluation des performances des applications IP acheminées
sur ces technologies est donc nécessaire. Il s’agit donc de déterminer les leviers sur lesquels
un opérateur peut agir en vue d’améliorer le comportement et la prise en charge des
applications IP (voix et données).
Nos principales contributions sont les suivantes.
Tout d’abord, nous avons spécifié et mis en place une plateforme démonstrative d’IP
DVB-RCS par satellite pour des services voix et données (VoIP, accès Web, e-mail, FTP…)
intégrant des solutions d’accélération TCP et de chiffrement IPsec. Outre l’analyse des
performances applicatives, nous avons mis en évidence, la qualité de la transmission de la
VoIP ce qui rend cette technique crédible, l’importance de l’allocation des ressources et la
prioritisation des flux. Ces analyses ne sont crédibles que dans la mesure où ces
expérimentations sont effectuées en vraie grandeur et certains aspects ne peuvent être
détectés qu’avec ce type d’études.
Une autre contribution de notre travail provient de la confrontation de plusieurs
technologies. Une deuxième plateforme a été mise en place et repose sur une technologie
propriétaire iDirect. Cette technologie a été spécifiquement conçue pour le transport des
paquets IP par satellite. L’originalité de notre démarche a consisté à comparer à la fois les
performances applicatives mais encore les différents mécanismes et niveau protocolaires mis
en œuvre.
La dernière contribution porte sur le nouveau standard DVB-S2 qui bénéficie de
progrès notables au niveau de la couche physique et introduit des techniques de modulations
de codages adaptatifs. Il est également mieux adapté au transport des paquets IP. Les
expérimentations menées sur la nouvelle maquette DVB-S2/RCS, développée dans le cadre
du projet DVB-S2 Satellite Experiment, a permis d’évaluer les gains en performances
qu’apporte la nouvelle norme aux applications IP.
Plan de Lecture
Ce manuscrit est organisé en 6 chapitres, hormis l’introduction et la conclusion générale.

Le premier chapitre fournit un rappel historique de l’évolution des réseaux de
télécommunications par satellite. Il place ce dernier dans le contexte actuel des
réseaux de nouvelle génération. Ensuite, il définit les concepts généraux des systèmes
de télécommunications par satellite. Il met aussi en évidence les avantages qu’il
apporte par rapport à d’autres médias de transmission d’informations.

Le second chapitre définit le cadre de référence des systèmes satellite étudiés. Il
expose les techniques spécifiques aux satellites pour la gestion et l’allocation des

2
 ressources. Il s’attarde notamment sur les méthodes de compensation des
atténuations sur les liens avec la modification de la forme d’onde. La deuxième partie
du chapitre relève les difficultés que pose le transport de l’IP par satellite. La raison
principale est l’inadaptation de la pile de protocole TCP/IP au produit important
délai-bande passante caractéristique des réseaux satellite. Il décrit également les
techniques mises en œuvre pour surmonter ces contraintes.

Le troisième chapitre rappelle les principaux aspects du standard DVB-RCS. Il
s’attarde sur les spécificités de la couche physique des deux voies de transmissions,
les techniques qui permettent d’encapsuler et de transporter des flux IP, l’allocation
et le partage des ressources sur la voie retour.

Le quatrième chapitre décrit l’architecture et le fonctionnement d’une plateforme
démonstrative IP DVB-RCS que nous avons intégrée dans le cadre de l’étude.
L’objectif premier du chapitre est de déterminer le niveau de performances offert par
ces technologies (DVB-RCS, Accélération TCP, Chiffrement IPsec..) quand elles sont
intégrées au sein d’un système global. Nous présentons nos conclusions sur des
expérimentations de VoIP chiffrée par IPsec acheminée par satellite et nos
observations sur le comportement en termes de gestion de ressources, de coût
d’encapsulation et de qualité de service IP.

Le cinquième chapitre présente la technologie propriétaire iDirect, spécifiquement
développée pour le transport de l’IP. Nous menons une étude comparative. Nous
abordons la conception des couches physiques et MAC en comparant les techniques
d’accès au canal ainsi que le formatage des trames et son impact sur l’utilisation de la
bande. Nous évaluons les performances des deux technologies via l’observation du
comportement de la VoIP acheminée sur des réseaux implantant ces deux
technologies.

Le sixième chapitre fournit une description des avantages apportés par le standard
DVB-S2. Nous proposons des évaluations théoriques et des expérimentations menées
sur un réseau prototype DVB-S2/RCS que nous interprétons et analysons.

3
I. Les réseaux satellite dans un contexte de convergence
IP

I.1. Introduction
La convergence vers le tout IP est désormais une réalité. Ceci est perceptible, d’une part,
à travers les efforts accomplis par les fournisseurs d’infrastructures qu’elles soient fixes,
mobiles, câblées ou sans fil. Cela est également visible chez les opérateurs qui, désormais, ne
conçoivent les services qu’ils proposent que dans un contexte de tout IP. Cette affirmation
est en particulier vraie pour les réseaux de télécommunications par satellite.
Nous nous proposons dans ce chapitre de décrire le chemin suivi par les réseaux de
télécommunications géostationnaires et ayant abouti à leur intégration au sein de
l’infrastructure des réseaux Nouvelle Génération NGN (Next Generation Network). Nous
dépeindrons les étapes successives de développement des satellites de télécommunications.
En situant cette évolution dans le contexte général de l’évolution des réseaux, nous
dégagerons les principaux facteurs ayant favorisé leur adaptation à transporter de l’IP et par
là même faciliter leur intégration dans un contexte de convergence IP.
Ensuite, nous exposerons les principales caractéristiques des systèmes bidirectionnels de
télécommunications par satellite amenés à acheminer de l’IP. Cela permettra de prendre
conscience des contraintes techniques mais également des solutions mises en place pour
adapter cette catégorie de réseaux à la transmission de l’IP par satellite.

I.2. Les satellites de télécommunications et la convergence IP

I.2.1 Un peu d’histoire
Le terme satellite fut employé pour la première fois en 1945 par Arthur C. Clarke.
Dans son article publié dans le magazine « Wireless World» [1], il décrivait le satellite
géostationnaire comme un engin élevé au-dessus de la surface de la terre servant à distribuer
les signaux de télévision. Le satellite a ainsi été défini par sa fonction principale : un relais de
signaux de télécommunications.
L’idée n’a pas eu l’écho escompté à l’époque. Elle ressurgit en 1955 avec J.R. Pierce des
laboratoires AT&T qui envisagea sérieusement l’idée d’utiliser un répéteur placé à une orbite
moyenne comme miroir pour des signaux émis par des stations terrestres.
Cette idée était motivée par un constat. C’est celui des difficultés considérables pour établir
des communications à longue distance observées à l’époque. La télévision, service en plein
essor, ne pouvait toujours pas être diffusée en direct. Les câbles sous-marins, limités en
capacité, contraignaient les performances des liaisons transatlantiques. TAT-1, reliant
l’Europe aux Etats-Unis et au Canada, a été conçu pour traiter un maximum de 36
communications simultanées. Victime de son succès, il a acheminé 588 conversations le
premier jour de sa mise en service en septembre 1956.
Plusieurs pistes étaient explorées à l’époque afin de pallier ces difficultés. L’idée de placer un
répéteur dans l’espace capable de gérer 1000 communications téléphoniques simultanées,
avancée par Pierce, devenait de plus en plus séduisante. Le satellite, tel que le concevait les
pionniers de l’époque, était non seulement un support pour des communications à longue
distance mais aussi un moyen d’acheminer une plus grande quantité d’informations.
Pourtant, le premier satellite de l’histoire de l’humanité fut Sputnik-1. Equipé d’un émetteur
radio embarqué, il fut lancé par les russes en 1957 et suivi par Sputnik-2 en 1958. Pendant ce

4
temps, les Américains expérimentaient les répéteurs passifs (ECHO) et actifs capables
d’amplifier le signal et de transmettre une plus grande quantité d’informations.
Le premier satellite Américain ne fut lancé qu’en décembre 1958. Il s’appelait PROJECT
SCORE et servait à relayer l’information. A bord, un magnétoscope à cassette contenait des
messages préenregistrés. Le premier qu’on a diffusé, fut celui du président Eisenhower pour
promouvoir la paix dans le monde.
Créé par un groupe international composé d’Américains, d’Anglais et de Français,
TELESTAR 1, lancé par la NASA depuis Cap Canaveral en juillet 1962, était le premier
satellite avec un répéteur actif -capable d’amplifier le signal- à bord. Il relayait des
communications intercontinentales. Placé en orbite elliptique, il a permis, le 11 juillet, la
première transmission de télévision en direct entre les stations d'Andover aux Etats-Unis et
Pleumeur-Bodou en France
Toutefois, ce n’est qu’en 1965 que le satellite entre dans le domaine public et signe le début
de l’ère des télécommunications par satellite telle que nous la connaissons aujourd’hui. Ce fut
suite au lancement par COMSAT, une organisation gouvernementale à l’origine de la
création d’Intelsat, du satellite Early Bird construit par la compagnie Hughes. A la fin de
l’année Early Bird relayait plus de 150 communications téléphoniques simultanées et environ
80 heures de télévision.
I.2.2 Les services de télécommunications par satellite
Initialement, le satellite n’était perçu que comme un relais entre deux points
géographiquement distants. Les services de télévision et de téléphonie se réduisaient donc à
des communications point-à-point exploitant peu la large couverture du satellite.
Depuis une quarantaine d’années et en raison des progrès technologiques
considérables, (semi conducteurs, traitement du signal, puissance, lanceurs..) une mutation à
dans deux directions, a vu le jour. Les satellites « rudimentaires » du début, se sont étoffés
de composants de plus en plus sophistiqués et résistants. Ils ont ainsi vu leur taille croître.
Le poids d’INTELSAT 1 ne dépassait pas les 68 kg pour une capacité de 480 canaux
téléphoniques et une durée de vie d’environ un an et demi. Le satellite KA-SAT [2] offrira
500 Mbit/s et pèsera 5,8 tonnes pour une durée de vie estimée à 15 ans.
D’autre part, les stations terrestres très imposantes au départ se sont progressivement
munies d’antennes de plus en plus réduites. Les antennes actuelles des récepteurs TV par
satellite ne dépassent pas les 96 cm alors que 2 antennes de 30 m de diamètre étaient
nécessaires pour la première transmission de télévision en direct avec TELESTAR.
La taille décroissante des stations terrestres a parallèlement entraîné leur coût à la baisse et
permis leur vulgarisation auprès des professionnels tout d’abord et puis des particuliers.
Cette évolution a avantagé l’exploitation d’une des qualités intrinsèques des
satellites : leurs larges couvertures et par conséquent leur habilité à collecter plusieurs
signaux provenant de sources différentes et à les diffuser par la suite vers plusieurs
destinations. Ainsi, il devint possible pour le satellite de recevoir des signaux issus de
multiples stations terrestres avant de les transmettre à une seule station centrale
traditionnellement appelée Hub ou Gateway. Inversement, il fut possible d’émettre depuis
cette station centrale en direction d’un ensemble de stations terrestres situées dans la zone
de couverture du satellite.
Une des conséquences directes et des plus visibles fut le succès de la télévision. Le satellite a
permis aux chaînes de TV et d’informations de disposer d’une large audience affranchie des
frontières géographiques. Le satellite apporte la possibilité d’atteindre un large public et
fournit des services communément appelés DTH (Direct-To-Home). Pour les agences de
presse, il est notamment devenu un moyen indispensable de collecte et d’échange de

5
programmes et d’informations auprès des partenaires et des correspondants partout dans le
monde.
En parallèle, d’autres types de services se sont développés comme la téléphonie par satellite
Irridium [3], Globalstar [4] ou la diffusion de radio numérique DAB (Digital Audio
Broadcasting [5]) ainsi que des communications mobiles (voix et données) pour des
applications maritimes (INMARSAT[6]) ou militaires (SYRACUSE [7])
Notons au passage qu’un autre facteur de succès a été une libéralisation du marché
des télécommunications et un assouplissement de la législation. Ceci à conduit à la
multiplication du nombre des opérateurs et des fournisseurs de service par satellite attirés
par le fort potentiel de croissance du marché.
Les réseaux ainsi constitués de points de collecte et de transmission de données et
composé de petites stations sol ne tarderont pas à être désignés par réseau VSAT (Very Small
Aperture Terminal). Appellation commerciale à l’origine, ce terme décrit une station terrestre
conçue et commercialisée par Telecom General, une entreprise américaine. Son utilisation fut
ensuite généralisée pour désigner toute station terrestre ayant une antenne de moins de 3
mètres. On dénombrait en 2003, 700 000 stations VSAT installées [8].
Le nombre de terminaux VSAT déployés dans le monde, l’évolution des technologies
d’accès et de partage de bande passante, la révolution Internet et la mutation des
comportements observée chez les usagers, sont tous des facteurs qui ont poussé à rendre ces
terminaux interactifs. Initialement prévus pour la seule fonction de réception, doter ces
terminaux d’une voie retour leur a permis d’émettre et recevoir de l’information sous
plusieurs formes (voix, vidéo, données).
I.2.3 La fin des réseaux dédiés et l’avènement d’Internet
I.2.3.1 La fin des réseaux dédiés
Jusqu’au milieu des années quatre vingt-dix, les architectures de télécommunications
suivaient le paradigme « d’intégration verticale ». Chaque service de télécommunication
possède son propre réseau et surtout ses propres protocoles et normes tel que le GSM pour
la téléphonie mobile, le Réseau Téléphonique Commuté (RTC) pour la téléphonie fixe, les
réseaux X25 pour les données. Dans la même logique, le satellite avec son lot de
technologies spécifiques acheminait essentiellement des services de télévision.
L’introduction graduelle de nouveaux services au sein de réseaux particuliers, tel que le fax
en plus de la voix sur le réseau de téléphonie, les messages textes en parallèle aux appels
GSM ainsi que le télétexte avec la diffusion télé, a permis de prendre conscience de la
conception limitée qu’on avait des réseaux. En effet, cette vision entraîne non seulement des
situations de monopole naturel mais aussi un usage systématique de technologies
propriétaires compliqués à faire évoluer et encore plus difficiles à interconnecter. Les
difficultés liées à l’hétérogénéité de ces réseaux découlaient essentiellement de l’association
systématique qu’il y avait entre celle du service fourni et de la technologie du réseau utilisée.
Dé-corréler deux notions principales, les services -au sens contenu du terme- et réseau au
sens -média de transmission- constitue un changement radical de la conception de ces
derniers. Les acteurs du monde des télécommunications ont rapidement pris conscience
qu’on pouvait quasiment transmettre n’importe quel type d’informations (voix, vidéo,
données) sur n’importe quel support de transmission pour peu qu’on y apporte les
adaptations nécessaires.
Ainsi et localement à chaque « catégorie » de réseaux on a observé l’éclosion d’un
mouvement d’harmonisation des moyens de transmission de l’information et des interfaces

6
inter-réseaux par l’adoption de protocoles communs ce qui conduit à la fin du cloisonnement
entre fixe et mobile, terrestre et satellite.

Figure I.1 Convergence fixe-mobile, télécommunications-technologies d’informations [9]

I.2.3.2 L’avènement d’Internet

Parallèlement à ce mouvement d’harmonisation, l’avènement d’Internet est venu
conforter les acteurs dans la nouvelle conception qu’ils avaient des réseaux.
Internet plus qu’une simple infrastructure pour le transfert de l’information, est venu
confirmer la suprématie d’une conception de réseau en couches virtuellement superposées.
L’adoption d’un « modèle en couches » définie chacune autour d’un ensemble de protocoles
permet à chaque niveau de s’extraire aux difficultés soulevées et résolues par les niveaux
inférieurs. L’avantage est de limiter l’étendue du problème que chaque entité du réseau de
transport devra traiter. Plus particulièrement, on réduit l’étendue de l’impact que pouvaient
avoir sur les données véhiculées, les caractéristiques physiques du réseau de transport qu’il
soit terrestre ou satellitaire, filaire ou non.
Cette nouvelle architecture s’articule autour d’un concept central : la commutation par
paquets. Fragmenter les flux de données en plusieurs paquets contenant chacun les
informations nécessaires à leur routage confère un caractère discret au flux de données. Il
permet leur entrelacement donnant, non seulement, l’impression à chaque source
d’informations de disposer de l’ensemble des ressources, mais aussi, qu’une même ressource
peut être utilisée par plusieurs communications simultanées.
Plusieurs solutions étaient en concurrence, le protocole IP l’a emporté en raison de sa
souplesse. Une autre raison est une API (Application Programming Interface) simple
d’utilisation qui facilite le développement d’applications et de services.
De plus en plus centré autour du protocole IP, ce modèle ouvert apporte la réplique à la
croissance rapide du nombre de services hétérogènes à véhiculer sur Internet. Son efficacité
résulte du pouvoir fédérateur du protocole IP et sa capacité à traiter des flux d’informations
de nature différentes tout en permettant d’interconnecter des réseaux de nature hétérogène.
I.2.3.3 Une nouvelle infrastructure de télécommunications
Un mouvement de standardisation a graduellement pris sa place autour d’IP. Il a
conduit à l’émergence de nouveaux protocoles des couches supérieures standardisant le
transport en mode connecté ou non connecté selon les besoins applicatifs permettant le
transfert de fichiers, de courrier électronique, de la voix ou de la vidéo.
Différents organismes de standardisation et de normalisation comme l’ETSI [10], IETF
[11] en Europe ou la TIA [12] aux Etats Unis ont entamé un effort d’adaptation des
couches dites basses, au transport de l’IP. L’objectif était clairement de pouvoir véhiculer de
l’IP sur des réseaux de natures physiques différentes (fixe, mobile, câblés, sans fils...).

7
 Ce mouvement d’harmonisation des protocoles de communications autour d’un
format « universel » de paquets d’information débuté au milieu des années quatre-vingt-dix,
a conduit à ce qu’on appelle aujourd’hui les réseaux de nouvelle génération ou NGN (Next
Generation Neworks). Bien que dépourvus d’une définition unique, les NGN sont surtout
l’illustration de la normalisation des interfaces et des protocoles de communication entre
réseaux de natures physiques différentes. C’est aussi leur aptitude à véhiculer des services
hétérogènes (voix, vidéo, data) en mode paquet. Une des conséquences les plus perceptibles,
est la multiplication des offres de triple et même quadruple play proposées par les fournisseurs
d’accès à Internet (Accès à Internet, Télévision, téléphonie fixe et même téléphonie mobile).
La figure 1.2 est une illustration de ce mouvement de convergence centré autour de l’IP.

Figure I.2 Convergence des réseaux et des services vers le tout IP

Pour les réseaux NGN, on retiendra la définition de l’ITU [13]

A Next Generation Network (NGN) is a packet-based network able to provide services including
Telecommunication Services and able to make use of multiple broadband, QoS-enabled transport
technologies and in which service-related functions are independent from underlying transport-related
technologies. It offers unrestricted access by users to different service providers. It supports generalized
mobility which will allow consistent and ubiquitous provision of services to users.
Ce qui se dégage essentiellement de cette définition est un ensemble de caractéristiques
communes :
– Un réseau de commutation par paquets orienté vers le « tout IP » ;
– Le découplage des fonctions service et réseau de transport ;
– La garantie d’une qualité de service QoS des services fournis ;
– L’ubiquité et l’accessibilité de ces réseaux ;
La figure 1.3 décrit la segmentation établie entre les différents acteurs des réseaux NGN. La
distinction entre le service et les réseaux y est clairement montrée. Il est à noter la
séparation entre les réseaux de transit et d’accès. C’est aussi une preuve de l’importance que
revêtent les technologies qui leur sont associées notamment l’ADSL ainsi que l’ensemble des
technologies « radio » telles que le WiFi, Wimax et le satellite que nous étudierons
précisément dans le cadre de cette thèse.

8
 Figure I.3 Segmentation des acteurs dans le modèle NGN

I.2.4 Le satellite comme composant de l’infrastructure NGN

I.2.4.1 Introduction
A ce jour, L’ADSL reste incontestablement la technologie dominante pour l’accès à
Internet particulièrement pour des utilisateurs résidentiels ou des PME. Cependant, le
satellite occupe largement sa place dans l’échiquier des technologies d’accès. Grâce à ses
avantages intrinsèques, il comble les lacunes observées au niveau de l’ADSL ou des
technologies radio comme le Wifi ou le Wimax.
Les offres d’accès à Internet par satellite qui se multiplient tous les jours et pour des
prix équivalents à ceux de l’ADSL pour des débits semblables en sont une preuve [14]. Le
succès des réseaux Internet par satellite tels que Twister [15] solution par excellence à la
fracture numérique ou l’adoption du satellite par des entreprises pétrolières comme le moyen
privilégié de connexion à Internet ou à leur site central en métropole pour leurs plateformes
en haute mer ou dans le désert en sont d’autres.
L’usage croissant du satellite comme un relais de toutes les formes d’informations non
restreintes à la diffusion vidéo est également perceptible chez les opérateurs. Le diagramme
figure 1.4 montre l’occupation d’un transpondeur de l’opérateur Eutelsat à des périodes
différentes de la journée. On y observe une répartition de charge entre données, audio et
vidéo.
Transponder Capacity
38
data
34 data 10 MBit/s
22 MBit/s 30% data
24 65% 30 MBit/s
90%
16 video/audio
Video/audi 24 MBit/s
8 70% video/audi
o12 MBit/s 4 MBit/s
0 35%v 10
8am 6pm 1am 8am
Time Period

Figure I.4 Evolution de la charge (Voix, vidéo, data) d’un satellite Eutelsat [16]

I.2.4.2 Avantages et utilisations des systèmes satellites

Le recours croissant au satellite pour acheminer des données, de la voix ou pour fournir
l’accès à Internet en plus de son usage « traditionnel » comme un moyen de diffusion de la
télévision est conforté par les avantages multiples qu’il procure.

9
Pour ce type d’utilisation, les réseaux sont majoritairement bâtis autour de satellites
géostationnaires. Ces derniers présentent les avantages suivants :

Une infrastructure terrestre réduite;

Une large couverture ;

Un déploiement rapide des terminaux.
Alors que le déploiement des réseaux terrestres ne peut être que progressif et doit garder
une continuité physique, les réseaux satellites de part leur mode de transmission hertzien, ne
requièrent pas la création d’infrastructures sur le domaine public. C’est aussi la raison pour
laquelle ils s’affranchissent des frontières géographiques. Le caractère continental et parfois
mondial des principaux opérateurs suffit pour s’en convaincre.
Les grandes zones de couverture des satellites, pouvant atteindre des continents entiers,
combinées à une rapidité de déploiement en fait un moyen central pour la lutte contre la
fracture numérique. Le projet DDSO (Digital Divide, the Satellite Offer) parrainé par la
commission Européenne et piloté par Astrium [17] dédié à l’accès Internet pour zones
rurales de plusieurs pays Européens confirme la position privilégiée du satellite dans ce
domaine.
Les réseaux satellite offrent également un moyen d’interconnexion et de relais entre des
réseaux terrestres (Internet) et des stations embarquées dans des bateaux, ou des voitures.
Ils s’avèrent particulièrement utiles pour la collecte instantanée des programmes de
télévision enregistrés sur le terrain, pour la téléphonie mobile récemment proposée en
service commercial à bord des avions.
Un autre atout du satellite est l’impact réduit que peuvent avoir les catastrophes naturelles
(incendies, inondation, tremblement de terre) sur ses infrastructures. Ils peuvent en revanche
causer des dégâts irréversibles aux réseaux terrestres. La facilité de déploiement et de
maintien des réseaux satellites en font le meilleur et parfois l’unique moyen de
communication en cas de sinistres, facilitant ainsi l’intervention des pompiers en cas
d’inondation ou de tornades et celui des soldats en cas de conflits ou de guerres. Nombre
de services, autres que la télévision, exploitent à l’heure actuelle la capacité naturelle de
diffusion des satellites. Ce sont des moyens incontournables pour la diffusion de radio, de
données telles que la météo ou les dépêches d’informations.
Une autre utilisation non moins importante mais moins connue du satellite est le
« backhauling » consistant à transporter le trafic entre sites distribués ou entre deux réseaux
de cœur aussi bien pour de l’Internet que pour la téléphonie. C’est notamment le cas à l’île de
Madagascar où France Telecom connecte l’ensemble de l’île au réseau Internet mondial via
un lien satellite de 2 Mbit/s.

I.3. Systèmes satellites bidirectionnels

Les avantages de l’utilisation des satellites que nous venons d’évoquer sont globalement
communs à tous les systèmes. Toutefois, et selon les applications et les services proposés
(téléphonie, transfert de données, télévision, renseignement militaire…) l’architecture du
réseau et les caractéristiques des satellites mis en œuvre peuvent varier. Dans cette section,
nous décrivons les caractéristiques principales des réseaux satellites destinées aux
transmissions bidirectionnelles de flux IP.

10
I.3.1 Architecture générale
Un réseau satellite fournissant des services interactifs à haut débits, se compose de trois
segments distincts (cf. figure 1.5)
- Le segment spatial qui consiste en un ou plusieurs satellites géostationnaires (GEO)
assurant le relais, l’amplification et la transposition du signal transmis et selon les
cas, du traitement à bord.
- Le segment utilisateur ou site distant ou terminal - l’appellation diffère selon
l’usage- Ce sont les points d’accès au réseau global pour les utilisateurs finaux. Ces
terminaux reçoivent les services multimédia auxquels ils sont abonnés, et
transmettent du trafic ou des requêtes de bande passante via une voix retour qui peut
être terrestre ou par satellite.
- Le segment opérateur, il est constitué d’une ou plusieurs Gateway ou passerelles
pour former le NCC (Network Contrôle Center). Elle comporte généralement
l’ensemble des connexions au réseau extérieur (Internet, téléphonie...)

Gateway / hub
Internet

TV

RTC
GSM

Segment Opérateur (NCC) Segment Spatial Segment Utilisateur

Figure I.5 Architecture générale d’un réseau en étoile

I.3.2 Topologies
Deux principales topologies existantes. Le recours à l’une ou l’autre dépend de la taille
du réseau (nombre de terminaux), des services proposés mais aussi des fonctionnalités
embarquées ou non à bord du satellite
I.3.2.1 Réseau en étoile
Dans cette configuration la Gateway forme le lien entre les utilisateurs finaux situés
au niveau des terminaux et les fournisseurs de services. Elle centralise l’ensemble des
connexions vers le réseau Internet, le réseau de téléphonie mobile ou fixe. La passerelle
assure notamment des fonctions de contrôle d’accès des terminaux, de synchronisation
temporelle et d’allocation de ressources.

Figure I.6 Topologie en étoile

11
 La plupart des satellites de télécommunication géostationnaires, en orbite
actuellement, sont transparents puisque leur rôle consiste à amplifier le signal et transposer
sa fréquence sans aucun traitement à bord. La majorité des réseaux en opération repose sur
une topologie en étoile où tout le traitement « intelligent » (modulation, codage..) se fait au
sol. Un des inconvénients de cette architecture est justement l’importance critique que revêt
la passerelle ou le (NCC). En effet, une panne à ce niveau peut entraîner un
dysfonctionnement global du réseau. Une autre faiblesse est que dans le cas d’une
communication inter-terminaux tels que la voix sur IP, l’impact du délai sur la qualité est
doublement ressenti en raison du double bond (sol-satellite) effectué par le signal.
I.3.2.2 Réseau maillé
Dans un réseau maillé ou Mesh, des communications « directes » entre terminaux
sont possibles. Le temps de transmission est ainsi diminué de moitié. Dans le genre de
réseau, le rôle de la passerelle ou du NCC, appelé parfois modérateur se restreint à la
synchronisation temporelle et l’allocation de bande passante aux terminaux. Les connexions
avec les réseaux extérieurs tels qu’Internet ou téléphonie peuvent être réparties sur plus
d’un terminal.

Figure I.7 Topologie maillée

Cette répartition des fonctionnalités critiques sur plusieurs terminaux qui peuvent dans
l’absolu avoir tous le rôle de Gateway réduit considérablement la vulnérabilité du système.
Toutefois, les réseaux Mesh requièrent des satellites performants disposant de
fonctionnalités avancées telles que le routage et la commutation à bord.
En dépit des avantages qu’il apporte, ce genre de réseau n’est pas encore très répandu. Les
satellites avec traitement à bord sur lesquels il repose ne sont toujours pas assez développés
pour raisons techniques mais surtout pour des raisons de coûts. D’autre part, les terminaux
Mesh incluant des fonctions avancées et donc onéreuses résistent peu au passage à l’échelle.
Il est toutefois possible de combiner ces deux topologies pour aboutir à des configurations
mixtes de réseaux satellites. Le groupe de travail BSM (Broadband Satellite Multimedia) de
l’ETSI distingue ainsi plusieurs familles de systèmes satellite combinant une topologie
maillée et étoilée définis dans [18] ainsi que plusieurs types de satellite avec ou sans
intelligence embarquée.
I.3.3 La couverture du satellite
La majorité des satellites de télécommunications actuellement en orbite assure une
couverture mono faisceau. Conçus pour la diffusion de programmes TV, l’objectif était de
s’étendre sur la zone la plus large possible puisque le même message est envoyé à tout le
monde. Toutefois, le gain était limité par l’angle d’ouverture de l’antenne en plus d’une
mauvaise utilisation du spectre de fréquences allouées. Ceci constitue une contrainte à
l’augmentation du débit nécessaire à la transmission de services interactifs (Internet, VoIP,

12
VoD…). Une couverture mono faisceau avec une petite ouverture d’antenne et donc
concentrée sur une zone moins étendue apporte certes un meilleur gain mais ne permet pas
de couvrir une multitude de terminaux géographiquement distants.
Les techniques multi faisceaux concilient ces deux solutions. La couverture du satellite est
étendue par la juxtaposition de plusieurs faisceaux ou spots. Chaque faisceau offre ainsi un
gain d’autant plus élevé que l’ouverture d’antenne est réduite. Ainsi, pour une taille
d’antenne équivalente le terminal bénéficie d’un débit supérieur. D’autre part, avec un signal
de meilleur gain, le recours aux bandes de fréquences élevées comme la bande Ka se trouve
désormais simplifié. Cette technique permet notamment une multiplication virtuelle du
nombre de fréquences en réutilisant la même fréquence sur des spots non adjacents pour un
usage optimisé du spectre.

Monofaisceau Monofaisceau Multifaisceaux

large étroit

Couvertures satellite

Figure I.8 Couverture mono faisceau et multifaisceaux

Néanmoins, un système multi faisceau pose des défis technologiques complexes

résidants essentiellement dans les interférences qu’il pourrait engendrer entre différents
spots en plus de la difficulté de la mise en place d’un système de saut de transpondeur
(transponder hoppping) afin de permettre à une Gateway située dans un spot x d’émettre du
trafic dans un spot y. Cette complexité a longtemps contraint le développement et la diffusion
de cette technique qui existe pourtant depuis longtemps (Astra 1H est composé de 32
transpondeurs en bande Ka [19]). Elle arrive à présent à maturité et tend à être implantée
sur un grand nombre de satellites de télécommunications en cours de fabrication. Le satellite
KA-SAT dont le lancement est prévu 2010 par Eutelsat, totalisera 82 faisceaux différents en
bande Ka dont chacun couvrira une zone de 250 km de diamètre (4 suffiront pour couvrir la
France) [2]
I.3.4 Le traitement à bord
Le rôle des satellites transparents consiste à transposer la fréquence du signal reçu et
amplifier sa puissance avant de le retransmettre. L’amplification du signal à bord du satellite
permet le recours à des antennes de taille réduite en réception. En revanche, la transposition
des fréquences minimise les risques d’interférences entre signaux montants et descendants
Une autre catégorie plus sophistiquée des satellites, dits régénératifs, consiste à embarquer
des fonctionnalités avancées à bord (On Board Processing). Leur apport réside dans leur
faculté de démoduler les signaux en bande de base, régénérer le signal, router ou commuter
les paquets, les multiplexer avant de les retransmettre [20].
Le traitement embarqué permet de découpler le bruit introduit sur la voie montante et
descendante ce qui réduit par ailleurs la taille des antennes des stations sols. Ce genre de
satellites est particulièrement utile pour les réseaux maillés. On tend de plus en plus, du
moins dans des projets expérimentaux, à embarquer de l’intelligence à bord du satellite. Le

13
réseau expérimental Arethuse [21] disposait d’un processeur embarqué comprenant un
démodulateur et décodeur multi-porteuses, du routage en Mesh et Star en plus de
l’encapsulation ATM vers MPEG. Nous verrons d’une manière plus détaillée ces schémas
d’encapsulation dans les chapitres qui suivent.
Les constellations de satellites opérant en orbite MEO ou LEO telles qu’Iridium, GPS,
intègrent également de l’intelligence embarquée plus ou moins avancée en fonction du
système. Toutefois, on observe que sur les 260 satellites -géostationnaires- de
télécommunications civiles en 2008, excepté les satellites INMARSAT et Thuraya en plus
de quelques charges utiles expérimentales, seulement 2% des satellites intègrent du
traitement à bord [20]. Au moins à court terme, cette situation n’est pas amenée à changer.
L’évolution permanente des techniques de codage et de modulation d’un côté et des
technologies des microprocesseurs d’un autre pendant la durée de vie d’un satellite
géostationnaire (entre 15 et 18 ans) remettent constamment en cause les systèmes de
traitement à bord des satellites en orbite, en les rendant rapidement obsolètes. Les satellites
régénératifs restent coûteux en raison de la complexité des systèmes (processeurs,
redondances..) qu’ils embarquent d’autant plus qu’il serait difficile de mettre à jour un
satellite géostationnaire à 36000 km de la terre.
I.3.5 Bande de fréquences et bande Ka
Les signaux de télécommunications par satellite se transmettent via les ondes
radioélectriques ou hertziennes ayant une fréquence entre 9kHz et 3000 GHz et ne
nécessitant pas de guides artificiels. Régulé par l’Union Internationale des
Télécommunications, le spectre radio est divisé en neuf bandes de fréquence. La figure 1.9
résume les principales bandes de fréquences. Les désignations ainsi que la segmentation des
bandes de fréquences peuvent varier d’un organisme à un autre

Figure I.9 Les différentes bandes de fréquences satellite

Comme la qualité du signal se dégrade à mesure que la fréquence augmente, les

bandes basses comme les bandes L ou S sont particulièrement convoitées et précieuses. Elles
sont également utilisées aussi bien pour les réseaux terrestres que pour les réseaux satellite.
La bande L sert principalement aux services mobiles par satellite MSS (Mobile Satellite
Services).
Bien que légèrement sensible aux perturbations introduites par les conditions de
propagations, la bande C est l’une des premières à avoir été utilisée pour les applications
commerciales par satellite et les services fixes FSS (Fixed Satellite Services), en raison de la
bande passante plus large qu’elle offre.

14
 La croissance du nombre de technologie sans fil (GSM, Wifi, Wimax, UMTS…) et
satellite exploitant ces bandes basses a entrainé la saturation du spectre autour de ces
fréquences y compris la bande Ku. L’avènement de normes et de technologies certes plus
performantes comme le MPEG4 pour la HDTV toujours plus gourmandes en bande
passante, a exacerbé cette tendance. La réaction de la communauté satellite fut donc de
mettre en œuvre des systèmes capables d’utiliser la bande Ka (18-40 GHz)1. Par ailleurs et
alors même que la mise en place des systèmes en bande Ka n’est qu’à son début, on réfléchit
déjà à recourir aux bandes à plus courtes longueurs d’ondes comme la bande Q/V (37 et 50
GHz).
En dépit d’une forte sensibilité aux conditions atmosphériques, la bande Ka présente des
avantages multiples. Elle dispense les opérateurs satellites des autorisations d’émettre et de
recevoir comme tel est le cas s’il y a des opérateurs terrestres sur là même bande. L’ITU a
alloué les fréquences 17,2-21,2 et 27,5-31 GHz pour les services fixes par satellites (FSS)
[22]. Cette allocation a aussi l’avantage d’une bande passante de 2,5 GHz largement
supérieure à celle offerte par les bandes inférieures et adaptée aux flux multimédia sensés
être transmis. De plus, certaines sous-bandes comme 18,4-18,6 GHz et la 18,8-19,7 GHz ne
nécessitent pas de coordination inter-réseaux avec les satellites d’observation de la terre ni
avec les satellites mobiles (non GEO) et sont donc particulièrement intéressantes pour les
services de télécommunications [22]. En plus et comme le diamètre des antennes est
inversement proportionnel à la fréquence, la bande Ka est adaptée aux terminaux VSAT avec
des petites antennes de quelques dizaines de centimètres de diamètres.
Cependant et comme toutes les bandes à fréquences élevées, la bande Ka subit de fortes
dégradations dues à la pluie, aux nuages et aux gaz atmosphériques. Des études de
caractérisation des niveaux d’atténuation pour les hautes bandes de fréquences ont fait
apparaître de grandes dégradations de la qualité des signaux radios, jusqu’à 40 dB
d’atténuation à 40 GHz [23].

Figure I.10 Atténuations dues à la pluie (A), au brouillard (B) ,aux gaz atmosphériques (C) [23]

En conséquence la qualité de service à fournir se trouve fortement détériorée. La mise

en place de procédés techniques qui compensent ces atténuations et recouvrent les pertes en
puissances subies par le signal sont donc nécessaires. Certaines de ces techniques sont
largement abordées au cours des chapitres qui suivent.

1 La bande Ka (18 - 40 GHz) dont il est question regroupe la bande K (18-27 GHz) de SHF et la bande Ka (27-

40 GHz) d’EHF.

15
I.4. Conclusion
Dans ce chapitre, nous avons retracé les principales étapes de l’évolution des systèmes
de télécommunications par satellite. Nous avons notamment tenté de relever les principaux
facteurs qu’ils soient techniques ou non ayant permis au satellite de prendre sa place en tant
que technologie d’accès au sein d’une infrastructure NGN centrée autour de l’IP.
De plus, nous avons présenté les caractéristiques essentielles des réseaux satellite
amenés à acheminer des flux IP bidirectionnels. Dans le chapitre qui suit, nous étudions
spécialement les contraintes à la transmission du trafic IP par satellite. Nous nous
intéressons également à l’ensemble des solutions qui ont été trouvées pour le faire.

16
II. Le satellite comme support de l’IP, difficulté de la mise
en œuvre

II.1. Introduction
Les réseaux satellites appartiennent aujourd’hui aux technologies d’accès au même
titre que l’ADSL, l’UMTS ou le Wimax. La baisse du coût des terminaux, les efforts
soutenus en matière de standardisation et d’interopérabilité, l’évolution des techniques de
codage et de compression, tout semble converger pour doter le satellite des moyens
nécessaires à son intégration au sein de l’infrastructure NGN.
Cependant, et d’un point de vue protocolaire ce travail est encore loin d’être achevé.
Nous proposons à travers ce chapitre présenter les principales spécificités des réseaux
satellite considérés. Nous exposerons par la suite les contraintes que pose une adaptation
efficace des protocoles IP à des systèmes de télécommunications par satellite
géostationnaires. Plusieurs solutions ont été proposées afin de pallier ces difficultés. Nous en
présenterons un panorama tout en mettant l’accent sur celles qui ont abouti à des
implantations industrielles et dont les performances peuvent être évaluées par un moyen
autre que la simulation logicielle.

II.2. Cadre de référence des systèmes satellites étudiés

II.2.1 Préambule
A l’instar des autres technologies d’accès, les efforts entamés pour adapter des
protocoles du monde IP dédiés à la signalisation, à la gestion et au contrôle, par ailleurs
largement éprouvés sur les réseaux terrestres, demeurent encore inachevés dans un contexte
satellite. Les satellites GEO souffrent d’un large produit délai-bande particulièrement
dommageable à l’efficacité d’un protocole comme TCP ; ce qui requiert la mise en place de
moyens permettant d’en améliorer les performances sur satellite à l’exemple des PEP (Proxy
Enhancing Protocol) [30]
D’un autre côté, les politiques de qualité de service IP comme le contrôle d’admission ou
l’agrégation de flux nécessitent une interaction avec les mécanismes de niveau 2 afin de
compenser une bande passante faible également caractéristique des réseaux satellite et
parfaire une gestion de ressources trop grossière au niveau IP. L’ensemble des techniques de
compression des en-têtes et des contenus de paquets apporte une contribution qui permet
une économie de bande passante et minimise le surcoût provoqué par les encapsulations
successives des paquets IP.
II.2.2 Le modèle architectural BSM fondé sur IP
A partir de ces constatations le groupe BSM (Broadband Satellite Multimedia) de
l’ETSI [3] a décidé de définir un cadre architectural propice à l’intégration de ces protocoles
et les adapter aux spécificités des réseaux BSM. Ce modèle architectural se veut générique et
non spécifique à un système satellite particulier.
Ce cadre de référence n’exclut pas le recours à une architecture maillée avec un satellite
régénératif [3,4]. Néanmoins, la plupart des réseaux IP par satellites en fonctionnement
adoptent une topologie en étoile qui n’est sans doute pas sans relation avec le grand nombre
de satellites transparents en orbite.

Par conséquent, on propose dans le contexte de ce travail de thèse de se restreindre aux

réseaux satellite ayant les caractéristiques suivantes :

17
 - Une topologie en étoile.
- Un satellite géostationnaire transparent donc un long délai de propagation terre-
satellite de l’ordre de 250 ms.
L’architecture proposée dans la figure 2.1 a été définie dans le rapport TR 102 157 [3].
Elle définit ainsi une interface SI-SAP (Satellite Independent Service Access Point) entre les
fonctionnalités indépendantes du système satellite sous-jacent et les fonctionnalités
spécifiques au système satellite utilisé. Deux fonctions d’adaptation s’ajoutent. La première
SIAF (Satellite Independent Adaptation Function) se situe en bas de la couche 3 pour adapter les
protocoles de niveau 3 aux « services support BSM » et inversement. La seconde SDAF
(Satellite Dependent Adaptation Function) opère en haut de la couche 2 pour adapter les «
services support BSM » aux services offerts par l’interface air native. Ces « services support
BSM » s’appuient sur des mécanismes de niveau 2 du système satellite sous-jacent. Ils
offrent notamment des services orientés connexion ou non, uni- ou bidirectionnels et
symétriques ou asymétriques (en bande passante, en QoS…) et des connexions unicast ou
multicast. Les couches SLC et SMAC peuvent être apparentées au niveau de la couche 2 du
modèle OSI et la couche SPHY au niveau 1.

OSI Couche 4 et 7
Couche Application et Transport

OSI Couche 3
Couche Réseau

OSI Couche 2
Mécanismes MAC et Gestion des ressources
radio RRM

Couche Physique

Figure II.1 Réseau d’accès BSM (Broadband Satellite Multimedia) [3]

Les niveaux 1 et 2 du modèle BSM regroupent l’ensemble des mécanismes spécifiques

au satellite. Ils permettent la transmission du signal à travers un milieu bruité et organisent
les accès à la bande passante entre les différents terminaux géographiquement dispersés.

II.3. Gestion et accès aux ressources aux niveaux des couches basses
II.3.1 Introduction
En comparaison à ce qui est offert par l’ADSL ou par la fibre, la ressource radio reste un
paramètre non seulement limitant mais aussi coûteux pour les systèmes satellite. De
surcroît, la transmission par satellite est caractérisée par une forte atténuation de l’espace et
par une puissance plafonnée au niveau du transpondeur. S’ajoute aussi l’obligation de
partager les ressources entre l’ensemble des utilisateurs du réseau. Toutes ces raisons
justifient le besoin de recourir à des stratégies d’allocation, de partage et de gestion des
ressources radio en vue de garantir une efficacité du système et assurer sa rentabilité
économique.
Cette problématique s’étend à l’ensemble des niveaux protocolaires. Elle va de la qualité
de service IP au contrôle de puissance du canal radio [5] Ceci étant et indépendamment des
protocoles et des technologies sous-jacentes spécifiques à chaque système de transmissions

18
bidirectionnelles par satellite, les mécanismes opérant au niveau 2 et 1, SLC, SMAC et
SPHY au sens BSM, pour la gestion et l’allocation de la bande passante sont généralement
similaires.
Nous exposons dans ce qui suit les principales techniques de gestion et d’allocation de
bandes. Nous nous penchons notamment sur certains procédés mis en œuvre pour
compenser les atténuations atteignant les liaisons satellite.
II.3.2 Accès aux ressources
La politique d’accès est le moyen qui organise le partage des ressources entre les
différents utilisateurs du système. Elle leur permet d’émettre simultanément leur trafic (voix,
vidéo, données) [5].
Il est toutefois nécessaire de distinguer le sens du trafic (montant ou descendant) dans le cas
d’une topologie en étoile. En effet, les flux allant de la Gateway vers les terminaux partent
de la même source vers des destinations multiples alors que dans le sens contraire ils sont
issus de sources multiples mais vers une même destination (la Gateway).
II.3.2.1 Lien descendant
Dans ce sens du trafic, le flux suit un comportement typique d’un réseau de diffusion
par satellite. La Gateway dispose d’une porteuse unique avec une large bande passante
pouvant atteindre des dizaines de mégabits par seconde. Les différents types de flux (voix,
vidéo, data), échantillonnés en plusieurs slots, suivent un multiplexage temporel pour former
une porteuse TDM (Time Division Multiplex) qui s’étale sur toute la bande disponible.
Dans la zone de couverture du satellite, tous les terminaux reçoivent la même porteuse.
Toutefois, ils n’extraient que les trames qui leur sont destinées2.
Dans le cas où le satellite ne permet pas de couvrir toute la zone où sont situés les
terminaux, plusieurs TDM, éventuellement émises par plusieurs satellites, peuvent être
générées. Elles peuvent notamment opérer dans des bandes de fréquences différentes (C et
Ku par ex.) si les conditions climatiques sont différentes d’une zone couverte.
Par ailleurs, et en raison de l’usage croissant des techniques multifaisceaux, le lien
descendant peut comporter plusieurs porteuses TDM avec des bandes passantes plus
réduites couvrant chacune un nombre moins important de terminaux.
II.3.2.2 Lien montant (Necessity dictates sharing)
Sur le lien montant, toutes les stations, dispersées géographiquement, émettent
simultanément leur flux respectifs en utilisant le même canal radio. Devant ces accès
multiples et en l’absence d’une politique qui organise les accès, les collisions entre différents
trames émises peuvent sensiblement dégrader les performances du réseau d’autant plus que
les délais de propagation sont élevés.
Les principales politiques d’accès sont CDMA, FDMA et TDMA mais aussi plusieurs
combinaisons les associant.
Avec le CDMA (Code Division Multiple Access) les stations transmettent en permanence en
utilisant la même fréquence. Le problème d’interférence est résolu à la réception par
l’identification de la « signature » ou du code associé à chaque émetteur. Ces codes sont en
général orthogonaux afin de faciliter la discrimination entre les différents signaux.
Couramment utilisée par les militaires pour les propriétés de discrétion qu’elle apporte en
étalant le spectre, cette technique est moins présente dans les systèmes satellites

2 La résolution des adresses sur le lien descendant sera détaillée dans les chapitres suivants.

19
commerciaux actuels mis à part quelques applications spécifiques [6]. Son inconvénient
majeur consiste en un débit faible : le spectre des fréquences porteuses est occupé par un
débit qui reste faible pour une porteuse donnée [2].
Fréquemment utilisée pour les applications analogiques telles que la téléphonie ou la radio,
la FDMA (Frequency Division Multiple Access) consiste en un partage du spectre des
fréquences porteuses entre les différents utilisateurs. Le spectre est divisé en sous-bandes
avec une fréquence porteuse pour chacune. Ainsi, les stations émettent en permanence et le
canal achemine plusieurs porteuses simultanément. Des intervalles de garde entre les
différentes porteuses sont nécessaires pour éviter les interférences et pallier les imperfections
des filtres et des oscilloscopes.
En TDMA (Time Division Multiple Access), le canal est fragmenté en plusieurs tranches
horaires couramment appelées Time Slot. L’émetteur dispose de la totalité du canal sur des
courts instants. Ainsi un multiplexage temporel est effectué entre times slots en provenance
de différents émetteurs et les stations transmettent leur flux d’une manière séquentielle. En
raison de la dispersion géographique dans la zone de couverture du satellite, les délais de
transmission en direction de la Gateway varient d’un terminal à un autre. Les stations ne
découvrent le chevauchement des signaux qu’avec une latence significative due au délai
terre-satellite de d‘environ 250 ms. C’est une perte non négligeable de quelques mégabits par
seconde sur le canal. Afin de compenser les variations de transmission entre terminaux, une
tranche de temps sans émission de trafic est insérée entre les times slots consécutifs et
appelée temps de garde (Guard Time). Pour une variation de délai entre 250 et 290 ms, la
différence de temps est d’un total de 80 ms pour le délai global (Round Trip Time). Un temps
de garde de 80 ms entre deux slots consécutifs est une perte significative de bande passante
[6]. La mise en place d’une procédure de synchronisation entre stations émettrices permet
d’éviter les collisions des times slots et minimiser les temps de garde. Ceci constitue la
principale difficulté de la mise en place d’un accès de type TDMA. La synchronisation
repose sur l’existence d’une référence de temps dont la précision peut atteindre l’ordre de
quelques nanosecondes (Plusieurs implantations reposent sur une référence GPS). Cette
référence est diffusée périodiquement de la Gateway à l’ensemble des terminaux.
Connaissant leur position, celle du satellite, les terminaux évaluent leur propre délai de
transmission, le temps transmission satellite-Gateway étant invariable pour le terminal et
connu de ce dernier.
D’autres politiques hybrides associant ces trois techniques de bases (FDMA, TDMA,
CDMA) sont notamment utilisées. La méthode la plus couramment utilisée et largement
éprouvée dans les réseaux satellite combine FDMA et TDMA pour un multiplexage
simultané en temps et en fréquence appelé MF-TDMA (Multi Frequency Time Division
Multiple Access). Cette méthode hybride (cf. figure 2.2) allie à la fois les avantages des deux
méthodes d’accès et maximise le nombre d’usagers pouvant accéder au réseau satellite.
Toutefois, un de ses principaux critères de performance réside dans l’aptitude des terminaux
aux sauts de fréquences (Frequency Hopping), et donc de basculer d’une porteuse à une autre
entre slots adjacents ou proches. Les temps de garde entre les times slots en plus des
intervalles entre fréquences adjacentes représentent aussi des critères d’évaluation de
l’efficacité de l’usage de la bande passante.

20
 Figure II.2 MF-TDMA, Multiplexage en temps et en fréquence

II.3.3 Allocation de ressources

Préalablement à l’accès au canal radio, l’utilisation de la bande, essentiellement sur le
lien retour où la ressource est limitée, doit être régie par une autorité de contrôle qui veille à
ce que l’allocation de la bande soit optimale et équitable entre les émetteurs. Par conséquent
une fonction « administrative » est mise en œuvre pour répartir les ressources entre les
différents terminaux. Ce partage dépend de plusieurs facteurs tels que le niveau de service
établi avec chaque terminal (SLA), la disponibilité de la bande passante, les attributs de
qualité de service spécifiée par les couches supérieures, la nature des applications transmises,
la faisabilité, la rentabilité…
Les deux méthodes les plus courantes se fondent sur deux principes différents : allocation
statique et allocation dynamique de ressources [2].
II.3.3.1 Allocation statique
Basée sur un niveau de service préétabli (SLA), la ressource est attribuée sous forme
d’un débit ou d’un volume fixe dédié à chaque terminal et immédiatement disponible dès sa
connexion au réseau. Cette allocation est indépendante des besoins instantanés de la station
ainsi que de leur variation dans le temps. Cependant, elle garantit une disponibilité des
ressources pour des applications à forte contraintes temporelles telles que la VoIP ou la
télévision [5], en plus de la connaissance exacte dans le temps des ressources dont dispose le
terminal.
Toutefois, elle peut s’avérer contraignante si la bande requise au terminal est supérieure à
celle qui lui est allouée ou dans le cas où elle est sous-utilisée par les autres terminaux. En
plus, elle ne prend pas en compte l’évolution des besoins en bande passante dans le temps qui
peuvent excéder la quantité disponible. Aussi, demeure-t-elle peu efficace pour un passage à
l’échelle puisqu’elle constitue un gaspillage de bande passante précieuse quand le nombre de
terminaux croît.
II.3.3.2 Allocation dynamique
L’allocation de ressources varie dans le temps en fonction de l’évolution des besoins
immédiats de chaque station désirant émettre ainsi que de l’ensemble des ressources
disponibles.
Dans les systèmes satellite reposant sur un schéma d’accès MF-TDMA, le DAMA
(Dynamic Assignment Multiple Access), protocole de niveau MAC, est le plus répandu pour des
allocations dynamiques. Le DAMA attribue les ressources aux terminaux sur la base de
requêtes explicites adressées par ces derniers. Cette fonction désignée notamment par RRM

21
(Radio Ressource Allocator) qui peut également comprendre la fonction CAC (Call Admission
Control)3 relève du rôle de la Gateway. Elle est responsable de la réception des demandes en
bandes passantes émises par les terminaux. Elle établit l’allocation en fonction de la charge
totale du réseau et la nature des flux à écouler (débit constant, bursty). Ensuite, elle organise
l’accès aux porteuses retour en attribuant individuellement aux terminaux les times slots à
utiliser pour émettre. Cette stratégie requiert l’existence d’une entité, désignée par RRR
(Radio Resource Request), au niveau du terminal responsable de l’évaluation du volume du
trafic à émettre avant de soumettre les requêtes. La littérature abonde de descriptions
d’algorithmes DAMA [2,5,7,8,55]. Même s’il est un élément déterminant de l’efficacité d’un
système satellite aussi bien d’un point de vue des performances que de l’utilisation de la
bande passante, la liberté de son implantation est laissée aux concepteurs.

Il est communément admis que la première stratégie est recommandée pour les
réseaux devant acheminer des volumes importants de trafic entre stations traitant des débits
élevés tandis que la deuxième est adaptée pour un réseau avec un grand nombre de petites
stations disposant de ressources limitées [2]. Cette affirmation reste tout de même relative
au système considéré.
En effet, c’est là que le dimensionnement de trafic prend toute son importance puisque ce
sont des décisions à prendre au cas par cas en combinant ces deux stratégies pour optimiser
l’utilisation de la bande passante et satisfaire les contraintes de qualité de service propres à
chaque stations. Cela reste largement dépendant de la taille, de la nature du réseau, du coût
de la bande passante, des types de services et de leur répartition dans le volume global, du
niveau de service établi avec le client pour chaque application mais aussi de celui décidé par
l’opérateur en fonction de ses critères de rentabilité.
Par ailleurs, une troisième méthode d’accès aléatoire dite allocation avec contention
existe. Cette méthode est adaptée aux réseaux à grand nombre de terminaux avec de longues
périodes d’inactivité entre les transmissions [2]. Son principe est de permettre une
transmission quasiment sans restriction pendant une durée limitée en occupant la totalité de
la bande. Cette technique ne se prête pas à une garantie de qualité de service. En raison de
l’accès aléatoire au canal, cette stratégie développe une tolérance aux collisions entre paquets
et par conséquent la nécessité des retransmissions. Elle est lourdement pénalisée par les
délais de propagation entre émetteurs et récepteurs terrestre. Néanmoins, son principal
avantage réside dans la simplicité de sa mise en œuvre et son coût peu élevé [1]. Le
protocole ALOHA [9] et sa variante Slotted ALOHA en sont des illustrations. Notons que
cette méthode peut venir en complément aux précédentes pour certains types d’utilisations.
II.3.4 Le niveau physique et les techniques de contre-mesure (FMT)
Il ne s’agit pas dans cette partie de présenter ni de détailler les caractéristiques de la
couche physique pour les liaisons satellites, sujet qui dépasse largement le cadre de ce
travail. Nous considérons les techniques dont l’utilisation impacte directement la bande
passante disponible et influe les décisions prises par les couches supérieures.
II.3.4.1 Pertes et atténuations sur le lien physique.
Au niveau physique l’ensemble des décisions (qualité de service, allocation de bande
passante..) qu’elles soient optimales ou non ont déjà été prises et une séquence de bits doit
donc être envoyée sur le lien radio. Toutefois, la qualité de service décidée par les couches
protocolaires supérieures doit être préservée. Ainsi, préserver la qualité de service de la

3 La fonction CAC est définie ultérieurement dans ce chapitre.

22
liaison physique revient à assurer un taux d’erreurs binaires BER inférieur à un certain seuil
pendant une certaine de durée de l’année. C’est ce qu’on désigne par la disponibilité de la
liaison.
En effet, et contrairement aux réseaux terrestres, où les pertes sont majoritairement
dues à la congestion, les techniques de contrôle d’accès telles que le CAC, limitent fortement
les pertes de ce genre. En revanche, les erreurs de bits dues à la nature bruitée du canal,
provoquent des pertes au niveau paquets4. En effet, ces pertes sont loin d’être uniformément
réparties. Les liaisons satellites observent des jeux d’erreurs en rafales, couplés à des erreurs
ponctuelles plus classiques. Ces dernières pouvant être recouvrées plus facilement ; les pertes
en rafales entraînent des pertes de paquets. Ces erreurs sont corrélées aux perturbations
atmosphériques et aux atténuations pouvant atteindre le canal radio.
La fonction première du lien physique est donc celle de compenser les atténuations
qui affectent le signal transmis avec des mécanismes qui sont certes transparents pour les
couches supérieures mais en étroite relation avec les techniques d’accès et de partage de
bande de niveau MAC. Le signal radio est d’autant plus sensible aux diverses conditions
atmosphériques que les fréquences sont plus élevées.
Afin de compenser ces atténuations, une marge est ajoutée à la valeur requise du
niveau de signal sur bruit et interférences évaluée lors du bilan de liaison. Elle sert à
préserver la disponibilité du système. Deux approches peuvent être adoptées pour le choix
de la marge. La première consiste à contrebalancer la dégradation du signal par une marge
statique estimée en fonction des conditions de propagation du pire mois de l’année [10]. Il
va sans dire que cette méthode représente un gaspillage significatif de ressources qui peut,
toutefois, s’avérer incontournable dans le cas d’un service de diffusion TV (one way) pour des
millions de récepteurs.
II.3.4.2 Techniques de contre-mesure (FMT)
La seconde approche consiste à adapter la valeur de la marge en fonction des pertes
réelles subies par le signal radio. Cette méthode constitue le principe de base des méthodes
de contre-mesures d’atténuations ou FMT (Fade Mitigation Techniques). L’objectif n’est pas
de détailler ces techniques. Les études traitant du sujet sont nombreuses dans la littérature
[10,11,12,13]. Il est surtout question de dégager l’impact qu’elles peuvent avoir sur la
manière dont seront encapsulés les paquets des niveaux supérieurs. Les techniques FMT
peuvent être répartie en trois catégories : contrôle de puissance, diversité et adaptation de la
forme d’onde.
- Le contrôle de puissance : le but est de maintenir la valeur du signal sur bruit à une
valeur constante. Ainsi, on fait varier la puissance de transmission de la porteuse en
fonction de dégradations subies. Plusieurs variantes de cette technique on été
développées [11].
- La diversité : il s’agit de modifier l’architecture de la chaîne de transmission en
introduisant des éléments externes qui bénéficient de conditions de propagation plus
favorables. Cela peut consister en un changement de site, de satellite, de temps ou de
fréquence [11,12,14,15].

4 La relation entre BER et PLR (Packet Loss Rate) est fortement dépendante de la technologie ainsi que des codes
correcteurs d’erreurs utilisés.

23
II.3.4.3 Adaptation de la forme d’onde (taux de codage et modulation)
Certes, les techniques précédentes permettent une haute disponibilité du lien mais
induisent des coûts et une complexité non négligeables. Elles ne sont pas forcément adaptées
à un contexte de transmission multimédia bidirectionnelle par satellite qui en plus des
impératifs de coûts peu élevés exige une certaine stabilité de l’architecture du système. Afin
de pallier ces contraintes, une troisième technique de contre mesure paraît plus attractive
puisque elle tire avantage de la possibilité qu’ont les terminaux à émettre du trafic, en plus
de celle d’en recevoir.
En effet, et en se fondant sur des informations passées ou quasi instantanées remontées par
les terminaux sur la qualité du lien physique, on modifie dynamiquement la forme d’onde
pour l’adapter au mieux au niveau du signal sur bruit plus interférence du terminal. Une
forme d’onde adaptative consiste à varier un ou plusieurs de ses paramètres afin de s’adapter
aux conditions de transmission et notamment au rapport signal sur bruit SNIR (Signal to
Noise plus Interference Ratio). Concrètement et en fonction des conditions de propagation on
fait varier la valeur de l’énergie émise par bit d’information qui se traduit par une variation
de la valeur du signal sur bruit selon la formule ci-dessous.
C /( N 0 + I 0 ) = Rb * Eb /( N 0 + I 0 ) (I)
Deux approches peuvent être employées afin d’adapter la forme d’onde.
II.[Link] Réduction du débit
Typiquement, on transmet à des débits élevés dans le cas de conditions favorables et
à des débits plus faibles si les conditions de propagation sont mauvaises (atténuations). Les
performances en puissance d’une forme d’onde sont liées à l’énergie transmise par bit
utile Eb . Un moyen d’augmenter cette énergie consiste à considérer des bits avec une durée
plus longue, un débit plus faible, tout en gardant un même niveau de puissance transmise.

Le débit est le produit l’efficacité spectrale5 par la bande selon la relation Rb = τ * B . Le

moyen de le réduire est d’agir soit sur la bande, soit sur l’efficacité spectrale. La chaîne de
transmission est ainsi plus fiable suite à l’augmentation de l’énergie moyenne par bit utile
même si le signal occupe une bande moins large par rapport au signal du départ car la durée
du bit est plus longue.
II.[Link] Adaptation du codage et de la modulation
Dans ce cas, on fait varier les valeurs que peut prendre l’énergie par bit
d’information Eb / N 0 . Pour ce faire on agit soit sur le code correcteur d’erreur, soit sur la
modulation du signal sachant que ces deux techniques sont souvent combinées.

Adaptation du codage canal: dans le cas de mauvaises conditions de transmission on

ajoute des bits de redondances en modifiant le taux de codage. Ceci engendre une
variation du débit utile transmis mais assure une transmission avec moins de bits
erronés.

5 Efficacité spectrale (exprimée en bit/s/Hz) = rapport entre le débit binaire et la bande occupée autour de la

porteuse. Elle caractérise la capacité d’une modulation à passer un débit maximal dans une largeur de canal
minimale.

24

Adaptation de la modulation: en fonction du niveau d’atténuation subi par la liaison
radio on fait varier l’ordre de la modulation (i.e. le nombre de bits par symbole).
L’accroître permet de transmettre à plus fort débit tout en gardant une bande
passante constante, toutefois au pris d’un Eb / N 0 élevé. D’un autre côté, la réduction
de ce taux de modulation permet de réduire la valeur requise de Eb / N 0 , en cas
d’affaiblissement, et donc de toujours garantir le bilan de liaison.

Faire varier le taux de codage et l’ordre de la modulation, souvent associés sous le

vocable ModCod, implique des modifications sur le nombre de bits avant codage mais aussi
sur la durée en symboles des trames de la couche physique. Ceci n’est pas sans incidence sur
le nombre de trames MAC à encapsuler dans la trame physique. Cet aspect sera abordé dans
le chapitre suivant mais surtout développé en étudiant l’efficacité d’encapsulation des paquets
IP sur le format de trame MAC DVB-S2 [16] au chapitre VI.

II.4. Contraintes et solutions à la mise en œuvre de l’IP sur satellite

Les méthodes d’accès au support et les caractéristiques de la couche radio pour les
liaisons satellite ne sont pas sans conséquences sur le comportement des protocoles de la pile
IP. Les systèmes satellite, réseau sans fil par excellence, se distinguent par une bande
passante réduite en comparaison à l’ADSL ou à la fibre optique. Ils souffrent notamment
d’un produit capacité-délai élevé pondéré par un délai terre-satellite de l’ordre de 250 ms. Le
caractère fortement bruité des liaisons radio et l’asymétrie accentuée entre les liens
compromet souvent le fonctionnement performant des protocoles IP terrestres
implicitement conçus pour une structure filaire à l’instar de TCP, principal protocole de
transport.
D’un autre côté, l’absence de technologies standardisées au niveau 2 laissent le champ
libre aux multiples propositions pour l’indispensable interaction entre les mécanismes de
qualité de service de niveau IP et ceux de la couche MAC. Concernant cette dernière, de
multiples protocoles ont été étudiés (ATM, MPEG, MPLS..). Certains ont été implantés
voire standardisés. Le but était non seulement de réduire le surcoût protocolaire mais aussi
de minimiser le trafic induit à ce niveau par la signalisation entre les terminaux et la
Gateway.
Loin d’être exhaustifs, surtout dans un contexte NGN en permanente évolution, nous nous
proposons dans cette section d’explorer les principaux verrous à la mise en œuvre de l’IP sur
des systèmes satellites GEO. Quelques une de ces problématiques comme le protocole TCP,
font l’objet de recherches depuis quelques années. Certaines ont déjà débouché sur des
solutions industrielles que nous avons pu testées dans le cadre de cette étude.
II.4.1 TCP/IP adapté au satellite
II.4.1.1 Introduction
Le protocole TCP a été conçu au début des années 1980 dans un contexte de
technologies réseau très différent de celui d’aujourd’hui. Même si sa longévité témoigne de
sa robustesse, des évolutions technologiques - comme l’augmentation des débits et le
caractère hétérogène des réseaux actuels (liaisons sans fil, réseaux cellulaires, réseaux
d’accès asymétriques...) - posent de sérieux problèmes de performance à TCP. Dans sa
première version [17], le protocole ne comprenait pas de techniques de contrôle de flux.
Depuis, TCP a considérablement évolué avec l’ajout de plusieurs algorithmes comme le
Slow Start, Congestion Avoidance pour le contrôle de congestion en plus des mécanismes de
recouvrement d’erreur Fast Recovery dans la version TCP Tahoe en 1988 et ensuite de TCP

25
Reno en 1990. Des algorithmes de retransmission de paquets Fast Retransmit sont ensuite
venus l’améliorer pour enfin aboutir en 1996 à la version la plus déployée jusqu’à aujourd’hui
[18].
L’adaptation de TCP aux réseaux satellite géostationnaires est les un des points les plus
étudiés dans le cadre d’IP sur satellite. En effet, La performance de bout-en-bout de TCP sur
les liens satellite à délai élevé souffre des interactions avec les mécanismes de contrôle de
flux
Cette partie expose les principales contraintes liées à l’utilisation du protocole TCP par
satellite. Nous insisterons davantage sur les solutions qui ont conduit à des implantations
réelles.
II.4.1.2 Les limites du protocole TCP sur satellite
Les réseaux satellite s’inscrivent dans une catégorie caractérisée par un fort produit
Bande x Délai (BDP) (Bandwidth Delay Product). Dans ce contexte, les pertes de paquets
qu’elles soient dues à la congestion ou aux erreurs de transmission peuvent avoir
d’importantes conséquences quant à l’utilisation des capacités de transmission. C’est le
résultat de la nature même de cette catégorie de réseaux :
- Un délai de propagation élevé (500 ms aller-retour).
- Une asymétrie souvent forte entre lien Aller et Retour
- Des méthodes d’accès dynamiques.
- Les erreurs sur le lien physique
II.4.1.3 Taille de la fenêtre
Selon la relation (1),
advertized _ window
D MAX = (1)
RTT
Le délai Aller-Retour, c'est-à-dire entre l’envoi d’un paquet de données et la réception
d’un accusé de réception, est inversement proportionnel au débit maximal que peut atteindre
une liaison. Ce débit est surtout conditionné par la taille maximale de la fenêtre du récepteur
(advertized_window) qui est fixée à 65535 octets [19]. Ainsi, pour 500 ms, il n’est pas
possible d’émettre en-dessus de 1048 Kbit/s. La figure 2.3 montre l’évolution du débit en
fonction de la taille de la fenêtre TCP et du délai.

Figure II.3 Débit en fonction de la taille de la fenêtre [18]

Une autre cause des mauvaises performances de TCP par satellite est le
comportement standard de mécanismes de régulation de flux. En raison du long délai, les
techniques de contrôle de flux fondées sur la fréquence de réception des ACK imposent un

26
rythme de progression lent des algorithmes de régulation de flux (Slow Start et Congestion
Avoidance).
A l’ouverture d’une connexion TCP, l’algorithme de démarrage lent Slow Start adapte le
débit en fonction de la fréquence des accusés de réception reçus ACK pour éviter de saturer
le lien. Il double le nombre de segments envoyés après chaque ACK reçu correctement.
Toutefois, la valeur initiale de la fenêtre est très basse. A partir d’un certain seuil et d’une
taille de fenêtre donnée (sthreshold), c’est l’algorithme d’évitement de congestion
(congestion_avoidance) qui prend le relais et adapte la taille de la fenêtre en fonction du flux.
Dès qu’il y a détection d’un paquet non transmis, la taille de la fenêtre d’émission est réduite
de moitié avec reprise d’une augmentation graduelle de cette taille. La figure 2.4 décrit les
comportements respectifs de ces deux algorithmes.

Figure II.4 Comportement des algorithmes Slow_Start et Congestion_Avoidance dans TCP

Dans le cas d’une liaison satellite GEO avec un long délai aller-retour, on voit
clairement que le canal est sous-utilisé pendant une durée relativement longue
correspondant à l’envoi des premiers segments. De surcroît, TCP attribue systématiquement
toute perte de paquets à une congestion du réseau et diminue donc la taille de la fenêtre
limitant ainsi le débit. Or dans un média aussi bruité que le satellite, ce n’est pas forcément le
cas. Par conséquent et sur toute la période de fonctionnement de TCP, on observe une sous
utilisation du canal satellite aussi bien pour la phase de démarrage lent que pendant celle de
la régulation de flux.
II.4.1.4 Evaluation du temps Aller Retour
Le calcul de la temporisation RTO (Retransmission Time Out) i.e. la durée après laquelle
un paquet émis non acquitté est considéré comme perdu et devant donc être retransmis par
l’émetteur, est estimé à chaque nouvelle valeur du délai d’Aller-Retour RTT. Un accès
dynamique à la bande passante notamment sur la voie retour peut induire des variations
importantes dans la valeur du RTT et donc des difficultés à calculer le RTO. En plus, ce
paramètre est évalué à chaque émission de nouvelle fenêtre, ce qui pose un problème lorsque
la taille de la fenêtre est importante avec un RTT qui fluctue en permanence.
D’un autre côté le calcul de la valeur du RTO, reste critique et directement dépendante de la
valeur choisie ou estimée du RTT.
- Un délai trop important introduira un retard dans la retransmission des paquets
perdus.
- Un délai trop court risquera d’engendrer des retransmissions inutiles et de charger le
lien.

27
II.4.1.5 Asymétrie du lien
Une autre source de restriction du débit est un ratio d’asymétrie élevé entre la voie
aller et la voie retour. Si l’on note T1 et T2, respectivement le temps d’émission d’un
datagramme (de taille data) sur le lien aller, et le temps d’émission d’un ACK (de taille ack)
sur le lien retour. Notons DA et DR les débits respectifs de la voie aller (source vers
terminal en passant par une Gateway) et de la voie retour. On a alors engorgement des
acquittements dès que T2 est supérieur à T1, soit, en fonction du débit du lien et de la taille
de la donnée :
data ack ack DR
T1 ≤ T2 ⇔ ≤ ⇔ ≥
DA DR data DA
Or pour un débit aller DA de 512 Kb/s, des acquittements de 40 octets et une taille maximale
d’un segment TCP (MSS Maximum Segment Size) de 1460 octets, on obtient une valeur
limite d’environ 14,2 Kb/s pour DR . En deçà de ce seuil, il y a congestion des acquittements,
et le trafic aller est limité par le faible débit de retour des acquittements.
II.4.2 TCP et son adaptation aux communications par satellite
Industriels et organismes de recherches se sont attelés à l’exploration des différents
moyens d’amélioration des performances de TCP sur le lien satellite. Plusieurs approches
ont été entreprises dans ce sens [29,34]
II.4.2.1 Modification des paramètres de TCP
A ce titre un groupe de travail TCPsat de l’IETF a eu pour objectif de réfléchir sur les
modifications à apporter au le protocole TCP afin d’en améliorer le comportement sur les
liens satellites. Ce travail a abouti à une RFC [20]
Une amélioration du comportement TCP passe par un paramétrage plus approprié qui le
rend plus conforme à une transmission par satellite :
- Une augmentation de la taille de la fenêtre de congestion initiale pour permettre un
démarrage plus « agressif » du protocole pour atteindre plus rapidement le seuil de la
fenêtre de congestion. [21, 22].
- Le « Path Memory Discovery », spécifié dans [23], vise à déterminer la valeur MTU
pour laquelle les datagrammes IP ne seront pas fragmentés sur le réseau. Dans
l’idéal, l’intégralité du datagramme IP est contenue dans le champ de données d’une
trame physique, ce qui assure une transmission plus efficace sur le réseau physique.
- Le recours à une fenêtre de réception plus grande avec l’extension Window Scale [24]
en tenant compte des capacités de mémorisation de l’émetteur et du récepteur et de la
taille des tampons.
- Traitement de la rémanence des numéros de séquences et la garantie de leur unicité
pendant toute la durée de vie d’un segment [24].
- Le recours aux acquittements sélectifs [25] qui permet de s’affranchir de la
contrainte des ACKs cumulatifs de TCP en indiquant explicitement les blocs
acquittés. De cette façon, le récepteur notifie dans ses acquittements la liste des blocs
effectivement reçus, ce qui permet à l’émetteur de ne réémettre que les segments non
reçus.
Ces optimisations apportent des améliorations certaines, mais impliquent aussi d’autres
problèmes. Ainsi l’augmentation de la taille maximale de la cwnd (Congestion Window) permet
d’avoir un meilleur débit sur le lien, mais accentue le risque de pertes multiples dans une

28
même fenêtre. Le Path MTU Discovery allonge le temps d’établissement de la connexion
TCP. Pour ce qui est de l’estampillage des datagrammes, ils ajoutent de l’overhead, ce qui
peut poser problème notamment au niveau de la voie retour
II.4.2.2 Implantations différentes
Une autre piste de réflexion a été de définir complètement de nouveaux protocoles.
TCP westwood [26] en est une illustration. C’est une modification côté émetteur de la pile de
protocoles TCP qui permet une estimation dynamique de bout en bout de la bande passante
du lien avant de fixer la taille de la fenêtre de congestion. D’autres approches permettent de
conférer à TCP la possibilité de distinguer les pertes dues à la congestion de celles dues au
lien physique Explicit Loss Notification (ELN) [27]. Cela nécessite une coordination entre les
couches transport et liaison de données et éventuellement la modification de la structure de
la pile TCP/IP des deux extrémités communicantes.
Une autre approche, plus spécifique aux réseaux sans fil, permet de pallier les pertes de
paquets en laissant inchangée la structure TCP. En effet, étant donné un type de liaison sans
fil, une bande passante, une taille d’antenne et une puissance d’émission données, les objectifs
de performances sont fixés en déterminant le taux d’erreur binaire et un taux de transfert
(IBR Information Bit Rate) souhaités en sélectionnant les schémas de modulations et les taux
de codage adéquats. C’est une approche qualifiée de Cross-layer bien qu’elle reste
transparente pour les couches supérieures. On obtient ainsi de meilleures performances de
TCP avec un choix judicieux du TEB et de l’IBR du lien physique [28].
L’ensemble des solutions décrites ci-dessus, qu’elles soient des optimisations du
protocole ou encore des extensions de TCP, nécessitent souvent une mise en œuvre de bout
en bout ou au moins des modifications sur les entités communicantes. Or il n’est pas toujours
possible d’avertir la source et le client qu’ils utilisent un lien satellite, notamment lorsque la
source est un serveur quelconque sur le Web, et/ou que le satellite assure une liaison entre
deux réseaux distincts géographiquement à l’image des backbones en fibre optique entre
continents.
D’autre part, si des modifications sont mises en place, celles-ci vont affecter
l’ensemble du réseau traversé et pas seulement le lien satellite, au risque d’avoir un
comportement indésirable sur la traversée de réseaux terrestres.
II.4.2.3 Les proxies
Dans l’objectif d’éviter un impact sur l’ensemble des entités constituant le réseau, une
autre démarche consiste à en repenser l’architecture. Ainsi, par l’intermédiaire de
l’introduction de techniques intermédiaires (middleware techniques), on isole le problème de
TCP uniquement sur le lien satellite et on développe les moyens qui apportent un gain en
performances exclusivement sur cette partie. Ces mécanismes sont regroupés sous
l’appellation PEP (Performance Enhancement Proxies) [30]. Les proxies interceptent les
données et implantent à ce niveau tout changement pour le lien satellite. Une des solutions
consiste à considérer un protocole autre que TCP plus performant sur le lien satellite tel que
SCPS-TP, XTP) [31,32]. À l’autre extrémité du lien satellite, un autre proxy restitue les
données initiales en enlevant les changements effectués pour le satellite. Cette fragmentation
de la connexion TCP entre la source et le destinataire en trois morceaux se nomme spoofing
[33]. Se basant sur leur connaissance des caractéristiques physiques de la liaison satellite,
l’extrémité du lien satellite envoie les accusés de réception à l’émetteur qui stocke les paquets
en cours de transit sur le lien satellite dans une mémoire tampon en vue de les réexpédier en
cas de pertes ou d’erreurs [24]. Cette configuration est complètement transparente pour le
client et le serveur qui, en fait, communiquent avec leur proxies respectifs qui leur envoient
les acquittements nécessaires dans les délais standards.

29
 Internet

Figure II.5 Implantation des proxies PEP sur une liaison satellite

II.4.2.4 Conclusion
En dépit des difficultés que pose TCP quand il opère sur lien satellite, il reste
incontournable pour une transmission fiable des paquets IP aussi bien sur des réseaux
filaires que câblés. Les solutions d’optimisation, couramment appelées solutions
d’accélération TCP - la raison de l’appellation est qu’elles permettent d’atteindre plus
rapidement le débit maximal par rapport à un fonctionnement standard du protocole- les
plus répandues dans l’industrie et souvent efficaces se fondent sur des proxies qui soit
implantent un protocole de transport différent pour le lien satellite soit concentrent
l’ensemble des modifications apportées par les RFCs [20, 24] sur segment satellite. Ces
modifications sont également introduites sous la forme d’une brique logicielle additionnelle
au sein même de certains terminaux satellite. Ces techniques apportent une amélioration
sensible aux performances de TCP. Elles ont, toutefois, l’inconvénient de rompre les liaisons
de bout-en-bout chiffrées telles que celles reposant sur IPsec [5 ,34].
II.4.3 La qualité de service et la gestion de la bande passante
II.4.3.1 Introduction
Les réseaux satellite appartiennent aux technologies d’accès au même titre que
l’ADSL, l’UMTS ou le Wifi. Ils sont ainsi amenés à acheminer un nombre croissant de
services de natures fortement hétérogènes (VoIP, E-mail, FTP, VoD, Streaming…). La mise
en œuvre de mécanismes de différenciation de traitement entre ces services par rapport aux
contraintes spécifiques (délai, débit constant ou variable, gigue, perte de paquets …) que
posent chacun, est nécessaire. L’ensemble de ces techniques peut être inclus sous
l’appellation de qualité de service dont une des définitions est « QoS is the ability of a network
element (e.g an application, host or router) to have some assurance that its traffic and service
requirement can be satisfied » [35]
Ainsi, ils font face à l’obligation de fournir des mécanismes et des architectures de
différenciation de traitement au niveau IP - QoS IP - en fonction des contraintes variables
de délais, de bande passante. Ces architectures sont en majorité héritées du travail déjà mené
dans l’Internet dans un souci de continuité. Elles s’appuient sur des paramètres et des
techniques standards de classification et de traitement de services pour assurer un minimum
d’interopérabilité entre les différents réseaux.
Néanmoins, l’adaptation des mécanismes de QoS IP n’a pas lieu sans problèmes pour
deux raisons principales. Premièrement, ces techniques s’intègrent dans l’infrastructure
globale des réseaux NGN, travail encore inachevé, même si les principales fonctionnalités
des protocoles se dégagent progressivement. Deuxièmement, et à l’instar de l’ensemble des
réseaux sans fil, les systèmes satellite doivent s’appuyer sur des mécanismes QoS de niveau 2

30
pour compenser leur limitation en bande passante et offrir des garanties comparables à celles
des réseaux terrestres.
Dans cette partie et dans un premier temps, nous présentons les architectures de
qualité de services existantes, les orientations et les projets de développement. Ensuite, nous
y exposons les difficultés que soulèvent les interactions avec les mécanismes de niveau 2.
II.4.4 Architectures de qualité de service existantes
II.4.4.1 L’évolution des architectures de QoS IP
En ce qui concerne la qualité de service, le rapport [3] se contente d’un recensement
global des mécanismes de qualité de service existants dans les systèmes terrestres (SIP,
COPS, Diffserv, Classes de trafic, …) [36,37]. Il ne préconise rien de nouveau concernant
leur adaptation à un contexte satellite. Il offre toutefois un cadre architectural nécessaire à
l’établissement de solutions génériques. Aucun modèle standard de QoS n’existe à l’heure
actuelle. Nous proposons donc de décrire l’évolution de la conception et de l’architecture
QoS dans le monde IP en les replaçant dans un contexte satellite.
II.4.4.2 Intserv
Une première approche d’architecture est orientée « utilisateur ». Elle a pour objectif
de fournir une QoS homogène de bout en bout. Sa mise en place suppose un protocole de
signalisation explicite hors bande et commun à l’ensemble des routeurs Internet. Le modèle
le plus abouti de cette architecture reste Intserv [38,39]. Issu des travaux de standardisation
de l’IETF, ce modèle définit deux nouveaux services : garanti [40] et contrôlé [41].
L’implantation d’IntServ requiert une réservation des ressources par flux sur le réseau à la
demande de l’application. Cela suppose la mise en place de fonctions de contrôle d’accès, de
classification et de gestion de ressources dans chaque nœud du réseau via le protocole de
signalisation bout en bout RSVP [39,42].
En dépit d’une gestion de la QoS de bout en bout très fine, la plus grande faiblesse de
l’architecture IntServ reste sa non résistance au facteur d’échelle. Bien que standardisé depuis
1997, les inconvénients du modèle IntServ ont empêché son déploiement. Il fallait penser
une architecture qui s’accommode au passage à l’échelle et apporte des mécanismes de QoS
qui répondent aux contraintes des opérateurs de réseaux.
II.4.4.3 DiffServ
Le modèle proposé par DiffServ est le premier à prendre en compte le nombre
croissant de services hétérogènes et surtout la structure d’Internet. L’architecture DiffServ
s’appuie sur le découpage actuel d’Internet en domaines autonomes, c’est-à-dire un
regroupement de nœuds qui répondent chacun à une seule et même autorité administrative.
Au sein de ce « domaine autonome », on distingue les routeurs de bordure (routeur d’Entrée
ou de Sortie qui peuvent être reliés directement à un réseau utilisateur ou à un autre
domaine) et les routeurs de cœur. Ce domaine sous l’autorité d’un opérateur de réseau offre
des services. Tout client (opérateur ou particulier) qui veut en bénéficier négocie un accord
avec l’opérateur concrétisé par un contrat différencié : le SLA [43] (Service Level
Agreement). Il contient des termes et des conditions techniques et non techniques. Ce
contrat est généralement décliné en plusieurs SLS (Service Level Specification) qui
constituent la partie technique du SLA [43].
Afin de résoudre le problème de passage à l’échelle, l’architecture DiffServ, donne la priorité
aux regroupements de flux dont les besoins sont similaires (agrégation) et à la définition des
traitements nécessaires dans les routeurs pour que l’agrégat de ces flux soit traité
correctement. D’un point de vue économique, l’absence de réservation de ressources permet

31
aux opérateurs d’offrir de nouveaux services tout en gardant un système de tarification
simplifié.
Dans ce modèle, la seule signalisation nécessaire est une étiquette contenue dans l’en-tête du
paquet IP utilisée pour assurer un traitement différencié. Il n’y a pas de signalisation dans le
cœur du réseau. Cette capacité permet aux routeurs de garder un mode de fonctionnement
relativement simple. La complexité est reportée sur les routeurs de bords à l’entrée ou à la
sortie d’un domaine administratif. Ces équipements sont chargés de déterminer la valeur de
l’étiquette de chaque paquet en fonction d’un contrat SLA, du service demandé et des
mécanismes de contrôle de trafic. L’approche Diffserv s’appuie sur un nombre de notions :
- Métriques de QoS : c’est un ensemble de paramètres, communs aux opérateurs de
réseau permettant d’évaluer les performances de transferts de paquets IP d’un réseau
à un a autre.
- Classes de trafic : c’est un classement des applications en fonction des attentes de
clients en termes de qualité de service. Les critères de distinction sont communs à
l’ensemble des organismes (ITU, 3GPP, TIPHON) [44,45].

Trafic orienté connexion ou non

Interactivité, temps réel, interactif ou non.

Critères de QoS : perte de paquets, délai, gigue.
- Classes de services : Partant de ces classes de trafic, il est possible de former
plusieurs classes de services. Le BSM a établit un ensemble de recommandations
recensées dans [3]. Elles incluent des techniques d’admission et de gestion de
ressources adaptés à chaque type de trafic. Elles associent également des classes de
trafic avec des classes de services.
II.[Link] Différenciation des flux dans Diffserv
Avant d’entrer dans le réseau de cœur, l’ensemble des paquets IP qui traversent le
routeur d’entrée sont étiquetés via le champ d’en-tête DSCP (Diffrentiated Service Code Point)
[46]. La tâche principale de ces routeurs d’entrée est donc de conditionner le trafic entrant,
de le classifier et de le re-marquer en fonction de la politique de l’opérateur du réseau qui
résulte en une valeur attribuée au champ DSCP. Deux critères permettent d’établir cette
différentiation : la classe de service et la priorité des paquets. Pour ce faire, les routeurs de
périphérie s’appuient sur des classificateurs multi-champs comme les adresses IP source et
destination, protocoles de transport UDP, TCP ou autres, les ports sources et destination,
caractérisant par ailleurs, la notion de classe de trafic introduite précédemment.
Ensuite et à l’intérieur d’un domaine Diffserv, les routeurs de cœur traitent les
paquets en fonction de la valeur du champ DSCP en leur affectant un PHB (Per Hop
Behaviour). D’après [46], un PHB est la description des caractéristiques d’acheminement qui
seront observées par tous les paquets comportant la même valeur de DSCP. L’utilisation
d’un PHB ou d’un groupe de PHB ajoutée aux opérations de conditionnement réalisées à
l’entrée d’un domaine forment ce qu’on appelle un service Diffserv. En plus, du « Best
Effort » comportement standard du réseau, deux types de PHB ont été standardisés EF
(Expedited Forwarding) [47] avec la priorité la plus élevée et AF (Assured Forwarding) [48]
qui garantit l’acheminement de certains paquets en cas de congestion.

32
II.[Link] Avantages et inconvénients
Le modèle Diffserv, se distingue par une conception réaliste de l’Internet et propose
une gestion de la qualité de service multi-niveau définie par l’opérateur avec une
signalisation intra-bande. Elle résout certes les problèmes de passage à l’échelle mais
présente toutefois certaines limites.
En effet, une allocation de ressources non automatisée requiert une configuration entière ou
partielle au sein d’un domaine DiffServ en cas d’ajout d’un nouveau service. Ceci implique par
ailleurs, un surdimensionnement des ressources empêchant le réseau de s’adapter aux
fluctuations de trafic d’autant plus qu’elle engendre une utilisation non optimisée de la bande
passante. D’un autre côté, aucun protocole de réservation de ressources au niveau des
applications utilisateurs n’est obligatoire ce qui empêche ces derniers de modifier
dynamiquement les ressources en fonction de leur besoins.
De plus, rassembler les flux en différents agrégats peut entraîner une distribution
inéquitable des ressources du fait de l’agressivité de certains.
Enfin, la configuration des routeurs d’entrée souffre de l’association statique entre groupes
d’utilisateurs ou d’applications et des classes de services. Ceci est peu compatible avec les
changements dynamiques qui atteignent un réseau.
En dépit de ses multiples lacunes, le principe d’agrégation de flux du modèle DiffServ, sa
conformité au principe de séparation des différents domaines administratifs et la liberté qu’il
procure aux opérateurs dans la gestion des ressources à l’intérieur de leur domaine, demeure
la solution la plus souple et la plus performante actuellement.
II.4.4.4 Une qualité de service Cross-Layer
II.[Link] Une conception hybride de la QoS IP
En s’appuyant sur cette architecture pour le partage des ressources inter-domaines,
les recherches se sont focalisées sur la problématique de réservation de ressources à
l’intérieur d’un domaine donné ce qui a abouti à une conception de la QoS en deux étages
[32]. Par l’intermédiaire d’un protocole de signalisation intra-domaine, on confère aux
applications une « conscience » QoS leur permettant de réserver les ressources dont elles ont
besoin durant leur période d’activité. Cette vision de la qualité de service appelée « QoS
orientée session » permet des garanties de QoS de bout-en-bout en couplant les deux visions
historiques de la QoS à savoir Diffserv et Intserv.
La qualité de service orientée session fait l’objet de multiple projets de recherches
(Tequila, Cadenus [45]) ainsi que ceux menés par l’IETF. Elle suscite d’autant plus d’intérêt
pour les réseaux d’accès par satellite puisqu’elle entretient l’espoir d’une utilisation optimisée
d’une bande passante coûteuse. Dans ce contexte, l’émergence de SIP [36] (Session Initiation
Protocol) protocole du niveau application dont le rôle est d’initier, modifier et terminer les
sessions multimédia, en fait une solution pour la mise en œuvre d’une signalisation QoS.
Le projet SATIP6 [45] dont l’objectif est de faciliter l’intégration des services IP
dans les réseaux d’accès DVB-RCS [56] apporte dans son lot de contributions, une
proposition d’architecture de contrôle de qualité de service via le protocole SIP [42]. Elle
prévoit le recours à un proxy SIP au niveau du terminal pour relayer le trafic SIP.
L‘interaction du proxy avec l’entité allouant les ressources au niveau de la Gateway permet
une gestion automatisée de la réservation de ressources, du contrôle d’admission et de
l’allocation de ressources. En plus, elle conditionne l’établissement d’une session à la
disponibilité et à la réservation de ressources ce qui permet malgré un délai d’établissement
plus long, un bon déroulement de la session.

33
 Cette approche de la qualité de service propose une meilleure gestion des ressources
de bout-en-bout. Toutefois, une signalisation intra-domaine suppose une interaction entre le
niveau 2 et la couche physique où les ressources sont effectivement allouées.
A l’opposé des réseaux filaires ADSL ou en fibre optique qui proposent des
infrastructures généralement surdimensionnées en bande passante par rapport aux débits à
véhiculer, les réseaux sans fil souffrent de la faiblesse de celle. Ceci est particulièrement vrai
pour les systèmes satellite où les méthodes d’accès au lien en plus des stratégies d’allocation
de bande sont là pour optimiser au mieux des ressources radio mais requièrent, tout de
même un temps non négligeable. Se pose alors la contrainte supplémentaire de l’interaction
entre les mécanismes de qualité de service et les techniques d’allocation de bande passante
radio.
II.4.4.5 Interaction entre la qualité de service et les ressources radio dans les
réseaux satellite
Les réseaux d’accès par satellite ne peuvent se satisfaire d’une qualité de service
niveau IP pour garantir des performances comparables à celles des réseaux terrestres. Ils
doivent impérativement s’appuyer sur des mécanismes de niveau 2 pour compenser la
faiblesse de la bande passante qu’ils proposent. A l’instar des autres technologies sans fil les
systèmes satellites n’intègrent pas de mécanismes de QoS entièrement standardisés au
niveau 2. Cela limite les interactions possibles avec les couches supérieures dont notamment
IP.
Les mécanismes des couches MAC et physique apportent des solutions à la fluctuation de la
bande passante par le biais de techniques telles que l’adaptation de la forme d’onde. De
surcroît, et particulièrement au satellite, le mode de partage MF-TDMA combiné au DAMA
permettent d’attribuer ainsi uniquement aux terminaux utilisateurs les ressources dont ils
ont besoin. Cela s’effectue selon des modes d’allocation dont l’interactivité est directement
liée aux besoins des applications en jeu. Il demeure toutefois nécessaire d’inculquer aux
couches hautes une « conscience » de cette variabilité des ressources en leur remontant des
informations sur l’état du lien physique. Ce retour permettrait aux applications de s’adapter
dynamiquement à un environnement bruité avec par exemple l’adoption de codecs applicatifs
moins gourmands en bande passante. D’un autre côté et afin de pouvoir tirer le meilleur
parti des ressources de ces réseaux, les architectures de QoS ne peuvent plus se contenter de
propager vers les couches basses une QoS qui n’est que la mise en correspondance de classes
de service de niveau IP. Des mécanismes dits de Cross-Layer assurent par l’échange
d’informations entre couches basses (Physique et MAC) et couches hautes (IP, transport et
applicatives), une utilisation optimisée de la bande passante en plus d’une meilleure
adaptation à la fluctuation de celle-ci.
Outre les mécanismes d’ordonnancement et de QoS au niveau 2, les principales
fonctionnalités de demande et d’allocation de bande passante sont
- Le RRR (Radio Resource Requester) – ou toute appellation équivalente- qui évalue le
trafic à acheminer du côté du terminal et émet des requêtes de bande passante vers la
Gateway.
- L’ensemble CAC [11] (Connection Admission Control) et le protocole DAMA, sont
responsables d’accepter ou non les demandes de connexions - acheminement des flux-
et d’allouer la bande passante nécessaire en fonction des besoins ponctuels de chaque
terminal.
Ces entités tentent de concilier deux objectifs antagonistes. Le premier consiste à assurer
la QoS établie par les niveaux applicatifs et compatibles avec le SLA spécifié. Le deuxième
tend à optimiser la consommation des ressources radios susceptibles de varier dans le temps.

34
De plus, l’utilisation croissante des techniques FMT afin d’éviter de compenser les
atténuations avec une marge statique impose ainsi une interaction entre les modules
d’allocation de bande passante et le contrôleur FMT dans l’objectif d’éviter les préjudices
causés par la variabilité de la capacité.
On s’aperçoit à la seule formulation de la problématique, de la complexité que peut entraîner
sa mise en œuvre. En effet, elle requiert non seulement des interactions verticales entre les
niveaux protocolaires mais aussi des échanges horizontaux entre entités d’une même couche
protocolaire.
Les approches de recherche autour de cette thématique sont diverses. On a tenté à chaque
fois d’aborder le problème différemment ou de se focaliser sur une problématique isolée. Une
des démarches tend à se pencher sur le développement des performances de la couche MAC.
Une multitude de travaux a porté sur l’optimisation des stratégies de CAC6 (Call Admission
Control) [11]. Ces techniques ne sont pas abordées dans le cadre de cette étude.
Une autre approche est de se focaliser sur les stratégies dynamiques d’allocation de
bandes qui assurent une utilisation optimisée des ressources radio. Elle a également comme
objectif de minimiser la latence induite par le processus de requête-allocation entre le
terminal et la Gateway. Une des propositions formulée dans le cadre du projet SATIP6
consiste à définir un facteur d’anticipation spécifié sur la base des caractéristiques des
différents flux ce qui peut apporter une parade à la latence introduite par le cycle requête-
allocation [49,50].
D’autres propositions d’algorithmes de BoD (Bandwidth on Demand) permettent au terminal
de décider des ressources nécessaires compte tenu d’un équilibre entre utilisation optimisée
des ressources et performance de l’application en fonction de plusieurs niveaux de service ou
de performances, allégeant par ailleurs la charge au niveau de la Gateway [51].
D’un autre côté, le caractère ouvert des algorithmes de réservation et d’allocation de bande
passante, d’ordonnancement de flux, a été favorable à un nombre important de propositions,
même si les implantations sont restées propriétaires.
Une autre approche consiste à définir des correspondances entre les différentes
catégories de ressources radio et celles des classes de service Diffserv. La plupart des
propositions ont porté sur le standard DVB-RCS [56] puisque les catégories de bandes
passantes radio y sont clairement définies. Par ailleurs, le Satlabs [52], organisme en charge
du suivi et du développement du standard DVB-RCS, a publié un document où ces
correspondances sont clairement définies [53]. Dans l’esprit de cette association, il est
possible d’imaginer des protocoles de signalisation intra-domaines comme SIP, qui rendent
compte des besoins en QoS de l’application et les traduisent en requêtes de ressources radio
en volume ou en débit avec ou sans garantie, tout en minimisant les délais requis par le cycle
requête-allocation [45,54]
Les évaluations qu’on peut avoir de ces implantations relèvent souvent de la simulation et
s’appuient dans la plupart des cas sur le standard DVB-RCS. Les constructeurs de systèmes
satellite type DVB-RCS [56] communiquent peu sur la manière dont ils gèrent la
coopération entre les mécanismes de QoS de niveau IP et la gestion de bande passante
niveau 2. Outre les difficultés de conception, des choix de dimensionnement influent sur le
comportement du système satellite dans le respect du compromis entre QoS et optimisation
de l’usage des ressources. Ainsi, le meilleur moyen d’apprécier les performances d’un système

6 La fonction CAC, Contrôle d’Admission des Connexions, est définie selon l’ITU-T [43] comme l’ensemble des procédures
et actions accomplies par le réseau pendant la phase d’établissement d’une connexion pour déterminer si celle-ci peut ou non
être établie. La fonction CAC a donc pour objet de limiter le nombre de connexions dans le système favorisant ainsi les
mécanismes de contrôle de congestion, de flux, de reprise sur pertes, d’accès aux supports, etc [8]

35
satellite fondé sur DVB-RCS ou sur d’autres technologies reste celui d’effectuer des
expérimentations avec différentes applications IP. Cette approche expérimentale d’évaluation
sera l’objet des chapitres suivants du présent travail.
II.4.5 L’effet de la signalisation et de l’encapsulation
Les techniques de transmission des flux IP sur des systèmes satellite conduit à la
proposition de nouveaux schémas de qualité de service avec des techniques Cross-layer
incluant des protocoles inter-niveaux ou l’adjonction de sous-couches supplémentaires au
niveau 2 pour les adapter au support radio. Elles ne sont pas sans impact sur la bande
passante. En effet, la signalisation introduite aussi bien au niveau IP (session multimédia,
VoIP..) qu’au niveau de la gestion des ressources et de la synchronisation des terminaux
n’est pas négligeable. Les étapes d’encapsulation successives et les techniques de correction
d’erreurs engendrent aussi des coûts non négligeables en bande passante.
II.4.5.1 La signalisation
La signalisation de « bas niveau » pour les réseaux satellite est un des fondements de
spécifications de ces technologies. En effet, la norme DVB-RCS [56] y accorde une part
importante en dépit de la lourdeur et de la redondance de certaines tables de signalisation.
Cette partie de la signalisation, généralement dans la bande n’est pas sujet à modification.
Pourtant, certains travaux proposent d’intégrer une architecture, au-dessus de la couche
physique DVB-S2 [16] associant IP et MPLS [58]. Ceci remet en cause la signalisation
DVB [57]. Toutefois, la marge de manœuvre concernant la signalisation bas niveau est
assez restreinte. Il est en revanche indispensable de recourir à des protocoles nécessitant peu
d’échanges et incluant le minimum de messages ce qui, par là-même, réduit l’effet de la
latence satellite sur les trafics à acheminer.
II.4.5.2 Encapsulation
Le coût d’encapsulation en partant d’un paquet d’information utile jusqu’à l’accès au
support physique est d’autant plus important que la taille initiale du paquet est réduite.
Outre un choix optimisé de la taille des paquets, des techniques de compression d’en-tête
générique comme IPcomp [60] ou spécifique à l’application tels que cRTP ou ROHC
permettent souvent d’économiser une bande passante précieuse [59]. Cet aspect sera
développé davantage au cours des chapitres suivants.

II.5. Conclusion
Nous avons décrit dans ce chapitre les principales caractéristiques des réseaux IP par
satellite considérés dans cette étude. Dans un deuxième temps nous avons mis en évidence
les principales difficultés relatives à l’acheminement des flux IP à travers les réseaux
satellites géostationnaires. Un tableau, non exhaustif, des techniques et des procédés qui
permettent d’améliorer le comportement des flux IP sur satellite, a été dressé.
Cependant, les solutions décrites sont naturellement liées à la manière avec laquelle le
système doit être conçus comme les algorithmes de DAMA, l’interaction entre les ressources
radio et la qualité de service.
Dans les chapitres qui suivent, nous allons aborder le problème du point de vue de
l’opérateur qui dispose déjà de la technologie. Il reste dans l’obligation de dimensionner au
mieux son système aussi bien au niveau applicatif (choix des codecs VoIP, taille des paquets,
compressions…), de la précédence des flux en terme de QoS, de l’’encapsulation des paquets,
du compromis et des proportions en terme d’allocation statique et dynamique de bande afin
d’atteindre ses objectifs de niveau de service établi avec le client mais aussi en terme de coût
avec un usage optimisé des ressources satellite.

36
III. DVB-RCS, un standard pour la transmission de l’IP
bidirectionnel par satellite.

III.1. Introduction
Après avoir introduit dans le chapitre précédent les concepts de bases relatifs aux
technologies de transmission de l’IP bidirectionnel par satellite, l’objet du présent chapitre
est de présenter une technologie particulière. Il s’agit du standard DVB-RCS (Digital Video
Broadcasting Return Channel Satellite) [7]. Ce sera la technologie satellite de référence
retenue pour la plateforme de tests IP par satellite dont il sera question au quatrième
chapitre. La littérature ne manque pas de présentations de la norme, nous nous contenterons
ici de n’évoquer que les concepts qui nous semblent essentiels à l’appréciation de notre
travail. Notre description est axée sur les mécanismes développés par le standard afin
d’acheminer de l’IP sur satellite.
La présentation porte donc sur les caractéristiques du standard DVB-RCS avec une voie
aller DVB-S entre une Gateway et des terminaux et une voie retour RCS par satellite des
terminaux vers la Gateway. Nous abordons les spécificités de la couche physique des deux
voies de transmission, les techniques permettant d’encapsuler et de transporter des flux IP,
l’allocation et le partage des ressources sur la voie retour ainsi que certains aspects relatifs à
la signalisation y sont abordés.

III.2. La norme DVB

L’ETSI (European Telecommunication Standard Institute) a été en 1993 à l’origine du
projet DVB, une famille de spécifications de transmission numérique de la vidéo et du son en
se fondant sur le format MPEG [1] définissant à la fois les méthodes de compression et les
techniques de multiplexage. DVB fut décliné en autant de spécifications qu’il y a de média de
transmission. Les principaux standards sont le DVB-C [2] pour le câble, DVB-T [3] pour
la télévision numérique terrestre, le DVB-H [4] pour les applications multimédia pour
mobiles, le DVB-S (Digital Video Broadcasting- Satellite) pour le satellite et le DVB-SH [5]
approuvé en 2007 pour une réception portable par satellite.
La philosophie du groupe de travail DVB fut d’exploiter au mieux les technologies et les
normes existantes pour apporter des solutions à bas coût aussi bien pour les fabricants que
les usagers. DVB ce sont surtout des normes définissant la signalisation diffusée dans les
flux -tables DVB- mais aussi les techniques de codage et de modulation à appliquer à chaque
média physique de transmission.
Le DVB-S [6] fut adopté, à l’exception de quelques pays tels que les Etats-Unis, comme la
technologie de référence pour la transmission de la télévision et de la radio numérique et
utilisé par une grande majorité de diffuseurs TV et d’opérateurs satellite.
Fort de ce succès et avec la possibilité qu’a DVB de transporter des informations autres que
la voix et la vidéo, une voie de retour par satellite procurant aux terminaux la possibilité
d’émettre en plus de celle de recevoir fut explorée. Ceci a abouti à la spécification du
standard DVB-RCS [7] en 2000.

III.3. La voie Aller DVB-S

La voie Aller de la Gateway vers l’ensemble des terminaux est conforme au standard
de diffusion DVB-S. La norme regroupe les informations relatives au multiplexage des
données basées sur le format MPEG-2, les méthodes d’accès au flux ainsi que les techniques

37
de modulation et de codage canal. La première version du standard fut publiée en 1993. Elle
fut régulièrement reprise et enrichie au fur et à mesure des innovations technologiques et de
l’évolution des besoins des utilisateurs. La norme DVB-S doit son succès aux éléments
suivants :

La simplicité d’une Gateway qui centralise les données à envoyer aussi bien
l’ensemble des programmes à diffuser que la signalisation nécessaire à l’accès au
multiplex ;

Des terminaux qui s’installent aisément ;

Des conteneurs MPEG-2 à caractère générique offrant une capacité d’évolution des
contenus ;
III.3.1 La couche physique DVB-S
La chaîne de transmission du standard DVB au niveau de la couche physique est décrite ci-
dessous.

Figure III.1 Chaîne de transmission DVB

En première étape, la dispersion d’énergie permet une répartition homogène des bits.
Ensuite, la chaîne de transmission fait apparaître le code correcteur d’erreur en mode bloc,
Reed-Solomon (codage externe ou outer code) avec des tailles de bloc avant codage de 188
octets et 204 octets après. L’entrelacement a pour objectif d’étaler sur une plus longue
période de temps les rafales d’erreurs introduites par le canal. Le codage convolutif (ou
codage interne, inner code) appliqué par la suite corrige d’autres types d’erreurs et permet
d’atteindre des seuils de taux d’erreurs binaires inférieurs à 10 −10 (Quasi Error Free).
Toutefois, il introduit une forte redondance des données réduisant par la même l’efficacité
spectrale du canal. La norme prévoit le choix entre plusieurs taux de codage 1/2, 2/3,3/4,
5/6 et 7/8 dans le but de s’adapter à différentes conditions de transmissions et fournir
plusieurs débits pouvant atteindre 43 Mbit/s de débit théorique utile7. Toutefois, un seul
code doit être sélectionné ne donnant ainsi qu’une seule chaîne de transmission.
La seule modulation prévue par la norme est une modulation de phase à quatre états, QPSK
(Quadrature Phase Shift Keying) avec une réponse en fréquence en cosinus surélevé (Roll-off)
de 0,35.
Le standard DVB-S est utilisé par des systèmes de diffusion opérant en bande C et Ku moins
sensibles aux intempéries que la bande Ka. Ainsi, la norme n’envisage aucune procédure
dynamique de modification dynamique du taux de codage et de l’ordre de modulation aux
conditions de transmission. Afin d’émettre dans de bonnes conditions, les diffuseurs
prévoient une marge statique de 3 dB supplémentaires par rapport à la puissance minimale
requise.
Sur le tableau ci-dessous tiré du document [8], on note que les points de fonctionnement en
termes d’énergie par symbole par densité de bruit Es / N 0 varient de 4.5 dB pour un taux de
codage de 1/2 jusqu’à 8,4 dB pour 7/8. Cette marge est insuffisante pour un contexte de
transmission en Ka car les atténuations peuvent atteindre des valeurs plus importantes.

7 Taux de codage de 7/8 avec un transpondeur de 36 MHz et un Roll-off de 0,35

38
Aussi il est important de mentionner que la forme d’onde DVB-S ne permet pas d’assurer la
qualité de service requise pour des valeurs de Eb / N 0 inférieures à 4,5 dB.

Taux de codage Eb/No (dB) Es/No (dB)

1/2 4,5 4,5

2/3 5 5,44

1/4 5,5 6,47

5/6 6 8,2

7/8 6,4 8,82

Tableau III-1 Eb/No et Es/No requis pour un TEB de 2.10-4

III.3.2 L’accès au canal

Le système de diffusion étant unidirectionnel, les Gateways, interfaces entre les
fournisseurs de service et le réseau émettent leur signal vers l’ensemble des terminaux. La
méthode d’accès est assez simple avec une division dans le temps de l’ensemble de la bande
disponible TDM (Time Division Multiplex). La taille du multiplex dépend du nombre de
programmes à acheminer.

III.3.3 Le standard DVB-S et la norme MPEG-2

III.3.3.1 La pile protocolaire DVB-S
Le DVB-S a été conçu avec la possibilité de transporter des données autres que
l’audio et la vidéo. Ainsi lorsqu’un paquet IP, par exemple, doit être acheminé via satellite,
une entité de niveau 3 doit être présente en bordure du système pour encapsuler et
multiplexer les paquets IP en cellules MPEG-2 [1]. La pile protocolaire du standard DVB-S
dont un aperçu est fourni par la figure 3.2 montre qu’aussi bien pour le plan utilisateur que
pour le plan de contrôle et de gestion DVB-S s’appuie sur la norme MPEG-2.

Figure III.2 Pile de protocole DVB

MPEG-2 joue donc un rôle prépondérant dans DVB-S aussi bien au niveau du
traitement de données (compression, encapsulation, transmission) qu’au niveau de la
signalisation.
III.3.3.2 MPEG-2
Le choix par le groupe DVB du standard MPEG-2 pour le codage et le multiplexage
des données a été stratégique. Il fut motivé par la possibilité dont dispose MPEG-2 de
générer des images avec une qualité qui varie de studio à la haute définition mais aussi par le
fait que la norme ait été retenue par l’ISO (International Organization for Standards) et soit

39
devenue un standard pour la TV numérique des débits de 3 à 10 Mbit/s. MPEG-2 se
compose d’un ensemble de standards génériques ne pouvant pas être utilisés tels quels pour
construire des services comme ceux proposés par DVB.
Une des tâches du projet DVB fut donc de définir la manière avec laquelle le standard
MPEG-2 devra être utilisé. Cela concernait aussi bien les profils qui sont des restrictions au
niveau de la syntaxe et des valeurs de paramètres mais aussi les implémentations de services.
Connu principalement en tant que standard de compression, le standard MPEG-2 regroupe
des méthodes de multiplexage. Elles reposent essentiellement sur le découpage des flux
élémentaires ES (Elementary Stream) en trames élémentaires dites PES (Packet Elementary
Stream) [1]. Les PES sont formés des flux audio, vidéo et de données de synchronisation.
Deux méthodes de multiplexage sont proposées dans MPEG-2. L’utilisation dépend de
l’application et du support de transmission.
La première (Program Stream) est formée à partir d’un unique programme regroupant
plusieurs PES (audio, vidéo et données de synchronisation). Reposant sur des paquets de
grande taille (2048 octets par exemple), PS est privilégié pour les supports et les canaux à
faible taux d’erreurs. Il est utilisé pour le stockage des média sur disque dur, CD ou DVD.
La deuxième méthode de multiplexage de données appelée TS (Transport Stream), qui peut
en revanche combiner plusieurs programmes, nous intéresse davantage dans notre contexte.
TS est privilégié pour les supports de transmission à forte probabilité d’erreurs comme le
canal satellite. Les codes correcteurs d’erreurs mis en place sont d’autant plus efficaces que
les blocs qu’ils traitent sont petits. La trame élémentaire d’un Transport Stream est ainsi fixée
à 188 octets.
Les paquets MPEG-TS sont générés en plusieurs étapes. Dans le cas où il s’agit d’un flux
audio vidéo par exemple, ces derniers sont compressés séparément pour donner chacun de
son côté un flux constant ES. Les deux flux sont ensuite découpés en plusieurs PES en se
référant à la même base temporelle (Source Time Clock) quand il s’agit d’un même
programme. Ensuite, les PES sont multiplexés dans des paquets MPEG-TS composant le
Transport Stream, via une méthode nommée Data Streaming. Le paquet MPEG-TS se
compose d’un champ d’en-tête de 4 octets en plus de 184 octets de charge utile. Un champ
optionnel de longueur variable peut augmenter l’en-tête réduisant par ailleurs le champ de
données utiles.

Figure III.3 Structure d’un paquet MPEG-TS

La figure 3.3 détaille la structure d’un paquet MPEG-2 qui intègre dans son en-tête les
champs suivants :
- Synchronisation Byte : indique le début d’un nouveau paquet MPEG

40
 - Transport_Error_indicator indique la présence ou non d’au moins un bit erroné
et irrécupérable. Un protocole autre que la couche MPEG-TS peut indiquer
une erreur dans la chaîne de transmission.
- Payload Unit Start Indicator : indique la présence ou non du début d’un paquet
de données encapsulées dans MPEG-TS (PES, ou autre format de données).
- Transport priority : confère au paquet une priorité supérieure aux autres paquets
de même PID.
- Packet Identifier PID (13 bits) il identifie de manière unique le flux ou le canal
logique. Certaines valeurs de PID sont réservées.
- Transport Scrambling Control : utilisé par les procédures d’accès conditionnel
pour chiffrer certains paquets MPEG.
- Adaptation Field Control : indique la présence ou non du champ d’en-tête
optionnel.
- Continuity Counter : champ incrémenté à chaque nouveau paquet MPEG de
même PID.
III.3.3.3 La signalisation
Dans le but de décrire la structure de ses multiplex sur satellite, DVB-S utilise des
tables de signalisation ou de services. Elles permettent aux terminaux de recevoir, de dé-
multiplexer, d’extraire et de reconstituer les services. La signalisation DVB-S repose en
grande partie sur la signalisation MPEG-2 ou tables PSI. Ces tables sont complétées par
celles énoncées dans la norme DVB-SI [9] et spécifiques au standard, en plus d’un panel
d’autres tables envisagées par le standard notamment pour ses dérivés interactifs.
Présentées par la norme ISO-MPEG-2 [1], les tables PSI (Program Specific Information)
(figure 3.4) contiennent les informations permettant aux terminaux d’identifier et d’accéder
aux différents flux d’un multiplex. Elles sont dotées d’un PID fixes et renseignent
uniquement sur le multiplex où elles sont présentes. Certaines sont indispensables :

PAT (Program Association Table) renseigne sur les PID des PMT de chaque
programme présent dans le multiplex. Elle indique également le PID de la table NIT

PMT (Program Map Table) contient les informations relatives à un unique
programme consistant en les PID de l’ensemble des ES qui le forment en plus de la
localisation de la référence temporelle qui lui est spécifique.

NIT (Network Information Table) Son contenu et sa syntaxe ont été définis par la
norme DVB-SI même si elle est présente dans le standard MPEG-2. Elle indique
l’organisation physique des multiplex d’un réseau donné comme les transpondeurs
associés, les coordonnées orbitales du satellite…

CAT (Conditional Access Table) indique les programmes nécessitant un accès
conditionnel.

41
 Figure III.4 Les tables DVB-SI

En plus de la signalisation PSI, la norme DVB a spécifié un ensemble de tables aussi

bien à caractère obligatoire qu’optionnel [9] dans le but de fournir des informations
supplémentaires sur les multiplex. Nous éviterons de les présenter étant donné leur faible
intérêt dans le cadre de cette étude. Il faut néanmoins souligner qu’elles apportent un
caractère évolutif au standard en rendant possible l’ajout de nouvelles tables. Plus
particulièrement c’est le cas du DVB-RCS qui requiert l’adjonction de nouvelles tables de
signalisation pour fournir un service interactifs.
A titre informatif, la structure générique d’un multiplex DVB est donnée par la figure 3.5

Figure III.5 Structure générique d’un multiplex DVB

III.3.4 Les méthodes d’encapsulation de l’IP sur DVB

Le caractère ouvert de la norme DVB permet de véhiculer d’autres types de trafic
autres que les flux vidéo et audio. Elle propose en conséquence multiples méthodes
d’encapsulation (cf. figure 3.6). Elles sont au total de six [10]. Parmi elles, une méthode
privée laisse une liberté au concepteur de définir sa propre technique d’encapsulation à
condition que le conteneur final soit MPEG-TS. Cette liberté ne présente un intérêt que
dans le cas où la démarche s’inscrit dans un contexte de normalisation pouvant être
profitable à une grande échelle et non restreinte à un constructeur donné.

42
 Figure III.6 Les méthodes d’encapsulation

Dans ce qui suit on parcourt brièvement les cinq méthodes d’encapsulation. L’accès sera
cependant mis sur la technique qui permet la transmission des paquets IP.

Data Streaming : Les données à traiter sont considérées comme des flux continus à
l’exemple de la vidéo ou l’audio. Ces flux sont segmentés en PES soit en mode
synchrone en utilisant une référence de temps commune (PCR) Program Clock
Reference ou en mode asynchrone. Elle est peu adaptée aux transports de trafic IP
dans la mesure où ce dernier est plutôt de nature sporadique (bursty). Son utilisation
peut être, éventuellement, envisagée pour un flux IP à débit constant tels que la
VoIP. Cette méthode permet l’encapsulation des paquets IP selon un mode
asynchrone.

Data Piping :: elle offre un cadre générique pour les méthodes d’encapsulation
propriétaires. La seule contrainte consiste en une encapsulation des flux de données
comme s’il s’agissait de PES. Ainsi aucune méthode de fragmentation/réassemblage
ou encapsulation/dé-encapsulation n’est prévue. Ce mode sert de socle de base pour
les nouvelles alternatives à l’encapsulation de l’IP sur MPE Multi Protocol
Encapsulation) que nous verrons dans le paragraphe suivant.

Object Carroussel et Data Carroussel : techniques d’encapsulation et de
multiplexage très similaires. Elles sont utilisées pour envoyer périodiquement les
tables de programmes et reposent de fait sur des techniques de transmissions
cycliques. Pour l’encapsulation, la même structure que pour MPE est utilisée pour
ces deux méthodes, le DSM-CC (Digital Storage Media – Command and Control)
Parmi les méthodes d’encapsulation de données spécifiées par le standard, la Multi
Protocol Encapsulation se distingue comme la méthode la mieux adaptée et la plus
recommandée pour encapsuler et transmettre des paquets IP sur DVB-S.
III.3.4.1 Multi Protocol Encapsulation (MPE)
La méthode MPE [10] fournit un mécanisme d’encapsulation des paquets IP au-
dessus de MPEG2-TS dans les réseaux DVB. C’est aussi la méthode utilisée par DVB pour
encapsuler les tables de service. Le standard MPE s’appuie sur le format de section DSM-CC
décrite dans la norme MPEG-2 [1]. Au niveau de la Gateway, le paquet IP est encapsulé
dans une section privée dite section datagramme et définie par DSM-CC. Elle consiste en
l’ajout d’un en-tête de 12 octets et d’une somme de contrôle CRC de 4 octets. L’en-tête MPE
(figure 3.7) contient l’adresse MAC du terminal destination du trafic -compatible avec la

43
norme ISO/IEEE pour les LAN et WAN- même si le standard DVB ne spécifie pas la
manière dont celles-ci sont attribuées.

Figure III.7 Structure d’un en-tête MPE

La taille d’une section MPE ou section privée varie selon celle du paquet IP.
Toutefois, la taille maximale n’excède pas les 4080 octets. Il faut souligner que le standard
MPE n’effectue pas de fragmentations des paquets IP dont la taille est supérieure à la MTU.
La fragmentation devra avoir lieu en amont donc au niveau réseau. Notons que, dans la
plupart des cas, MPE opère à la frontière entre un réseau DVB-RCS et un réseau LAN ou
WAN où les paquets IP sont formatés selon la MTU Ethernet de 1500 octets.
Pour une section MPE, l’en-tête basique et le plus courant contient l’adresse MAC du
destinataire et ne mentionne pas la nature des données [13]. Ainsi la plupart des pilotes
logiciels des récepteurs supposent qu’il s’agit d’IPv4. Dans la perspective d’un passage à
IPv6, le champ d’en-tête devra explicitement indiquer le type de données. Pour ce faire, et
plus généralement pour transporter un protocole autre qu’IPv4, MPE nécessite le recours au
champ LLC/SNAP [10]. Ceci augmente par ailleurs l’overhead par l’ajout de 8 octets
supplémentaires.
Une fois les sections MPE formées, elles sont encapsulées et multiplexées dans des paquets
MPEG-TS. Deux techniques d’encapsulation sont possibles : avec ou sans bourrage. Dans le
cas où MPE opère avec bourrage, les sections sont fragmentées en autant d’MPEG-TS que
nécessaire. Dans le cas où le paquet MPEG contenant le dernier fragment de la section MPE
n’est que partiellement rempli, des octets de bourrage sont introduits pour occuper la partie
restante de la charge utile. Ceci constitue évidemment un gaspillage de bande passante bien
qu’il peut s’avérer nécessaire si des applications peu tolérantes au délai comme la VoIP sont
acheminées.
Le mode sans bourrage est appelé Section Packing. Les sections MPE sont encapsulées les
unes à la suite des autres au sein des paquets MPEG-2. Un paquet MPEG partiellement
rempli doit « attendre » l’arrivée de la section MPE suivante. Le champ PUSI de l’en-tête
obligatoire du paquet MPEG indique la présence d’une nouvelle section MPE. De plus, au
niveau de l’en-tête optionnel Adapatation Field, un champ d’1 octet (pointeur) indique
l’emplacement du début d’une nouvelle section MPE au niveau du paquet MPEG.

Figure III.8 Insertion d’un octet additionnel en en-tête en mode sans bourrage

44
 D’une manière générale et lorsque le Section Packing est utilisé, seul le champ
pointeur de 1 octet est nécessaire parmi les 4 octets de l’en-tête MPEG additionnel. Ainsi, la
plupart des encapsulateurs IP/DVB selon la méthode MPE qui se trouvent sur le marché,
prévoient seulement l’ajout de cet octet immédiatement à la suite de l’en-tête obligatoire de 4
octets. Cela réduit le champ de données à 183 octets pour le paquet en question. Il s’agit là
d’une implantation modifiée de la norme MPEG puisqu’elle rend incompatible le champ
PUSI avec le champ d’adaptation classique. Néanmoins, elle demeure la plus courante dans
les systèmes DVB-RCS intégrant MPE.

Figure III.9 Encapsulation MPE MPEG avec section packing activée

Il est également utile de mentionner que dans le cas où plusieurs sections MPE sont
présentes au sein d’un même paquet MPEG, seul le début de la première section est indiqué
par le paquet MPEG. Formulé autrement, l’en-tête MPEG ne dépassera pas les 5 octets. Il
revient au récepteur, en partant de cette indication en plus de la taille des différentes sections
DSM-CC indiquée dans l’en-tête MPE de les dé-multiplexer correctement.
Outre l’octet additionnel que le mode sans bourrage requiert au niveau des paquets MPEG,
il apporte une réelle économie en bande par rapport au mode avec bourrage tel que le montre
la figure 3.10

Figure III.10 Efficacité IP sur MPEG avec et sans Section Packing [12]

45
III.3.4.2 ULE, une alternative à MPE
L’encapsulation MPE est certes recommandée par ETSI. Cette technique demeure
tout de même « surdimensionnée » pour transporter de l’IP sur DVB. En effet, plusieurs
champs d’en-tête s’avèrent inutilisés ou inutiles. Un groupe de travail IETF a introduit en
2004 un draft détaillant une méthode d’encapsulation de l’IP alternative à MPE nommée
ULE Ultra Lightweight Encapsulation [13]. En partant de la méthode Data Piping, ULE offre
la possibilité d’encapsuler de l’IPv4 ou IPv6 en éliminant les parties inutilisées de l’en-tête
MPE. Avec un en-tête de 4 octets et une somme de contrôle de 4 octets, ULE permet
d’encapsuler des paquets des données indépendamment de leur nature (IP ou autre
protocole) directement sur MPEG-TS. Elle offre notamment des possibilités de compression
d’en-tête IP ou de multicast IP. On trouve plusieurs descriptions d’ULE dans la littérature.
On dispose également une multitude d’articles [11,14,15] démontrant la supériorité en
termes de performances d’ULE par rapport à MPE. L’avantage qu’apporte ULE par rapport
à MPE reste tout de même dépendant de plusieurs paramètres comme la taille des paquets
IP. Malgré le gain indéniable d’ULE en terme d’économie de bande passante, son adoption
par les fabricants de solutions DVB et DVB-RCS reste limitée8. L’absence jusqu’à
maintenant de RFC ou de standard est probablement l’une des raisons. Par ailleurs, et avec
l’arrivée de la nouvelle génération du standard DVB-S2 et la proposition toujours en cours
de GSE (Generic Stream Encapsulation) [16] qui omet le passage par la couche MPEG-2 et
les gains considérables en performance qu’il promet peut apporter une alternative sérieuse à
MPE et ULE.
III.3.5 La résolution des adresses
Le transport de l’IP sur satellite requière des procédés d’encapsulation afin de
l’adapter au lien satellite. De plus, il pose d’autres contraintes dont la plus notable reste la
résolution d’adresses. Il s’agit principalement de la correspondance sur le lien Aller à établir
entre les adresses MAC des terminaux et celles des réseaux IP destinations du trafic au
niveau du segment utilisateurs.
Afin de signaler la disponibilité et l’emplacement des flux IP au sein d’un multiplex TS, un
des moyens et qui fut d’ailleurs proposé par la norme DVB est la table INT (IP/MAC
Notification table). Cette méthode n’a rien d’obligatoire bien qu’elle soit recommandée. Elle a
par ailleurs été proposée après le protocole MPE. Sous la notion de flux IP, sont regroupées
les séquences de paquets IP avec la même adresse IP destination.
Toutefois, dans sa conception et conformément à la philosophie DVB, la table INT reste
générique. Elle regroupe les flux IP/MAC présents dans le multiplexe, en identifiant chacun
d’entre eux d’une manière unique ainsi que le NCC ou la Gateway qui leur correspond.
Cette technique spécifie un nombre de descripteurs permettant de gérer de l’IP au sein d’un
réseau DVB. Elle ne mentionne pas, en revanche, comment sont attribués les PIDs, ni
comment se déroule la résolution des adresses MAC, ni comment est établie cette association
entre les flux IP et les différents adresses MAC. Ceci laisse une grande marge de liberté aux
constructeurs pour des implantations propriétaires. Dans le cas d’un réseau satellite, la
résolution d’adresses se déroule suivant 3 étapes. La première consiste à établir une
association entre une adresse IP et une adresse MAC, ensuite elle est associée à un PID et
par la suite à un multiplex TS. Aucune association entre les adresses MAC et IP n’est
spécifiée et elle reste le plus souvent configurée statiquement.

8 A ce qu’on sache, seul le constructeur Newtec la propose dans les solutions d’encapsulations IP sur DVB.

46
III.4. La voie retour DVB-RCS
De multiples raisons ont motivé l’émergence du standard DVB-RCS qui spécifie une
voie retour par satellite. Le succès de la norme DVB-S et son adoption par une multitude
d’opérateurs et de diffuseurs de TV numérique, la croissance du nombre de terminaux DVB
d’une part, la variété des services IP (VoD, VoIP, Internet..) d’autre part sont parmi les
principales. Ces faits ont justifié le besoin d’apporter de l’interactivité au terminaux DVB qui
n’étaient dédiés qu’à la réception jusque là.
Il fallait, tout de même, prendre en considération de multiples contraintes. La première est le
caractère asymétrique des échanges sur Internet essentiellement pour un trafic de type
client-serveur. La deuxième concerne la non monopolisation des ressources tout en
privilégiant un accès concurrentiel à la bande passante. D’ailleurs, cette deuxième contrainte
exclut le recours au DVB-S étant donné qu’il ne spécifie aucune méthode d’accès partagé au
canal satellite.
La première approche fut de concevoir une voie de retour terrestre généralement via une
connexion modem RTC. Le standard UDLR (UniDirectional Link Routing) [18] émulait à
moindre coût cette approche. Toutefois, cette solution demeure dépendante d’une
infrastructure terrestre et elle écarte certains cas d’utilisation (plate forme pétrolière en
haute mer, sinistres..) où un recours exclusif au satellite est nécessaire.
Le groupe DVB a standardisé en 2000 la spécification détaillant une voie retour par satellite
avec un accès partagé à la bande. Couplée à une voie aller DVB-S au sein d’une architecture
en étoile, la norme permet via un accès partagé à la bande sur la voie retour d’introduire
l’interactivité requise pour un réseau IP par satellite.
III.4.1 Pile protocolaire
Deux piles protocolaires subsistent en DVB-RCS. Elles dépendent de la méthode
utilisée pour l’encapsulation des paquets IP avant leur transmission à la couche physique. La
première méthode, obligatoire dans le standard, repose sur la couche d’adaptation AAL-5
(ATM Adaptation Layer) pour contenir les paquets IP avant une encapsulation dans des
cellules ATM (48 octets de données et 5 octets d’en-tête). La deuxième proposée en option
dans le standard implante la même méthode que DVB-S, une encapsulation MPE avant un
multiplexage MPEG-TS (cf. figure 3.11).

Figure III.11 Pile protocolaire DVB-RCS

III.4.2 La couche physique

A l’instar des systèmes MF-TDMA (Multi Frequency - Time Division Multiplex) aussi
bien les données que la signalisation sur la voie retour DVB-RCS sont formatés en tranches
temporaires ou Time Slot comprenant des bursts spécifiques à chaque type de contenu.

47
 Figure III.12 Chaîne de transmission DVB-RCS

Tel que décrit par la figure 3.12, les bursts ainsi formés subissent un embrouillage pour
la dispersion de l’énergie avant de passer par un code correcteur d’erreur. A ce niveau la
norme DVB-RCS prévoit deux schémas de codage canal. Le premier est identique à celui
utilisé en DVB-S c’est-à-dire une concaténation d’un code Reed Solomon et un code
convolutif avec les mêmes taux. Le deuxième schéma consiste en un codage turbo. Il s’agit
en fait d’un TCC (Tubo Convolutional Code). Découvert il y a environ une quinzaine d’années
par Claude Berrou [17], l’un des avantages des turbos codes est qu’il requière pour un même
taux de perte de paquets moins d’énergie par bit d’information Eb/No. Le standard [7]
fournit les valeurs que doit prendre ce dernier paramètre pour un codage canal donné et un
taux de perte de paquet spécifié. Toutefois, le fait que le DVB-RCS soit un standard ouvert,
ces valeurs ne cessent de s’améliorer. Seule la modulation QPSK est proposée par la norme
avec un coefficient d’occupation de bande ou Roll-off de 0,35
III.4.3 Accès et Allocation des ressources
III.4.3.1 Méthode d’accès
Contrairement au DVB-S où un nombre réduit de stations terrestres (une seule)
diffusent un flux d’informations vers l’ensemble des terminaux, la norme DVB-RCS a été
conçue afin de permettre à un grand nombre de terminaux d’avoir accès au canal satellite et
d’émettre sur la voie retour. En conséquence, une décomposition de la bande en temps et en
fréquence selon la technique MF-TDMA (Multi Frequency Time Division Multiple Access) a été
adoptée par le standard. Outre le fait qu’un nombre important de terminaux peut émettre en
accédant à l’une des multiples porteuses retour, ce mode assure une bonne efficacité
spectrale.
Les terminaux, utilisent les tranches temporelles ou Time slots afin d’émettre leur bursts qui
peuvent contenir aussi bien de la signalisation que du trafic de données. A ce titre quatre
types de bursts sont proposés par le standard.

Le burst CSC (Common Signallling Channel) est le burst de logon utilisé par le terminal
pour s’identifier auprès de la Gateway ou plus exactement le NCC (Network Control
Center). Il comprend plusieurs informations concernant le terminal comme l’adresse
MAC, l’aptitude à modifier dynamiquement sa porteuse (Frequency Hopping)…

Le burst ACQ (Acquisition Burst) est utilisé pour des besoins de synchronisation en
amont de la phase opérationnelle du réseau. Il est peu implanté dans les systèmes
déployés. Ceux-ci s’appuient pour la plupart d’entre eux sur le burst SYNC pour la
synchronisation et les échanges de signalisation.

Le burst SYNC est envoyé périodiquement par le terminal afin de maintenir la
synchronisation une fois connecté au réseau. Il contient également des informations
sur la fréquence d’émission et la référence temporelle. Ces données serviront à la
Gateway de notifier le terminal les corrections à effectuer. Un des champs du burst
SYNC est utilisé pour transmettre les requêtes de capacité des terminaux vers la
Gateway.

48

Le burst TRF (Traffic Burst) contient les données utiles. Sa structure dépend du
mode d’encapsulation adopté (AAL/ATM ou MPE/MPEG). La norme spécifie la
possibilité de transporter 1, 2 ou 4 cellules ATM (48 octets utiles et 5 octets d’en-
tête) ou 1 TS MPEG-2 (184 octets utiles et 4 octets d’en-tête) par burst de données.
III.4.3.2 Répartition de bande sur la voie Retour
Sur le lien retour, les ressources disponibles sont gérées d’une manière centralisée par
la Gateway et plus particulièrement le gestionnaire de bande passante. Elles sont attribuées
selon un modèle qui suit une hiérarchie logique: super-trame, trame et Time Slot.
Les Time Slots constituent l’unité la plus élémentaire d’allocation et consistent en des
tranches temporelles dédiées chacune à un type d’information (données ou signalisation). Ils
sont définis par leur nature (TRF, CSC, SYNC), leur fréquence, leur bande passante, leur
temps de début et de fin. Les bursts, diffèrent principalement par leur taux de codage et par
conséquent par leur débit symbole ou par leur durée, le schéma de modulation étant unique
Les Times Slots sont regroupés en trames qui elles même sont organisées en super-trames.
Les trames constituent un niveau intermédiaire introduit par le standard pour simplifier la
gestion de la signalisation sur le lien aller DVB-S. Une trame est typiquement un ensemble
de Time Slots de nature différente (CSC, SYN, TRF).
Une super-trame peut être vue comme l’ensemble des ressources disponibles pour un
groupe de terminaux (un réseau) sur le lien retour. Plusieurs super-trames peuvent être
définies pour un réseau donné avec chacune sa propre répartition de trames et de times slots.
Chaque super-trame peut servir à un profil ou à un contexte d’utilisation donné. Elles
diffèrent essentiellement mais pas nécessairement par leur durée mais aussi par la
distribution des bursts qu’elles peuvent contenir.

Figure III.13 Trame, super-trame et Time slots

La super-trame est diffusée périodiquement à l’ensemble des terminaux. Sa durée

détermine la fréquence d’allocation de ressources pour un réseau donné. Aucune valeur
référence n’a été mentionnée par la norme. Cette durée dépend notamment du schéma
d’encapsulation sur la voie retour (ATM ou MPEG). Elle peut varier de 26,5 ms pour un
profil ATM à 120 ms pour un profil MPEG. Les constructeurs sont libres du choix de la
durée de la super-trame mais doivent tout de même trouver un compromis entre une bonne
périodicité d’allocation et une charge CPU « raisonnable » au niveau de la Gateway. La
structure de la super-trame est diffusée périodiquement à l’ensemble de terminaux.
La super-trame décrit dans les détails la distribution et la nature des bursts sur sa durée
temporelle et ce pour l’ensemble des terminaux qui forment le réseau satellite. Le standard
DVB-RCS propose deux modes de partage MF-TDMA. Le premier est statique. Le
deuxième, optionnel, est dynamique. Le premier mode utilise la même configuration MF-
TDMA trame par trame où la bande passante et la durée du time slot sont fixes. La
définition d’une nouvelle super trame est nécessaire pour changer la structure des times

49
slots. Avec le deuxième mode, la durée et la bande passante par time slots alloués à un
terminal peuvent varier au sein de la même super-trame. Dans un contexte à ordre de
modulation unique QPSK sur la voie retour RCS, changer de bande passante revient à
changer de taux de codage pour un time slot donné.
Ainsi pour le terminal, en plus de s’adapter au changement de la fréquence porteuse et à la
durée des Time-Slots, peut également être amené à modifier son débit de transmission et son
taux de codage d’un burst à un autre. Ce mode permet d’adapter au mieux les caractéristiques
des Time-slots aux divers profils de trafic multimédia ainsi qu’aux conditions de
propagation. Cependant cette flexibilité accrue se fait au détriment des temps d’accès au
support et demande des capacités de calcul supplémentaires de la part du NCC et des
terminaux.
III.4.3.3 La signalisation sur la voie retour
Le standard DVB-RCS spécifie un ensemble de tables et de messages qui vient
compléter la signalisation DVB-SI et MPEG PSI déjà utilisées par la norme DVB. Elles sont
principalement destinées à gérer les connexions et les déconnexions des terminaux, la
synchronisation temporelle ainsi que la demande et l’allocation de ressources aussi bien
dynamique que statique. Ces tables suivent aussi le schéma d’encapsulation MPE-MPEG2.
La figure 3.14 décrit l’architecture protocolaire du plan de contrôle.

Figure III.14 Pile protocolaire signalisation DVB-RCS

En plus des tables PAT, PMT et NIT propres à un flux DVB, la table SPT (Satellite
Position Table) donne la description du ou des satellites par lesquels transitent les flux
bidirectionnels. La table RMT (RCS Map Table) diffusée par la Gateway au sein du
multiplex permet de distinguer le réseau interactif DVB-RCS par rapport à l’ensemble des
autres réseaux recevant d’autres flux DVB. Elle a la même syntaxe que la table NIT décrite
ci-dessus mais envoyée sera un PID différent. Elle contient des pointeurs vers l’ensemble des
tables en relation avec le réseau interactif. Parmi ces tables on distingue essentiellement les
tables SCT, FCT, TCT qui décrivent respectivement

la répartition, le positionnement, le nombre et les identificateurs des super-trames
pour l’ensemble du réseau interactif DVB-RCS.

la description des différentes trames, durée, répartition et nombre des times slots au
sein des trames.

les types de slots ainsi que leurs paramètres de transmission. [7]
A cette description de la structure des ressources allouées s’ajoute une correspondance entre
les terminaux et les times slots attribués. C’est le rôle de la table TBTP (Terminal Burst Time
Plan) diffusée par la Gateway à l’ensemble des terminaux ou un groupe de terminaux au sein
du réseau interactif, chacun identifié d’une manière unique. Cette table indique le nombre, le
type et le nombre de time slots alloués individuellement à chaque terminal.
Aux fonctions d’allocation de ressources, s’ajoutent notamment le contrôle des
terminaux et le maintien de la synchronisation. C’est par ailleurs le rôle de la table CMT
(Correction Message Table) qui envoie des corrections périodiques en temps et en fréquences
aux terminaux. Les messages TIM (Terminal Information Message) sont envoyés à un ou

50
plusieurs terminaux. Ils peuvent contenir des informations diverses, comme la réponse à une
demande de connexion, les identifiants d’un terminal, des attributions de time-slots pour un
court temps, des informations sur le réseau…
Pour les besoins de synchronisation, les paquets PCR (Packet Insertion Clock Reference)
contiennent la NCR (Network Clock reference), la référence de temps permettant aux
terminaux de générer leur propre horloge locale et de la synchroniser avec la Gateway afin
de réduire les collisions entre bursts alloués.
La signalisation DVB-RCS spécifie notamment la manière avec laquelle les requêtes de
ressources dynamiques doivent être effectuées par le terminal. Les méthodes reposent sur le
descripteur SAC (Satellite Access Control) pouvant être contenu dans un burst SYNC, les en-
têtes des MPEG ou ATM des bursts de données , ou même des mini-slots alloués par la
Gateway pour les besoins de synchronisation et de contrôle. C’est le premier conteneur qui
est généralement privilégié, le burst SYNC. Les requêtes adressées à la Gateway spécifient la
catégorie de la ressource dynamique, la quantité en volume ou en débit ainsi que
l’identification du terminal qui en bénéficiera.
La figure 3.15 [7] décrit les échanges de signalisation à la connexion du terminal et pendant
La durée de session.

Figure III.15 Echanges de signalisation dans une session DVB-RCS

III.4.3.4 Catégories de ressources radio

En plus des schémas d’encapsulation et la signalisation nécessaire pour gérer un
réseau interactif par satellite, la norme DVB-RCS spécifie les différents types de ressources
radio dont peut disposer un terminal sur la voie retour. Deux mécanismes régissent ces
ressources. La fonction CAC garantit dans la mesure du possible l’accès à la bande en
réservant au fur et à mesure de la progression de la session du terminal la bande passante
nécessaire. La fonction DAMA, quant à elle, se charge de l’attribution effective des
ressources aux terminaux.
Le standard DVB-RCS ne donne pas de description de ces fonctions ni de la manière avec
laquelle elles doivent être implémentée. Toutefois, les deux stratégies statique et dynamique

51
d’allocation de bande passante sont décrites dans la spécification. A ce titre cinq catégories
de capacités radio sont définies par la norme :

CRA (Constant Rate Assignment) en représente la catégorie statique. C’est une
ressource réservée, à débit garanti et disponible immédiatement après la connexion
du terminal et pendant toute la durée de la connexion selon un contrat de service
préalable entre le terminal et la Gateway. Elle est disponible en cas de présence ou
non de trafic. Par définition, CRA est adaptée aux applications à fortes contraintes de
délai et de gigue.
Les capacités dynamiques peuvent, en revanche, être allouées soit en volume soit en débit et
elles sont justement définies selon ce critère.

RBDC (Rate Based Dynamic Capacity) comme son nom l’indique, est une ressource à
débit garanti, devant toutefois faire l’objet d’une requête explicite par le terminal.
RBDC est garanti à la hauteur d’un débit maximal défini par l’opérateur. C’est
également une ressource adaptée aux applications à fortes contraintes temporelles.

VBDC (Volume Based Dynamic Capacity) C’est de la bande qui est allouée en fonction
d’un volume de trafic à écouler et dont la demande a été émise par le terminal. Etant
exprimées en volume, les demandes en ressources peuvent être cumulées. AVBDC
(Absolute Volume Based Capacity) en est la variante non cumulative.
Le standard offre également la possibilité d’allouer aux terminaux les ressources radios non
utilisées. Ainsi FCA (Free Capacity Assignment) est une ressource distribuée par la Gateway
en cas d’excédent de bande passante et sans qu’aucune demande ne soit nécessaire. Toutefois,
DVB-RCS ne mentionne pas la manière avec laquelle cette ressource devrait être allouée.

III.5. Conclusion
La norme DVB-RCS définit une voie retour par satellite. Elle est l’une des technologies
les plus adaptées à transmettre de l’IP bidirectionnel par satellite. Nous en avons présenté
dans ce chapitre les aspects qui nous paraissaient les plus pertinents et les plus utiles à la
compréhension de la suite de notre étude. Cela concerne aussi bien les caractéristiques de la
couche physique, les méthodes d’encapsulation des paquets IP en passant par la signalisation
ou la gestion et l’allocation de la bande passante.
Le chapitre suivant aura pour objet l’évaluation expérimentale d’une plateforme de tests
implantant la technologie DVB-RCS. Ce sera le moyen d’apprécier la pertinence du recours
au DVB-RCS comme support des flux IP ainsi que les performances qu’on peut attendre d’un
tel choix technologique.

52
IV. La plateforme IP DVB-RCS, architecture et
expérimentations

IV.1. Introduction
Nous avons décrit dans les chapitres précédents, les concepts de base caractérisant les
réseaux bidirectionnels par satellite. Nous avons notamment présenté le standard DVB-RCS
devenu l’une des références pour le support de l’IP par satellite.
Ceci va donc nous permettre d’introduire la plateforme IP DVB-RCS. Il s’agit d’un réseau
démonstratif pour la transmission de l’IP bidirectionnel par satellite et reposant sur le
standard. Ainsi, l’objectif premier du présent chapitre est d’exposer l’architecture ainsi que
les principales caractéristiques de la plate forme IP DVB-RCS. Nous présentons, par la suite,
les différentes expérimentations que nous avons mises en œuvre suivies par notre analyse et
notre interprétation des résultats. Ces tests consistent en l’observation du comportement de
multiples applications IP (VoIP, HTTP, transferts de fichiers..) au sein d’un réseau DVB-
RCS.
Le but est d’évaluer les performances de ces applications. Ceci nous permettra
d’effectuer les adaptations nécessaires portant autant sur la configuration que sur le
dimensionnement du système dans le but d’améliorer les performances. Ces propositions
prennent en considération plusieurs paramètres tels que le niveau de service que s’est fixé
l’opérateur ou les niveaux de priorités qu’il souhaite accorder à ses applications respectives.
Ces exigences se traduisent au niveau technique par un éventail de possibilités dont dispose
l’opérateur en termes de stratégie d’allocation de bande passante (statique et dynamique), et
de niveau de qualité de service compte tenu des exigences de chaque application.
L’intérêt de la démarche réside dans son approche globale. En effet, en partant de
technologies dont l’efficacité a été démontrée, et par l’intermédiaire des solutions
industrielles qui les implantent on tend à atteindre deux objectifs. Le premier est d’apprécier
le niveau de performances offert par ces technologies (DVB-RCS, Accélération TCP,
Chiffrement IPsec..) quand elles sont intégrées au sein d’un système global à l’instar de la
plateforme IP DVB-RCS. Le deuxième objectif est de déceler les écarts qu’il y a entre la
norme et ses implantations industrielles tant sur les choix techniques des industriels, que sur
la mise en œuvre pratique des fonctions logiques (BoD, DAMA.). Nous essayons d’apprécier
l’impact potentiel de cet écart sur les performances.
Notons que ce travail représente, une part importante de notre contribution qui va de
la spécification de la plateforme IP DVB-RCS jusqu’à l’intégration, et finalement les
expérimentations et les résultats.

IV.2. La plateforme IP DVB-RCS

IV.2.1 Introduction
Depuis quelques années, nous assistons à la croissance de la demande de solutions
réseaux IP bidirectionnels par satellite. Ce besoin a été alimenté par le caractère
incontournable qu’ont acquis les technologies de l’information de communication en
parallèle à l’avènement de technologies IP par satellite pérennes et fiables, le DVB-RCS en
particulier.
En tant, qu’acteur incontournable de l’industrie satellite et intégrateur de solutions
VSAT, un des objectifs stratégiques d’EADS Astrium consistait à pouvoir fournir des
solutions réseaux multimédia large bande par satellite. Les clients potentiels vers lesquels

53
ces solutions se destinent sont surtout des acteurs de l’industrie pétrolière, les agences de
presse, des clients institutionnels tels que les Nations Unis …
Le DVB-RCS en tant que nouveau standard VSAT est, depuis quelques années déjà,
l’objet de multiples projets de recherche et de développement au sein de l’entreprise. On peut
citer Web ou Arethuse [1] à titre d’exemple. Ces expériences ont été le moyen d’étudier la
norme et développer les compétences techniques autour. Ce fut aussi la phase de préparation
au développement des moyens permettant d’intégrer et d’opérer des réseaux DVB-RCS pour
la transmission des applications IP (Internet, e-mail, VoIP...)
Ce travail a eu lieu dans le cadre du projet DVB export. La première étape était de
définir l’architecture et les caractéristiques d’une solution réseau IP DVB-RCS pour des
services voix et de données IP.
Ensuite, et en fonction de cette spécification, il fallait sélectionner les solutions
industrielles qui implantent les différentes technologies à intégrer au système c'est-à-dire :
DVB-RCS, VoIP, chiffrement IPsec...
IV.2.2 Principaux critères de spécification
Bâtie autour de la technologie DVB-RCS, le rôle principal du réseau IP DVB-RCS est de
servir de support démonstratif pour les services voix et data bidirectionnels par satellite.
Nous l’avons donc défini autour des critères suivants :

Fournir un accès bidirectionnel IP avec les différents types d’applications pouvant
être acheminées (Internet, LAN-to-LAN, email, transferts FTP…) et la possibilité
d’établir des niveaux de priorités entre les différents trafics.

Disposer d’une solution VoIP dont la mise en œuvre prend en considération les
caractéristiques du support physique de transmission par satellite avec un échange
minimal de signalisation. Elle doit permettre un large choix de codecs afin d’en
sélectionner à l’issue des tests ceux offrant les meilleures performances.

Etant donné qu’une part importante du trafic (http, FTP, email…) repose sur TCP
comme protocole de transport, une solution d’accélération TCP est nécessaire afin
d’atténuer les dégradations des performances du protocole sur un lien satellite. Des
PEPs et des accélérateurs TCP implantant des mécanismes tels que ceux décrits dans
le chapitre II (taille de fenêtre, spoofing..) ont été intégrés au réseau.

La solution est destinée à des clients professionnels. Par conséquent, la protection des
données revêt un intérêt non négligeable. Une piste d’étude fut non seulement de
trouver la solution permettant de chiffrer les données simultanément à une
accélération TCP mais surtout d’étudier l’impact potentiel du chiffrement sur la
qualité du service au sens général en terme de délai, de surcoût en encapsulation et
donc en bande passante.
A l’ensemble de ces critères s’ajoute une contrainte « système » côté Hub, propre au contexte
du projet de l’entreprise. On disposait déjà de l’ensemble des équipements pouvant implanter
un lien DVB-S (Aller). La démarche consistait donc à acquérir une solution DVB-RCS
suffisamment modulaire de sorte qu’on puisse doter d’une voie Retour RCS, notre lien DVB-
S existant.
Dans ce qui suit, nous présentons les multiples sous-systèmes composant le réseau
démonstratif IP DVB-RCS. Cela va de la technologie DVB-RCS, à la solution VoIP en
passant par l’accélération TCP et le chiffrement. Nous tentons aussi de montrer clairement
les différents liens et interdépendances entre ces sous-systèmes.

54
IV.2.3 Architecture générale de la plate forme IP DVB-RCS.
Le réseau démonstratif IP DVB-RCS suit une topologie en étoile avec une Gateway
comprenant plusieurs sous-systèmes et un nombre de terminaux ou plus généralement des
segments utilisateurs intégrant plusieurs composants (terminaux satellite, module
d’accélération TCP, téléphones IP...)
La Gateway joue à ce titre un double rôle. D’une part, elle assure des fonctions de contrôle
d’accès au réseau satellite, de gestion et d’allocation de bande passante en plus de la
synchronisation temporelle. D’autre part, elle centralise les interfaces de liaisons avec les
réseaux externes de téléphonie et d’Internet.
Les terminaux forment à leur tour le point d’accès pour les utilisateurs finaux (LAN
terrestres) au réseau satellite et par conséquent aux services qui y transitent (accès Internet,
VoIP …). Ils constituent également le point de départ de l’ensemble des requêtes de bande
passante vers le Hub.
Remarque
Pour le réseau IP DVB-RCS, un simulateur en bande L simule le lien satellite. Par
conséquent, les aspects relatifs à la radio fréquence ainsi que les équipements qui leur sont
associés (LNB, BUC, antennes …) ne seront pas abordés dans cette description.
Conformément au standard, une porteuse DVB-S est diffusée sur la voie Aller de la
Gateway vers les terminaux. Sur la voie Retour, un nombre de porteuses (qui peut varier)
selon le schéma MF-TDMA permet aux terminaux d’accéder au lien satellite. Les deux
directions du trafic assurent la connectivité IP bidirectionnelle par satellite entre les
différents LAN connectés aux multiples terminaux et les réseaux terrestres (Internet et
téléphonie) accessibles à travers la Gateway.
Le système supporte tous les services à base d’IP tels que HTTP, FTP, VoIP, Vidéo
streaming... et plus largement tout type de protocole au-dessus d’IP. Il intègre également les
mécanismes essentiels Diffserv permettant d’adapter la qualité de service en fonction des
besoins spécifiques des applications. Cet aspect sera traité davantage dans la suite du
chapitre.
L’architecture suit le schéma classique d’un réseau en étoile (cf. figure 4.1). Pour la décrire
nous reprenons la terminologie utilisée au chapitre II et elle consiste en:
- Le segment opérateur ou Gateway ou NCC (Network Control Center). Sa définition
regroupe l’ensemble des systèmes qui y sont situés (VoIP, PEP9,..) et elle n’est pas restreinte
aux seuls composants du réseau satellite.

La Gateway DVB-RCS et NCC ;

Le PABX (Private Automatic Branch eXchange) VoIP ainsi qu’une interface vers le
réseau de téléphonie GSM/PSTN ;

Le module de chiffrement des flux IP et d’accélération TCP. ;

Les interfaces avec les réseaux internet et téléphonique.

- Le segment spatial, simulé par un ECP (Emulateur de Canaux de Propagation) en bande

L (1-2 GHz)

9 Pour des raisons de simplicité de langage, on appellera PEP l’équipement responsable du chiffrement IPsec et

de l’accélération TCP.

55
- Le segment utilisateur pour la plateforme de tests, le nombre de terminaux varie entre 2
et 4. Chaque segment utilisateur comprend

Un terminal DVB-RCS ou RCST (Return Channel Satellite Terminal).

Un module d’accélération TCP et de chiffrement des flux IP par IPsec.

Un LAN utilisateur avec un nombre de PCs, de téléphones et de Soft phones IP.

DVB-S
DVB-RCS
Video Decoder

RCST

Internet

LAN
RCST
Video
Source
HUB

Figure IV.1 architecture globale du réseau IP DVB-RCS

Remarque
Afin que la plateforme IP DVB-RCS soit représentative, un minimum d’une Gateway
et de deux terminaux est suffisant. Le nombre de terminaux varie entre deux et quatre selon
les besoins en configuration pour les tests.
IV.2.3.1 Le segment utilisateur
Le segment utilisateur est composé d’un LAN local connecté au réseau satellite par
l’intermédiaire du terminal RCST. Le réseau local comprend un ensemble de PCs, de
téléphones et de soft phones IP pouvant avoir accès au réseau Internet via les liens satellites.
Les LANs situés au niveau des différents segments satellite peuvent notamment
communiquer entre eux même si un double bond satellite est, alors, nécessaire.
Dans le cas où le module d’accélération TCP et de chiffrement est présent, il joue dès
lors un rôle de routeur d’accès pour le trafic montant. En l’absence de ce module, ce rôle
incombe au terminal satellite RCST. Il attribue des niveaux de priorité aux flux IP sur la
voie retour et les traitent en fonction. En présence du module PEP, et dans les deux
directions du flux, le rôle du RCST se restreint à l’encapsulation ou à la dé-encapsulation
MPE/MPEG des paquets IP chiffrés qu’il reçoit.
L’interface air du RCST est directement connectée au simulateur satellite. Sur le lien Retour,
le terminal transmet un signal codé et modulé en bande L (1-2 GHz). Sur le lien Aller, où le
terminal est en réception, il démodule et décode le signal en bande L reçu du simulateur.

Figure IV.2 Architecture du segment utilisateur

56
IV.2.3.2 Le segment satellite
Le segment satellite est simulé par un Emulateur de Canaux de Propagation (ECP)
opérant dans la bande L (1-2 GHz). Son rôle principal est d’introduire un délai satellite fixe -
mais configurable- de l’ordre de 250 ms sur chaque direction de trafic afin d’aboutir à RTT
(Round Trip Time) de 500 ms.
IV.2.3.3 Architecture du segment opérateur
Tel que nous l’avons mentionné ci-dessus, le segment opérateur se compose de :

Une Gateway DVB-RCS et NCC ;

Un PABX VoIP avec une interface vers le réseau de téléphonie GSM/PSTN ;

Un module de chiffrement des paquets IP et d’accélération TCP placé en
coupure pour les flux entrants et sortant du réseau satellite;
Un routeur centralise les raccordements vers l’ensemble des sous-réseaux IP des différents
sous-systèmes en plus d’une connexion vers le réseau Internet.
PSTN

VoIP
PABX Forward Link Subsytem
DVB-S
P
Signalling

E Timing & Sync Channel Simulator

Internet P
Router
Return Link Subsytem
DVB-RCS

NCC Control & Supervision

Figure IV.3 Architecture du segment opérateur

IV.[Link] Le Système DVB-RCS

De part son rôle important, il constitue la partie centrale du réseau. Il se charge de la
transmission dans les deux directions du trafic de la totalité des flux IP transitant par le
réseau satellite. Il est composé de quatre parties principales. Cette décomposition reste tout
de même schématique étant données les fortes corrélations et interdépendances entre les
différentes parties.

IV.[Link].1 Le sous système Aller ou Forward,

Le sous-système Aller (ou Forward), décrit par la figure 4.4, implante un lien DVB-S et
comprend :

Un encapsulateur IP/DVB chargé de transformer les flux IP reçus en flux
MPEG2-TS conformément au schéma MPE MPEG ;

Un multiplexeur MPEG dont le rôle est de multiplexer les tables de signalisation
DVB-S/RCS, le flux MPEG des données et la référence temporelle PCR. (Packet
Clock Rate) ;

57

Un modulateur DVB chargé d’appliquer le code correcteur d’erreur (Reed Solomon et
convolutif) et de moduler le signal –voie Aller- en QPSK avant de l’émettre en bande
L vers le simulateur du segment satellite.

Figure IV.4 le sous système Forward ou Aller (DVB-S)

IV.[Link].2 Le sous système Retour ou Return

Au sous-système Retour (ou Return) incombe le rôle de recevoir le signal montant –voie
Retour- en bande L à la sortie du simulateur. Ainsi le signal et plus particulièrement les
bursts, sont extraits et les cellules MPEG restitués. Ce sous-système est également en charge
de générer l’ensemble des tables de signalisation à expédier au multiplexeur. Il comprend

Le RLSS (Return Link SubSystem) est en charge de démoduler, décoder et de dé-

encapsuler le signal des différentes porteuses sur le lien retour. Le signal montant est
constitué de bursts de signalisation et de bursts de données. Les paquets IP sont
restitués à partir de ces derniers et expédiés vers le PEP ou vers le routeur (en cas
d’absence d’accélération et de chiffrement). La capacité de traitement de l’équipement
est limitée par le débit maximal global (la somme des débits des porteuses Retour), le
nombre de paquets par secondes PPS (Packets Per Second) ainsi que le nombre de
porteuses.

Le NCR Inserter est l’équipement en charge de générer la référence temporelle

NCR. Elle est diffusée à l’ensemble des terminaux sous forme de paquets PCR. La
NCR est asservie à une référence 10 MHz externe diffusée par le sous-système de
synchronisation. Cet équipement s’occupe notamment d’expédier au multiplexeur les
tables DVB-SI et RCS générées par le NCC. Les délais de traitement du multiplexeur
MPEG et du modulateur DVB sont pré-compensés par le NCR Inserter afin d’éviter
une dérive de l’horloge.

Le NCC (Network Control Center) est la partie « intelligente » de la Gateway

DVB-RCS. C’est également une partie propre au constructeur dont l’implantation
architecturale, logicielle et matérielle est laissée au libre choix du concepteur du
système. Elle est composée de 3 serveurs.
o Le premier serveur sert de base de données. On y stocke les comptes
utilisateurs (nombre, profils, description..) ainsi que les paramètres de
configuration du réseau.
o Le deuxième serveur implante les fonctions intelligentes du système
regroupant la gestion des accès, la fonction CAC, l’algorithme d’allocation de

58
 bande passante DAMA et le contrôle du lien. Il est également responsable de
gérer les tables DVB-S/RCS qu’il transmet par la suite au NCR Inserter.
o Le troisième serveur fournit une interface de configuration aussi bien pour le
réseau (terminaux, paramètres du satellite, débits, porteuses retour, time slot,
trames, super trames..) que pour la pré-configuration des tables de
signalisation (délai de transmission, position du satellite..). Il interagit en
permanence avec le premier serveur qui stocke l’ensemble de ces
modifications.
Remarque
Dans la suite du document, nous réservons la terminologie paquets aux datagrammes IP et
par analogie avec ATM, nous appelons cellules les PDU MPEG.

IV.[Link].3 Le sous-système de référence temps et fréquence,

Ce sous-système consiste en un générateur temps et fréquence GPS. Il a pour rôle de

fournir la référence de temps, base nécessaire pour générer la NCR. Il sert également à
fournir une source temporelle unique pour l’ensemble des serveurs et des équipements du
Hub. Il génère aussi une référence en fréquence. C’est en se référant à cette base que le NCC
peut évaluer les écarts en fréquence des terminaux avant de notifier les corrections à
effectuer.
La figure 4.5 donne l’architecture détaillée de la Gateway DVB-RCS avec le lien
DVB-S (Aller) y compris leurs différents composants. Tel que nous l’avons mentionné plus
haut, nous disposions déjà d’un lien DVB-S (Aller). Afin d’utiliser le maximum
d’équipements et pour des raisons évidentes de coût, il fallait trouver, côté Hub, la solution
DVB-RCS qui nous permet d’intégrer le lien Retour au segment Aller déjà à notre
disposition. Le choix s’est donc porté sur cette solution modulaire. Elle a l’avantage de
séparer physiquement les deux liens de la transmission (Aller et Retour) et rend, par la
même, envisageable, l’idée de doter d’une voie Retour RCS un système DVB-S déjà existant.
Notons que la plupart des solutions industrielles sont beaucoup plus compactes. Tous les
composants d’un Hub DVB-RCS se répartissent sur un nombre limité d’équipements. Ceci
empêche une distinction claire d’un point de vue matériel entre lien Aller et lien Retour. La
phase d’intégration du système DVB-RCS consistait davantage en une mise à jour d’un
réseau DVB-S en un réseau bidirectionnel DVB-RCS.

Remarque:
L’architecture du Hub DVB-RCS décrite ci-dessous est une implantation industrielle
possible du standard. En effet, ce sera aussi l’un des résultats de nos expérimentations, la
norme laisse certaines marges de liberté autant sur les choix techniques que sur les
implantations algorithmiques (BoD, DAMA..). Nous notons, à titre d’exemple, qu’une
référence temps et fréquence GPS tel que c’est le cas ici n’est pas imposée par le standard.
IV.2.4 Fonctionnement du système DVB-RCS
Cette partie fournit un descriptif succinct du mode de fonctionnement du Hub DVB-
RCS. Bien qu’il soit compatible avec le standard, ce fonctionnement reste dépendant de
certains choix systèmes que nous avons effectués et que nous tenterons de développer quand
ce sera nécessaire en raison du caractère modulaire du Hub considéré. C’est pour cela que
nous jugeons utile d’exposer la manière avec laquelle le système DVB-RCS fonctionne.

59
IV.2.4.1 Lien Aller DVB-S
Sur le lien Aller, les flux IP proviennent d’Internet, du PABX VoIP mais aussi du
sous-système Retour dans le cas d’un trafic entre deux terminaux. La destination par défaut
de ces flux est la passerelle IP/DVB ou l’encapsulateur IP/DVB. A la sortie de cet
équipement, un seul flux MPEG-TS est généré. Il constituera avec la signalisation, la
porteuse DVB-S. Un PID unique (PID données) est attribué à tous les paquets MPEG-TS
composant le flux. Ce sera le PID trafic que tous les terminaux doivent « écouter ». Il est
spécifié par l’opérateur du réseau et spécifié dans le NCC également.
C’est notamment au niveau de la passerelle IP/DVB, qu’une association statique
entre les adresses IP des différents réseaux locaux, les adresses MAC des terminaux qui leur
sont associés et le/les PID trafic (données), est établie. D’une manière schématique, pour
router les paquets sur le lien Aller, la passerelle IP/DVB joue un rôle de routeur d’accès
dans ce cas. Elle détermine l’adresse MAC du terminal correspondant à une adresse IP
destination en consultant le fichier des associations statiques. Elle procède par la suite à
l’encapsulation MPE MPEG. Notons, au passage, que le système DVB-RCS en question n’a
pas recours à la table INT (IP/DVB Notification Table). L’adressage et le routage DVB
s’appuie sur des associations statiques définies par l’opérateur du réseau.
C’est aussi au niveau de la passerelle IP/DVB que le débit MAC maximal que peut
atteindre la porteuse est spécifié. Etant, un équipement DVB, il est possible d’y configurer
les tables PSI et DVB-SI en particulier les tables PAT, PMT, NIT10 et SDT. Cette dernière
n’est pas très utile dans notre cas, le segment satellite étant simulé. Toutefois, ces tables sont
générées par le NCC DVB-RCS en plus de la signalisation RCS. Le but est d’avoir des tables
de signalisation cohérentes avec un même formatage, celui attendu par les terminaux.

Figure IV.5 Architecture du Hub DVB-RCS

Ensuite et à l’entrée du multiplexeur, on retrouve deux flux MPEG en bande de base. Le

premier est généré par la passerelle IP/DVB. Le second comporte l’ensemble de la
signalisation DVB-RCS (figure 4.5)

10 La table NIT indique la structure physique du multiplex DVB (fréquence porteuse, taux de codage et type de

modulation). Elle contient notamment la description et le nom du réseau DVB-RCS, données indispensables
aux terminaux pour acquérir la signalisation RCS.

60
A la sortie un flux MPEG unique est ainsi formé et transmis au modulateur DVB où le
signal est codé et modulé. A la sortie du modulateur, la porteuse TDM est ainsi formée et
elle est transmise en bande L au simulateur du lien satellite.
Côté réception et de part la nature diffusante de la porteuse DVB-S, l’ensemble des
terminaux la reçoivent. Ils accèdent aux cellules MPEG-TS identifiées par le PID données.
Ensuite, c’est en accédant au champ MPE que les RCST peuvent savoir, en fonction de
l’adresse MAC, si le trafic leur est destiné. Ce filtrage permet d’éviter de remonter au niveau
IP et d’alléger par la même la charge de traitement côté RCST.
IV.[Link] Lien Retour
La procédure de connexion du terminal consiste en l’identification et
l’authentification du terminal par le NCC. Durant cette phase de Logon le terminal
s’authentifie avec son adresse MAC ainsi que 2 identifiants logiques (Group_id et Logon_id)
[2]. Ces paramètres permettent au NCC de vérifier que le terminal appartient au réseau
interactif DVB-RCS mais aussi de déterminer le niveau de service qui lui est attribué, les
catégories de capacité radio à utiliser et le niveau de bande passante maximale à attribuer.
Ces paramètres permettent d’associer le terminal à une super-trame donnée. Dans la cadre
du réseau IP DVB-RCS, on ne dispose que d’un seul réseau interactif avec une seule
configuration de super trame.
Le NCC communique aux terminaux, via les messages TIM, les PIDs à utiliser pour émettre
du trafic sur la voie Retour. Dans notre cas, on dispose de deux PIDs. Ils caractérisent deux
classes de trafic au niveau MAC à savoir Best Effort et Real Time.
Sur le lien montant ou Retour, le terminal joue le rôle d’un routeur d’accès et répartit le
trafic selon les priorités. Les règles sont compatibles Diffserv et les flux IP sont répartis
selon leur adresse IP source/destination et/ou port source et destination mais aussi la valeur
du champ DSCP11.
Ensuite les paquets IP sont encapsulés suivant le schéma MPE/MPEG (cf. figure 3.6). C’est
le schéma d’encapsulation optionnel du standard qui est utilisé par le réseau DVB-RCS. Les
paquets MPEG ainsi formés vont venir occuper les Time Slots trafic alloués par le NCC. Ils
sont le résultat aussi bien d’une allocation statique par le NCC qu’une demande explicite du
terminal.
IV.2.4.2 Qualité de service et allocation de ressources radios
La question de la disponibilité et de l’allocation de ressources se pose davantage pour
le trafic montant et le lien Retour. Sa gestion est assurée par le NCC ; moins de ressources
sont disponibles comparées au lien Aller DVB-S.
Dans le sens descendant (DVB-S) du trafic, et étant donné la bande passante
disponible, l’ensemble des flux toutes priorités confondues va pouvoir être acheminé dans le
respect des contraintes spécifiques à chacun. Une porteuse DVB-S peut atteindre 45 Mbit/s
en débit MAC avant le codage canal.
Sur le lien Retour, le débit ne dépasse pas 2 Mbit/s par porteuse ce qui devient rapidement
contraignant si on considère les dizaines de PCs et de téléphones IP qui forment le segment
utilisateur et peuvent émettre simultanément.
Dans cette direction du trafic, le standard laisse ouverte l’implantation de la
correspondance entre la qualité de service IP et l’allocation de ressources. Certes, DVB-RCS

11 DSCP (Diffserv Code Point) ce sont les 6 premiers bits du champ TOS (Type Of Service) de l’en tête IPv4. Sa

valeur détermine le niveau de priorité Diffserv à attribuer au service.

61
mentionne le recours à la politique Diffserv et dénombre les catégories radio (CRA,
RBDC…). Cependant aucune indication n’est donnée quant à une éventuelle correspondance
entre la QoS IP et les catégories de ressources radio.
Cette liberté représente, tout de même, un des principaux critères de performance du
système sur la voie Retour. Une correspondance est établie entre les classes de service
Diffserv, les capacités radio ou des combinaisons les associant et les algorithmes
d’ordonnancement et de classification de flux. L’objectif est de garantir le respect des
propriétés intrinsèques des flux IP véhiculés en fonction de leur tolérance au délai et à la
gigue. Par ailleurs, Satlabs [3], l’organisme en charge du suivi et de la promotion du
standard a publié un document [4] regroupant des recommandations spécifiant un nombre
minimal de classes de services Diffserv à implanter ainsi que la manière avec laquelle il
faudra les faire correspondre avec la capacités radio.
La figure 4.6 décrit la manière avec laquelle est établie la correspondance entre la
classification QoS IP et l’ordonnancement niveau MAC. Suivant les critères de classification
Diffserv définis par l’opérateur (numéros de ports, adresses sources et destination..), les flux
IP sont répartis et classés selon leurs degrés de priorités respectifs. Au niveau MAC, cette
répartition aboutit à deux catégories de trafic : temps réel et non temps réel.
Pour acheminer le trafic présent dans les files d’attente et dans le cas d’une allocation
dynamique, le RRR (Radio Resource Requester) se charge d’évaluer la bande passante
nécessaire compte tenu des priorités des flux avant de transmettre sa requête à la Gateway.
Côté NCC, l’entité RRA (Radio Resource Allocator) qui regroupe les fonctionnalités CAC et
DAMA attribue les ressources dans la limite de la bande passante disponible pour le réseau,
de celle qui est autorisée pour le terminal et établie dans le cadre du contrat de service SLA.
Un BTP est ainsi formé et diffusé à l’ensemble des terminaux.

Figure IV.6 Bande passante à la demande

IV.2.4.3 Porteuses retour

Le BTP ainsi généré par le NCC est diffusé à l’ensemble des terminaux. Il définit de
manière unique chaque Time Slot (nature, débit symbole, FEC, temps de début).
La durée d’une trame est confondue ici avec celle de la super trame et fixée à 120 ms.
Sa structure est composée non seulement de bursts de signalisation CSC pour le logon, SYNC
pour le maintien de la synchronisation et pour les demandes de ressources mais aussi de
bursts de trafic.

62
A ce titre, plusieurs débits symboles sont proposés par le système (270 kS/s, 519 kS/s, 750
kS/s, 1200 kS/s). Les bursts de signalisation (CSC, SYNC) sont transmis via les porteuses
ayant les débits symboles les plus faibles tandis que les plus élevés sont réservés
exclusivement aux bursts trafic.
L’obligation d’utiliser des débits symboles faibles pour transmettre la signalisation constitue
une limitation en soit. En effet, ceci plafonne le débit maximal qu’on peut atteindre pour une
porteuse qui ne dépasse pas 900 kbit/s pour un débit symbole de 519 kS/s et ne permet pas
d’optimiser la consommation de bande disponible qu’en maximisant le débit symboles des
autres porteuses. Cela peut créer un déséquilibre notable entre porteuses. En plus et toujours
avec le souci de ne pas gaspiller les ressources, on doit multiplexer la signalisation et le trafic
sur ces porteuses à faible débit symboles. Nous sommes contraints dans ce cas à transmettre
à faible débit.
C’est un autre exemple des aspects laissés ouverts par le standard DVB-RCS et qui a
un impact sur la performance globale. En effet, la spécification ne recommande que le débit
symbole le plus faible (270 ks/s) [5]. Les porteuses Retour sont ainsi définies par leur débit
symboles.
Par ailleurs, le passage d’un débit symbole à un autre entre deux bursts adjacents
constitue un autre critère de performance dans le sens où il implique un changement de
fréquence (Frequency Hiopping). C’est le terminal qui renseigne à la connexion via le burst de
logon CSC sur sa faculté ou pas de changer rapidement de fréquence entre deux Time slots
adjacents (Fast Frequency Hopping) ou non. Sinon, un intervalle minimal d’un time slot est
nécessaire pour que le terminal puisse changer de débit symbole. La figure 4.7 est un
exemple de la distribution des Time Slot au sein d’une super-trame.

F re q u e n c y S u p e r fra m e _ id 1
t i m e s lo t _ 0 tim e s lo t_ 1 tim e s lo t_ 8 3 t im e s l o t _ 1 0 3
TRF TRF SYNC CSC
fr a m e _ id 1 ... ...
3 /4 T C C 3 /4 T C C 1 /2 T C C 1 /2 T C C
750ksps 750ksps 750ksps 750ksps
t i m e s lo t _ 0 tim e s lo t_ 1 tim e s lo t_ 8 3 t im e s l o t _ 1 0 3
TRF TRF SYNC CSC
fr a m e _ id 1 ... ...
3 /4 T C C 3 /4 T C C 1 /2 T C C 1 /2 T C C
750ksps 750ksps 750ksps 750ksps
t i m e s lo t _ 0 tim e s lo t_ 1 tim e s lo t_ 8 3 t im e s l o t _ 1 0 3
TRF TRF SYNC CSC
fr a m e _ id 1 ... ...
3 /4 T C C 3 /4 T C C 1 /2 T C C 1 /2 T C C
750ksps 750ksps 750ksps 750ksps
t i m e s lo t _ 0 tim e s lo t_ 1 tim e s lo t_ 8 3 t im e s l o t _ 1 0 3
TRF TRF SYNC CSC
fr a m e _ id 1 ... ...
3 /4 T C C 3 /4 T C C 1 /2 T C C 1 /2 T C C
750ksps 750ksps 750ksps 750ksps

T im e

Figure IV.7 Répartition des Times Slots au sein des trames

IV.2.4.4 Le module d’accélération TCP et de chiffrement IPsec

La norme DVB-RCS n’aborde que la manière avec laquelle les paquets IP doivent
être encapsulés et adaptés par les couches supérieures et acheminés via les ondes
hertziennes.
La spécification ne traite pas des protocoles au-dessus d’IP tels que TCP, HTTP….
Néanmoins, il n’est pas envisageable sur le plan de la performance technique de concevoir un
système IP DVB-RCS sans y intégrer des mécanismes d’amélioration du comportement de
TCP sur satellite.

63
 Actuellement, la plupart des systémiers DVB-RCS proposent des solutions PEP12
intégrés à leurs systèmes et qui se présentent souvent sous forme de briques logicielles au
niveau du terminal et de la Gateway. En revanche, cette prise en compte était relativement
novatrice quand la plateforme IP DVB-RCS a été spécifiée. Seuls étaient disponibles des
modules hardwares sous forme de boitiers PC qui même en compliquant l’architecture du
système, demeurent indispensables à son bon fonctionnement.
Par ailleurs, dans un contexte d’un service destiné à des professionnels, il est nécessaire de
mettre en place des mécanismes de chiffrement du trafic dans les deux directions du trafic.
La solution PEP, que nous avons retenue, a l’avantage de pouvoir accélérer le trafic TCP
entre les terminaux et la Gateway dans les deux sens du flux et de chiffrer les données en
formant des tunnels IPsec sur le lien satellite par lequel transite tout le trafic.

Figure IV.8 Solution d’accélération et de chiffrement (Source Udcast)

IV.[Link] Architecture du PEP

La solution de chiffrement IPsec et d’accélération TCP est une architecture type
Client Serveur. Le module Client est placé en coupure avant le terminal DVB-RCS dans le
sens retour du trafic. Le module Serveur est placé à la Gateway en coupure pour le trafic
DVB-S et RCS comme le montre la figure 4.9.
La solution étant commerciale, certaines informations techniques sont
nécessairement incomplètes, la description que nous faisons ici repose sur la documentation
reçue et sur la compréhension acquise suite à l’utilisation des équipements.

IV.[Link].1 Accélération TCP

La solution d’accélération proposée est compatible avec la pile de protocole TCP/IP.

Les PEPs placés de part et d’autre du lien satellite (un côté Hub et un côté terminal)
procèdent en deux étapes. Dans un premier temps la session TCP entre un émetteur et un
destinataire situés aux extrémités du lien satellite, est scindée en trois sessions TCP dont
deux terrestres et une via satellite avec le TCP modifié implantant la RFC 3135 [6]. Les
deux proxies PEPs assurent une fonction de spoofing en se substituant d’un côté et d’un autre
du lien satellite à l’émetteur et au destinataire des paquets TCP.

12 Le terme PEP désigne généralement une solution d’accélération TCP. Dans notre cadre, il désigne en plus

une solution de chiffrement IPsec.

64
 Internet

Figure IV.9 Spoofing sur le lien satellite

La figure 4.9 illustre un exemple de fonctionnement du spoofing. Côté terminal, c’est le PEP
RCST qui envoie les acquittements à l’émetteur à la fréquence habituelle simulant, par la
même, un comportement standard de TCP. Côté Gateway, le PEP GW reçoit les
acquittements reçus du destinataire.
Sur le lien satellite, la session observe un comportement non standard de TCP mais
transparent pour l’émetteur et le récepteur final. Les proxies PEP implantent un ensemble de
techniques qui atténuent la dégradation des performances du protocole TCP sur satellite :

Une augmentation de la taille de la fenêtre initiale afin de réduire dans le temps

l’intervention de l’algorithme Slow Start préjudiciable à la bande passante [7].

L’atténuation des effets de l’asymétrie des liens en augmentant la taille des segments
TCP (MSS), la réduction de la fréquence des accusés de réception en introduisant un
intervalle de temps minimal entre deux acquittements consécutifs… [8].

L’estimation de la valeur du RTO (Retransmission Time Out) sur la base du délai RTT
satellite 500 ms.

Le recours aux acquittements sélectifs SACKs. Ainsi les émetteurs ne réexpédient
que les blocs non reçus et évitent le recours à l’algorithme de Slow Start.

L’usage des acquittements sélectifs qui n’indiquent à l’émetteur que les blocs reçus
correctement et lui permettre de ne réexpédier que les blocs qui n’ont pas été
correctement transmis [9].

IV.[Link].2 Les Tunnels VPN

La solution PEP retenue rend possible la transformation du réseau IP DVB-RCS en
un réseau VPN. Elle garantit, en parallèle à l’accélération TCP, une transmission sécurisée
des flux IP sur les liens satellite Aller et Retour. Ainsi entre la Gateway et chaque terminal,
un tunnel VPN est établi (figure 4.10). Cette solution repose sur l’utilisation du protocole
IPsec (IP Security) en mode tunnel entre le terminal RCS et la Gateway.

Internet

Figure IV.10 Tunnel VPN & accélération TCP

65
IPsec [10], permet de sécuriser les échanges au niveau de la couche réseau. Il assure
l’intégrité, la confidentialité et l’authentification des données en plus de la protection anti
rejeu.
Afin de mettre en place les tunnels entre le RCST et la Gateway, la solution PEP a recours
au mécanisme ESP (Encapsulation Security Payload) d’IPsec. Ce dernier garantit la
confidentialité et l’authentification des données. Le principe d’ESP [11] est de générer à
partir d’un datagramme IP classique, un nouveau datagramme dans lequel les données et
l’en-tête sont chiffrés.

Figure IV.11 Chiffrement IPsec ESP en mode Tunnel

Dans ce mode de chiffrement, les deux proxies PEP aux deux extrémités du lien satellite se
substituent aux deux entités qui communiquent. Ce sont les adresses IP des proxies qui sont
mentionnées dans l’en-tête du paquet IP après application du protocole ESP.

IV.[Link].3 Association de sécurité et gestion des clefs

Pour sécuriser les paquets IP, ESP fait appel à des techniques de cryptographie dont les
attributs (algorithmes de chiffrement, clefs…) doivent être connus par les entités qui
communiquent via IPsec afin qu’elles puissent se mettre d’accord. Une association de
sécurité SA (Security Association), permet de gérer ces paramètres. C’est une « connexion »
unidirectionnelle qui fournit des services de sécurité aux données qu’elle transporte. Les
associations de sécurité sont aussi le résultat de la négociation des paramètres de sécurité
(Algorithmes de chiffrement, clefs…). Une association de sécurité est identifiée d’une
manière unique par le triplet

Adresse de destination des paquets chiffrés, en l’occurrence le proxy PEP de l’autre
côté du lien satellite.

Identifiant du protocole de sécurité (AH ou ESP) ;

Indice des paramètres de sécurité SPI (Security Parameter Index) ;
L’association de sécurité contient également

Les clefs et les algorithmes de chiffrement utilisés par ESP ;

Les clefs ainsi que les fonctions de hachages nécessaires à l’authentification des
paquets.
Pour un fonctionnement standard d’IPsec, les associations de sécurité et en particulier les
clefs de chiffrement sont gérés dynamiquement. Ce mode de gestion permet non seulement
d’assurer une bonne fréquence de renouvellement des clefs mais simplifie le passage à
l’échelle à mesure que le nombre de tunnels IPsec dans le réseau croît. L’IETF a retenu le
protocole de niveau applicatif IKE (Internet Key exchange) [12] pour assurer une gestion
dynamique des associations de sécurité.
Ce mode de gestion est certes efficace. Cependant, il pose des contraintes
considérables quand il est implanté dans des tunnels IPsec par satellite. Le protocole IKE
dédié aux communications Unicast ne permet pas d’exploiter le caractère de diffusion d’une
porteuse DVB-S. Aussi, le rafraîchissement des clefs et plus généralement des associations de

66
sécurité entre deux entités séparées par un lien satellite subit l’impact des délais. Pendant ce
temps, le tunnel VPN n’est pas opérationnel, ces délais constituent un préjudice notable à la
disponibilité du lien et par conséquent à la performance du réseau.
Par ailleurs, plusieurs travaux proposent des adaptations et des améliorations du
protocole IPsec sur lien satellite [13] avec des propositions pour une sécurisation des
données unicast et multicast. Dans notre cas, la gestion des associations de sécurité est
statique. En effet, le choix du numéro SPI des algorithmes de chiffrement et
d’authentification utilisés par ESP ainsi que leurs clefs est effectué et configuré statiquement
par l’opérateur du réseau. Il est clair qu’on privilégie, dans ce cas de figure, un tunnel VPN
opérationnel en permanence au dépend d’un niveau de sécurité élevé qu’aurait apporté un
rafraîchissement dynamique et fréquent des clefs. Un opérateur satellite d’un réseau IP
DVB-RCS peut gérer une politique statique de gestion de clefs d’autant plus que le nombre
de tunnel ne serait pas aussi important que pour un réseau terrestre.
Le tunnel VPN IPsec est établi entre deux proxies PEP disposant de la même association de
sécurité statique. Les proxies constituent un goulet d’étranglement autant pour le flux IP
Aller que celui à l’entrée du RCST dans le sens Retour du lien satellite. Dans les deux
directions du trafic, la totalité des flux passe par le proxy PEP et transite par le tunnel VPN.
A ce titre et avant de chiffrer les paquets IP, le PEP joue le rôle d’un routeur d’accès et
assure ainsi des fonctions de QoS en répartissant le trafic IP selon les règles compatibles
Diffserv définies par l’opérateur.
L’accélération TCP a naturellement lieu avant le chiffrement IPsec puisque l’en-tête
TCP d’un paquet entièrement crypté devient inaccessible. Ceci a l’inconvénient d’affecter les
performances des tunnels IPsec de bout en bout entre un PC hôte sur le LAN et une autre
station sur Internet. En effet, les paquets IP déjà chiffrés transitant par le tunnel VPN entre
les deux proxies ne sont pas accélérés puisque leurs en-têtes chiffrés sont inaccessibles. La
figure 4.12 donne un aperçu de la pile protocolaire du système IP DVB-RCS pour une
application client serveur de bout-en-bout

Figure IV.12 Pile de protocole DVB-RCS & Accélération TCP et Chiffrement

IV.2.4.5 Le système VoIP

Pour son utilisation professionnelle, la plateforme que nous avons mise en œuvre, se
doit de proposer des services type VoIP en plus des applications classiques d’échanges de
données sur Internet (Web, e-mail, FTP…)
Bien que très déployée dans les réseaux terrestres, la qualité de service de la VoIP par
satellite fait partie des défis de la plateforme IP DVB-RCS que nous avons intégrée. Cela est
dû à diverses raisons : aux délais incompressibles, à l’obligation pour les opérateurs de
mettre en place une politique de QoS efficace pour atténuer « l’effet satellite », à des choix

67
système nécessaires à une consommation optimisée de la bande passante statique et
dynamique.
Le besoin d’une solution de VoIP sur satellite pour les clients potentiels est réel quitte à se
satisfaire d’une qualité inférieure à celle des réseaux terrestres. Ce besoin s’explique par la
réduction considérable de coût qu’entraîne la mutualisation des infrastructures pour le
transport des données (email, Internet, transferts de fichiers..) et la téléphonie (Voix, vidéo)
au sein d’un réseau unifié fondé sur le protocole IP. Ils peuvent alors s’affranchir des moyens
de communications (téléphonie fixe GSM et autres). Ceci est un avantage indéniable compte
tenu des zones géographiques où sont situés ces clients et pour lesquelles la disponibilité des
réseaux n’est pas garantie.
Par conséquent, l’objectif est de fournir une solution de téléphonie sur IP
professionnelle. Elle se doit d’assurer la gestion des appels à l’intérieur du réseau IP par
satellite mais surtout une passerelle vers les réseaux téléphoniques extérieurs RTC et GSM.
Plus particulièrement le système de VoIP intégré au réseau IP DVB-RCS se compose de :

Un PABX (Private Automatic Branch eXchange) Open Source fondé sur la technologie
Asterisk [14]. Situé au niveau de la Gateway, il regroupe l’ensemble des
fonctionnalités requises pour un usage professionnel comme la messagerie unifiée, le
répondeur… De plus, il s’interface avec les réseaux de téléphonie extérieurs GSM et
PSTN. Tout de même, sa fonction principale consiste à gérer les appels entrants et
sortants au sein même du réseau.

Un ensemble de téléphones et de soft phones IP situés au niveau des segments
utilisateurs.
La plateforme IP DVB-RCS est destinée à acheminer une multitude d’applications à base
d’IP. Pourtant, les choix de configurations aussi bien au niveau de la QoS IP que des
stratégies d’allocation des ressources radios sont déterminées en fonction du niveau de
performance que doit avoir le système pour la VoIP. En effet, c’est une application à fortes
contraintes temporelles, qui est de surcroît acheminée par satellite. En plus, c’est une
application dont les dégradations de performance sont immédiatement perceptibles par les
utilisateurs finaux. La partie suivante, introduit les concepts de base de la VoIP. Même s’ils
sont largement connus et abondamment documentés, ils seront utiles pour l’interprétation
de résultats de tests.
IV.[Link] Les caractéristiques de la VoIP
La voix sur IP est une application temps réel dans le sens où le signal doit être
restitué à un instant aussi proche que possible de celui où il a été généré. Ce caractère
particulier redouble d’importance sur un réseau IP par satellite en raison des délais
d’acheminement des paquets dont certains incompressibles. A ce titre, l’opérateur se doit de
prendre les décisions de configuration nécessaires pour un compromis entre une utilisation
efficace de la bande passante et la restitution d’une voix de qualité acceptable pour
l’utilisateur final.
Ces choix portent aussi bien sur l’application elle-même que sur le paramétrage du
réseau satellite. En effet, au niveau de l’application, le choix des algorithmes de compression
de la voix (Codecs) de la durée, du nombre d’échantillons et de la taille des paquets à générer
ont un impact direct sur la consommation de la bande passante.
Au niveau du réseau, les décisions portent sur la stratégie d’allocation de bande
passante (dynamique et statique) à adopter et sur la QoS IP qui assurera une priorité pour la
voix tout en répartissant équitablement les ressources entre les différentes applications.

68
Pour cela il est intéressant de comprendre comment les paquets VoIP sont générés pour
déterminer les paramètres sur lesquels l’opérateur doit agir et améliorer les performances
des applications sur son réseau.

IV.[Link].1 Traitement de la VoIP

La première étape de traitement de la voix consiste en une numérisation du flux de
paroles et sa compression via un codec. La bande de fréquences audibles par l’oreille humaine
s’étend de 300 Hz à 3400 Hz. Le signal est donc échantillonné à 8kHz (théorème de
Shannon). Chaque échantillon est ensuite codé sur 8 bits conformément à la norme
Européenne pour un débit final de 64 kbit/s.
Les codecs (compresseur-décompresseur) interviennent dès lors afin de réduire ce débit et
par conséquent la bande passante nécessaire. Ils sont définis par le débit à la sortie du codeur
et la durée de la trame voix qu’ils génèrent. La qualité de la voix restituée par un codec est
évaluée par l’intermédiaire du MOS13
Avant d’être encapsulé dans des paquets IP et adaptées su support physique du lien
satellite via MPE/MPEG, le protocole RTP (Real Time Protcol) [15] doit au préalable
remédier aux lacunes des réseaux IP dans la gestion des flux temps réel. Il s'agit d'un
protocole de transport non fiable, dédié aux flux continus de données (audio, vidéo
principalement), et fonctionnant en point-à-point ou en multipoint sur un réseau IP. Comme
les paquets peuvent être perdus, dé-séquencés, dupliqués, ou simplement retardés, chaque
paquet RTP renferme dans son entête de 12 octets des informations de type numéro de
séquence et estampille temporelle, permettant au récepteur de déceler une perte ou un retard
trop important, et ainsi de jouer correctement le flux de données à l'arrivée. Les estampilles
temporelles sont utilisées à la fois pour la synchronisation intra-flux, la détermination des
instants de jeu de chaque paquet de données ainsi qu’à la synchronisation inter-flux, qui met
en jeu les éventuelles relations temporelles entre plusieurs flux.
Le caractère temps réel de la VoIP implique le recours au protocole UDP (User
Datagram Protocol) pour la transmission des paquets RTP. En effet, les mécanismes de
contrôle de flux et de recouvrement de pertes en font un protocole inadapté au transport de
la VoIP. Elles sont préjudiciables à la VoIP application à débit constant et dont la
performance est principalement définie par la réduction et la régularité des délais de
transmission.

IV.[Link].2 Le contrôle des sessions VoIP

En parallèle à RTP, un protocole de contrôle des sessions VoIP est indispensable afin
d’en organiser le développement. Le protocole SIP (Session Initiation Protocol) [16] s’est
imposé comme le protocole de signalisation de la VoIP par excellence. Bien que pour des
raisons historiques, la pile de protocole H.323 soit implantée dans plusieurs solutions de
VoIP, SIP est de plus en plus utilisé. SIP découle d'une approche dédiée à la signalisation
téléphonique sur Internet spécifiée par l’IETF. C’est un protocole de signalisation pair à pair
appartenant à la couche application du modèle OSI et s‘inspire du protocole HTTP. Son rôle
est d’ouvrir, modifier et libérer les sessions (notification de l’appelé par l’appelant,
négociation des paramètres de la session comme les codecs, les adresses sources et
destination…).

13 Le MOS (Mean Opinion Score) est une appréciation subjective de la voix selon certains modèles définis par

l’ITU [17]. Elle établit un coefficient de qualité ascendant sur une échelle de 1 à 5.

69
IV.[Link].3 Métriques d’évaluation de la VoIP

Les critères ci-dessous permettent d’évaluer la qualité des communications VoIP. Ils
sont d’autant plus nécessaires lorsque la VoIP est acheminée par satellite.

- Le délai : c’est le temps nécessaire pour le traitement et l’acheminement d’un paquet voix
de source à destination. Il regroupe les temps de traitement et de propagation dominés par la
durée de la traversée terre-satellite. La recommandation G.114 de l’ITU [18] suggère entre
200 et 350 ms de délai unidirectionnel pour les communications par satellite.
- La gigue : une estimation statistique de la variance de temps d’arrivée inter-paquets. Une
gigue excessive combinée à un buffer réduit peut conduire à une distorsion de la voix à la
restitution. Pour une communication de qualité moyenne la gigue est estimée à 60 ms et à 20
ms pour une communication de bonne qualité.

- La perte de paquets : est due à un délai ou une gigue excessifs ainsi qu’à du bruit ou des
interférences sur le lien satellite. La perte de quelques bits ou d’un paquet demeure
indétectable dans le cas d’une communication VoIP. Toutefois, si le phénomène s’amplifie, il
cause des trous perceptibles dans la communication. Le taux de perte doit rester inférieur à
5% pour une communication de qualité moyenne et inférieure à 1% pour une communication
de bonne qualité.

En plus des métriques ci-dessus, le débit reste un élément principal pour apprécier la
qualité de VoIP, spécialement dans un contexte satellite. Le débit IP nécessaire à une
communication VoIP dépend directement de celui du codec utilisé. A ce titre, il est
nécessaire de trouver à chaque fois le compromis nécessaire entre une bonne qualité de la
voix et un débit minimal du codec. Le tableau I ci-dessous donne un aperçu des
caractéristiques des différents codecs utilisés pour les communications VoIP par satellite.

Codec Voice frame duration (ms) Bit rate (Kbps) MOS

G.711 125 64 4,1
G.729 10 8 4
GSM 20 13,2 3,7
G.723 30 5,3 3,5
G.723 30 6,3 3,5

Tableau IV-1 Principaux codecs utilisées pour les communications VoIP par satellite14

14 Les valeurs du MOS peuvent légèrement varier d’une technique d’estimation à une autre.

70
IV.2.5 Architecture finale de la plateforme

La figure 4.13 donne un aperçu de l’architecture de la plate forme IP DVB-RCS, une

fois la phase d’intégration achevée. Le réseau IP DVB-RCS comprend la Gateway et 4
terminaux. Ce nombre limité apporte toutefois une représentativité suffisante d’un réseau
opérationnel. De plus, il apporte du réalisme aux tests effectués. Il permet d’illustrer le
fonctionnement de l’ensemble de la chaîne ainsi que de tous les mécanismes mis en œuvre La
présence ou non des PEP dépend également de la nature des tests à faire.

Figure IV.13 Architecture générale de la plate forme IP DVB-RCS

IV.3. Expérimentations, résultats et analyses

Nous avons adopté dans notre description de la plateforme IP DVB-RCS une approche
analogue, dans son principe, à la perception des sous-systèmes (DVB-RCS, PEP, VoIP) la
composant. Elle se réduit d’une manière générale à une vue centrée sur le mode de
fonctionnement d’une technologie donnée et dissocié du système dans lequel elle est
intégrée.
Après la phase d’intégration, vient celle de l’observation et de l’évaluation du
comportement des applications IP que nous désirons acheminer à travers le réseau IP DVB-
RCS. Cette observation renseignera sur la possibilité ou non de fournir certains services
mais aussi sur les moyens que nous pouvons mettre en place pour en améliorer les
performances. Nous avons donc envisagé certains contextes de fonctionnement et mis en
place les scénarios de tests qui les illustrent.
Parmi le panel d’applications IP proposées (FTP, web..), la VoIP reste un service
économiquement rentable pour un opérateur de réseau et crucial pour un client disposant de
ce genre de réseau IP par satellite pour ses activités.
D’un point de vue technique, l’application VoIP influe sur les choix d’un opérateur aussi bien
sur le plan de la répartition et l’allocation de la bande passante que sur celui de la qualité de
service IP.
Nous avons donc décidé de porter notre intérêt, lors de nos tests, sur l’application
VoIP dans un contexte de trafic mixte. Nous abordons plusieurs aspects : l’impact de la VoIP
sur les flux concurrents de plus basses priorités, le coût en bande passante qu’engendre son

71
acheminement par satellite, l’effet de la stratégie d’allocation de ressources sur ses
performances. Ces expérimentations portent aussi sur l’avantage potentiel que procurerait le
chiffrement de la voix par IPsec. Dans notre analyse, l’accent sera mis sur le comportement
de la voie Retour pour les raisons de disponibilité de ressources sur la voie Aller évoquées
précédemment.
La démarche expérimentale et les interprétations des différents résultats sont l’objet de la
présente section.

IV.3.1 Pour un service VoIP sur DVB-RCS de bonne qualité

Le contexte de transmission IP par satellite diffère de celui d’un réseau terrestre pour
les raisons détaillées dans les chapitres précédents. Ceci est encore vrai si on veut
transmettre de la voix. Une VoIP de bonne qualité sur un réseau DVB-RCS passe par une
stratégie optimisée d’allocation de bande passante et une réduction au mieux du délai de
transmission en plus d’une QoS IP qui rend prioritaire la voix et minimise le temps de
passage par les files d’attentes réduisant ainsi la gigue. Néanmoins, les délais
d’acheminement de la VoIP sont bornés par le temps de transmission incompressible entre la
terre et le satellite. Il devient donc crucial de prendre les décisions nécessaires au niveau :

De la QoS IP afin de réduire les variations de délais et traiter les flux IP en fonction
de leurs priorités respectives.

De la stratégie d’allocation de bande passante qu’elle soit statique ou dynamique afin
de rendre disponible les ressources aussi rapidement que possible.

De l’utilisation du segment spatial car étant donné la taille réduite des paquets IP, il
convient d’étudier au préalable le coût qu’entraînent les encapsulations successives et
le moyen de les optimiser.
La principale difficulté, quand on procède à la configuration du réseau IP DVB-RCS
réside justement dans son caractère modulaire. Il est, en effet, composé, d’un ensemble de
sous-systèmes, chacun pouvant fonctionner d’une manière indépendante. Les choix de
configuration portent sur un niveau ou un équipement particulier. Il est tout de même
nécessaire d’être conscient de l’impact de ce choix sur les autres parties du réseau puisque
l’objectif demeure une performance du système dans sa globalité.

IV.3.1.1 Allocation de bande passante et qualité de service IP pour la VoIP

Nous avons évoqué lors des précédents chapitres la dé-corrélation qui existe entre la
qualité de service IP et les ressources au niveau MAC pour les réseaux satellites. La
transmission de la VoIP sur DVB-RCS est une illustration concrète du problème. Afin d’en
atténuer l’effet, on se doit de prendre en compte un certain nombre de critères pouvant être
résumés comme suit.

Les ressources doivent être disponibles en permanence et ce même en cas de
congestion du réseau. La QoS IP assure certes un traitement prioritaire de la voix
mais ne garantit en aucun cas la disponibilité des ressources radios. L’effet –
indésirable- que peut avoir la variabilité des ressources sur la VoIP, application à
débit constant, est une fluctuation des délais et par conséquent une augmentation de
la gigue.

72

Il faut veiller à ce que la bande passante allouée n’excède pas les besoins du terminal
pour éviter un gaspillage inutile. Elle doit notamment être disponible en un
minimum de temps. Une allocation exclusivement dynamique avec un RTT (Round
Trip Time) assez long peut non seulement dégrader la communication surtout au
début voir empêcher son établissement si certains protocoles de signalisation tels que
H.323 ne s’en accommodent pas.

La façon avec laquelle sont attribuées les ressources doit garantir une transmission
de qualité. L’allocation doit avoir un rythme régulier dans le temps avec une
répartition homogène des slots. L’effet d’une allocation en rafales est à éviter pour la
voix. Ceci permet d’assurer un débit constant mais aussi des intervalles de temps
réguliers entre les slots et par conséquent une gigue minimale. De ce fait, les
allocations en volume (type VBDC) ne sont pas à recommander pour la transmission
de la voix.

En raison du coût élevé et parfois prohibitif de la bande passante satellite, une allocation
dynamique à débit constant et garanti type RBDC pour la VoIP est privilégiée. Cependant,
une allocation dynamique n’a pas lieu sans un certain coût. Il faut en effet tenir compte du
temps nécessaire au terminal d’évaluer le volume de trafic à écouler, d’envoyer la requête et
d’attendre l’attribution des slots par le DAMA. Cet échange dure au moins un RTT ce qui
allonge le temps d’établissement de la communication et retarde l’émission du premier
paquet voix sur la voie retour. Avec un scénario d’allocation exclusivement dynamique, une
augmentation brusque du volume de trafic de façon à ce qu’il excède les ressources allouées
est également envisageable.

L’hypothèse selon laquelle on assisterait à un grand nombre de communications qui

débuteraient au même instant est peu probable. Il y a toujours de brefs instants de décalage
entre les instants de démarrage des communications ou plus généralement les temps
d’arrivée des paquets VoIP au terminal sur le lien montant. Ceci atténue une montée brusque
et agressive du volume de trafic à écouler.

En revanche, ce scénario devient réel si le codec VoIP utilisé intègre la fonctionnalité de

suppression de silence15. En effet, la suppression de silence implique une baisse de la
demande en bande passante en période d’inactivité de la voix – de silence- avant de recroitre
lorsque la parole reprend. Au moment de la reprise de la parole, la taille des buffers des
paquets voix au niveau des terminaux augmente dans l’attente des ressources nécessaires à
les écouler. Durant ces périodes de transition, les buffers des paquets voient leur taille varier
constamment. Ceci implique naturellement de la gigue dégradant par la même la qualité de
la voix.

Nous avons fait le choix de ne pas recourir à cette fonctionnalité dans nos tests en raison
des arguments présentés ci-haut et afin de réduire les incertitudes pour une plateforme IP
DVB-RCS déjà suffisamment complexe de part sa modularité.

15 Il est statistiquement prouvé que 60% du temps de communications voix consiste en de longues et petites

périodes de silence. Une fonctionnalité de détection d’activité de la voix VAD (Voice Activity Detection) intégrée
au codec permet de réduire la consommation en bande passante en générant du bruit blanc.

73
 Une autre option peut se présenter lors des choix des allocations de bande passante.
Dans le but d’atténuer les effets négatifs d’un schéma d’allocation dynamique sur la qualité
de VoIP, certains opérateurs privilégient une combinaison entre capacité statique et
dynamique en ayant recours au débit garanti CRA. Nous trouvons cependant que cette
stratégie atteint rapidement sa limite dès que le nombre de terminaux croît. Pour un réseau
comptant 500 terminaux, prévoir 16 kbit/s de CRA à chaque terminal revient à leur réserver
en permanence 8 Mbit/s de bande passante qu’elle soit utilisée ou non. Ceci revient à
bloquer plus d’un cinquième des ressources d’un transpondeur de 36 MHz !
Il nous a semblé judicieux de recourir à un schéma d’allocation exclusivement
dynamique. Un débit constant et garanti via RBDC permet d’écouler le trafic VoIP qui
dispose de la plus haute priorité au sein du réseau. La bande passante attribuée en volume via
VBDC ou AVBDC servira à écouler les autres types de trafic de priorité plus basse
(transferts de fichier, navigation Web...) généralement de caractère sporadique (bursty). Ces
ressources serviront notamment à atténuer les effets négatifs sur la transmission de la voix
durant les périodes où les flux VoIP augmentent.
Naturellement, à l’instar des différents choix de configuration, cette stratégie n’est
pas la seule solution. Elle a été prise en fonction des caractéristiques de la plateforme mais
aussi en raison de la priorité accordée aux ressources radios au détriment d’une mauvaise
qualité passagère et éventuelle de la communication VoIP.
Cela dit, la qualité de la VoIP sur DVB-RCS ne dépend pas uniquement de la stratégie
d’allocation de bande passante. Le choix du codec c'est-à-dire son débit de sortie, la durée
d’un échantillon voix, la manière avec laquelle il sera encapsulé dans les couches
protocolaires successives avant d’accéder au canal satellite, ont un impact sur la
consommation de la bande. Un paramétrage adéquat est donc nécessaire.

IV.3.1.2 Configuration des codecs VoIP

L’autre volet de configuration intervient sur l’application VoIP en elle-même et
concerne aussi bien le choix d’un algorithme de compression adéquat (codecs), le nombre
d’échantillons voix à inclure dans un paquet IP que la compression des en-têtes IP, UDP ou
RTP.
En considérant des facteurs de qualité MOS équivalents généralement entre 3,5 et 4,5, on
privilégie les codecs ayant des débits de sortie peu élevés comme G.723 (6,3 Kbit/s) ou
G.729 (8 kbit/s) mais également dont la durée des trames voix est réduite.

Si on considère un codec tel que G.711 (64 kbit/s et 125 ms de durée de trame) qui
n’intègre quasiment pas de mécanismes de compression de voix, on aboutit à un débit IP de
130 kbit/s. Cette valeur ne résiste pas au passage à l’échelle puisque rien que pour établir 10
communications simultanées sortantes il faudra prévoir plus de 1,3 Mbit/s de débit. D’autre
part, la durée d’échantillonnage de ce codec équivaut à elle seule à un temps de traversée
terre-satellite ce qui allonge considérablement le délai de transmission global.
Une fois le codec choisi, le nombre de trames voix à encapsuler dans un paquet RTP
détermine la manière avec laquelle la bande passante est consommée par rapport au ratio
données utiles et en-têtes.

74
 Figure IV.14 Encapsulation RTP, UDP , IP

A titre d’exemple, considérons le codec G.729 avec un débit de 8 kbit/s et une durée
de trame élémentaire de 10 ms. Si on encapsule une seule trame voix (10 octets) dans un
paquet IP et en ajoutant les en-têtes RTP, UDP et IP (40 octets) au niveau IP, seul le quart
(1/4) du paquet représente des données utiles par rapport à la taille totale. Si on compte en
plus les en-têtes introduits par les différents niveaux d’encapsulation du standard DVB-S ou
DVB-RCS ce ratio va encore décroître.
Qu’il contienne un ou plusieurs échantillons voix, un paquet RTP requière toujours le même
nombre d’octet d’overhead, la solution consisterait à inclure plusieurs échantillons voix afin
de rééquilibrer la répartition entre les données utiles et les en-têtes. Pour l’exemple, avec
G.729, 4 échantillons voix d’une durée totale de 40 ms, le rapport charge utile en-tête
devient équilibré au niveau IP. Toutefois, les en-têtes occupent plus de bande passante au fur
et à mesure qu’on avance dans les couches d’encapsulations DVB-RCS surtout si l’option
Section Packing n’est pas activée et que du bourrage est introduit au niveau MPEG-TS. Le
schéma (figure 4.14) illustre l’exemple que l’on vient de donner.
Cela dit, l’efficacité de cette technique est relative. Elle dépend du degré de
granularité des échantillons offerte par le codec. Si G.729 apporte un certain confort avec
une durée de trame de 10 ms, ce n’est pas forcément le cas pour d’autres codecs comme
G.723 avec 30 ms de durée d’échantillons. Au-delà, d’un certain nombre de trames voix, le
temps nécessaire pour générer ces échantillons commence à se ressentir sur le délai de
transmission global en plus d’une dégradation sensible sur la qualité de la communication.
Une autre manière de réduire l’overhead introduit par IP est apportée par les techniques de
compression d’en-tête au niveau IP comme la compression cRTP [19]. Cela ramène la taille
globale (RTP+UDP+IP) d’un paquet VoIP de 40 à environ 12 ou 10 octets selon les cas.
Ces mécanismes qui interviennent au niveau IP ne sont pas prévus dans le standard DVB-
RCS.
IV.3.1.3 Coût d’encapsulation
Dans ce qui suit nous illustrons par un exemple, l’impact significatif que peut avoir
les encapsulations successives avec l’ajout systématique d’un en-tête sur l’utilisation de la
bande.
Nous établissons une estimation du ratio charge utile et en-têtes pour un paquet VoIP tels
que nous l’avons paramétrés sur la plateforme IP DVB-RCS (codec, nombre
d’échantillons…). Le digramme figure 4.15 décrit dans les détails, respectivement la
formation des paquets VoIP avec un codec GSM (13,2 Kbit/s et 20 ms), le chiffrement AES-

75
CBC16 (128 bits), l’ajout de l’en-tête ESP et l’encapsulation dans le nouveau datagramme IP
avec les adresses sources et destination des PEP.

Figure IV.15 Etapes d’encapsulation successives IPsec, MPE, MPEG

Considérons une seule trame voix par paquet IP, et pas de compression d’en-tête, et
examinons le rapport entre données utiles et taille totale du paquet transmis. A titre
d’exemple, pour 33 octets utiles, au niveau MPE, 148 octets sont requis ce qui présente un
rapport de 22% !

IV.3.1.4 Conclusion
Durant cette phase de configuration, plusieurs facteurs entrent en ligne de compte et
ont ainsi une incidence sur les performances du système IP DVB-RCS. Ces choix, dépendent
de l’efficacité des interactions entre les sous-systèmes, des possibilités offertes par une
plateforme modulaire et complexe et peuvent parfois produire des résultats inattendus. Cela
dépend également de l’ordre de priorités accordées aux applications d’un point de vue
opérateur. Ceci se transcrit techniquement en termes de niveau de service, de volume global
de flux et de taille du réseau. C’est aussi fonction de l’importance accordée aux ressources
par rapport au niveau de qualité exigé ou au degré de confidentialité des données. Dans la
partie qui suit, nous présentons les tests effectués sur le système IP DVB-RCS en fonction
des paramètres que nous avons jugé prioritaires.

16 Le choix de l’algorithme de chiffrement sera justifié dans la suite de ce chapitre (cf. 3.2.1)

76
IV.3.2 Scénarios des tests et interprétations
Le système IP DVB-RCS est une solution qui permet d’acheminer des flux IP par
satellite en atténuant les mauvaises performances de TCP mais aussi en assurant la
confidentialité et l’intégrité des données.
Le profil des clients visés, étant des institutions internationales, gouvernementales ou
militaires, Il était crucial de tester la possibilité de chiffrer de la VoIP en ayant recours au
protocole IPsec. Par conséquent, nous avons analysé le comportement de la VoIP chiffrée via
IPsec transitant sur le lien satellite. L’attention est portée sur l’impact en temps induit par le
processus de chiffrement sur le délai global. Nous avons notamment comparé le coût en
bande passante en plus de la différence d’allocation entre des flux VoIP chiffrés et non
chiffrés.
IV.3.2.1 Choix de configuration
Tels que décrit précédemment, le banc de test IP DVB-RCS est constitué de la
Gateway incluant le NCC, le PABX IP, et le module d’accélération TCP et de chiffrement
IPsec. Côté terminal, on trouve le terminal DVB-RCS, le module PEP pour le chiffrement
IPsec et l’accélération TCP en plus du réseau LAN local composé de PCs, de téléphones et
de Soft phones IP. Le lien satellite est simulé par un émulateur de canaux de propagation en
bande L introduisant un délai fixe d’environ 125 ms dans chaque direction du trafic (Aller et
Retour).
Afin de pouvoir évaluer simultanément la VoIP chiffrée et non chiffrée, les tunnels VPN ont
été activés sur deux des 4 terminaux DVB-RCS. Les 2 autres ont été laissés tels quels avec
l’accélération TCP active pour tous. Ci-dessous, on retrouve la configuration de la
plateforme de tests.

Figure IV.16 Architecture du réseau IP DVB-RCS après intégration des sous-systèmes

Le chiffrement IPsec est établi entre les PEP situés respectivement côté Gateway et
côté terminal pour former ainsi un tunnel sécurisé par lequel transite l’ensemble des flux IP
(données et voix) sur les deux liens satellite. Le processus de chiffrement repose sur ESP
décrit précédemment garantissant, la confidentialité, l’intégrité et l’authenticité des données.
Ainsi, les PEP jouent un triple rôle. Ils adaptent les flux TCP au lien satellite quand cela est
nécessaire. Ils encapsulent les paquets IP par IPsec. Ils ont enfin un rôle de routeur d’accès

77
qui attribue les niveaux de priorités aux différents flux IP avec le degré le plus élevé à la
VoIP. Côté terminal, ce rôle de routeur d’accès revient normalement au terminal DVB-RCS.
Il n’est, toutefois, plus possible de procéder ainsi puisqu’il reçoit des paquets IP ayant tous la
même source et la même destination et contenant à leur tour les datagrammes IP chiffrées.
Remarque
Les terminaux des sessions VoIP sont distincts sur les deux extrémités du tunnel
IPsec. Cela évite de configurer, individuellement, un grand nombre de téléphones IP et de
soft phones IP.
Les algorithmes utilisés par IPsec pour chiffrer les flux doivent tenir compte du
caractère temps réel de la VoIP. La solution PEP propose 3 algorithmes de chiffrement
symétrique DES (Data Encryption Standard) [20], AES [21] (Advanced Encryption Standard)
et 3DES [21]. Le premier utilise une clef de 56 bits dont la longueur ne permet pas
d’assurer une sécurité suffisante. 3DES, avec une clef 192 bits, garantit le plus haut niveau de
sécurité mais le temps de traitement est trop long pour des paquets VoIP à forte exigence en
délai. Le compromis entre niveau de sécurité et temps de traitement est assuré par
l’algorithme AES avec une clef de 128 bits et un temps de traitement 3 à 10 inférieur à
3DES.
Deux commentaires sont à formuler à propos de cette configuration. Le premier concerne les
clefs de chiffrement et d’authentification qui sont configurés statiquement sur les PEPs de
chaque côté du tunnel VPN et ce pour les raisons exposées précédemment. Le deuxième
concerne la signalisation DVB-RCS qui transite « en clair » sur le lien satellite.
Le réseau IP DVB-RCS repose sur une porteuse DVB-S pouvant atteindre 4 Mbit/s et deux
porteuses retour de l’ordre de 600 Kbit/s17.
La stratégie d’allocation de bande adoptée sur le lien retour est exclusivement dynamique.
Une ressource non garantie VBDC attribuée en volume et un débit garanti et constant
RBDC est alloué sur demande aux terminaux pour acheminer les paquets voix à hauteur de
512 kbit/s ce qui se rapproche de la taille d’une porteuse retour. On suppose ainsi que le
système pourra prendre en charge un trafic formé uniquement de VoIP sur la voie retour et
sera capable d’attribuer les ressources jusqu’à la limite de sa capacité.
IV.3.2.2 1er scénario de test : allocation dynamique de bande passante
L’objectif du premier scénario est de tester l’impact de l’allocation dynamique sur la
VoIP dans les deux cas : chiffré et clair. Dans les deux cas, nous initions une communication
VoIP depuis un terminal et nous évaluons les métriques de la VoIP : pertes de paquets, délai
et gigue. Nous portons notre attention davantage sur le lien retour.
Les pertes de paquets18 sont quasi nulles dans les deux sens Aller et Retour. Le délai Aller
n’excède pas les 260 ms. Les observations les plus intéressantes portent sur la gigue. Avec
une allocation dynamique, cette situation est le pire cas qui puisse survenir En effet, au
moment de l’arrivée des premiers paquets VoIP, aucun slot trafic n’est disponible. Ils doivent
donc attendre que le cycle de demande-allocation ait lieu et ce durant un temps RTT avant
que terminal ne dispose des premiers slots et ne commence à écouler le flux. Ceci se traduit
par une gigue élevée au début de la communication avant que le processus de demande-
allocation ne s’installe dans la durée et que la valeur se stabilise. Sur la figure 4.17 ce
comportement est plus visible dans le cas d’une communication chiffrée.

17 Les valeurs indiquées concernent le débit MAC avant codage canal et modulation.
18 Dues essentiellement à des collisions au niveau des hubs connectant les équipements

78
 Figure IV.17 Gigue de la VoIP chiffrée et en “clair” sur la voie retour

Sur le lien Retour, les valeurs moyennes de la gigue permettent une qualité
acceptable de la VoIP (figure 4.17). C’est aussi en raison de l’absence d’autres flux IP sur le
réseau. Les comportements des courbes de gigues dans le cas chiffré et clair, sont tout de
même différents.
Dans le cas chiffré, la gigue se stabilise autour d’une valeur de 5 ms alors qu’elle continue de
croître dans le cas clair jusqu’à se maintenir autour de 20 ms. Nous expliquons cette
différence par le niveau protocolaire auquel le terminal évalue le volume de trafic à écouler
avant d’émettre sa requête. En effet, nous constatons que cette évaluation a lieu au niveau
MPE. Pour un même paquet VoIP –même codec et même nombre d’échantillons, ce qui est
le cas ici- le débit MPE pour une communication chiffrée sera supérieur à celui qui passe en
clair en raison des en-têtes supplémentaires ESP et IP qui s’ajoutent dans le cas IPsec. Ainsi,
il peut y avoir des écarts importants entre les débits MPE dans les deux cas pouvant
atteindre un rapport de 1,8.
C’est en partant d’une évaluation de débit que le terminal adresse sa requête. La Gateway,
interprète la demande de ressources formulée en débit mais l’attribue sous forme de bursts
trafic. Pourtant, dans les deux cas –chiffré et clair- et en comptant les en-têtes additionnels
jusqu’au niveau MAC, un paquet VoIP ne requière pas plus d’un paquet MPEG-TS ce qui
correspond à un seul burst de trafic. Ainsi, le terminal qui émet du trafic chiffré se voit
allouer plus de bursts qu’il n’en a besoin. Cette « sur-disponibilité » des ressources contribue
à « lisser » le trafic et à stabiliser la gigue en la maintenant à une valeur basse (cf. figure
4.18).

Figure IV.18 Rythme des allocations des bursts trafic dans les cas chiffré et clair

79
 Dans le cas d’un trafic « clair », la Gateway attribue uniquement le nombre de bursts
trafic nécessaires. De plus, le cycle demande-allocation requiert plus de temps avant
d’atteindre un rythme plus régulier. La gigue met ainsi plus de temps à se stabiliser autour
d’une valeur supérieure.
Ce raisonnement se trouve confirmé par l’observation des requêtes de capacité au niveau du
terminal DVB-RCS. Il est visible (figure 4.19) que le volume des requêtes de capacités dans
le cas chiffré est plus élevé à celui dans le cas clair. Par conséquent, la bande passante allouée
est supérieure dans le premier cas.
Capacity reques ts

140
120
100 CR regular traf f ic
80
60 CR encrypted
40 traf f ic
20
0
1 26 51 76 101 126 151
pe riod num ber

Figure IV.19 Niveau des requêtes de capacités adréssées par le terminal

Nous concluons de ces observations et en raison de la manière avec laquelle le terminal

DVB-RCS a évalué les ressources à demander, que le chiffrement IPsec de la VoIP est
préjudiciable à une consommation optimisée des ressources. Cette constatation est vraie
essentiellement pour des flux de type voix. L’effet serait beaucoup moins visible s’il s’agissait
d’application de données (Web FTP..). En effet, dans ce cas, l’en-tête additionnel introduit
par IPsec (~ 40 octets) est négligeable devant la taille totale des paquets (1500 octets). La
variation de débit entre les cas chiffré et « clair » serait beaucoup moins notable et surtout
moins préjudiciable à la consommation de bande.
Les conclusions de ce test nous renvoient, encore une fois, à un aspect sur lequel le
standard DVB-RCS ne s’est pas clairement exprimé. On ne trouve pas dans la norme de
mention à propos du niveau protocolaire (IP, MPE ou MPEG) auquel les ressources doivent
être évaluées. Il n’est pas non plus spécifié la forme avec laquelle le terminal évalue la bande.
Est-ce en débit ou en nombre de slots que la Gateway attribue par la suite en RBDC ou
VBDC (débit ou volume) ? Là encore la norme laisse une liberté aux implantations.
IV.3.2.3 2ème scénario de test : BoD et qualité de service
Outre l’allocation de bande passante, il est important d’observer le comportement de
la VoIP chiffrée dans un contexte de réseau chargé avec des trafics de priorités différentes.
Nous générons du trafic de fond de plus faible priorité que la VoIP sur les voies Aller et
Retour. L’ensemble des flux transitent par le PEP pour être chiffrés avant transmission sur
satellite. L’objectif est de charger les liens Aller et Retour à hauteur de leurs capacités
maximales respectives. Ce sera le moyen de constater si les flux IP sont conformes aux
priorités définies.
Sur le lien Retour (figure 4.20) et dans le cas où les flux sont chiffrés, on observe une
croissance significative du délai qui atteint 600 ms. Le taux de pertes de paquets atteint les
30 %. Ceci dégrade sensiblement la qualité de la voix. Parallèlement, et dans le cas « clair »,
le délai garde des proportions acceptables de l’ordre de 260 ms et un taux de pertes de
paquets inférieur à 1%.

80
 Figure IV.20 Délais de la VoIP en chifré et en “clair” avec du trafic de fond sur la voie Retour

Sur le lien Aller DVB-S, le délai ne varie pas considérablement entre les cas chiffré et
clair (figure 4.21). Toutefois, le taux de pertes de paquets atteint les 40% dans le premier cas
rendant par là les communications VoIP inaudibles. En « clair », les communications VoIP
se déroulent dans des conditions « normales ».

Figure IV.21 Délais de la VoIP en chiffré et en “clair” avec trafic de fond sur la voie Aller

A partir de ces observations on constate que cette dégradation de performance sur les
deux liens n’est pas le résultat d’une mauvaise correspondance entre la qualité de service IP
et l’allocation de bande passante radio. En effet, quand il n’y a pas de chiffrement les
métriques de voix (délai, gigue et pertes de paquets) renvoient des valeurs correspondant à
des communications de bonne qualité d’autant plus que la voix est audible. Les délais et la
perte de paquets augmentent fortement pour un trafic de fond dont le débit ne dépasse pas la
moitié de la capacité totale du lien (Aller ou Retour).
Les délais excessifs et la perte de paquets sont davantage dus au comportement du
PEP. Dans le cas d’un trafic chiffré, le PEP un tunnel VPN par lequel transite la totalité du
trafic, représente un goulet d’étranglement. Chaque paquet IP est encapsulé et les en-têtes
ESP lui sont ajoutés. Cette opération très gourmande en CPU a une durée proportionnelle
au nombre de paquets arrivant par seconde. A ce stade, les règles de qualité de service dont
le rôle est de garantir les ressources mais surtout d’accélérer le routage des paquets à fortes
contraintes temporelles, ne sont pas applicables. Même si ces règles sont définies pour
chaque paquet IP, il n’est pas possible de contrôler l’accès des paquets au Crypto-Engine
(Chiffreur IPsec). Les règles de QoS IP n’ont aucun impact sur l’ordonnancement des
paquets quand ils accèdent au chiffreur IPsec. Si les paquets voix arrivent alors que la file
d’attente contient des paquets de données, ce sont ces derniers qui seront traités en premier.
Il n’y a pas de moyen à ce stade de distinguer les paquets IP temps réel de ceux ayant des
priorités inférieures. Le chiffreur agit selon une disposition de service premier arrivé,
premier servi. Par ailleurs, on constate que le délai de traitement des paquets IP par le
chiffreur croît à mesure que leur taille décroît. Ainsi les paquets VoIP mettent plus de temps
pour qu’IPsec soit appliqué (figure 4.22).

81
 IP s e c E n c r y p tion D e la y (m s )

700
600

D elay (m s)
500
400
300
200
100
0
80 1 00 120 1 25 250 5 00 1 000
P ack et S iz e ( B yte s)

A v er ag e D el ay ( B )

Figure IV.22 Durée du chiffrement IPsec en fonction de la taille des paquets IP

La taille des paquets arrivant au PEP combinée à un débit croissant du trafic de fond
sollicitent la CPU du chiffreur qui, au-delà d’un certain seuil, commence à rejeter des
paquets.

IV.3.2.4 Conclusion
Cette section a décrit les choix de configuration, l’évaluation théorique du coût
d’encapsulation ainsi que les tests expérimentaux portant sur la VoIP chiffrée par IPsec sur
un réseau DVB-RCS. On en conclut que les performances techniques ne confortent pas la
volonté de transmettre de la VoIP chiffrée par IPsec sur la plateforme IP DVB-RCS. Tout
d’abord, les ressources sont allouées inefficacement si les données sont chiffrées. Ensuite, le
PEP en cryptant les flux IP, augmente considérablement le délai de transmission et le taux
de perte de paquets.

IV.4. Conclusion
Dans ce chapitre, nous avons décrit les différents sous-systèmes constituant le réseau IP
DVB-RCS. Nous y avons évoqué, les choix technologiques, système et de configuration que
nous avons été amenés à faire. Nous avons notamment étudié la faisabilité technique d’un
service qui pouvait être proposé. Nous l’avons fait à travers des appréciations théoriques
mais surtout des tests expérimentaux sur la plateforme IP DVB-RCS. C’était aussi une
manière d’observer le comportement de l’ensemble de la chaine et de l’analyser en vue de
l’améliorer. Cela nous a aussi conduit à la conclusion que le DVB-RCS est une technologie
suffisamment fiable bien qu’encore ouverte sur plus d’un aspect. C’est ce qui explique
d’ailleurs son succès industriel. Néanmoins, elle n’est pas la seule sur le marché des réseaux
IP par satellite. Des technologies conçues spécialement pour transmettre de l’IP par satellite
ne manquent pas de succès à leur tour.
Ce sera précisément l’objet du chapitre suivant où nous établiront une comparaison
entre deux systèmes industriels. Le premier IP DVB-RCS, le second implante iDirect une
technologie propriétaire de plus en plus présente sur le marché.

82
V. Le nouveau standard DVB-S2 et les applications IP par
satellite

V.1. Introduction
La nouvelle génération du standard de diffusion par satellite, DVB-S2 [1] est
certainement la plus performante de celles qui existent actuellement. Elle apporte des
améliorations significatives. Cela va du changement dynamique du codage canal et de la
modulation à une pile protocolaire qui procure une meilleure efficacité d’encapsulation. Ce
nouveau standard a eu un écho favorable auprès des équipementiers satellite. Ils ont même
commencé à le proposer dans des systèmes, y compris bidirectionnels et anciennement
basées sur DVB-S ou des formats propriétaires. C’est en particulier le cas des technologies
étudiées DVB-RCS et iDirect.
Le travail présenté dans ce chapitre a été intégré dans un projet de recherche et
développement, une étude d’évaluation du nouveau standard lorsqu’il est amené à
transmettre des flux IP. Nous nous intéressons à l’avantage procuré par DVB-S2, intégré à
une voie retour par satellite (RCS), pour transmettre de l’IP.
La première partie du chapitre fournit une présentation du nouveau standard. Nous mettons
en évidence les nouveaux aspects qu’il introduit tant sur le plan de l’encapsulation des
données, que sur la modulation et le codage adaptatifs.
Ensuite, nous procédons à la description des évaluations théoriques et des expérimentations
menées sur un réseau prototype DVB-S2/RCS suivie par l’interprétation et l’analyse que
nous faisons des observations et des résultats. Ce travail a été mené dans le cadre du projet
DVB-S2 satellite experiment dont nous donnons davantage de détails par la suite.
Notre contribution porte sur l’intégration de la plateforme DVB/S2-RCS sur banc de test et
dans un environnement satellite. Elle concerne la définition et la mise en œuvre des tests
applicatifs IP en plus du travail d’interprétation et d’analyse.

V.2. Le standard DVB-S2

V.2.1 Introduction
Le DVB-S2 a été publié en mars 2005 par l’ETSI pour pallier les limites du standard
DVB-S. On assistait depuis quelques années à une carence croissante des fréquences,
accentuée par l’avènement de nouveaux services de diffusion à haute définition. Le DVB-S2
représente la solution pour accroître la capacité de transmission, en particulier celle de la
télévision numérique haute définition par satellite.
La norme DVB-S ne définit que le QPSK (Quadrature Phase-Shift Keying) comme schéma de
modulation. C’est une contrainte notable pour les infrastructures professionnelles en place
et pouvant acheminer des débits plus élevés des schémas de modulation plus développés. Le
standard DVB-DSNG (Digital Video Broadcasting Digital Satellite News Gathering) [2] a
apporté la solution pour ce contexte particulier d’utilisation19 en apportant plus de capacités
avec les modulations 8PSK et 16QAM.

19 Des équipes de télévision sur le terrain diffusant des émissions en direct ou en différé vers les régies centrales

avant de les retransmettre au grand public.

83
Pourtant, le besoin de recourir à des ModCod 20 avec des valeurs d’Es/No (rapport énergie
par symbole par densité de bruit) plus faibles, et donc le recours à d’autres codages canal que
le Reed Solomon, se faisait sentir.
La nouvelle génération de la norme est venue combler les lacunes qui persistent
principalement au niveau de la couche physique. On pourra donc caractériser les apports du
standard ainsi :

Un codage canal plus puissant LDPC (Low Density Parity Check) et BCH (Bose-
Chaudhuri-Hocquenghem).

Un mode adaptatif où la chaine de transmission fait varier le débit utile en fonction
des conditions de transmission.

Un large éventail de codages et de modulations avec un total de 28 ModCod allant de
QPSK ¼ à 32APSK 9/10, qui couvrent un grand intervalle de valeurs de signal sur
bruit de -2 dB à +17 dB environ.

Un format de trame ainsi qu’un schéma d’encapsulation plus efficace qui s’accommode
d’une variété de sources d’entrée (flux continus, multiplex MPEG-TS, paquets IP...)

La norme ne se restreint plus au seul standard de compression MPEG-2 (audio et
vidéo). Elle s’adapte à un large éventail de schéma de compression et de codage, en
particulier MPEG-4 et son option AVC, également standardisée par le groupe sous le
nom de H.264.
Le DVB-S2 est une technologie relativement « jeune » si on considère les équipements
industriels en vente sur le marché. Toutefois, les performances qui se profilent des
évaluations théoriques ainsi que des premières expérimentions sont largement meilleures
que ce que présentait le DVB-S.

Un codage canal efficace et proche de la limite théorique de Shannon.

Une meilleure efficacité spectrale
o 30% pour un même débit symbole et un rapport C/N donné [3]
o Plus de 100% à 200 % de gain avec le codage et la modulation adaptatifs
(ACM) en fonction de la condition du lien. [3]

Une meilleure disponibilité de la liaison satellite (de l’ordre de 99,9% quand l’ACM
est activé).

Une meilleure couverture géographique.
De part ses caractéristiques, le DVB-S2 apparaît comme un standard flexible pouvant
répondre à une variété d’applications par satellite. Cela va des services DTH à la télévision
numérique en passant par les services interactifs. C’est pourquoi la norme propose plusieurs
profils d’utilisation.

Le profil diffusion (Broadcast), est le contexte le plus répandu du standard avec des
services de télévision numérique en simple et haute définition. Dans ce cadre, les
utilisations type DVB-DSNG sont possibles bien que les équipements de ce genre
soient encore assez rares.

20 Le terme ModCod, signifie Combinaison d’un taux de codage et d’un schéma de modulation

84

Le profil interactif, destiné à fournir des services interactifs notamment, IP avec
l’accès à Internet par satellite pour des particuliers ou des petites structures. Il ne
requiert pas d’infrastructures coûteuses ni sophistiquées.

Le profil professionnel. Il ne se distingue du profil interactif que par le niveau de
fiabilité de ses infrastructures et la taille de ses antennes. Il est destiné aux
applications IP bidirectionnelles par satellite dans un cadre d’utilisation
professionnelle. Il permet des transferts de données en mode point à point ou point à
multipoints. Il est amené à assurer un certain niveau de services comme un débit
minimum garanti ou une disponibilité élevée.

V.2.2 Les principaux apports du standard

Les principaux apports du standard résident dans la couche physique. Les
innovations concernent deux aspects essentiels :

L’introduction d’un codage canal plus performant et des schémas de
modulation permettant des débits plus élevés.

La possibilité de modifier le ModCod trame par trame et l’adapter aux
conditions de transmission, soit par l’intermédiaire du mode VCM (Variable
Coding and Modulation) ou par l’ACM en présence d’une voie retour.
V.2.2.1 La correction d’erreur et la modulation
Le DVB-S2 profite des avancées technologiques récentes apportées sur les codeurs.
Le codage canal qu’il met en place améliore sensiblement les conditions de transmission dans
un canal fortement bruité comme le lien satellite.
Pour ce faire, la norme repose sur une concaténation d’un code en bloc interne LDPC et d’un
code en bloc externe BCH. Ce schéma remplace le codage convolutif concaténé Reed Solomon
de DVB-S et propose 11 taux de codage.
Le codage LDPC retenu, a été découvert en 1963 [4]. Il offre un écart minimal, inférieur à 1
dB, par rapport à la limite théorique de Shannon sur un canal de bruit blanc Gaussien
AWGN (Additive White Gaussien Noise). (cf. figure 6.1)

Figure V.1 ModCod et Eb/No [5]

85
 Il représente une amélioration de l’ordre de 2 dB comparé au codage Reed Solomon.
Cela se traduit par une augmentation des marges en puissance d’un système donné et de la
réduction des dimensions des antennes en réception pour un débit donné
Un autre avantage du codage LDPC provient les performances qu’il apporte à des débits
élevés et pour de longueurs de blocs importantes ainsi qu’à la relative simplicité de ses
décodeurs [5]. Deux longueurs de bloc sont retenues pour le DVB-S2, une trame courte
16200 bits et une trame longue de 64800 bits. Bien que les trames courtes soient moins
efficaces, elles restent recommandées pour des applications qui exigent un long temps
d’attente ou des délais plus courts.
Quatre schémas de modulation sont proposés par la norme DVB-S2. Les modes
QPSK et 8PSK sont mieux adaptés aux applications de radiodiffusion car elles disposent
d’une enveloppe quasi constante [5]. Elles peuvent donc être utilisées avec des répéteurs
satellite non-linéaires portés à quasi-saturation [6]. Les deux autres modes proposés sont le
16-APSK et le 32-APSK. Ils se caractérisent par un rendement énergétique moindre
puisqu’ils exigent un niveau plus élevé du rapport C/N. Ils présentent, tout de même, une
efficacité spectrale nettement supérieure recommandée pour un contexte d’utilisation
professionnelle.

Figure V.2 Schémas de modulations DVB-S2

Ces ordres de modulations supérieurs présentent des gains en efficacité en raison d’un
plus grand nombre de bits mappés dans les constellations.
Codage et modulation sont combinés pour proposer 28 ModCods au total. Afin d’atténuer les
mauvaises performances énergétiques de certains ordres de modulation, la norme adapte le
choix du taux de codage en vue d’améliorer les performances en puissance. La figure 6.3 [6]
présente les efficacités spectrales théoriques en fonction du rapport C/N (Roll-off exclu)
dans un canal AWGN.

86
 Figure V.3 Efficacité spectrale théorique en présence d’un bruit gaussien [6]

On peut observer que certains ModCods présentent une faible efficacité spectrale pour un
niveau élevé de signal sur bruit par rapport à d’autres ModCods. En effet, en fonction du
canal et des conditions de transmission, du satellite et du point de fonctionnement souhaité,
chaque opérateur fera son choix parmi les 28 ModCods proposés par le standard.
Dans ce cas d’utilisation, seuls 22 ModCos sont retenus. A titre d’exemple, on privilégie le
ModCod 8PSK 3/5 au QPSK 5/6 puisque le premier présente une meilleure efficacité
spectrale pour le même rapport de signal sur bruit. Pour le projet DVB-S2 Satellite
Experiment –que nous présenteront par la suite- également seuls 22 ModCods sont
éxploitables.
A titre d’illustration, nous présentons la courbe ci-dessous (figure 6.4) obtenue dans
le cadre du projet DVB-S2 Satellite Experiment. Avec une antenne de 1,2 m en réception d’une
porteuse DVB-S2. Elle balaye les valeurs d’efficacité spectrale en fonction du niveau du
signal pour les 28 ModCod. On notera que les valeurs couvrent un intervalle allant de -2 à
17 dB ce qui traduit la souplesse procurée par le standard DVB-S2. Aussi, est il toujours
possible d’émettre même en cas de très mauvaises conditions puisque on observe que pour
une modulation en QPSK 1/4, le niveau de puissance du signal est inférieur à celui du bruit.
DVB-S2 Assumptions (FECFRAME = 64800 bits)

4,5

4,0
Efficiency including carrier spacing in bit/s/Hz

3,5

3,0

2,5

2,0

1,5

1,0

0,5 QPSK 8-PSK 16-APSK 32-APSK

0,0
-3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Es/No in dB

Figure V.4 Efficacité spectrale et Rapport signal sur bruit [3]

87
 En plus d’une multitude de ModCods et afin d’améliorer encore l’efficacité du répéteur
satellite, la norme DVB-S2 propose deux facteurs additionnels de Roll-off permettant
d’optimiser l’occupation de bande. En ayant recours à des valeurs inférieures, on peut soit
« rapprocher » les porteuses adjacentes d’un transpondeur, soit augmenter le débit symbole
pour une même largeur de bande.

Tableau V-1 Les facteurs de Roll-off en DVB-S2

V.2.2.2 Le codage et la modulation adaptatifs

Le standard DVB-S2 a été conçu pour une multitude d’applications à haut débit, y
compris les services interactifs en particulier ceux fondés sur de l’IP. Avec l’adoption du
codage et de la modulation adaptatifs ACM (Adaptive Coding and Modulation), il permet de
modifier le taux de codage canal et le schéma de modulation sur une base trame par trame.
Au moyen d’une voie retour (par satellite), l’émetteur est renseigné sur les conditions de
réception, et adapte en conséquence le ModCod.
Les systèmes satellites multi faisceaux implantant le DVB-S ont été dimensionnés en
fonction du pire cas de transmission selon la disponibilité visée. Le standard, envisagé pour
des services en diffusion, considère donc un taux de codage et un schéma de modulation qui
demeurent fixes au cours de la transmission. C’est par ailleurs ce qui est appelé CCM
(Constant Coding and Modulation). Ce ModCod a été sélectionné en fonction de la couverture
ainsi que du niveau de disponibilité convenu. Cette approche implique le recours à une marge
fixe en plus de la puissance requise du signal dans le but de compenser les atténuations
résultant de mauvaises conditions de propagation. Pourtant, et dans la plupart du temps, les
interférences et les conditions de propagations permettant un meilleur niveau du signal
SNIR (Signal to Noise plus Interference Ratio). Par exemple, les liens de diffusion en bande Ku
sont dimensionnés avec une marge de 4 à 6 dB pour une disponibilité de 99% le pire mois
(une moyenne de 99,6%). Or et vu la nature des atténuations, cette marge peut s’avérer utile
uniquement pour une région donnée et ce pendant quelques minutes par an. Ces pertes en
ressources peuvent difficilement être évitées dans le cas de services de diffusion puisque des
millions de récepteurs dispersés dans la zone de couverture reçoivent simultanément le
même contenu. En revanche, ce dimensionnement n’est pas optimal pour les réseaux point à
point interactifs par satellite.
Fort de ce constat, le DVB-S2 permet d’exploiter cette dispersion des récepteurs dans
le temps et dans l’espace afin d’émettre au meilleur débit. Par conséquent, l’émetteur adapte
le ModCod en fonction du niveau de signal SNIR du récepteur. Ainsi, le débit devient
dépendant du temps et de la localisation du récepteur.
En cas de bonnes conditions de propagation, typiquement la plupart du temps, le signal
SNIR prend des valeurs élevées. Cela facilite le recours à des schémas de modulation à forte
efficacité spectrale comme 16APSK ou 32APSK et accroît le débit de transmission. Si les
conditions se dégradent, le système se replie sur des ModCod plus robustes pouvant
transmettre même avec un faible niveau de signal sur bruit. A partir des informations sur les
conditions de réception que remontent les terminaux via une voie retour, l’ACM change de
ModCod sur une base trame par trame en l’adaptant aux conditions de propagation propres
à chaque destination.

88
Dans le même esprit, le standard propose le VCM (Variable Coding and Modulation). Cette
technique adapte les ModCod en fonction de la destination du trafic dans la zone de
couverture (sans aucun retour d’information de la part les récepteurs). Le VCM donne la
possibilité de transmettre plusieurs services sur une même porteuse, chacun utilisant son
propre ModCod. Ce multiplexage au niveau physique, permet un codage et une modulation
en fonction des services (SDTV, HDTV, audio, multimédia) qui ne nécessitent pas le même
degré de robustesse.
V.2.2.3 ACM et les applications IP interactives
De part le caractère bidirectionnel des réseaux sur lesquels ils sont implantés, les
services interactifs, en particulier les applications IP, tirent un avantage réel de recours à
l’ACM. En étant informés par l’intermédiaire d’une voie retour sur les conditions de
réception, il est possible d’optimiser les paramètres de transmission en fonction de chaque
utilisateur mais aussi de l’état du canal. De plus, la diversité des schémas de modulation et
des niveaux de protection d’erreur procure à l’opérateur une marge de liberté dans la
différentiation de ses niveaux de services (en fonction de la priorité de chacun, du débit
minimal garanti...)

Figure V.5 Fonctionnement schématiques du DVB-S2 ACM [7]

Dans les systèmes ACM, les paramètres physiques retenus pour chaque trame ne
sont pas dissociés du processus d’ordonnancement. Si on considère des paquets IP, ceux
contenus dans la même trame sont transmis avec le même ModCod. Formulé autrement, les
données (IP ou autres) contenues dans une même trame doivent être sélectionnées en
prenant en considération les paramètres physiques requis pour le terminal destination. C’est
la raison pour laquelle, l’information relative au ModCod est générée en même temps que les
données (utilisateurs) et envoyée en entrée du modulateur DVB-S2 ACM. La figure 6.5
décrit le principe de fonctionnement du module DVB-S2 ACM.
Le module Merger sélectionne un nombre de paquets à partir des files et les combine
pour former un ensemble de bits d’informations. Les trames ainsi constituées sont envoyées
au modulateur ACM avec les paramètres de transmission associés.
V.2.3 Les méthodes d’encapsulation
Outre le codage et la modulation adaptatifs, le standard DVB-S2 offre un nouveau
schéma d’encapsulation. Il tolère de multiples formats en entrée, en plus du schéma classique
MPE MPEG, cellules ATM, des formats génériques de trames ou même des flux continus
de données. Pour les paquets IP, les deux principales méthodes qui se dégagent sont :

89

Une encapsulation MPE/MPEG similaire au standard DVB-S sur certains
aspects.

Une encapsulation GSE (Generic Stream Encaspulation) où les paquets IP sont
fragmentés et/ou contenus dans des paquets de niveau 2 de longueur fixe ou
variable. Ils peuvent également être directement mappés sur le flux TDM
Dans cette section, nous allons décrire deux méthodes d’encapsulation. La première repose
sur MPE MPEG à l’instar du standard DVB-S. Elle est implantée dans les premiers
systèmes DVB/S2-RCS. La seconde GSE (Generic Stream Encapsulation) est encore au stade
de spécification par le groupe DVB et a l’avantage de présenter des performances supérieures
en termes d’efficacité d’encapsulation.
V.2.3.1 L’encapsulation MPE MPEG
C’est une encapsulation « classique » MPE MPEG d’un paquet IP avec l’ajout d’un
en-tête de 12 octets et d’une somme de contrôle CRC de 4 octets pour générer une section
privée MPE. Ensuite les paquets MPE sont fragmentés afin d’être contenu dans des paquets
MPEG-TS de 184 octets de champ données. Du bourrage est introduit sur les paquets IP
partiellement remplis dans le cas où le mode Section Packing n’est pas activé.

Figure V.6 Encapsulation IP MPE avec le mode Section Packing (Sans bourrage)

V.2.3.2 L’encapsulation GSE (Generic Stream Encapsulation)

Le protocole GSE [8] permet l’encapsulation des paquets IP ainsi que des paquets ou
trames provenant d’autres protocoles de niveau réseau à véhiculer sur DVB-S2. Conçu en
parallèle au standard, et il est en voie de normalisation, il est censé remplacer l’encapsulation
MPE/MPEG-TS. Nous n’entendons pas le présenter dans ses détails mais plutôt en
présenter les aspects qui nous servirons par la suite notamment pour la comparaison
d’efficacité avec MPE/MPEG-TS.
GSE supporte une multitude de protocoles « réseau » (IPv4, IPv6, Ethernet…). Plus
généralement, ils sont appelés PDU (Packet Data Unit). Il permet le transport de paquets
chiffrés ainsi que la compression d’en-tête IP. Il supporte notamment plusieurs modes
d’adressage (Multicast, Unicast, adressage IP…)
GSE agit en définissant le début et la fin de chaque PDU, ajoute des informations de
contrôle comme le type du protocole réseau. Il permet des contrôles d’intégrité lorsque c’est
nécessaire. Il offre notamment la possibilité de fragmenter les paquets IP et plus
généralement les PDUs dans le cas où c’est nécessaire.

90
 La longueur d’un paquet GSE varie en fonction du PDU qu’elle contient. La
composition de son en-tête l’est également. La figure 6.7 décrit la forme que peut prendre un
paquet GSE quand il contient un PDU entier (non fragmenté). Dans ce cas, la taille d’en-tête
ajoutée par GSE est de 10 octets.

Figure V.7 Format d’un paquet GSE (PDU complet) [8]

V.2.4 L’interface air du standard DVB-S2

Une fois les paquets MPEG ou GSE générés, c’est un format de trame conçu par le
standard DVB-S2 qui intervient. La plateforme de tests implante un schéma d’encapsulation
MPE/MPEG, on adaptera donc notre description à cette méthode.
Les cellules MPEG-TS devant assurer un même niveau de service sont associées aux
paramètres physiques qui leur correspondent. Elles sont ensuite insérées dans le champ de
données de la trame en Bande de Base ou BB Frame définie par le standard. Une BB Frame
est composée d’un en-tête fixe de 10 octets et d’un champ de données DFL (Data Field
Length) de longueur fixe pour un taux de codage et une modulation donnés. Sa taille varie
uniquement en fonction du ModCod utilisé. Une BB Frame représente les données à l’entrée
du codeur canal (BCH puis LDPC).
Pour les flux de diffusion ou les flux DSNG, la totalité du champ de données DFL d’une BB
Frame (K-BCH21 – 80) est remplie. En revanche, pour les applications unicast, seul un
nombre entier de cellules MPEG-TS (ou GSE) peut être contenu dans une BB Frame. Cela
simplifie l’opération de décodage côté récepteur. Par conséquent, du bourrage est introduit
pour remplir la partie restante du champ de données DFL. Ceci est également le cas, quand
le nombre cellules MPEG n’est pas suffisant pour remplir le champ de données. Plus
généralement, du bourrage est introduit à chaque fois qu’on a l’inégalité suivante DFL < (K-
BCH – 80). (Figure 6.8)
Remarque
Le bourrage et la taille de la BB Frame en entrée du codeur dépend notamment du choix
Long Frames (64800 bits) ou Short Frames (16200 bits) proposées par la norme.

21 K-BCH spécifie la taille totale d’une BB Frame avant codage, en-tête compris.

91
 Figure V.8 L’air interface DVB-S2 avec ACM [8]

A la sortie du codeur canal, une FEC Frame est ainsi générée. Elle correspond à une
trame de 64800 ou de 16200 bits. La FEC Frame est ainsi fragmentée en un nombre de slots
de longueur identique (90 symboles par slot) et d’un en-tête de même longueur. L’ensemble
constitue ce que le standard définit comme la Physical Layer Frame ou PL Frame. (Figure
6.8)
En mode ACM, chaque trame peut avoir son propre ModCod. L’en-tête au niveau physique
(PL Header) sert, entre autres, à indiquer au démodulateur côté réception, le taux de codage
et la modulation appropriés à utiliser. De plus, et afin de faciliter la démodulation,
spécialement pour les ordres supérieurs (8PSK, 16APSK et 32APSK) même en présence d’un
bruit de phase ou d’un léger décalage en fréquence, le standard recommande le recours au
Pilot Symbols, introduits périodiquement au sein d’une trame physique PL Frame. Notons,
finalement que le temps d’émission d’une FEC Frame dépend aussi du schéma de
modulation.

V.3. Le projet DVB-S2 Satellite Experiment et les expérimentations

V.3.1 Introduction
Le projet DVB-S2 Experiment a été lancé par l’Agence Spatiale Européenne (ESA) afin
de mener une évaluation en profondeur en laboratoire et sur satellite des multiples
nouveautés introduites par le standard DVB-S2. Le projet est piloté par EADS Astrium en
tant que maître d’œuvre. Il regroupe notamment de multiples acteurs du monde satellite
comme les équipementiers ou les opérateurs satellites. Les premiers contribuent en
fournissant les équipements DVB-S2 ou DVB-S2/RCS prototypes ou commerciaux. Les
seconds mettent à disposition leurs infrastructures ainsi que l’accès au satellite.
Le premier objectif du projet est de monter des plateformes de tests à partir de
solutions proposées dans l’industrie. Il tend par là à valider le fonctionnement des
nouveautés introduites par le standard et ce pour les trois profils d’application (broadcast,
interactif et professionnel).

92
 Le but ultime de projet est de convaincre les acteurs du monde des télécommunications
par satellite d’intégrer le nouveau standard dans leur solution.
Notre tâche au sein de ce projet vient compléter le travail que nous avons entamé dans
le cadre de cette thèse. Notre contribution commence par l’intégration du banc de test
DVB/S2-RCS spécifique au profil professionnel d’utilisation du standard DVB-S2. C’est par
ailleurs l’une des premières plateformes dans le monde. Notre travail s’étend également à la
spécification et la mise en œuvre des tests applicatifs et à l’analyse et l’interprétation des
résultats.
La démarche expérimentale portait dans un premier temps sur une évaluation
théorique de l’encapsulation IP sur DVB-S2. Dans un deuxième temps on cherche à analyser
le comportement des applications IP (VoIP, applications TCP) en présence d’une boucle de
codage et de modulation adaptatifs. En cas de dégradation des conditions de transmission,
l’ACM intervient en adaptant les paramètres physiques de la transmission. Ce changement
induit entre autres une variation du débit utile.
Notre observation porte sur l’effet qu’entraîne la variation de débit sur les applications
IP ayant des niveaux de priorités différents.
V.3.2 La plateforme de tests
V.3.2.1 Description

Pour le profil professionnel, plusieurs applications IP ont été évaluées afin d’en
apprécier le comportement avec une boucle DVB-S2+ACM en plus du délai de transmission
ainsi qu’une bande passante variable dans le temps.

DVB-S2
DVB-S2 Traffic
Traffic
/RCS
/RCS Generator
Generator
Terminal
Terminal && Analyser
Analyser
Remote Site

A
Amplifier
Amplifier LNB
LNB
Up-Conv.
Up-Conv.
Gateway Hub
A DVB-S2
DVB-S2 Traffic
Traffic
NCC/NMS
MF/TDMA
MF/TDMA Interface
Interface /RCS
/RCS Generator
Generator
Receiver
Receiver Module
Module Terminal
Terminal && Analyser
Analyser

Traffic
Traffic DVB-S2
DVB-S2 DVB-S2
DVB-S2 Traffic
Traffic
Generator
Generator Scheduler
Scheduler CCM/ACM
CCM/ACM /RCS
/RCS Generator
Generator
&& Analyser
Analyser Modulator
Modulator Terminal
Terminal && Analyser
Analyser
B
Application
Application Application
Application
Spectrum
Spectrum
PC
PC PC
PC
Analyser
Analyser
Main Site

Control & VPN /

Monitoring Internet
System

Figure V.9 La plateforme de test DVB-S2 Experiment pour le profil professionnel par satellite

Dans son principe et son architecture, le banc de tests est similaire à celui décrit au
chapitre 3. La différence se situe au niveau des équipements DVB-S2/RCS avec

Un segment opérateur comprenant un NCC (Network Control Center) avec une
Gateway DVB/S2-RCS. Le sous-système Aller FLS (Forward Link Subsystem)
implante un lien DVB-S2+ACM avec les 22 ModCod « utiles » disponible, des trames

93
 longues (64800 bits) à la sortie du codeur canal, l’option insertion des symboles
pilotes activée et un schéma d’encapsulation MPE/MPEG. Le temps de réponse de la
boucle ACM est d’environ 1s.

Deux segments utilisateurs avec des terminaux DVB-S2/RCS et des réseaux
locaux composés d’IP phones et de PCs. Les RCSTs implantent une voie retour RCS
avec un schéma d’encapsulation MPE/MPEG. L’adaptation apportée aux terminaux
par rapport au cas DVB-S est le DRA (Dynamic Rate Assignment). C’est la possibilité
de faire varier dynamiquement le débit en réception en fonction du changement du
ModCod.

Un segment satellite qui varie en fonction de la configuration de tests
o Dans un premier temps un simulateur satellite est utilisé. Il a pour rôle de
simuler un comportement réel d’une liaison satellite géostationnaire avec le
délai, la dégradation du signal en plus d’un scénario de fading22 complet
permettant le recours à l’ACM.
o Dans un second temps, c’est une vraie liaison satellite qui est mise en place.
Cela permet d’un côté de voir le comportement des applications dans un
contexte réel. Il est en revanche, moins évident d’observer le comportement
de la boucle ACM. En effet, il est plus difficile et plus rare à une échelle de
temps de quelques semaines d’observer un réel phénomène de fading
Sur un plan applicatif IP, aussi bien pour la VoIP que pour l’accélération, nous avons repris
les mêmes solutions techniques utilisées précédemment

Un PABX (Private Automatic Branch eXchange) reposant sur le logiciel Open Source
Asterisk.

Des modules d’accélération TCP placés des deux extrémités du lien satellite au
niveau de la Gateway et des terminaux.

3 Satellite

Gateway Terminal
Applica Channel Applica
2 tion tion
Simulator

1 IP Satellite System Emulator

Realtime IP Observer (RIO tool)

Figure V.10 Blocs fonctionnels du banc de tests DVB/S2-RCS

V.3.2.2 Fonctionnement du lien Aller DVB-S2

22 Ce terme désigne une dégradation du signal nécessitant la mise en œuvre de procédés de contre mesure tels

que l’ACM.

94
 Le fonctionnement du sous-système Aller DVB-S2 ACM représente la modification
la plus significative par rapport à la plate forme IP DVB-RCS. Nous en donnons donc un
bref descriptif dans ce qui suit.
A l’arrivée des paquets IP et tel que décrit par la figure 6.11, une encapsulation en MPE est
effectuée suivie par une fragmentation en paquets MPEG avec le mode Section Packing (Sans
Bourrage) activé.
Applications

TCP/UDP

IP IP

MPE/DSM-CC

MAC MAC MPEG

BBFRAME

PHY (Ethernet) PHY (Ethernet) PHY (DVB-S2)

Satellite Network
Terrestrial Network

Figure V.11 La pile de protocole DVB-S2

La phase d’encapsulation est suivie par la prise en charge des paquets par
l’ordonnanceur. Il a pour tâche de répartir les paquets selon les différents niveaux de
priorités IP spécifiés. L’ordonnancement (ou Scheduling) est l’étape la plus critique de la
transmission en raison de son impact sur les performances de la transmission DVB-S2. La
prise de décision du module d’ordonnancement est régie par la qualité se service IP, ainsi le
choix des paramètres physiques (ModCod).
Le banc de test DVB-S2 experiment étant principalement un prototype pour un profil
professionnel d’utilisation du DVB-S2, pour les flux de données, 2 classes de services ont été
prévues : temps réel et Best Effort. Le fonctionnement global de la chaîne, encapsulation et
ordonnancement décrit par la figure 6.12.

MAC & PID HH

HH
H
IP Header
Routing and Best effort
IP Header Encapsulation
IP Header Classifying

HH
HH
Drop QoS-marking H
Real-time constraint
QoS

Figure V.12 Encapsulation et ordonnancement

En plus des flux de données, une file d’attente pour la signalisation est prévue et
dispose de la plus haute priorité. Au niveau physique, et au vue de son importance critique, la
signalisation est diffusée avec la modulation et le codage canal le plus robuste, le ModCod 1
(QPSK ¼).
L’encapsulation couche physique de banc de test a été implantée conformément au standard.
Seul un nombre entier de paquets MPEG peut être encapsulé dans une BB Frame. La

95
fragmentation d’un paquet IP sur plusieurs paquets MPEG n’est pas permise. Du bourrage
est donc introduit dans les trames Bande de Base partiellement remplies.
Le nombre maximal de paquets MPEG-TS par BB Frame dépend du ModCod et du débit
symbole. La manière avec laquelle les BB Frames sont remplies dépend de la taille des
paquets MPE issus de l’encapsulation. Si la longueur du paquet MPE suivant est supérieure
à la partie non encore remplie dans la BB Frame, alors du bourrage est introduit aussi bien
dans le paquet MPEG que dans la BB Frame.
Notons encore une caractéristique spécifique au banc de test DVB-S2 experiment mais qui
n’est pas sans impact sur les performances en occupation de bande par les paquets IP. Les
terminaux, utilisés sont à la base prévus pour le DVB-S et conçus pour fonctionner en CCM
(Constant Coding and Modulation). Le constructeur a dû les adapter au mode ACM et leur
permettre de recevoir de porteuses dont le débit varie dynamiquement en fonction du
ModCod. Le nombre maximal de cellules MPEG a été limité à une certaine valeur pour
chaque ModCod, inférieure à celle définie par le standard.
V.3.3 Les évaluations théoriques
Dans le cadre du projet et en parallèle aux expérimentations menées sur le banc de
tests, nous avons effectué une évaluation des encapsulations successives des paquets IP au
sein de la pile de protocole DVB-S2. En plus des éléments de repère dégagés de cette étude
théorique, cela a l’avantage de nous sensibiliser à la manière d’optimiser ces encapsulations
et à améliorer l’occupation de la bande passante.
Notre schéma d’encapsulation de référence reste le profil IP/MPE/MPEG sur DVB-S2
(voir figures 6.6 et 6.8). Dans ce qui suit, nous cherchons à déterminer le nombre maximal
de paquets MPEG et de paquets IP à transporter par BB Frame en fonction d’un ModCod
donné. Au risque de se répéter, ci-dessous nous énumérons les critères et les hypothèses
servant de base à l’évaluation:

Un paquet IP est composé d’un champ de donnée en plus d’un en-tête de 20 octets.

L’encapsulation MPE DSM-CC ajoute un en-tête de 12 octets et une somme de
contrôle de 4 octets.

Le mode Section Packing est activé au niveau de l’encapsulation MPEG-TS avec un
en-tête de 5 octets (au lieu de 4) pour le premier MPEG-TS contenant le premier
fragment d’une section MPE DSM-CC.

Au niveau de la couche physique DVB-S2, chaque BB Frame transporte un nombre
entier de paquets MPEG-TS. Une BB Frame est composée d’un champ de données et
d’un en-tête de 10 octets.
V.3.3.1 Cellules MPEG-TS par BB Frame
Ainsi le nombre maximal de paquets MPEG est donné par la formule (1)

K − 80 
N MPEG =  BCH  23 (1)
 188 × 8 
Le tableau ci-dessous, établit en fonction des ModCod, le nombre d’octets utiles par trame
Bande de Base et le nombre maximal de paquets MPEG correspondant

23 K-BCH représente la longueur totale (données + en-tête) d’une BB Frame avant codage.

96
 Useful data Nb of
Modcod Modulation / BCH Uncoded
BBheader per FEC MPEG
Number Coding Block Length
Frame Packets
1 QPSK 1/4 16008 bits 80 bits 15928 bits 10
2 QPSK 1/3 21408 bits 80 bits 21328 bits 14
3 QPSK 2/5 25728 bits 80 bits 25648 bits 17
4 QPSK 1/2 32208 bits 80 bits 32128 bits 21
5 QPSK 3/5 38688 bits 80 bits 38608 bits 25
6 QPSK 2/3 43040 bits 80 bits 42960 bits 28
7 QPSK 3/4 48408 bits 80 bits 48328 bits 32
8 QPSK 4/5 51648 bits 80 bits 51568 bits 34
9 QPSK 5/6 53840 bits 80 bits 53760 bits 35
10 QPSK 8/9 57472 bits 80 bits 57392 bits 38
11 QPSK 9/10 58192 bits 80 bits 58112 bits 38
12 8-PSK 3/5 38688 bits 80 bits 38608 bits 25
13 8-PSK 2/3 43040 bits 80 bits 42960 bits 28
14 8-PSK 3/4 48408 bits 80 bits 48328 bits 32
15 8-PSK 5/6 53840 bits 80 bits 53760 bits 35
16 8-PSK 8/9 57472 bits 80 bits 57392 bits 38
17 8-PSK 9/10 58192 bits 80 bits 58112 bits 38
18 16-APSK 3/5 43040 bits 80 bits 42960 bits 28
19 16-APSK 2/3 48408 bits 80 bits 48328 bits 32
20 16-APSK 3/4 51648 bits 80 bits 51568 bits 34
21 16-APSK 5/6 53840 bits 80 bits 53760 bits 35
22 16-APSK 8/9 57472 bits 80 bits 57392 bits 38
23 16-APSK 9/10 58192 bits 80 bits 58112 bits 38
24 32-APSK 3/4 48408 bits 80 bits 48328 bits 32
25 32-APSK 4/5 51648 bits 80 bits 51568 bits 34
26 32-APSK 5/6 53840 bits 80 bits 53760 bits 35
27 32-APSK 8/9 57472 bits 80 bits 57392 bits 38
28 32-APSK 9/10 58192 bits 80 bits 58112 bits 38

Tableau V-2 Nombre maximal de cellules MPEG en fonction du ModCod

Une remarque importante se dégage de ce tableau et pour ce schéma d’encapsulation.

Pour chaque ordre de modulation, on retrouve le même nombre de cellules MPEG
transportées pour les deux taux de codage les plus élevés. Ainsi, on transporte la même
quantité d’informations utiles dans ces deux cas. Le choix à recommander à l’opérateur est
d’utiliser le ModCod le plus robuste (avec le plus faible taux de codage) et par ailleurs celui
qui requiert un niveau plus bas de signal sur bruit. Plus généralement, le nombre de paquets
MPEG-TS par BB Frame est indépendant de la modulation et dépend uniquement du taux
de codage.
V.3.3.2 Paquets IP par BB Frame
Ce calcul représente la première étape de l’évaluation du nombre de paquets IP à encapsuler
par BB Frame en fonction de la longueur des premiers. L’overhead introduit sur un paquet
IP avant la fragmentation MPEG est de 17 octets (MPE + IP). Dans le cas où plusieurs
paquets IP sont encapsulés au sein d’un même paquet MPEG, l’overhead introduit pour les
autres paquets IP est de 16 octets.
Les sections MPE sont « mappées » dans les 184 octets utiles d’un paquet MPEG et le
nombre maximal de paquet IP est donné par la formule (2)
 N MPEG × (183 + δ ) 
N IP =  
 IP _ packet _ size + (16 + δ )  (2)
where δ = 1 when IP _ packet _ size ≥ 167, 0 otherwise
On itère la formule (2) pour des tailles de paquets IP allant de 1 jusqu’à 1460 octets
(inférieur au MTU Ethernet). Le résultat est donné par la figure 6.13

97
 1000

code 1/4
Number of IP packets per Frame

100 code 1/3

code 2/5
code 1/2
code 3/5
code 2/3
code 3/4
code 4/5
code 5/6
10 code 8/9
code 9/10

1
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500
IP Packet Size in Bytes

Figure V.13 Nombre maximal de paquets IP par BB Frame et par ModCod

Notons que le nombre de paquets IP diminue au fur et à mesure qu’on approche du MTU
(Maximum Transfer Unit) Ethernet de 1500 octets, où seulement 4 paquets peuvent être
contenus dans une BB Frame. Le résultat aurait été plus mauvais si on avait eu recours à des
trames courtes (16200 bits).
Aussi, pour des longueurs élevées de paquets IP, les courbes avec des taux de codage
différents ont tendance à se confondre. Par exemple et pour une taille de paquets de 1400
octets et en fonction du taux de codage, 1, 2 ,3 ou 4 paquets peuvent être contenus dans une
trame. Plus généralement, nous nous apercevons que 4 taux de codage (1/4, 2/5, 3/5 et ¾)
suffisent pour couvrir toutes les possibilités et offrir les meilleurs pourcentages de
remplissage des trames. Les taux de codage restants peuvent s’avérer inutiles et inefficaces
en termes de seuil opérationnel du rapport signal sur bruit.
De plus, il est possible de maximiser l’efficacité de remplissage des BB Frames et exploiter
l’ensemble des ModCod proposés par le standard DVB-S2 en limitant l’utilisation du
bourrage. Il est plus judicieux de recourir à des paquets IP de longueurs différentes. Cette
approche peut ne pas s’avérer uniquement théorique. En effet, dans le cas où on connait
exactement les types d’applications qui transitent sur le réseau, on pourrait en fonction de
des caractéristiques de chacune lui attribuer une taille de paquet appropriée.
V.[Link] Rapport IP sur BB Frame
En fonction du nombre de paquets IP par BB Frame, l’efficacité IP sur BB Frame est
définie comme le rapport entre la longueur totale des paquets IP encapsulés et le champ de
données de la BB Frame. La figure 6.14, montre les courbes d’efficacité pour chaque taux de
codage.

98
 100%

90 %

80 %

70 %

60 %
co de 1/ 4

co de 1/ 3

50 % co de 2/ 5

co de 1/ 2

co de 3/ 5

40 % co de 2/ 3
co de 3/ 4

co de 4/ 5

30 % co de 5/ 6

co de 8/ 9

co de 9/ 10

20 %

10%

0%
0 100 20 0 300 400 500 60 0 700 800 9 00 1000 1100 1200 1300 1400 1500

I P P ac ket Si z e i n B y t es

Figure V.14 Efficacité IP sur BB Frame

Les courbes représentent une concaténation de segments linéaires formant ainsi une courbe
en accordéon dont l’importance varie en fonction l’évolution croissante des paquets IP. Pour
les taux de codage les plus bas, la longueur du champ données est faible comparée aux
paquets IP de grandes tailles (entre 1000 et 1500 octets). D’une part ceci limite le nombre de
grands paquets IP pouvant remplir une BB Frame. D’autre part, la granularité de ces
paquets étant importante, le passage d’un pas à un autre combiné à l’incapacité de la BB
Frame de les contenir, implique un recours au bourrage induisant une chute significative de
l’efficacité.
Cet effet accordéon est atténué à mesure que les taux de codage augmentent. En effet, la
longueur du champ de données au sein d’une BB Frame croît proportionnellement et devient
largement supérieure pour des taux comme 9/10 à la taille maximale que peut atteindre un
paquet IP (~1500 octets). Ceci réduit l’effet néfaste de la granularité et améliore l’efficacité.
On note au passage, le rapport IP sur BB Frame pour les petits paquets (< 100 octets) est
assez faible et ce en raison de l’overhead introduit par les en-têtes successifs.
V.3.3.3 Efficacité Spectrale
En poussant le raisonnement sur l’efficacité IP, un peu plus loin, nous tentons
d’évaluer le rapport IP par symbole. Ceci représente l’efficacité spectrale IP. On la définit
comme le nombre de bits par symbole. Il reste tout de même possible - ce qui n’est pas le cas

99
ici- d’intégrer dans les calculs, les différents Roll-off proposés par le standard et estimer le
taux d’occupation « utile » d’un répéteur satellite. La figure 6.15 donne les efficacités
spectrales relatives aux 22 ModCod en fonction de la taille du paquet IP.

4.5

QPSK 1/4
4 QPSK 1/3
QPSK 2/5
QPSK 1/2
3.5
QPSK 3/5
QPSK 2/3
QPSK 3/4
3
IP Bits per Symbol Efficiency

QPSK 4/5
QPSK 5/6
8-PSK 3/5
2.5
8-PSK 2/3
8-PSK 3/4
16APSK 3/5
2
16APSK 2/3
16APSK 3/4
16APSK 5/6
1.5
16APSK 8/9
32APSK 3/4

1 32APSK 4/5
32APSK 5/6
32APSK 8/9
0.5 32APSK 9/10

0
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500
IP Pack e t Size in Byte s

Figure V.15 Bits IP par symbole

A partir des évaluations ci-dessus, il devient aisé de déduire les débits IP en

multipliant les efficacités spectrales respectives par le débit symbole. A titre d’exemple, des
paquets IP de 600 octets transmis avec le ModCod 25 (32-APSK 4/5) ont une efficacité de
(10 paquets IP/13338 symboles = 3,6 bits/symbole). Un débit IP de 108 Mbit/s requirt un
débit symbole de 30 MS/s
V.3.3.4 Comparaison MPE & GSE
Dans ce qui suit nous établissons une comparaison théorique entre le schéma
d’encapsulation MPE/MPEG et le GSE décrit précédemment et proposé en option du
standard. L’en-tête d’une encapsulation GSE varie en fonction de plusieurs paramètres
(fragmentation des paquets IP, paquet complet…). On se place dans le pire cas, et on
suppose que pour chaque paquet IP, c’est un en-tête maximal GSE qui est introduit avec 10
octets et une somme de contrôle de 4 octets.

100
 6000

5000

4000
Number of Bytes per Frame

BB Frame usef ul (w ith header)

Total MPEG (w ith header)
3000
Total MPE (w ith header)
Total IP / MPE (w ith header)
Total GSE (w ith header)
Total IP / GSE (w ith header)
2000 IP diff erence GSE - MPEG

1000

0
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500
IP Packe t Size in Byte s

Figure V.16 IP sur MPE et GSE pour code 3/5

Le tableau III prend comme exemple le taux de codage 3/5 et nous évaluons le nombre de
paquets IP à encapsuler par BB Frame si on adopte GSE comme schéma d’encapsulation. Le
schéma montre notamment l’écart IP « utile » dans le remplissage entre une encapsulation
MPE/MPEG et une encapsulation GSE.
On note que, dans l’ensemble, GSE présente un meilleur taux de remplissage utile et
ce en raison d’un overhead plus réduit. Ce résultat est indépendant de la taille des paquets IP
mais il reste en particulier vrai pour des petits paquets IP. GSE est ainsi mieux adapté pour
acheminer des applications comme la VoIP. Le gain moyen en efficacité apporté par GSE est
de l’ordre de 4,6 % pour des trames DVB-S2 avec le code 3/5 et une distribution uniforme
des tailles de paquets IP entre 0 et 1460 octets.
V.3.3.5 Conclusion
Ces évaluations renseignent sur les performances théoriques des paquets IP sur
DVB-S2. La principale conclusion est le gain en efficacité d’encapsulation apporté par GSE.
Aussi, le recours aux trames longues (64800 bits) est recommandé pour la transmission de
l‘IP.
Un choix adapté de la taille des paquets IP ainsi que du ModCod permet d’atteindre des
résultats optimaux en termes d’occupation de bande. Cette affirmation peut toutefois n’être
que théorique. En effet, la taille des paquets IP varie selon les applications IP. En plus celle
des BB Frames varie dynamiquement si le mode ACM est activé.
Cependant, d’un point de vue pratique et selon les cas, il est toujours possible de
trouver un moyen d’occuper au mieux la bande passante en jouant sur la taille des paquets
IP et le ModCod. D’une manière générale, un opérateur d’un réseau IP par satellite connaît
exactement les applications qui transitent sur le réseau. Si on prend l’exemple d’un réseau de

101
données avec un trafic consistant majoritairement en un accès Web, e-mail ou le transfert de
fichiers, il devient plus aisé de fixer la taille des paquets IP. Il s’agit, dans ce cas, d’une
majorité de paquets de grandes tailles. On peut avoir recours à des modules aux extrémités
d’un réseau satellite tels que les accélérateurs TCP, véritables goulet d’étranglement du
trafic ascendant et descendant. De cette manière, il est possible de choisir la taille des
paquets IP qui conduit aux meilleures efficacités. En parallèle, et pour une transmission en
ciel clair, il est toujours possible de définir le ModCod qui assure l’efficacité visée. Ce couple
taille IP de paquets et ModCod sera opérationnel la plupart du temps.
En plus, l’ACM n’est déclenché qu’en cas de dégradation de conditions de transmission
et ce pour un faible pourcentage du temps. Durant cet intervalle de temps, la priorité est
davantage à la transmission même du signal qu’à un usage efficace de la bande passante.
V.3.4 Les tests applicatifs et l’ACM
L’objectif premier des tests que nous décrivons ci-dessous est de d’analyser le
comportement des applications IP avec des conditions de transmission nécessitant le recours
à l’ACM.
Notre attention porte, d’une part, sur la relation entre la boucle ACM (d’une durée d’1
seconde) et son effet sur les flux IP. D’autre part, nous nous penchons sur l’observation du
comportement des applications IP, par ailleurs implantées par des sous-systèmes distincts de
la solution DVB/S2-RCS. En présence d’une boucle ACM, il reste crucial de savoir si les
niveaux de précédence IP sont respectés et d’évaluer le niveau de dégradation des
performances qui résulte de la baisse brusque des ressources. Au cours des expérimentations,
nous étions attentifs à l’impact d’un changement rapide dans le temps du niveau du signal
sur bruit sur ces applications.
Dans notre approche nous considérons deux catégories d’applications IP.

Les applications TCP : elles regroupent l’ensemble des flux IP reposant sur le
protocole TCP pour la transmission et nécessitant la mise en œuvre de
mécanismes d’accélération sur satellite.

La VoIP, application temps réel et à débit constant et sensible à la variation de
la bande passante.
V.3.4.1 L’événement deFading
Si l’on considère un contexte -réel- de transmission par satellite, les phénomènes de
dégradations des conditions atmosphériques entraînant des variations significatives du
niveau du signal sur bruit et le déclenchement de la boucle ACM sont peu fréquents dans le
temps –heureusement d’ailleurs-.
L’environnement contrôlé du laboratoire et le recours au simulateur satellite, nous
permettent de définir un scénario de Deep Fading ayant pour conséquence de déclencher une
boucle ACM et d’activer une multitude de ModCods.
Par ailleurs et à titre d’information, la figure 6.17 retrace un événement de fading
naturel. En effet, au cours de la campagne de tests par satellite, nous avons eu la chance
d’assister à un orage !
La figure 6.17 décrit une variation de signal sur bruit suite à des intempéries sur trois
antennes en réception d’une porteuse DVB-S2. La boucle ACM oscille entre 6 ModCod (19
et 25). La courbe de couleur orangée montre les seuils impliquant un changement de
ModCod.

102
 Figure V.17 Fading naturel par satellite observé sur trois antennes

Cependant et pour les besoins des tests applicatifs IP, nous avons élaboré un
événement de Deep Fading (entraînant un forte chute du signal sur bruit). Cet événement,
bien que de courte durée et ne parcourant pas la totalité des 22 ModCod utiles, reste assez
représentatif de ce qui survient en cas de fortes détérioration de la liaison suite à des
intempéries.
L’événement se répartit en trois phases successives. La première caractérise des
conditions de transmissions optimales en ciel clair. Ensuite, intervient la phase de Fading,
avec une dégradation notable entraînant une chute du niveau de signal sur bruit. Elle
implique une baisse de 70 % de l’efficacité spectrale et une atténuation de l’ordre de 7 dB. On
part du ModCod 9 (QPSK 5/6) avec un niveau de signal d’environ 6 dB pour atteindre le
ModCod 1 (QPSK ¼) et un niveau de signal de -1 dB avec une atténuation de 0,5 dB par
seconde. Notons que même avec un niveau de bruit supérieur à celui du signal utile, il est
toujours possible d’émettre. Suit la phase d’atténuation, un retour aux conditions de
transmission optimales avec une croissance du niveau du signal et une transmission en
ModCod 9.

Figure V.18 Événement de Fading expérimental

103
 Cet événement de Fading expérimental donne la possibilité de « parcourir » 9
ModCods en mode ACM. C’est une situation assez rare étant donné qu’un orage ou une
dégradation de cette ampleur des conditions de transmission est tout de même peu
fréquente. Remarquons que l’événement de fading naturel (figure 6.17) déclenche 6 ModCod
ce qui est déjà exceptionnel !

V.3.4.2 ACM et applications TCP

Dans notre démarche expérimentale, nous avons regroupées l’ensemble des
applications TCP. Cela couvre aussi bien la navigation Web, l’e-mail ainsi que le transfert de
fichiers. Les deux premières se caractérisent plutôt par un débit variable avec des pics en
période de récupération de données avec un comportement bursty, le transfert de fichiers a
généralement24 lieu à débit constant. Toutefois, TCP étant un protocole sans pertes, le
caractère commun reste le temps requis pour transmettre les données, en particulier par
satellite. C’est d’ailleurs la raison pour laquelle nous avons regroupé les applications TCP.

Pour les besoins de nos tests, nous avons opté pour un transfert de fichier via FTP.
En effet, les accès Web ou l’email (à moins d’une pièce jointe de grande taille) n’entraînent
pas de débits significatifs pouvant être sujet à observation, spécialement pour notre réseau
expérimental d’une Gateway et deux terminaux.

Notre test consiste donc en un transfert d’un fichier de 1 Go entre la Gateway et le

terminal (lien DVB-S2) auquel on applique un événement de fading impliquant le
déclenchement de la boucle ACM. Ce test se déroule en deux étapes. Le première se déroule
sans le recours à l’accélération TCP, le deuxième a lieu avec des PEPs placés des deux
extrémités du lien satellite.

Figure V.19 Transfert FTP avec TCP non accéléré en présence d’un événement de Fading et d’une boucle ACM

La figure 6.19 retrace la courbe d’évolution du débit, des pertes de paquets, du délai
et de la gigue pendant la durée de tests entre la source du trafic (serveur FTP) côté Gateway

24 Pour peu que la taille du fichier à transférer soit suffisamment grande (pour durer un minimum).

104
et sa destination (le client FTP) côté terminal. Notons que la durée du transfert du fichier
excède largement celle de l’événement de fading que nous avons mis en place.
Durant la première phase (conditions optimales), on observe un comportement standard de
l’algorithme Slow Start de TCP et une augmentation graduelle (bien que lente en raison du
délai satellite) de la fenêtre de transmission jusqu’à atteindre la taille optimale avec le débit
maximal autorisé. Remarquons au passage que le débit IP maximal de la porteuse DVB-S2
est de l’ordre de 6 Mbit/s. La taille des fenêtres TCP maximales, initialement limitées à 64
KB ont été modifiées au niveau du client et du serveur FTP pour permettre d’atteindre le
débit maximal (Débit = taille de la fenêtre / RTT).
Ensuite survient l’événement de Fading proprement dit. Le mode congestion avoidance
est activé. Cette phase intervient au moment de l’atténuation du signal et du déclenchement
de la boucle ACM. Dans la phase descendante de l’ACM, le nombre croissant de paquets
perdus et la constante décroissance du niveau du signal oblige le protocole à réduire la taille
de sa fenêtre. Les premières tentatives de déclenchement de l’algorithme fast recovery échoue
puisque le niveau signal est encore en train de baisser.
Ainsi, le débit TCP chute jusqu’à une valeur quasi nulle résultant par ailleurs en une perte de
paquets ainsi qu’un pic de délai et de gigue. Ensuite, débute une phase de fast recovery, où le
débit observe une progression. Notons par ailleurs, que durant cette phase et même si le
signal subit encore des dégradations, le trafic est tout de même transmis puisque son volume
est inférieur au débit IP max que permet le ModCod 1.
L’algorithme fast recovery agrandit en permanence la taille de la fenêtre résultant par là
même en une augmentation du débit. Cette croissance est également accompagnée par
l’évolution du débit dans la phase ascendante de l’ACM.
Ce que nous pouvons conclure de ces observations, c’est le préjudice causé par les
atténuations et le déclenchement du mode ACM. Bien que les pertes de paquets soient
réduites, grâce au changement dynamique du codage et de la modulation pour renforcer la
liaison, le comportement standard de TCP, en particulier la combinaison des algorithmes de
Congestion avoidance et de fast recovery, ne permet pas d’atteindre rapidement le débit IP
maximal que permet le ModCod de la boucle ACM activé à cet instant.

Figure V.20 FTP avec TCP accéléré en présence d’un événement de fading et d’une boucle ACM

105
 Dans la seconde étape du test, le transfert FTP est effectué en présence
d’accélérateurs TCP aux deux extrémités du lien satellite. Lorsque l’événement de fading est
déclenché et que la boucle ACM est activée, on observe une forte augmentation des pertes de
paquets en plus de celles des délais. Toutefois, en mode TCP accéléré et même en cas
d’atténuation du signal, TCP tente de « revenir » au débit d’émission maximal autorisé par
le ModCod le plus élevé avec une quasi inexistence des algorithmes de contrôle de flux.
L’explication tient au fait que les valeurs de débit maximal de la liaison ainsi que celle du
RTT, sont déjà préconfigurées au sein de l’accélérateur TCP. Par conséquent, et à priori
indépendamment des conditions de liaisons, l’accélérateur tente de revenir au débit maximal
tel qu’il l’a évalué en fonction des paramètres configurés. Cela explique par ailleurs les pertes
de paquets plus nombreuses que dans le cas standard. Ceci étant et dans la « phase
ascendante de l’ACM », TCP accéléré atteint plus rapidement le débit maximal de la liaison.
On conclut des ces observations, que dans sa version accélérée, TCP nous évite de gaspiller
de la bande passante en atteignant plus rapidement le débit maximal. Toutefois, il implique
des pertes de paquets plus significatives en présence d’un événement de fading. En effet, il
tente systématiquement d’atteindre le ModCod permettant la plus large bande passante alors
qu’on en présence d’ACM, ce sont les ModCod inférieurs qui sont utilisés. Nous remarquons
que ce comportement reste spécifique à l’accélérateur TCP utilisé dans le cadre de ce test où
la configuration est statique et n’évolue pas en fonction des conditions de transmissions.
Toutefois, ceci reste le cas de la plupart si ce n’est de la totalité des solutions d’accélérations
TCP implantées. Ces dernières ont été conçues pour des liaisons satellite configurées avec
des marges statiques et des largeurs de bande fixes, ne supportant pas l’ACM.
Cette observation nous sensibilise à la nécessité d’interaction qui doit avoir lieu entre le
niveau transport, en l’occurrence TCP, et le module ACM (Couche physique) où les
décisions de changement de ModCods sont prises. C’est aussi l’esprit des interactions Cross-
Layer où un échange d’informations sur l’état de liaison est nécessaire pour éviter des pertes
de bande passante. Dans ce cas précis, on peut imaginer qu’à chaque changement de ModCod
le module ACM puisse communiquer au module d’accélération TCP le débit maximal
atteignable. En se basant sur cette information en plus de la valeur du RTT, le PEP est en
mesure d’estimer la taille de fenêtre adaptée au ModCod en question.

Dans l’immédiat et afin d’éviter les pertes des paquets, une solution possible – qui loin d’être
optimale en terme d’usage de bande- est de configurer l’accélérateur TCP pour qu’il atteigne
au plus le débit IP maximal autorisé par le ModCod le plus robuste et donc le « plus bas » de
la boucle ACM. C’est envisageable dans ce contexte d’utilisation professionnelle du réseau IP
par satellite (pas d’applications pair-à-pair ou de téléchargement lourd). Les accès Internet et
les transferts de fichiers ne requièrent pas en général des débits très élevés.
V.3.4.3 Voix sur IP et ACM
Les tests de VoIP que nous allons décrire sont utiles sur plus d’un aspect. Ils
permettent dans un premier temps d’évaluer l’encapsulation sur le format de trame DVB-S2.
Ensuite, ils procurent un moyen d’évaluer la qualité de service IP et l’impact de l’ACM.
V.[Link] VoIP et durée de trame
A travers ce test, nous tentons de trouver la durée de trame voix optimale en fonction
du codec choisi. Nous recommençons ici un exercice déjà effectué avec les technologies
étudiées précédemment. Outre le délai, la durée de la trame voix est également dépendante
de la pile protocolaire de la technologie qui la transporte. L’objectif du test est de trouver le
compromis entre l’overhead introduit par les encapsulations successives et la taille des

106
données utiles. Notre choix de codecs a porté sur le G.729 en raison de la modularité offerte
par la taille élémentaire de l’échantillon qu’il génère (10 ms).
On établit une communication VoIP (seul trafic sur le lien et sans mécanisme de
compression) qui transite via le lien DVB-S2. On modifie à chaque fois la durée de la trame
voix. On débute avec une durée de 10ms et on incrémente graduellement à chaque phase de
test jusqu’à 80 ms. Ce test a lieu en mode CCM (Constant Coding and Modulation) avec le
ModCod 3 (QPSK 2/5) qui permet le meilleur ratio MPEG/BB Frame. (De l’ordre de
99,5%.) Les courbes de débit IP et MPEG et BB Frame (sur une autre échelle) sont montrées
par la figure 6.20.

BB Frame bit rate according to voice frame duration Voice Frame Duration & MPEG-TS occupation
200
3

B itra te (Kbps)
B itr a te (M b p s )

150
2 100

50
1
0
0 10 20 30 40 50 60 70 80

10 20 30 40 50 60 70 80 Voice Frame length (ms)

Voice Frame Duration (ms) IP Bitrate MPEG Bitrate

Figure V.21 Les courbes de débit IP, MPEG et BB Frame en fonction de la durée de la trame voix

Nous observons que plus la trame voix est longue moins les débits IP, MPEG et BB Frame
sont élevés. Nous notons également que chaque paquet VoIP est encapsulé en une seule
cellule MPEG-TS et en une seule BB Frame ce qui explique le débit important de ces
dernières. A mesure qu’on augmente la durée des trames, le nombre de paquets IP, de
cellules MPEG-TS et de BB Frames nécessaires par seconde diminue induisant une baisse du
débit.
En parallèle l’augmentation de la durée de trame voix améliore l’efficacité d’encapsulation.
Toutefois, il n’est pas possible d’augmenter indéfiniment la durée des trames. Cela résulte en
une dégradation sensible de la qualité de la voix, perceptible à l’oreille. A ce titre et aussi
bien pour le DVB-S2 que pour les autres technologies, nous optons pour une trame voix
entre 40 et 50 ms qui présente le meilleur compromis entre utilisation de la bande et qualité
de la voix restituée.
VoIP over BB Frames effciency
90%

80%

70%
Efficiency

60%

50%

40%

30%
10 20 30 40 50 60 70 80
VoIP payload length ( Bytes)

Figure V.22 Efficacité VoIP(utile)/BB Frame

107
V.[Link] La VoIP et l’ACM
Le principe de ce test de générer une multitude de communications VoIP en présence
d’un trafic de fond (UDP) moins prioritaire que la voix et suffisant pour charger le lien
DVB-S2 à hauteur de sa capacité maximale. Un maximum de 8 communications VoIP
transite par le lien DVB-S2 avec un débit total de 128 kbit/s (40 ms de trame voix, sans
compression d’en-tête). Ensuite, on applique l’événement de fading qui implique le
déclenchement de la boucle ACM.

Figure V.23 Débit IP, délai, pertes de paquets et gigue pour les communications VoIP

Le débit IP par communication VoIP ainsi que le débit pour l’ensemble des appels
simultanés restent constants. Nous n’observons aucune variation de délai, ni de gigue ainsi
qu’aucune perte de paquets. Ceci est la preuve que la baisse de bande passante induite par le
fading et la boucle ACM n’ont pas d’impact sur les appels VoIP et ce pendant toute la durée
de l’atténuation.

Figure V.24 Débit IP, délai, perte de paquet et gigue pour le traffic de fond sur le lien DVB-S2

108
 En revanche, nous relevons une réduction brusque du débit IP, une augmentation des
pertes de paquets, des délais ainsi que de la gigue pour le trafic de fond. Moins prioritaire, ce
flux IP subit les conséquences de baisse de bande passante provoquée par le recours à des
ModCod plus robuste mais de moindre efficacité spectrale.
Les règles de qualité de service IP établies rendant la VoIP prioritaire sur les autres
types de flux combinées à la baisse des débits a été préjudiciable aux flux moins prioritaires.
On en conclut, d’une part, le bon fonctionnement de la correspondance établie entre les
règles QoS IP et l’ordonnanceur (Scheduler) des files d’attentes au niveau MAC dans un
contexte ACM. D’autre part, nous relevons la bonne réactivité du système aux données
retournées par les terminaux concernant l’état du lien.
La conclusion qu’on peut tirer de ce test est qu’en présence d’un événement de fading et
d’une boucle ACM, la mise en œuvre des règles d’IP QoS adéquates permet de préserver les
performances de la VoIP. Toutefois, cette affirmation reste vraie du moment que le débit
total des communications VoIP simultanées reste inférieur au débit IP maximal autorisé par
le ModCod le plus robuste de la boucle ACM, en l’occurrence le ModCod QPSK ¼ dans notre
cas. Dans le cas contraire, la qualité de certaines communications VoIP (applications à débit
constant) va être affectée par le manque de bande passante. Ceci se traduit par des pertes de
paquets, une augmentation du délai et de la gigue ainsi que la détérioration de la qualité
perceptible de la voix.
V.3.4.4 Conclusion des tests
Les expérimentations que nous avons décrites permettent d’apprécier l’apport du DVB-
S2 et spécialement la modulation et le codage adaptatifs. Elles ont globalement montré de
meilleures performances que dans le cas du DVB-S. Même en mode ACM, ces performances
restent acceptables. Elles demeurent tout de même tributaires des choix de configuration
système et de dimensionnement de trafic effectué par l’opérateur.

V.4. Conclusion
Au cours de ce chapitre nous avons introduit la nouvelle génération du standard de
diffusion par satellite, le DVB-S2. Nous avons détaillé les principaux aspects et apports et
qui concernent principalement la couche physique. Notre contribution se situe
principalement au niveau des expérimentations effectuées sur une plateforme DVB/S2-RCS,
avec un profil professionnel. Outre l’intégration de la plateforme de tests, nous avons analysé
les résultats et procédé en amont à des évaluations théoriques de l’apport du standard pour
les paquets IP. Les tests que nous avons présentés ne représentent qu’une partie des
expérimentations menées sur les applications IP dans le cadre du projet et comprennent
notamment le Vidéo Streaming et la vidéoconférence. Néanmoins, la conclusion générale qui
se dégage est certainement l’avantage qu’apporte le DVB-S2 quand il est utilisé pour
transmettre des applications IP.

109
VI. Conclusion et Perspectives

VI.1. Conclusion
La problématique de nos travaux consiste en une évaluation des performances des
technologies satellites quand elles sont amenées à transmettre des applications IP exigeant
différents niveaux de qualité de service.
L’utilité de la problématique se déduit de la place qu’occupe désormais le satellite en
tant technologie d’accès à part entière au sein d’une infrastructure globale de
télécommunications centrée autour du protocole IP. Ce positionnement se justifie comme
nous l’avons décrit au premier chapitre par les caractéristiques intrinsèques des systèmes
satellites. Au cours du deuxième chapitre, nous avons défini le cadre de référence et les
caractéristiques principales des réseaux satellite utilisées pour la transmission des flux IP.
Cela a été l’occasion de relever les principales difficultés auxquelles on fait face dans ce
contexte. Nous avons notamment pu noter les solutions mises en œuvre pour surmonter ces
contraintes.
Ce travail initial nous a sensibilisés non seulement aux choix technologiques à
effectuer en termes de technologies satellite et d’applications IP mais surtout à la démarche à
entreprendre au cours de ce travail d’analyse et d’interprétation.
Par la suite, intervient la phase d’évaluation. Elle débute par la description de la
technologie satellite de référence retenue, le standard DVB-RCS. Une démarche
expérimentale a été mise en œuvre dans laquelle nous avons associé différents sous-
systèmes, DVB-RCS pour la technologie satellite, une solution de VoIP et des techniques
d’accélération TCP au sein d’une plateforme de tests. Cela nous a permis d’observer le
fonctionnement global du réseau IP par satellite.
Il ressort de cette analyse des points cruciaux. Nous nous sommes tout d’abord
aperçus que certains types de services comme la VoIP chiffrée par IPsec sur satellite ne sont
pas viables. Les raisons des mauvaises performances observées sont multiples. Cela est dû à
un coût d’encapsulation prohibitif. S’ajoute une sur-allocation de bande passante sur la voie
retour par le gestionnaire de ressources en plus de l’inadaptation du chiffreur IPsec aux
petits paquets de VoIP et son non respect des règles de QoS. Ces points-là sont très délicats
à déceler au travers d’études uniquement théoriques ou menées par simulation. On pense
plus particulièrement à la charge du chiffreur IPsec.
En suivant le même principe expérimental, nous avons procédé à une comparaison de
performances entre le standard DVB-RCS et iDirect une technologie propriétaire pour la
transmission de l’IP par satellite. Dans notre analyse, nous nous sommes penchées sur les
interactions entre les politiques des QoS développées par chaque technologie et les
mécanismes d’ordonnancement de niveau MAC. C’était aussi l’occasion d’observer l’aptitude
des piles protocolaires respectives à encapsuler des paquets IP ainsi que les mécanismes mis
en œuvre pour les transporter. A travers des tests de VoIP sur les deux technologies, nous
avons noté les conséquences d’un choix dynamique ou statique en termes d’allocation de
bande passante. Nous avons notamment pu noter l’impact des règles de qualité de services
IP sur la demande et l’allocation de la bande passante sur la voie retour pour les deux
technologies.
Ces expérimentations nous ont notamment sensibilisés à la marge de liberté laissée par le
standard DVB-RCS sur l’implantation effective des systèmes et son impact sur les
performances des applications IP.

110
Nous avons enfin introduit le nouveau standard DVB-S2 et les possibilités qu’il apporte en
termes de modification dynamique de la forme d’onde pour l’adapter aux conditions de
transmission (ACM). Nous avons procédé à une évaluation théorique de ses avantages en
termes d’efficacité d’encapsulation. A travers le banc de test DVB/S2-RCS, nous avons
évalué les performances des applications TCP mais aussi de la VoIP en présence d’un
évènement de fading qui déclenche une boucle ACM. Nous avons relevé la bonne
correspondance qu’il y a entre les règles de qualité de service au niveau IP et le module
ACM au niveau physique et MAC en cas de variation de bande passante. Les performances
sont meilleures que celles obtenues avec le standard DVB-S. Toutefois, la dé-corrélation qui
persiste entre les mécanismes d’accélération TCP actuels et le module ACM, influe
négativement sur les performances.
La démarche analytique adoptée au cours cette étude et surtout l’expérimentation de vrais
systèmes IP par satellite a été utile sur plus d’un aspect. Le premier est de constater les
niveaux de performances acceptables des applications IP sur satellite compte tenu des
solutions qui existent et en dépit de la différence des approches pour le faire. C’est aussi le
moyen de se sensibiliser aux choix système et de configuration qu’un opérateur doit prendre
pour atteindre les niveaux de service escomptés.
Ces expérimentations sont aussi l’occasion de relever certaines lacunes et rendre compte des
axes de recherche à développer dans le but d’améliorer les performances des applications IP.

VI.2. Perspectives
Les limites relevées dans le cadre de ce travail mais aussi l’évolution permanente des
services qu’on cherche à mettre en œuvre sur ce genre de réseau en fonction des nouveaux
besoins des usagers offrent de nouvelles perspectives de recherches.
On pense notamment, à l’échange d’informations qui doit avoir lieu entre les couches
protocolaires supérieures telles que TCP et les couches basses notamment le module ACM
afin de sensibiliser les premiers à la variation dynamique de bande passante. Plus
concrètement et tels que nous l’avons relevé, signaler à l’accélérateur TCP, le débit maximal
que peut acheminer un ModCod donné à l’instant où il est utilisé, évite des pertes de paquets.
Cela s’apparente, d’ailleurs, à une démarche Cross-Layer. Grâce à des techniques de codage
canal et de modulation performantes, on réduit significativement les erreurs sur les liaisons
satellite. Cela se passe au dépend d’un débit qui varie en permanence. Les couches
supérieures doivent tenir compte de manière réactive de ce type de variations.
Nous avons également à l’esprit les améliorations possibles de l’efficacité
d’encapsulation. Si on prend l’exemple du standard DVB-RCS, le recours combiné à ATM et
MPEG en fonction du trafic à acheminer ou plus exactement de la taille des paquets à
transmettre, peut significativement améliorer l’utilisation des ressources. En effet, même s’il
rend l’allocation de ressources plus complexe, le fait, par exemple, d’associer ATM aux
paquets inférieurs à une certaine longueur (VoIP) et à MPEG au-delà, conduit probablement
à de meilleurs résultats en encapsulation. Une autre piste pour améliorer l’encapsulation,
apparemment en cours d’étude pour la nouvelle version du standard DVB-RCS, est celle
d’adopter le format de trame DVB-S2 avec les BB Frames et éventuellement le GSE.
Avec l’arrivée du nouveau standard DVB-SH (Digital Video Broadcasting – Satellite
Handled), et son aptitude à transporter des flux IP, c’est une nouvelle architecture de réseaux
qui se met en place. Ce sont désormais des réseaux hybrides transportant des paquets IP.
Cela amène à repenser non seulement les formats de trames mais aussi des techniques tels
que l’ACM afin des les adapter au nouvel environnement de transmission.

111
Bibliographie

Chapitre I : Les réseaux satellite dans un contexte de convergence IP

[1] A.C. Clarke, “Extra-terrestrial relays, Can rocket station give worldwide Radio Coverage ?”, Wireless World, 10-1945
[2] “L’Internet haut débit descend du ciel” p.56-58, Magazine Usine Nouvelle, 04-2008.
[3] [Link]
[4] [Link]
[5] [Link]
[6] [Link]
[7] [Link]
[8] [Link]
[9] G. Nicolai, P. Cerrito “Satellite and Wireless Network Evolution for Broadband Applications”, 11th Ka Band Conference
& ICSSC, Rome, Italy 09-2005.
[10] European Telecommunications Standards Institute [Link]
[11] Internet Engineering Task Force [Link]
[12] Telecommunications Industry Association [Link]
[13] [Link]
[14] [Link]
[15] G. Verelst “Satellite Broadband communication solutions for rural regions in Europe” Ka and Broadband communication
conference, 09-2006
[16] A. Korur, “Internet and data broadcasting via satellite”, Eutelsat Commercial department study, 2003
[17] L. Thomasson, M. Vaissière, F. Joly, M.P. Kluth, S. Taylor, C. Elia, R. de Gaudenzi “DDSO, the satellite contribution to
European Government for e-Incllusion of citizens and regions”, ESA Presentation, 08-2006.
[18] ETSI TR 102 157, v1.1.1 “Satellite Earth Stations and Systems (SES) ; Broadband satellite Multimedia; IP networking over
satellite; Performance availability and Quality of Service”, 07-2003.
[19] L. Boukhatem. “Le Handover dans les Constellationns de Satelite LEO”. PhD thesis, Universit´e de Paris VI, 2001.
[20] N. Girault, “Traitement à bord”, Cours ENSTB, option SCS, ISAE, 02-2008
[21] L. Bouscary, P. Bermejo, L. Thomasson, “Validation of DVB-RCS systems”, AIAA, 2004
[22] Sahay, Y. Kim “Demande de bande Ka pour les systèmes à satellites géostationnaires” ITU, archives, WRC 97.
[23] M. Schnell and U.C Fiebig. “Fade Slope Statistics of 40 GHz beacon signals” Electronics letters, 33 (21) :1819–1821, 10-
1997

Chapitre II : Le satellite comme support de l’IP, difficulté de la mise en œuvre

[1] G. Pujolle, “les réseaux, Edition 2008”, Editions Eyrolles, 2008

[2] G. Maral, M. Bousquet, “Satellite Communications Systems”, Fourth Edition, Wiley edition, 2006
[3] ETSI TR 102 157, v1.1.1 “Satellite Earth Stations and Systems (SES) ; Broadband satellite Multimedia; IP networking over
satellite; Performance availability and Quality of Service”, 07-2003
[4] ETSI TR 102 295, v 1.1.1 “Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia (BSM), services and
architectures; BSM Traffic Classes”, 02-2004
[5] P. Barsocchi, N. Celandroni, E. Ferro, A. Gotta, F. Davoli, G.i Giambene, F. J. G. Castaño, J. I. Moreno, and P. Todorova.
« Radio resource management across multiple protocol layers in satellite networks: A tutorial overview. Technical report”
International Journal of Satellite communication and networks, 265–305, 2005.
[6] “DVB-RCS background book” , Nera broadband Satellite, first edition 2002, [Link]
[7] F. Nivor, P. Berthou, S. Abdellatif, T. Gayraud, “Amélioration de l’Allocation Dynamique de Ressource dans un Système
Satellite DVBS/RCS”, CFIP 2006.

112
[8] P. Feldman. “An Overview and Comparison of Demand Assignment Multiple Access (DAMA) Concepts for Satellite
Communications networks” RAND Corporation, September 1996.
[9] N. Abramson. “The ALOHA system -Another alternative for computer communications”. In Proc. AFIPS Fall Joint
Comput. Conference, volume 37, 1970
[10] ITU-R. “Methodologies for determining the availability performance for digital multi programme BSS systems, and their
associated feeder links operating in the planned bands”, 2005. ITU R BO.[Doc. 6/67]
[11] F. TRA, “ Contrôle d’Admission des Connexions pour les Systèmes de Télécommunication par Satellite avec des Liaisons
Physiques Adaptatives”, Phd Thesis, Ecole Nationale Supérieure de l’Aéronautique et de l’Espace, 2007
[12] R. Chaggara, « Les Modulations à Phase Continue pour la Conception d’une Forme d’Onde Adaptative Application aux
Futurs Systèmes Multimédia par Satellite en Bande Ka » Phd Thesis, ENST Paris, 2004.
[13] COST project 255 “Final Report. Radiowave Propagation Modelling for new Satellite Communication Services at Ku-band
and above. Technical report”, ESA Publications Division, ESTEC, Noordwijk, The Netherlands, 1998.
[14] Russo E. “Implementation of a space diversity system for Ka-band satellite communications.” Proceedings of the IEEE
International Conference on Communications (ICC 93), Geneva, Switzerland, 05-1993; 1468–1474
[15] F. Carassa, E. Matricciani, G. Tartara. “Frequency diversity and its applications”. International Journal of Satellite
Communications 1988; 6:313–322.
[16] ETSI EN 302 307 “Digital Video Broadcasting (DVB), Second generation framing structure, channel coding and
modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications” 03-
2005
[17] “Transmission Control Protocol”, IETF RFC 793, 09-1981.
[18] D. ROS “Le protocole de transport TCP”, bases documentaires Techniques de l’Ingénieur.
[19] W. R. Stevens, “TCP/IP Illustrated Volume 1 – The Protocols”, Edition Addison-Wesley, 2001.
[20] M. Allman, D. Glover, L. Sanchez, “Enhancing TCP over Satellite Channels using standard mechanisms ”, IETF RFC
2488, 01-1999
[21] G; Maral, “VSAT Networks”, Wiley Edition, 1995.
[22] M. Allman, S. Floyd, C. Partridge, “Increasing TCP's Initial Window”, IETF RFC 3390, 10-2002
[23] J. Mogul, S. Deering, “Path MTU Discovery”, IETF RFC 1191, 11-1990.
[24] V. Jacobson, R. Braden, D. Borman, “TCP Extensions for High Performance”, RFC 1323, 05-1992
[25] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, “TCP Selective Acknowledgment Options”, IETF RFC 2018, 10-1996
[26] Gerla M, Sanadidi AMY, Wang R, Zanella A, Casetti C, Mascolo S. “TCP Westwood: congestion control using bandwidth
estimation”. In Proceedings of the IEEE Globecom 2001, San Antonio, Texas, vol. 3, November 2001; 1698–1702
[27] Balakrishnan H, Katz RH. “Explicit loss notification and wireless web performance”. Proceedings of the IEEE Globecom
Internet Mini-Conference, Sydney, Australia, November 1998.
[28] N. Celandroni, F. Potortı. « Maximising single connection TCP goodput by trading bandwidth for BER ». International
Journal of Communication Systems 2003; 16(1):63–79.
[29] D. Astuti, M. Kojo, "TCP and Link Layer Enhancements in DVB-S/DVB-RCS satellite systems” Berkeley - Helsinki
Ph.D. Student Workshop on Telecommunication Software Architectures. University of Berkeley, USA, 21, 24-06-2004.
[30] J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby “Performance Enhancing Proxies Intended to Mitigate Link-
Related Degradations”, IETF RFC 3135, 06-2001
[31] [Link]
[32] R M. Sanders and A C. Weaver “The Xpress Transfer Protocol (XTP) — A Tutorial”
[33] M. Allman, J. Ishac “On the performance of TCP spoofing in satellite networks”, 2001
[34] J. Fasson “ Etude d’une architecture IP integrant un lien satellite géostationnaire” Phd Thesis, INPT Toulouse, 12-2004
[35] S. Kota, M. Marchese “Quality of Service over IP networks: a survey” International journal of satellite communications
and networking, 06-2003
[36] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, « Session
Initiation Protocol », IETF RFC 3261, 06-2002
[37] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry “The COPS (Common Open Policy Service) Protocol”
IETF RFC 2748, 01-2000
[38] S. Shenker and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements”, IETF
RFC 2215, 1997
[39] Wroclawski, J., “The Use of RSVP with IETF Integrated Services”, IETF RFC 2210, 1997
[40] S. Shenker, C. Patridge, R. Guern. “Specification of Guaranteed Quality of Service. Standards Track” RFC 2212, sept.
1997.

113
[41] J. Wroclawski “Specification of the Controlled-Load Network Element Service .Standards Track” IETF RFC 2211, 09-
1997.
[42] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin « Resource ReSerVation Protocol (RSVP) » IETF RFC 2205, 09-1997.
[43] A. Westerinen, “Terminology for Policy-Based Management”, IETF RFC 3198, 11-2001.
[44] O. Medina, G. Texier “La differentiation de services”, Bases documentaires Techniques de l’Ingénieur
[45] O. Alphand “Architecture à qualité de service pour systèmes satellites DVB-S/RCS dans un contexte NGN” Phd thesis,
12-2005
[46] K. Nichols, S. Blake, S. Blake, D. Black, “ Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers” IETF RFC 2474, 12-1998
[47] B. Davie, A. Charny,J.C.R. Bennett, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis “An
Expedited Forwarding PHB (Per-Hop Behavior)” IETF RFC 3246, 03-2002.
[48] J. Heinanenst, F. Baker, W. Weiss, J. Wroclawski, “Assured Forwarding PHB Group” , IETF RFC, 06-1999
[49] F. Nivor, P. Berthou, S. Abdellatif, T. Gayraud “Amélioration de l’allocation de resource dans un système satellite DVB-
RCS”, CFIP 2006.
[50] F. Nivor, M. Gineste, C baudoin, P. Berthou, T. Gayraud “ Cross-Layer Anticipation of resource allocation for Multimedia
applications based on SIP signalling over DVB-RCS satellite system” International Workshop Budapest, 07-2007.
[51] H. P Lexow, T. A. Navekvien, V. M. Paxal “Satellite resource management combining distributed cooperative methods
and central control using using BoD variants of DVB-RCS”.
[52] [Link]
[53] SatLabs System Recommendations “Part 2 – Quality of Service Specifications” 11-2006.
[54] O. Alphand, R. I. Qureshi, “SIP based QoS control over satellite networks”, International Conference on Engineering
technology, IEEE 2005.
[55] P.D. Mitchell, D. Grace, and T.C. Tozer. “Burst targeted demand assignment multiple-access for broadband Internet
service delivery over geostationary satellite”. IEEE Journal on Selected Areas in Communications, 22: 546–558, 04-2004.
[56] ETSI EN 301 790, “Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems” 09-2005.
[57] ETSI EN 300 468, “Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems” 06-
2004.
[58] E. Dubois, C. Baudoin, E. Chaput, A.L Beylot “Television services over an IP/MPS convergent satellite system”, ICSSC,
05-2007
[59] G. Dimitriadis, S. Karapantazis, F-N. Pavlidou “Performance Evaluation of CRTP and Enhanced CRTP within the DVB-
RCS network” International Workshop Budapest, 07-2007.
[60] A. Shacham, R. Monsour, R. Pereira, M. Thomas “IP Payload Compression Protocol, IPcomp”, IETF RFC, 12-1998.

Chapitre III : DVB-RCS, un standard pour la transmission de l’IP

bidirectionnel par satellite

[1] “Generic coding of Moving Pictures and Associated Audio Information”, Ref: ISO/IEC [Link]-C
[2] EN 300 429 V1.2.1 “Framing structure, channel coding and modulation for cable systems”, 04- 1998
[3] ETSI EN 300 744 V1.5.1 “Framing structure, channel coding and modulation for digital terrestrial television”, 06 2004.
[4] ETSI EN 302 304 V1.1.1 “Transmission system for handheld terminals”, 11-2004
[5] ETSI TS 102 585 V1.1.1 “System Specifications for Satellite services to Handheld devices (SH) below 3 GHz” 07-2007.
[6] ETSI EN 300 421 “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz
satellite services”, 08-1997
[7] ETSI EN 301 790 “Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems”, 09-2005.
[8] R. Chaggara, « Les Modulations à Phase Continue pour la Conception d’une Forme d’Onde Adaptative Application aux
Futurs Systèmes Multimédia par Satellite en Bande Ka » Phd Thesis, ENST Paris, 2004
[9] ETSI EN 300 468 “Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems” 05-
2003.
[10] ETSI TR 101 202 V1.2.1 “Digital Video Broadcasting (DVB); Implementation guidelines for Data Broadcasting”01-2003.
[11] G. Fairhurst and A. Matthews, “A comparison of IP transmission using MPE and a new lightweight encapsulation”,
University of Aberdeen, 2003.

114
[12] R M.A.Vázquez Castro, R. Rinaldo “Encapsulation and Framing Efficiency of DVB-S2 Satellite Systems” Packet-Oriented
Service Delivery via Satellite, COST Action 272, 08-2005.
[13] B. Collini-Nocker, H. Linder, G. Fairhurst “Ultra Lightweight Encapsulation (ULE) Extension Header”, Internet Draft
05-2004.
[14] T.C Hong, W.T Chee, R. Budiarto “A Comparison of IP Datagrams Transmission using MPE and ULE over Mpeg-
2/DVB Networks”, ICICS 2005,
[15] B. Collini-Nocker, G. Fairhurst “ULE versus MPE as an IP over DVB Encapsulation”,
[16] DVB Bluebook A 116, “Generic Stream Encapsulation (GSE) Protocol”, DVB document, 05 -2007.
[17] C. Berrou and A. Glavieux. “Near optimum error correcting coding and decoding turbo-codes” IEEE Transactions on
Communications, 44, 10 - 1996.
[18] ETSI TR 101 790 V1.2.1 “Digital Video Broadcasting (DVB); Interaction channel for Satellite Distribution Systems;
Guidelines for the use of EN 301 790” 01-2003.

Chapitre IV : La plateforme IP DVB-RCS, architecture et

expérimentations

[1] L. Thomasson, P. Bermejo and L. Bouscary, “Validation of DVB-RCS system”, 21st International Communications
Satellite Systems Conference and Exhibit, AIAA, 04-2003
[2] ETSI EN 301 790 “Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems”, 09-2005.
[3] [Link]
[4] SatLabs System Recommendations “Part 2 – Quality of Service Specifications”, 11-2006
[5] ETSI TR 101 790 V1.2.1 “Digital Video Broadcasting (DVB); Interaction channel for Satellite Distribution Systems;
Guidelines for the use of EN 301 790” 01-2003
[6] J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby “Performance Enhancing Proxies Intended to Mitigate Links »
IETF RFC 3135 06-2001.
[7] M. Allman, S. Floyd, C. Partridge, “Increasing TCP's Initial Window”, IETF RFC 3390, 10-2002
[8] H. Balakrishnan, V. N. Padmanabhan, G. Fairhurst, M. Sooriyabandara « TCP Performance Implications of Network Path
Asymmetry », IETF RFC 3449, 12-2002.
[9] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, “TCP Selective Acknowledgment Options”, IETF RFC 2018, 10-1996
[10] S. Kent, R. Atkinson, “Security Architecture for the Internet Protocol”, IETF RFC 2401 11-1998
[11] S. Kent,R. Atkinson “IP Encapsulating Security Payload (ESP)” IETF RFC 2406, 11- 1998.
[12] G. Labouret “IPsec technical Presentation”, Hervé Schauer Consultants HSC
[13] O. Alphand, P. Berthou and T. Gayraud, L. Duquerroy and S. Josset, “SatIPSec : an optimized solution for securing
multicast and unicast satellite transmissions” International Communications Satellite Systems Conference & Exhibit,
AIAA, 2004
[14] [Link]
[15] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson “RTP: A Transport Protocol for Real-Time Applications”, IETF
RFC 3550, 07-2003.
[16] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler “SIP: Session
Initiation Protocol” IETF RFC 3261, 06 2002.
[17] ITU Standards, Series P: Telephone Transmission quality, Telephone Installations, Local line networks, “Mean Opinion
Score (MOS) Terminology”, P. 800, 03-2003
[18] ITU standards, Series G: Transmission Systems and Media, Digital systems and networks “International telephone
connections and circuits – General Recommendations on the transmission quality for an entire international telephone
connection”, G.114 05-2003.
[19] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy « Enhanced Compressed RTP (CRTP) for Links with High
Delay » IETF RFC 3545, 07-2003
[20] Federal Information Processing Standards Publication, U.S. DEPARTMENT OF COMMERCE/National Institute of
Standards and Technology “Data Encryption Standard (DES)” 10-1995
[21] [Link]

115
Chapitre V: iDirect et DVB-RCS, comparaison des performances

[1] ETSI EN 301 790 “Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems”, 09-2005.
[2] [Link]
[3] ETSI EN 300 421 “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz
satellite services”, 08-1997
[4] C. Berrou and A. Glavieux. “Near optimum error correcting coding and decoding turbo-codes” IEEE Transactions on
Communications, 44, 10 – 1996
[5] J. Heinanen « Multiprotocol Encapsulation over ATM Adaptation Layer », IETF RFC 1483, 07-1993
[6] “Generic coding of Moving Pictures and Associated Audio Information”, Ref: ISO/IEC 13818-16.
[7] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, “TCP Selective Acknowledgment Options”, IETF RFC 2018, 10-1996
[8] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy « Enhanced Compressed RTP (CRTP) for Links with High
Delay, Packet Loss and Reordering” IETF RFC 3545, 07-2003

Chapitre VI le nouveau standard DVB-S2 et les applications IP par satellite

[1] ETSI EN 302 307 V1.1.1, “Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and
modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications”,
03-2005.
[2] EN 301 210 V1.1.1 “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for Digital
Satellite News Gathering (DSNG) and other contribution applications by satellite”, 03-1999
[3] “ACM Modem final report” [Link] , 08-2008
[4] T. Richardson and R. Urbanke. The capacity of low-density parity check codes under message-passing decoding. IEEE
Transactions on Information Theory, 47 599–618, 02-2001.
[5] R. Stasiewicz “La nouvelle norme internationale DVB-S2”, Revue des technologies de radio Canada, numéro 3, 01-2007.
[6] A. Morello, V. Mignone “ DVB-S2 dans les starting blocks”, Radio Televisione Italiana, UER, Revue technique, 2004 .
[7] ETSI TR 102 376 “Digital Video Broadcasting (DVB) User guidelines for the second generation system for Broadcasting,
Interactive Services, News Gathering and other broadband satellite applications (DVB-S2)”
[8] “Generic Stream Encapsulation (GSE) Protocol”, DVB Document, 05-2007

116
Liste des publications

Conférence Internationales

N. Jegham, N. Lerouge, G. Roussel « Voice over IPsec in a DVB-RCS network »,
12th Ka and Broadband Communication Conference, Naples, Italy, 09-2006

N. Jegham, A-L Beylot, S. Lohier, G. Roussel « Performance of Voice over IP in
DVB-RCS and iDirect satellite networks », 26th AIAA International Communication
Satellite SystesmConference, San Diego, USA, 06-2008

N. Jegham, N. Girault, C. Le Guern, A-L Beylot, S. Lohier, G. Roussel « VoIP over a
DVB-S2 ACM link », International Workshop on Satellite and Space
Communications, 10-2008

N. Girault, A-L Beylot, C. Le Guern, N. Jegham, « OURSES: Efficiency of IP
Encapsulation over DVB-S2 Links », International Workshop on Satellite and Space
Communications, 10-2008

Conférences nationales

N. Jegham, N. Lerouge « VoIP sur DVB-RCS, état de l’art », actes, 8ème Journées
Doctorales en Informatique et Réseaux, Marne-La-Vallée, 17, 18, et 19 Janvier 2007.

N. Jegham, A-L, Beylot, S. Lohier, G. Roussel, « Les applications IP sur satellite,
exemple de la VoIP », Journées ResCom, 7 et 8 février 2008.

117