THÈSE

En vue de l'obtention du

DOCTORAT
DOCTORAT DE
DE L'UNIVERSITÉ
L'UNIVERSITÉ DE
DE TOULOUSE
TOULOUSE

Délivré par l'Institut National Polytechnique de Toulouse

Discipline ou spécialité : Réseaux et Télécommunications

Présentée et soutenue par Emmanuel DUBOIS

Le 3 novembre 2008

Titre : Convergence dans les réseaux satellite

JURY

Pascal Lorenz Professeur Université Haute-Alsace Rapporteur

Walid Dabbous Directeur Recherche INRIA Rapporteur

Fabrice Valois Professeur Université Lyon, INRIA Président

Cédric Baudoin Ing. Recherche Thales Alenia Space Membre, co-encadrant

Patrick Gélard Ing. Recherche CNES Invité

Thierry Gayraud M.C Université Toulouse III, HDR Membre

André-Luc Beylot Professeur INP-ENSEEIHT Directeur de thèse

Emmanuel Chaput M.C INP-ENSEEIHT Membre, co-encadrant

Ecole doctorale : Mathématiques Informatique et Télécommunications

Unité de recherche : IRIT
Directeur(s) de Thèse : André Luc Beylot
ii
Remerciements

J’entame ces remerciements avec le soulagement d’avoir achevé et soutenu ma

thèse. A la fin de cette période particulière, il convient de me retourner en arrière et de té-
moigner ma reconnaissance aux personnes qui m’ont soutenu pendant ce parcours. Ces
remerciements marquent la fin de trois années de travail, en espérant que les contacts
perdureront à cette étape doctorale avec de nombreuses personnes.
Tout d’abord, je remercie mes encadrants académiques André-Luc et Manu, qui
n’ont d’académiques que le statut. Ils m’ont toujours soutenu du début à la fin et m’ont
largement guidé dans mes choix d’orientation professionel. Ils ont su me donner de
précieux conseils pour avancer et ne pas abandonner dans les moments plus difficiles.
Je les remercie énormément pour leur disponibilité et leur bonne humour ! Je n’oublierai
jamais les bons moments passés en Corée, en Italie avec Manu, même si une conférence
en chine avec eux aurait été encore mieux ! Je recommande à Manu de faire attention à
ne pas manger trop de glaces pendant les conférences et André-Luc à ne pas finir comme
le concierge de l’IRIT.
En second lieu, je remercie Cédric, encadrant industriel à Thales Alenia Space, pour
son encadrement malgré un emploi du temps bien chargé. Il a toujours réussi à se dé-
gager du temps, notamment pendant mes périodes à Thales Alenia Space qui furent
à chaque fois efficace et déterminante pour l’avancement de la thèse. Je le remercie
vraiment pour sa bonne humeur communicative qui contribue largement à la bonne am-
biance de toute l’équipe de recherche de Thales. Je salue d’ailleurs Fabrice, Erwan,
Mathieu, Katia, Zakariya et Isabelle pour leur accueil. La conférence ASMS’08 fut un
très bon moment d’échanges en bonne compagnie.
S’il y a une structure à remercier, c’est bien le laboratoire TeSA. En effet, j’y ai
passé la grande partie de ces trois ans, parfois la nuit et quelques week-ends. Je re-
mercie l’ensemble des personnes pour l’ambiance sympathique autour des repas et de
l’organisation du laboratoire : les sécrétaires sans qui on ne pourrait rien faire : Marie-
José, Sarah, Yamina ; les ingénieurs de TeSA : Will, David, Philippe, Hassan, Tayeb ;
les autres doctorants : Emmanuel, Lucile, Ferdinand, Mariana, Xavier, Julien, Benja-
min, Anchalee, Christophe, Tai. Je n’oublie pas l’incontournable Patrice et les longues
conversations politiques et culturelles, sans oublier les doyens du laboratoire Francis et
Bernard.

iii
iv

Le deuxième emplacement important de ma thèse fut incontestablement l’IRIT à

coté de l’ENSEEIHT, laboratoire de mes encadrants. Je salue toute l’équipe IRT et no-
tamment Rahim et Alexandra que je remercie pour ces trois années d’échanges. Merci
également à Corinne, Jean-Yves et Nathalie pour leur constante bonne humeur. J’ai
également beaucoup apprécié tous les enseignements effectués à l’ENSEEIHT et les
personnes avec qui j’ai partagé cette expérience enrichissante de partage du savoir. Un
spécial merci à Julou et Fred pour leur amitié et les nombreux restaurants découverts
grâce à eux ! Les soirées ciné-resto et les jeux de rôles magnifiquement portés par Julien
sont à chaque fois de très bons moments.
Je remercie les membres du jury de s’être déplacé pour juger de mon travail, no-
tamment mon collègue actuel Patrick Gélard, le président du jury Fabrice Valois qui a
répondu présent malgré une sollicitation tardive, Pascal Lorenz sans qui la thèse n’aurait
pu être soutenu faute de rapporteur et Thierry Gayraud qui a eu de nombreuses inter-
rogations intéressantes sur la thèse. Je remercie également Walid Dabbous d’avoir émis
un avis favorable pour soutenir ma thèse.
Enfin, je remercie mes proches d’avoir eu à supporter ce travail de longue haleine
de l’extérieur. J’ai été très touché qu’ils viennent nombreux à ma soutenance de thèse.
Je profite de ces remerciements pour exprimer tout le bien que je pense d’eux au jour le
jour et leur importance dans ma vie et dans mon coeur.
Table des matières

Remerciements iii

Liste des acronymes xiii

Introduction 1

1 Réseaux satellite GEO 3

1.1 Caractéristiques d’un lien satellite . . . . . . . . . . . . . . . . . . . . 5
1.1.1 LEO, MEO, GEO . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2 Transparent/régénératif . . . . . . . . . . . . . . . . . . . . . . 6
1.1.3 Réseaux DVB . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Voie aller DVB-S et DVB-S2 . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Vue générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 MPEG2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Signalisation PSI/SI . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4 DVB-S et DVB-S2 . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.5 Encapsulation de données . . . . . . . . . . . . . . . . . . . . 13
1.3 Voie retour DVB-RCS . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.1 Vue générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2 Signalisation DVB-RCS . . . . . . . . . . . . . . . . . . . . . 15
1.3.3 Étapes de fonctionnement de DVB-RCS . . . . . . . . . . . . . 17
1.4 Évolution des satellites GEO . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Les architectures de convergence 23

2.1 Panorama historique . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1 Monde des opérateurs de télécommunications . . . . . . . . . . 24
2.1.2 Monde informatique . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.3 Monde opérateur vidéo . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Convergence des communications . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Définition de la convergence . . . . . . . . . . . . . . . . . . . 27

v
vi TABLE DES MATIÈRES

2.2.2 Caractéristiques générales de convergence . . . . . . . . . . . . 29

2.2.2.1 Structure protocolaire . . . . . . . . . . . . . . . . . 29
2.2.2.2 Simplicité . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.2.3 Topologie distribuée . . . . . . . . . . . . . . . . . . 30
2.2.2.4 Intéropérabilité . . . . . . . . . . . . . . . . . . . . 30
2.2.2.5 Interconnexion . . . . . . . . . . . . . . . . . . . . . 31
2.2.2.6 Qualité de Service . . . . . . . . . . . . . . . . . . . 31
2.2.2.7 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2.8 Gestion . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Solutions de convergence satellite . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Convergence des architectures réseaux . . . . . . . . . . . . . . 32
2.3.1.1 Solution DVB . . . . . . . . . . . . . . . . . . . . . 32
2.3.1.2 Solution ATM . . . . . . . . . . . . . . . . . . . . . 35
2.3.1.3 Solution Ethernet . . . . . . . . . . . . . . . . . . . 37
2.3.1.4 Solution tout IP . . . . . . . . . . . . . . . . . . . . 39
2.3.1.5 Solution MPLS - MultiProtocol Label Switching . . . 41
2.3.2 Convergence fixe mobile . . . . . . . . . . . . . . . . . . . . . 44
2.3.3 Convergence par les services . . . . . . . . . . . . . . . . . . . 45
2.3.3.1 Approche DVB . . . . . . . . . . . . . . . . . . . . 46
2.3.3.2 Approche IP . . . . . . . . . . . . . . . . . . . . . . 46
2.3.3.3 Approche IMS . . . . . . . . . . . . . . . . . . . . . 47
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3 Solution MPLS : cas unidirectionnel 49

3.1 Architecture IP/MPLS générale . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Télévision sur IP/MPLS par satellite unidirectionnel . . . . . . . . . . . 52
3.2.1 Architecture de diffusion TV . . . . . . . . . . . . . . . . . . . 52
3.2.1.1 Couches de service de télévision . . . . . . . . . . . 54
3.2.1.2 Couches de convergence IP/MPLS . . . . . . . . . . 55
3.2.1.3 Couches d’accès satellite . . . . . . . . . . . . . . . 57
3.2.2 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.2.1 Migration de la signalisation PSI/SI . . . . . . . . . . 58
3.2.2.2 Adressage du service télévisé . . . . . . . . . . . . . 60
3.2.2.3 Confidentialité et sécurité des programmes . . . . . . 63
3.2.2.4 Synchronisation . . . . . . . . . . . . . . . . . . . . 63
3.2.2.5 Qualité de service et ordonnancement . . . . . . . . . 64
3.2.3 Analyse du système . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.3.1 Migration depuis un système actuel . . . . . . . . . . 65
Migration réseau : . . . . . . . . . . . . . . . . . . . . 65
Migration des services : . . . . . . . . . . . . . . . . . 66
3.2.3.2 Analyse quantitative . . . . . . . . . . . . . . . . . . 66
TABLE DES MATIÈRES vii

Overhead : . . . . . . . . . . . . . . . . . . . . . . . . 66
Signalisation : . . . . . . . . . . . . . . . . . . . . . . 67
Services utilisateur : . . . . . . . . . . . . . . . . . . . 67
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 Solution MPLS : cas bidirectionnel 69

4.1 Télévision sur IP/MPLS par satellite bidirectionnel . . . . . . . . . . . 70
4.1.1 Problématiques liées à la voie retour . . . . . . . . . . . . . . . 70
4.1.1.1 Organisation système . . . . . . . . . . . . . . . . . 71
4.1.1.2 Organisation protocolaire issue de DVB-RCS . . . . 72
Approche conservatrice de DVB-RCS : . . . . . . . . . 73
Approche d’intégration avec IP/MPLS : . . . . . . . . . 73
4.1.2 Architecture IP/MPLS bidirectionnelle . . . . . . . . . . . . . 77
4.1.2.1 Couches de communications satellites . . . . . . . . 77
4.1.2.2 Couches IP/MPLS . . . . . . . . . . . . . . . . . . . 79
4.1.2.3 Service de télévision bidirectionnel . . . . . . . . . . 80
Vote orienté fournisseur : . . . . . . . . . . . . . . . . . 80
Vote orienté Terminal : . . . . . . . . . . . . . . . . . . 81
4.1.3 Problématiques de l’architecture choisie . . . . . . . . . . . . . 82
4.1.3.1 Adressage . . . . . . . . . . . . . . . . . . . . . . . 83
Identifiants IP/MPLS/GSE . . . . . . . . . . . . . . . . 83
Identifiants DVB-RCS . . . . . . . . . . . . . . . . . . 83
4.1.3.2 Résolution d’adresse . . . . . . . . . . . . . . . . . . 84
4.1.3.3 Accès à la signalisation de la voie aller . . . . . . . . 84
4.1.3.4 Migration de la signalisation . . . . . . . . . . . . . 85
4.1.3.5 Synchronisation . . . . . . . . . . . . . . . . . . . . 86
4.1.3.6 Sécurité et Confidentialité . . . . . . . . . . . . . . . 86
4.1.3.7 Compatibilité unidirectionnelle/bidirectionnelle . . . 88
4.2 Multi-services sur une architecture IP/MPLS satellite bidirectionnelle . 88
4.2.1 Architecture satellite IP/MPLS triple play . . . . . . . . . . . . 89
4.2.2 Service de Téléphonie . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5 Application au projet ULISS 95

5.1 Le projet ULISS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.1 Organisation générale . . . . . . . . . . . . . . . . . . . . . . 98
5.1.2 Etapes de fonctionnement . . . . . . . . . . . . . . . . . . . . 100
5.2 Convergence IP/MPLS dans ULISS . . . . . . . . . . . . . . . . . . . 103
5.2.1 Approche par encapsulation . . . . . . . . . . . . . . . . . . . 103
5.2.2 Approche compatible DVB . . . . . . . . . . . . . . . . . . . . 104
5.2.3 Approche d’intégration avec les protocoles IP/MPLS . . . . . . 108
viii TABLE DES MATIÈRES

5.3 Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . . . . 110

Conclusion 111

Bibliographie 113
Liste des figures

1.1 Système DVB-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Codage et multiplexage de programmes MPEG2 . . . . . . . . . . . . 8
1.3 Format de la trame MPEG2-TS . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Fonctionnement du système DVB-S2 . . . . . . . . . . . . . . . . . . . 12
1.5 En-tête GSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Système DVB-RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.7 Tramage MF-TDMA DVB-RCS . . . . . . . . . . . . . . . . . . . . . 16
1.8 Fonctionnement de DVB-RCS . . . . . . . . . . . . . . . . . . . . . . 18
1.9 Architecture maillée type Amerhis . . . . . . . . . . . . . . . . . . . . 21

2.1 La convergence des réseaux par IP . . . . . . . . . . . . . . . . . . . . 28

2.2 Récapitulatif de l’architecture ATM . . . . . . . . . . . . . . . . . . . 35
2.3 Architecture UETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4 Entrée du réseau MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5 Cœur du réseau MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.6 Sortie du réseau MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.7 Nomadisme et mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1 Architecture IP/MPLS générale . . . . . . . . . . . . . . . . . . . . . . 51

3.2 Nouvelle architecture de diffusion vidéo . . . . . . . . . . . . . . . . . 53
3.3 Description des étapes d’un transport de programmes télévisuels . . . . 61
3.4 Overhead en fonction du nombre de paquets MPEG2 . . . . . . . . . . 66

4.1 Organisation système du satellite bidirectionnel envisagé . . . . . . . . 71

4.2 Approche conservatrice de DVB-RCS . . . . . . . . . . . . . . . . . . 74
4.3 Approche d’intégration avec IP/MPLS . . . . . . . . . . . . . . . . . . 75
4.4 Architecture du service de télévision sur une liaison satellite bidirec-
tionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.5 Exemple de déroulement d’un service de télévision interactif orienté
fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

ix
x LISTE DES FIGURES

4.6 Exemple de déroulement d’un service de télévision interactif orienté

terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.7 Intégration de nouveaux services sur une architecture IP/MPLS . . . . . 90
4.8 Session SIP de communication téléphonique VoIP . . . . . . . . . . . . 91

5.1 Vue d’ensemble du projet ULISS . . . . . . . . . . . . . . . . . . . . . 96

5.2 Principe du Radio Burst Switching dans le projet ULISS . . . . . . . . 97
5.3 Organisation générale du système ULISS . . . . . . . . . . . . . . . . 98
5.4 Etapes de fonctionnement d’ULISS . . . . . . . . . . . . . . . . . . . 102
5.5 Etapes de fonctionnement pour l’approche compatible de convergence . 107
5.6 Approche de convergence avec les protocoles IP/MPLS . . . . . . . . . 109
Liste des tableaux

1.2 Signalisation SI de la voie retour . . . . . . . . . . . . . . . . . . . . . 17

3.3 Correspondance avec la signalisation SI . . . . . . . . . . . . . . . . . 58

3.5 Exemple de signalisation SDP pour le service télévisé . . . . . . . . . . 59

4.2 Correspondance des tables SI pour la voie retour . . . . . . . . . . . . . 76

4.4 Évolution de la table TBTP . . . . . . . . . . . . . . . . . . . . . . . . 87

5.4 Couches protocolaires du système ULISS et leurs évolutions . . . . . . 105

xi
xii LISTE DES TABLEAUX
Liste des acronymes

ACQ ACQuisition.
ACM Adaptive Coding & Modulation.
ATSC Advanced Television Systems Committee.
ADSL Asymmetric Digital Subscriber Line.
ATM Asynchronous Transfer Mode.
AAL ATM Adaptation Layer.
AAL5 ATM Adaptation Layer 5.
BBFRAME BaseBand Frame.
BCC Beam Control Centre.
BOOTP Bootstrap Protocol.
BAT Bouquet Association Table.
B-ISDN Broadband ISDN.
BHP Burst Header Packet.
BTP Burst Time Plan.
CNES Centre National d’Etudes Spatiales.
CBQ Class Based Queuing.
CoS Class of Service.
CSA Common Scrambling Algorithm.
CSC Common Signalling Channel.
CAT Conditionnal Access Table.
CAC Connection Admission Control.
C2P Connection Control Protocol.
CR-LDP ConstRaint based LDP.
CMT Correction Message Table.
CSCT CSC Table.

xiii
xiv LISTE DES ACRONYMES

DOCSIS Data Over Cable Service Interface Specification.

DULM Data Unit Labelling Method.
DAMA Demand Assignment Multiple Access.
DRM Digital Rights Management.
DVB Digital Video Broadcast.
DVB-C Digital Video Broadcast - Cable.
DVB-RCS Digital Video Broadcast - Return Channel Satellite.
DVB-S Digital Video Broadcast - Satellite.
DVB-T Digital Video Broadcast - Terrestrial.
DVB-S2 Digital Video Broadcasting - Satellite - Second Generation.
DLS Down Link Signaling.
DVB-CA DVB - Conditional Access.
DVB-H DVB - Handheld.
DVB-SH DVB - Satellite services to Handhelds.
DHCP Dynamic Host Configuration Protocol.
EPG Electronic Program Guide.
ES Elementary Stream.
ESA European Space Agency.
ETSI European Telecommunications Standards Institute.
EIT Event Information Table.
FMIP Fast handover for Mobile IP.
FIFO First In First Out.
FECFRAME Forward Error Correction Frame.
FLS Forward Link Signaling.
FEC Forwarding Equivalence Class.
FCT Frame Composition Table.
GMPLS Generalized MPLS.
GSE Generic Stream Encapsulation.
GEO Geostationary Earth Orbit.
GSM Global System for Mobile communications.
HTTP HyperText Transport Protocol.
IEEE Institute of Electrical and Electronics Engineers.
LISTE DES ACRONYMES xv

ISDB Integrated Services Digital Broadcasting.

ISDN Integrated Services Digital Network.
ISO International Organization for Standardization.
ITU International Telecommunication Union.
ICMP Internet Control Message Protocol.
IETF Internet Engineering Task Force.
IGMP Internet Group Management Protocol.
IP Internet Protocol.
IPv4 IP - version 4.
IPv6 IP - version 6.
IMS IP Multimedia Subsystem.
IPsec IP Security.
IPTV IP Television.
INT IP/MAC Notification Table.
ISDB-S ISDB - Satellite.
ITU-T ITU Telecommunication Standardization sector.
LDP Label Distribution Protocol.
LER Label Edge Routeur.
LIB Label Information Base.
LSP Label Switch Path.
LSR Label Switch Router.
LLC Link Layer Control.
LMP Link Management Protocol.
LAN Local Area Network.
LDPC Low-Density Parity-Check.
LEO Low Earth orbit.
MIB Management Information Base.
MAC Media Access Control.
MEO Medium Earth orbit.
MPEG2 Moving Pictures Expert Group - Second Generation.
MPEG2-TS MPEG2 - Transport Stream.
MPE Multi-Protocol Encapsulation.
xvi LISTE DES ACRONYMES

MPLS Multi-Protocol Label Switching.

MHP Multimedia Home Platform.
MF-TDMA Multiple Frequency Time Division Multiple Access.
NAT Network Address Translation.
NCR Network Clock Reference.
NCC Network Control Centre.
NIT Network Information Table.
NTP Network Time Protocol.
OBP On-Board Processing.
OSI Open Systems Interconnection.
OBS Optical Burst Switching.
PES Packet Elementary Stream.
PID Packet IDentifier.
PLFRAME Physical Level Frame.
PAT Program association Table.
PCR Program Clock Reference.
PMT Program Map Table.
PSI Program Specific Information.
PSTN Public Switched Telephone Network.
QPSK Quadrature Phase-Shift Keying.
QoS Quality of Service.
RBS Radio Burst Switching.
RMT RCS Map Table.
RTP Real-Time Transport Protocol.
RFC Request For Comments.
RSVP Resource ReSerVation Protocol.
RCST Return Channel Satellite Terminal.
ROHC RObust Header Compression.
RSVP-TE RSVP - Traffic Engineering.
RST Running Status Table.
RTC Réseau Téléphonique Commuté.
RNIS Réseaux Numériques à Intégration de Services.
LISTE DES ACRONYMES xvii

SACT SAC Table.

SAC Satellite Access Control.
SNC Satellite Network Controller.
SPT Satellite Position Table.
SRTP Secure RTP.
SDT Service Description Table.
SI Service Information.
SAP Session Announcement Protocol.
SDP Session Description Protocol.
SIP Session Initiation Protocol.
SMTP Simple Mail Transport Protocol.
SNMP Simple Network Management Protocol.
ST Stuffing Tables.
SCT Superframe Composition Table.
SYNC SYNChronisation.
SDH Synchronous Digital Hierarchy.
TBTP Terminal Burst Time Table.
TIM Terminal Information Message.
3GPP Third Generation Partnership Project.
TDT Time and Data Table.
TDMA Time Division Multiple Access.
TOT Time Offset Table.
TCT Time-slot Composition Table.
TTL Time To Live.
TRF Traffic.
TCP Transport Control Protocol.
TDL Transport Data Link.
T-MPLS Transport MPLS.
TSDT Transport Stream Description Table.
TOS Type of Service.
ULISS ULtra fast Internet Satellite Switching.
ULE Unidirectional Lightweight Encapsulation.
xviii

UDLR UniDirectional Link Routing.

URI Uniform Resource Identifier.
UETS Universal Ethernet Telecommunications Service.
ULS Up Link Signaling.
UDP User Datagram Protocol.
VSAT Very Small Aperture Terminal.
VCI Virtual Channel Identifier.
VPI Virtual Path Identifier.
VPLS Virtual Private LAN Service.
VPN Virtual Private Network.
VoIP Voice over IP.
WFQ Weighted Fair Queuing.
Résumé

Les réseaux satellite ont été standardisés par le groupe DVB en se focalisant sur
le service de télévision. Dans un contexte de convergence, notamment caractérisé par
l’émergence des offres “triple play”, les nouvelles architectures de télécommunica-
tion par satellite doivent être conçues de façon plus ouverte. Après une description du
contexte des réseaux satellites DVB, nous recensons les solutions de convergence ap-
plicables à ces réseaux. Notre choix s’est porté sur les technologies convergentes IP et
MPLS pour proposer une telle architecture de convergence. Pour en évaluer les qualités,
plusieurs scénarios sont alors envisagés. Le premier se concentre sur le service histo-
rique de télévision avec un satellite transparent et unidirectionnel. Nous montrons que
la solution IP/MPLS permet d’offrir le même service avec des performances similaires
et surtout ajoute une structure protocolaire augmentant l’évolutivité. Les scénarios sui-
vants s’occupent d’un service de télévision interactif avec voie retour et d’un service
de voix sur IP et mettent en valeur la facilité de leur mise en œuvre. Le dernier scé-
nario applique notre approche convergente IP/MPLS au projet de satellite régénératif
hybride ULISS. Cela a permis de montrer la flexibilité de l’architecture et d’étendre les
possibilités de services du projet.

xix
xx
Abstract

Satellite networks have been built by the DVB group and dedicated to digital te-
levision service. However, in the current service convergence trend, a future satellite
network architecture has to be built in a less dedicated way to fit heterogeneous ser-
vices. This work begins with a description of DVB satellite networks. Then, network
convergence solutions are studied for the satellite context. IP and MPLS have then been
chosen to build a satellite convergent architecture. Several scenarios are examined so
as to evaluate this architecture. A first one deals with the historical television service in
a unidirectional, transparent satellite context. We show the feasibility of such a scena-
rio with similar performances and better protocol organisation which simplifies satellite
evolution. The next scenarios concern an interactive television service with a return link
and a voice over IP service. The ability of deploying new services in a simple manner is
thus highlighted. The last scenario applies our convergent approach to the ULISS indus-
trial project of a regenerative hybrid satellite. It shows the flexibility of our architecture
and expand ULISS service capabilities.

xxi
xxii
Introduction

Les systèmes de communication par satellite ont longtemps eu des fonctionnements

dédiés et souvent propriétaires. L’essor de la télévision par satellite a vu l’apparition
de nombreux standards, d’abord analogiques puis numériques. Le standard le plus ré-
pandu s’appelle DVB-S (Digital Video Broadcast - Satellite) et repose sur la norme de
compression MPEG2 (Moving Pictures Expert Group - Second Generation). Les prin-
cipes des réseaux satellite sont donc souvent très éloignés de standards de réseaux de
télécommunication terrestres du fait de leur utilisation ciblée et de leurs caractéristiques
intrinsèques.
Le futur de ces réseaux satellite de télévision se pose donc dans le contexte géné-
ral de la convergence. En effet, les réseaux de télécommunication ne sont plus dédiés
à la téléphonie, à l’échange de données ou encore à la télévision. De très nombreuses
offres “triple play” intégrant tous ces services sur le même support se sont développées.
Les utilisateurs souhaitent être joignables partout, tout le temps et avec n’importe quel
terminal. Cette convergence des réseaux a été portée par le succès planétaire du réseau
Internet animé par le protocole IP (Internet Protocol). Utilisé d’abord pour des services
d’échange de fichiers (mail, web), ce protocole a permis le développement d’applica-
tions multimédia qui concurrencent les services des opérateurs de télécommunications.
IP est ainsi devenu l’interface incontournable des services, adoptée désormais par ces
opérateurs dans leurs offres intégrées.
Cette thèse a pour objectif d’étudier cette convergence des moyens de communica-
tion dans le cadre des réseaux satellite de télévision. En effet, en raison d’une conception
dédiée à la télévision, l’intégration de nouveaux services dans les réseaux satellite stan-
dards est complexe. Le développement des offres Internet par satellite pour connecter
des lieux non couverts par les opérateurs terrestres montre l’utilité de proposer de nou-
velles architectures de communication moins dépendantes du fonctionnement de la télé-
vision. La thèse de J. Fasson [1] étudiait déjà les difficultés d’une telle évolution du fait
des fortes différences entre IP et les fonctionnements DVB existants. Il concluait que,
si de nombreuses solutions d’interconnexion existaient bien, il manquait “une architec-
ture fédératrice et pérenne, apportant une solution entre les satellites actuels et futurs et
intégrant différents services”. Nous cherchons ici à répondre à ce besoin d’architecture
convergente satellite.

1
2 INTRODUCTION

Dans une première partie, nous détaillons alors les standards de télécommunication
dans le monde satellite. Nous ne nous attachons pas aux techniques propriétaires qui,
par nature, ne se prêtent pas à une convergence entre différents mondes et différents
constructeurs.
Ensuite, nous nous penchons sur la notion de convergence et en particulier sur celle
des architectures de réseaux qui apparaît comme plus importante. Après un panorama
historique, des critères de convergence sont définies. Nous décrivons alors différentes
solutions de convergence et leur applicabilité au système satellite. Leurs avantages et in-
convénients sont analysés à partir des critères proposées. Le but est de comparer les dif-
férentes approches pour choisir une architecture de convergence par satellite acceptable.
Notre choix se porte sur les technologies IP et MPLS (Multi-Protocol Label Switching)
pour étudier cette convergence.
Une architecture globale fondée sur IP et MPLS est donc définie. L’étude exhaustive
d’une architecture répondant à toutes les configurations s’avère inadaptée. Il est préfé-
rable de considérer un scénario élémentaire : le service de télévision unidirectionnel sur
un satellite transparent. Il s’agit d’une part de valider notre solution dans ce cadre clas-
sique, et d’autre part de montrer qu’il est possible d’obtenir un service comparable avec
des performances équivalentes.
Après avoir établi la faisabilité d’une telle solution pour le service historique, le
chapitre suivant décrit un système de télévision interactif par satellite dans un mode
bidirectionnel. Dans ce cadre, un scénario d’intégration de différents services est traité,
en particulier pour un service de téléphonie sur IP. Notre travail trouve alors tout son
sens. Nous montrons la capacité de notre solution à intégrer des services attractifs pour
les utilisateurs.
Parmi les difficultés que l’on rencontre à l’heure actuelle avec les systèmes de com-
munication par satellite, on peut citer l’absence de structuration en couches et un simple
découpage fonctionnel. Cette technique convient parfaitement pour des systèmes mono-
technologie, mono-service et mono-opérateur, mais pose des problèmes d’évolutivité et
d’interopérabilité. Un des points forts de notre travail aura été proposer un découpage
fonctionnel de la signalisation permettant ainsi de séparer la signalisation spécifique
au système satellite de celle liée au service. Pour mettre en évidence tout l’intérêt de
notre approche, nous nous sommes intéressés dans le dernier chapitre à l’application de
l’architecture de convergence IP/MPLS dans un contexte industriel du projet de com-
mutateur embarqué ULISS (ULtra fast Internet Satellite Switching). Ce scénario dans
un contexte de satellite régénératif montre la flexibilité de l’approche et l’intérêt d’un
modèle de convergence pour le satellite.
Chapitre 1

Réseaux satellite GEO

1.1 Caractéristiques d’un lien satellite . . . . . . . . . . . . . . . . . . . . 5

1.1.1 LEO, MEO, GEO . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2 Transparent/régénératif . . . . . . . . . . . . . . . . . . . . . . 6
1.1.3 Réseaux DVB . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Voie aller DVB-S et DVB-S2 . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Vue générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 MPEG2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Signalisation PSI/SI . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4 DVB-S et DVB-S2 . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.5 Encapsulation de données . . . . . . . . . . . . . . . . . . . . 13
1.3 Voie retour DVB-RCS . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.1 Vue générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2 Signalisation DVB-RCS . . . . . . . . . . . . . . . . . . . . . 15
1.3.3 Étapes de fonctionnement de DVB-RCS . . . . . . . . . . . . . 17
1.4 Évolution des satellites GEO . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3
4 CHAPITRE 1. RÉSEAUX SATELLITE GEO

Les satellites ont été inventés avec l’idée qu’un point d’observation en très haute
altitude pourrait servir à de nombreuses applications de télécommunication. Avant la
conquête de l’espace, ce principe de relais d’ondes électromagnétiques a été assuré par
des avions en haute altitude, des ballons ou même la Lune. L’écrivain Arthur C. Clarke
avait décrit dès 1945 le principe d’un relais géostationnaire et montré qu’une couverture
mondiale serait possible avec trois satellites “fixes” [2]. Plus tard, le premier satellite
artificiel dans l’espace fut Spoutnik 1, lancé par les soviétiques en 1957. Après de nom-
breux essais, le premier satellite actif de communication fut Telstar et la première trans-
mission télévisuelle par satellite eut lieu en 1962 [3]. En août 1964, le premier satellite
fixe en orbite géostationnaire Syncom 3 permit véritablement d’assurer un service de
télécommunication point à point pour des transferts sur longue distance.
Avec l’évolution des tailles des antennes et des technologies des satellites, les ser-
vices en diffusion se sont ensuite largement imposés [4]. La multiplication des offres
de télévision a poussé à l’adoption de standards de communication d’abord analogiques
puis numériques. En Europe, le groupe DVB (Digital Video Broadcast) de l’ETSI (Euro-
pean Telecommunications Standards Institute) standardise le fonctionnement d’un ser-
vice de télévision sur de nombreux supports : câble (DVB-C), hertzien (DVB-T) et
satellite (DVB-S). Ce système se fonde sur le standard vidéo MPEG2 (Moving Pictures
Expert Group - Second Generation) [5]. Un article de D. Wood, membre important du
projet DVB, explique le contexte de ce projet de diffusion numérique et les choix effec-
tués [6].
Concurrencé par des systèmes équivalents reposant également sur MPEG2 comme
le système ATSC (Advanced Television Systems Committee) [7] ou ISDB-S (ISDB -
Satellite) [8]), cette norme s’est néanmoins imposée dans la plupart des pays comme
le standard pour la télévision numérique par satellite. Un groupe de l’IETF (Internet
Engineering Task Force), organisme de standardisation de l’Internet, a même été créé
pour étudier l’intégration du trafic IP sur des réseaux DVB. Les standards DVB forment
donc l’architecture de communication de base des réseaux satellite domestiques exis-
tants. D’autres architectures ont été utilisées pour des services point à point de type
VSAT (Very Small Aperture Terminal) ou pour échanger de grandes quantités d’infor-
mations entre deux continents. Ces services restent néanmoins beaucoup plus coûteux
et moins répandus ; leur standardisation s’est donc moins imposée. C’est pourquoi nous
nous concentrons sur le fonctionnement des architectures DVB par satellite, les plus
courantes.
La première partie rappelle certains principes de base des réseaux satellite pour en-
suite détailler le standard DVB-S et son évolution DVB-S2 dans une deuxième partie.
Enfin, le standard DVB-RCS (Digital Video Broadcast - Return Channel Satellite) per-
mettant d’ajouter une interactivité au fonctionnement unidirectionnel classique est dé-
crit. Les bons livres de vulgarisation d’Hervé Benoit sur le sujet témoignent du succès
public de ces systèmes [9, 10, 11].
1.1. CARACTÉRISTIQUES D’UN LIEN SATELLITE 5

1.1 Caractéristiques d’un lien satellite

Les satellites de télécommunication transmettent donc des informations d’un point
à l’autre de la Terre, notamment des programmes télévisés en diffusion mais aussi des
communications téléphoniques ou de données. Un satellite est constitué d’une plate-
forme (“service module”) assurant le maintien à poste dans l’espace et d’une charge
utile (“payload”) permettant de remplir la mission du satellite. Pour un satellite de télé-
communication, elle est constituée de différents transpondeurs qui reçoivent, amplifient
et retransmettent des signaux sur des fréquences différentes. Les satellites utilisent des
bandes de fréquence particulières ; les plus communes sont les bandes C (3.7 - 4.2GHz),
Ku (10.70 - 12.75GHz) ou plus récemment Ka (20 - 30 GHz).
Le médium satellite a donc des caractéristiques particulières :
– une grande couverture pouvant aller du tiers de la planète à 100 km pour les plus
petits faisceaux ;
– une diffusion naturelle, qui a naturellement aidé à développer la télévision par
satellite ou toute application de diffusion ;
– une accessibilité totale dans la zone de couverture, ce qui qui a permis de
conserver cette technologie, non dépendante de facteurs terrestres (montagnes ou
autres) ;
– un délai qui peut être important avec un temps de propagation plus grand que le
temps d’émission (autour de 250 ms pour une orbite géostationnaire) ;
– peu d’infrastructures terrestres nécessaires ;
– un coût important du fait du satellite lui-même mais aussi des équipements de
transmission et de gestion du satellite et du réseau ;
– une robustesse des composants et des systèmes ; il est trop dangereux d’envoyer
des technologies non matures sur des satellites car elles doivent avoir une longue
durée de vie en raison des coûts.

1.1.1 LEO, MEO, GEO

Les premiers satellites n’avaient pas une longue durée de vie, ni un temps d’utilisa-
tion très important ; il fallait, en effet, attendre qu’ils passent dans le champ de visée.
Le lancement de satellites géostationnaires a permis de résoudre ce problème. Du fait
de leurs caractéristiques assez différentes, les satellites ont été ainsi classés suivant la
hauteur de leurs orbites :
1. Les satellites GEO (Geostationary Earth Orbit) ayant donc une trajectoire calée
sur celle de la terre dans un plan voisin de celui de l’équateur. Ils évoluent à une
altitude de 35 786 km liée à leur vitesse qui doit suivre celle de la terre.
2. Les satellites MEO (Medium Earth orbit) évoluent sur une orbite médiane autour
de 10000 km.
6 CHAPITRE 1. RÉSEAUX SATELLITE GEO

3. Les satellites LEO (Low Earth orbit) représentent des satellites en orbite basse de
plusieurs centaines de kilomètres autour de 1000 km.
Les satellites GEO sont les plus communs grâce à leur position relative fixe dans
l’espace et ce malgré leur coût important, un délai important et une diffusion importante
non adaptée à certaines applications. L’utilisation de plusieurs faisceaux (on parle de
multi-faisceaux) réduisant la taille des zones de couverture et d’intelligence à bord sont
des pistes permettant de compenser certains problèmes des satellites GEOs.

1.1.2 Transparent/régénératif
Au delà de la classification en fonction de l’altitude, on peut aussi s’intéresser à leur
fonctionnement interne. Les satellites les plus simples sont qualifiés de transparents,
c’est-à-dire que leur charge utile ne fait aucun travail sur le signal, excepté sa réception,
son amplification et sa réémission. Le médium satellite est donc vu seulement comme
un câble virtuel tiré entre deux zones au sol. Il n’y a pas de commutation, de routage
ou de choix de faisceaux à bord. Un satellite avec intelligence embarquée est qualifié de
régénératif car il doit décoder le signal reçu pour pouvoir effectuer un traitement et le
réémettre vers la terre. On donne aussi le nom d’OBP (On-Board Processing) à la par-
tie de traitement intelligent embarqué. Un satellite peut aussi avoir un fonctionnement
hybride, ne régénérant qu’une partie du trafic comme la signalisation par exemple.
Ces différents satellites engendrent classiquement des topologies de réseaux diffé-
rentes. En effet, avec un satellite transparent, une topologie en étoile (“star”) est assez
directe car les communications peuvent toujours repasser par le même centre de contrôle
du réseau. Cela engendre un double bond pour faire communiquer deux clients par le
satellite et un délai induit important mais un mode maillé reste possible. En revanche,
un satellite régénératif permet de mettre en place plus facilement une topologie maillée
(“mesh”) grâce à l’OBP pouvant orienter les communications directement en un seul
bond et réduisant d’autant le délai entre deux clients.

1.1.3 Réseaux DVB

Comme indiqué en introduction, nous nous concentrons maintenant sur le fonction-
nement des réseaux satellite les plus communs reposant sur les standards DVB. L’appli-
cation la plus importante est donc un service de télévision utilisant un lien satellite GEO
transparent unidirectionnel en diffusion depuis un émetteur vers de nombreux terminaux
(mode star). On appelle ce lien “la voie aller”. Les programmes de télévison sont par
exemple diffusés par la flotte Eutelsat (Hot-Bird, Atlantic Bird 3, W1,2,3, etc.) ou celle
de la Société Européenne de Satellites (SES), Astra 1 et 2. Ce système global s’appelle
donc DVB-S et repose sur la norme vidéo MPEG2. Il est aussi possible de transporter
des données sur ce système. Son fonctionnement est décrit dans la partie suivante.
1.2. VOIE ALLER DVB-S ET DVB-S2 7

F IG . 1.1 – Système DVB-S

Avec le développement du satellite comme accès Internet notamment avec les offres
UDLR (UniDirectional Link Routing), une “voie retour” satellite a été définie pour per-
mettre aux zones blanches des réseaux terrestres d’accéder à Internet. Ce système a pour
nom DVB-RCS et son fonctionnement est également détaillé dans la suite.
Les évolutions et perspectives de ces réseaux DVB sont enfin décrits en conclusion.

1.2 Voie aller DVB-S et DVB-S2

1.2.1 Vue générale
Comme le montre la figure 1.1, un système de télévision classique DVB-S est donc
composé de trois éléments : un émetteur nommé passerelle ou “gateway” diffuse des
flux vidéos via un satellite transparent vers des terminaux récepteurs-décodeurs des pro-
grammes.
Le système repose sur le standard MPEG2 pour coder les flux vidéos, les flux audio
et d’autres informations (télétexte) et enfin pour les multiplexer dans un flux MPEG2-
TS (MPEG2 - Transport Stream) composé de trames de 188 octets. Des informations de
contrôle et de synchronisation sont également insérées (voir figure 1.2.2). La gateway
code, module et envoie ces trames en TDMA (Time Division Multiple Access) vers le
satellite qui répète le signal vers les terminaux. Ces terminaux accèdent à la signalisation
de contrôle pour trouver la “carte” des programmes et décodent seulement les trames
relatives à un programme visé.
Dans un premier temps, nous détaillons le système MPEG2 pour ensuite détailler
sa signalisation PSI (Program Specific Information) ainsi que la signalisation SI (Ser-
vice Information) enrichie par le groupe DVB. Nous décrivons ensuite brièvement le
8 CHAPITRE 1. RÉSEAUX SATELLITE GEO

standard DVB-S lui-même qui concerne uniquement la couche physique de transmis-

sion et son amélioration le DVB-S2. Nous détaillons ensuite l’encapsulation de données
Internet dans de tels systèmes dédiés.

1.2.2 MPEG2

F IG . 1.2 – Codage et multiplexage de programmes MPEG2

MPEG2 est l’ensemble de normes de deuxième génération du Moving Picture Ex-

perts Group de l’ISO définissant la compression d’images animées et de sons et leur
transport dans une structure ou “trame” commune. La figure 1.2.2 décrit cette chaîne de
codage et de multiplexage.
D’abord, les sources analogiques vidéos et audios des programmes de télévision sont
encodées à partir d’une horloge commune permettant de conserver la synchronisation
du programme. Cet encodage spécifique pour la vidéo ou l’audio est décrit dans des
normes MPEG2 spécifiques [12, 13]. De nouveaux codages plus efficaces comme H264
[14] du standard MPEG4 ou des formats propriétaires peuvent également être utilisés.
Ces différents encodages engendrent des flux élémentaires ES (Elementary Stream) qui
sont ensuite découpés en PES (Packet Elementary Stream).
Le format des PES est assez complexe et a une structure qui dépend de la nature du
flux transporté. Il comporte en particulier les champs suivants :
1.2. VOIE ALLER DVB-S ET DVB-S2 9

packet_start_code_prefix : Ce champ est une suite binaire invariable identifiant le dé-

but du PES.
stream_id : Ce champ permet de décrire la nature du flux et donne potentiellement un
numéro de flux dans un programme.
PES_packet_length : Il représente la longueur du paquet sans l’en-tête.
La présence des champs optionnelles dépend de la nature du flux et des nombreux
flags de l’en-tête. On retrouve par exemple des options d’embrouillage, d’estampillage
temporel, de priorité, de synchronisation, de droit d’auteur, de débit du flux, de vitesse
de mouvement, . . .
Ces flux de données doivent donc être maintenant multiplexés en vue d’être en-
voyés. La norme MPEG2 - Systèmes [5] explique la création d’un train de données
encapsulant un flux de diffusion. Elle définit deux moyens totalement différents : le flux
de programme ou “Program Stream” et le flux de transport ou “Transport Stream”. Le
Program Stream est un mécanisme d’encapsulation permettant de stocker les flux sur
support (par exemple bande magnétique, DVD, . . .) et qui n’est pas adapté à la trans-
mission. Le Transport Stream est un mécanisme visant la transmission sur des média
potentiellement bruités. On peut considérer cette couche MPEG2-TS comme la struc-
ture de référence d’un système DVB-S.
Un flux MPEG2-TS est constitué de “paquets” de 188 octets avec un en-tête de 4
octets. Chaque paquet est identifié dans l’en-tête par un PID (Packet IDentifier) qui in-
dique le type de contenu en fonction de la signalisation PSI/SI. A chaque programme
contenant plusieurs flux PES identifiés par leur stream_id est associé un PID. Suivant
leurs tailles, les PES sont découpés en paquets adéquats de 184 octets en utilisant du
bourrage pour compléter le dernier paquet grâce à un champ adaptation_field variable
dans l’en-tête. Ce champ d’adaptation servira par la même occasion à transporter la ré-
férence d’horloge pour la synchronisation temporelle PCR (Program Clock Reference).
Format de la trame MPEG2-TS (fig. 1.3) :
sync_byte (8 bits) : il contient une valeur unique de synchronisation 0x47. Cette valeur
ne devrait pas être utilisée dans d’autres champs pour aider à la synchronisation.
transport_error_indicator (1 bit) : il indique au moins une erreur dans le paquet.
payload_unit_start_indicator (1 bit) : il indique si un PES débute dans cette trame.
transport_priority (1 bit) : il indique le niveau de priorité de la trame.
PID (13 bits) : il représente l’élément clef de cette en-tête. Il caractérise le type de
paquet et donc la façon de traiter les données encapsulées en rapport avec la si-
gnalisation PSI/SI.
transport_scrambling_control (2 bits) : il indique si les données de la trame sont em-
brouillées ou non.
10 CHAPITRE 1. RÉSEAUX SATELLITE GEO

F IG . 1.3 – Format de la trame MPEG2-TS (src : [1])

adaptation_field_control (2 bits) : il indique la présence d’un champ additionnel dans

l’en-tête et la présence de données à la suite.
continuity_counter (4 bits) : il représente un compteur incrémental de données pour
chaque PID et permet notamment de savoir si des données sont dupliquées.
adaptation_field : si adaptation_field_control vaut ‘10’ ou ‘11’, on trouve un “adapta-
tion_field” de taille variable
pointer_field : ce champ est présent pour le transport des tables PSI/SI afin d’indiquer
l’emplacement de départ de la table.

1.2.3 Signalisation PSI/SI

Afin d’assurer le fonctionnement d’un tel système, des informations de contrôle sont
nécessaires pour notamment attribuer aux PIDs le type de programme. Ce système de
contrôle s’occupe également du controle d’accès, de la gestion du réseau et d’autres
fonctions. Il utilise pour cela un ensemble de tables. La norme MPEG2 décrit unique-
ment les tables PSI : PAT, CAT, PMT, NIT. Elles ont été précisées et complétées par le
groupe DVB par d’autres tables SI basées sur la même structure [15, 16].
Tables PSI/SI obligatoires :
Table NIT (Network Information Table) : Dans un système DVB, cette table est di-
rectement indiquée par un PID de ‘0x0010’. Elle donne des informations sur l’or-
ganisation du réseau physique. C’est la première table que l’on trouve dans un
1.2. VOIE ALLER DVB-S ET DVB-S2 11

système DVB. Elle permet de trouver la bonne fréquence du flux d’un terminal
par exemple.
Table PAT (Program association Table) : Identifiée par un PID de ’0x0000’, elle liste
les programmes présents ainsi que les PIDs des tables de description de pro-
gramme (PMT) associés. Elle a donc un rôle d’index pour trouver d’autres tables
décrivant le flux.
Table CAT (Conditionnal Access Table) : Identifiée par un PID de ’0x0001’, elle
donne des informations sur les controles d’accès mis en place dans le multiplexe
pour limiter l’accès aux programmes aux abonnés.
Tables PMT (Program Map Table) : On les trouve à partir de la table PAT. Une table
PMT identifie et indique la localisation des flux associés à un service/programme.
Elle définit donc la compréhension des données suivant leurs PIDs.
Table SDT (Service Description Table) : Elle liste les noms et paramètres associés à
chaque service d’un multiplexe
Table EIT (Event Information Table) : Elle transmet des événements en cours ou à
venir dans le multiplexe. Elle peut permettre de bâtir un guide électronique des
programmes ou EPG (Electronic Program Guide).
Table TDT (Time and Data Table) : Elle permet une remise à l’heure de l’horloge in-
terne du terminal récepteur .

Tables PSI/SI optionnelles :

Table TSDT (Transport Stream Description Table) : Elle décrit le type de contenu
du flux MPEG2-TS.
Table BAT (Bouquet Association Table) : Elle groupe les différents ser-
vices/programmes en bouquet pour présentation à l’utilisateur.
Table RST (Running Status Table) : Cette table permet la mise à jour rapide d’un ou
plusieurs événements.
Table TOT (Time Offset Table) : Elle indique le décalage horaire aux terminaux.
Table ST (Stuffing Tables) : Elle permet d’invalider des tables devenues inutiles.
Chacune de ces tables a un but particulier et contient des descripteurs définis dans
la norme. Ces descripteurs peuvent être communs à différentes tables ; par exemple, un
descripteur décrivant le nom d’un bouquet pourra être utiliser dans la BAT et la SDT.
Les descripteurs sont des structures permettant de faire des liens entre les tables.

1.2.4 DVB-S et DVB-S2

Un flux MPEG2-TS doit être ensuite pris en charge par une couche physique dé-
pendante du médium utilisé. Dans le cas de la voie aller du système satellite transparent
12 CHAPITRE 1. RÉSEAUX SATELLITE GEO

classique, le système physique est le DVB-S [17] qui, par abus de langage, désigne gé-
néralement tout le système. Le multiplexe MPEG2-TS est traité par toute une chaîne de
transmission comportant brouillage, codage Reed-Salomon, entrelacement, code convo-
lutif, poinçonnage, modulation QPSK (Quadrature Phase-Shift Keying). On arrive à un
débit utile de 38Mb/s pour un transpondeur de 35 MHz.
Le standard de nouvelle génération DVB-S2 est compatible avec l’ancien système
DVB-S mais fait évoluer différents principes [18, 19]. Tout d’abord, DVB-S2 profite
d’un meilleur codage de type LDPC (Low-Density Parity-Check) combiné à plusieurs
types de modulations (QPSK, 8PSK, 16APSK, 32APSK). De plus, grâce au développe-
ment des voies retours, un fonctionnement adaptatif en mode ACM (Adaptive Coding
& Modulation) est possible faisant évoluer ces paramètres de codage et de modulation
suivant l’évolution du média satellite. Enfin, une nouvelle structure physique a été défi-
nie permettant de se passer de la structure MPEG2-TS grâce au mécanisme des Generic
Streams.

F IG . 1.4 – Fonctionnement du système DVB-S2 (src : [18])

Comme le montre la figure 1.4, des PLFRAME constituent la trame physique de

base du système DVB-S2. Elles encapsulent et codent des FECFRAME (Forward Error
Correction Frame) suivant une modulation-codage (MODCOD) donnée dans l’en-tête
de la PLFRAME. La FECFRAME peut avoir deux tailles fixes (64800 ou 16200 bits)
suivant le paramétrage du système. Le MODCOD et la taille de la FECFRAME donnent
la taille des données utiles d’une BBFRAME encapsulée et codée dans la FECFRAME.
Contrairement à DVB-S, la couche physique peut ainsi être composée de conteneurs de
1.2. VOIE ALLER DVB-S ET DVB-S2 13

données de taille variable pour s’adapter aux conditions de réception. Si le MODCOD

est fixe, on retrouve un système équivalent au DVB-S. Enfin, l’encapsulation de flux de
différents types est rendue possible par l’en-tête de la BBFRAME (mécanisme “Generic
Stream”).

1.2.5 Encapsulation de données

Le groupe DVB a défini plusieurs méthodes pour transporter des données dans le
multipexe MPEG2-TS reposant sur l’encapsulation de données privées dans le stan-
dard MPEG2. La plus utilisée s’appelle MPE (Multi-Protocol Encapsulation) qui défi-
nit un format de couche liaison de données pour l’encapsulation de trafic de type IP par
exemple [20, 21]. L’en-tête contient notamment l’adresse MAC (Media Access Control)
de destination ainsi qu’un champ indiquant si la paquet contenu est un paquet IP ou
LLC, l’encapsulation de paquets IP étant la plus utilisée. Des informations supplémen-
taires doivent être ajoutées dans la signalisation SI pour permettre de trouver les don-
nées MPE encapsulées. Un mécanisme complexe et évolutif reposant sur une table INT
(IP/MAC Notification Table) permet de faire la correspondance entre les flux IP et les
flux MPEG2-TS (PID). Un mécanisme de résolution d’adresse peut ainsi être implanté.
Le groupe IPDVB de l’IETF, considérant cette encapsulation MPE peu efficace et
complexe, a développé une autre méthode d’encapsulation appelée ULE (Unidirectional
Lightweight Encapsulation), permettant d’augmenter les performances [22, 23]. Cette
méthode casse aussi la compatibilité avec certains mécanismes MPEG2. Les champs
de l’en-tête sont limités à un champ de taille des données, un champ type de données,
une adresse optionnelle et un code de correction. Les trames ULE sont découpées en
morceaux et encapsulées directement dans MPEG2-TS.
Dans le cas d’un système DVB-S2, il est donc possible de se passer de MPEG2-
TS par le mécanisme des Generic Streams. Une méthode d’encapsulation appelée GSE
(Generic Stream Encapsulation) a été proposée par le groupe DVB et le groupe IPDVB
[24]. Cette méthode repose sur de nombreux concepts d’ULE et permet de gérer la
fragmentation et le réassemblage. La figure 1.5 montre les différents champs de l’en-
tête GSE décrit ci-après (les champs grisés sont obligatoires) :
S (Start) : Ce champ indique la présence du début du paquet encapsulé dans cette
trame.
E (End) : Ce champ indique de la même la présence de la fin du paquet encapsulé dans
cette trame.
LT (Label Type) : Cet élément donne la présence, le type et la longueur du champ
label.
Longueur GSE : Ce champ indique la longueur de la trame GSE à la suite.
Identifiant de fragmentation : Présent lorsque les champs Start et End ne sont pas
positionnés, il donne le numéro de fragment du paquet encapsulé.
14 CHAPITRE 1. RÉSEAUX SATELLITE GEO

Longueur totale : Présent lorsque le champ Start est positionné (premier fragment), il
indique la longueur totale du paquet encapsulé.
Type de protocole : Il indique le type de données encapsulées.
Label : Ce champ contient une adresse de 3 ou 6 octets suivant le champ Label Type.
Extensions : Ce champ permet d’ajouter certains mécanismes optionnels comme l’en-
voi de trames GSE de test.

F IG . 1.5 – En-tête GSE (src : [24])

1.3 Voie retour DVB-RCS

Le système DVB-S classique est donc complètement adapté à de la diffusion. Néan-
moins, un besoin d’interactivité est apparu avec la demande de connectivité à Internet
nécessitant un lien bidirectionnel. Tout d’abord, la première solution a consisté à mettre
en place une voie retour asymétrique par voie terrestre jusqu’à la gateway (solution
UDLR standardisée par l’IETF [25]). Cette solution enlève néanmoins l’un des prin-
cipaux avantages du satellite : l’indépendance d’emplacement par rapport au réseau.
Pour permettre une vraie interactivité entièrement fondée sur le satellite, une voie re-
tour DVB a été définie avec le standard DVB-RCS (Digital Video Broadcast - Return
Channel Satellite) [26, 27].
Tout d’abord, une vue générale est décrite pour ensuite détailler la signalisation et
finir par les étapes de fonctionnement d’un système RCS.

1.3.1 Vue générale

La norme DVB-RCS repose sur un système aller DVB-S qui lui confère de nom-
breuses informations de contrôle pour régler le système. Un des buts affichés est de
permettre de créer des récepteurs appelés RCST (Return Channel Satellite Terminal)
à un prix envisageable pour les abonnés. La figure 1.6 montre l’ajout d’une voie re-
tour à un système DVB-S. Cette voie retour est fondée sur un autre transpondeur dédié
qui peut se trouver aussi bien sur le même satellite que sur un autre satellite que celui
utilisé pour la voie aller. Dans un système DVB-RCS, un centre de contrôle réseau ou
NCC (Network Control Centre) souvent associé à la gateway est en charge de toute la
signalisation opérateur.
1.3. VOIE RETOUR DVB-RCS 15

F IG . 1.6 – Système DVB-RCS

Les terminaux ou RCST ont donc maintenant une partie émission spécifique.
L’émission des informations n’est plus constante mais repose sur le principe de “bursts”
utilisant un découpage temporel et fréquentiel standardisé appelé MF-TDMA (Multiple
Frequency Time Division Multiple Access). En effet, il est difficile de savoir le nombre
d’éléments qui émettront sur le support et il est également nécessaire de les synchroni-
ser. Le fonctionnement de cette répartition est décrit plus loin et repose sur une signali-
sation aller DVB-S dans de nouvelles tables SI et sur une signalisation retour dans des
bursts spécifiques. Un RCST est donc maintenant un véritable élément de réseau actif
avec de nombreux identifiants associés.
Après synchronisation du système à partir de la signalisation, le transfert d’infor-
mation se fait dans des bursts de données appelés TRF (Traffic). Deux méthodes d’en-
capsulation de données sont possibles : MPEG2-TS ou ATM (Asynchronous Transfer
Mode). Dans le cas MPEG2-TS, du trafic IP est encapsulé grâce aux mécanismes MPE
ou ULE. Dans le cas d’ATM, la couche d’adaptation AAL5 (ATM Adaptation Layer 5)
classique est utilisée.

1.3.2 Signalisation DVB-RCS

Le fonctionnement de la voie retour DVB-RCS repose sur deux types de signalisa-
tion : celle de la voie aller dans des tables SI et celle de la voie retour.
Sur la voie aller, de nombreuses tables supplémentaires décrites dans le tableau 1.2
permettent le fonctionnement de DVB-RCS. A partir du fonctionnement existant d’indi-
rection par les tables NIT, PAT, PMT et de la nouvelle table RMT (RCS Map Table), un
terminal trouve les tables DVB-RCS nécessaires au fonctionnement de sa voie retour.
Un mécanisme d’horloge fondée sur la synchronisation classique PCR liée à MPEG2
permet d’assurer la cadence d’émission temporelle. Cette synchronisation peut être cor-
16 CHAPITRE 1. RÉSEAUX SATELLITE GEO

rigée par la table SPT liée à la position du satellite et par la table CMT. Comme le montre
la figure 1.7, le tramage MF-TDMA pour la voie retour est décrit par les tables SCT et
FCT organisant ce tramage en supertrames, trames et intervalles de temps (timeslots).
Un timeslot contient un burst de données. Le contenu de cet intervalle de temps est défini
par la table TCT et par la table TBTP qui permet d’allouer les ressources aux différents
terminaux. Enfin, une table TIM permet d’envoyer des messages de configuration aux
terminaux.

F IG . 1.7 – Tramage MF-TDMA DVB-RCS

Sur la voie retour, les intervalles de temps définis par ce tramage MF-TDMA cor-
respondent à des burst de différents types. Outre les bursts TRF transportant les données
utiles, on trouve également des bursts de signalisation CSC (Common Signalling Chan-
nel), ACQ (ACQuisition) et SYNC (SYNChronisation). Le burst CSC peut contenir
une demande de connexion liée à l’adresse MAC du terminal. L’accès au CSC se fait
en Aloha en concurrence entre les terminaux. Les bursts ACQ et SYNC contiennent
tous les deux des informations de synchronisation. Néanmoins, un burst SYNC peut
“piggybacker” un champ SAC (Satellite Access Control) de requête de ressources. Une
autre méthode moins performante appelée DULM (Data Unit Labelling Method) permet
aussi de transporter des requêtes de ressources dans des canaux virtuels dans les don-
nées. La méthode d’allocation de ressources peut être fixe, gérée par la fonction CAC
(Connection Admission Control) à la connexion des terminaux. Les ressources peuvent
aussi être allouées dynamiquement à la demande grâce au champ SAC par une méthode
DAMA (Demand Assignment Multiple Access).
1.3. VOIE RETOUR DVB-RCS 17

Forward Link Signalling (FLS)

Nom Fonction
SCT (Superframe Composition Table) indique l’organisation en supertrames et trames de
tout le réseau retour
FCT (Frame Composition Table) indique le partitionnement des trames en slots
temporels
TCT (Time-slot Composition Table) indique les paramètres de chaque slot temporel
SPT (Satellite Position Table) contient des informations d’ephemeride de
correction des bursts
CMT (Correction Message Table) indique aux RCST des corrections physiques à
effectuer
TBTP (Terminal Burst Time Table) assigne les slots temporels aux RCST
TIM (Terminal Information Message) contient des messages de configuration
NCR (Network Clock Reference) donne une horloge de référence pour la
synchronisation retour à partir du mécanisme PCR
RMT (RCS Map Table) donne l’emplacement des différentes tables de la
voie retour (type NIT)

TAB . 1.2 – Signalisation SI de la voie retour

1.3.3 Étapes de fonctionnement de DVB-RCS

Comme le montre la figure 1.8, un terminal RCST va se synchroniser en plusieurs
étapes pour faire fonctionner sa voie retour :
1. Procédure initiale de synchronisation :

(a) Synchronisation physique : La signalisation aller nécessaire au fonctionne-

ment de la voie retour est considérée comme un service DVB au même titre
qu’un programme de télévision ou un flux Internet. Elle est donc référencée
dans les tables NIT, PAT et PMT. A partir d’une fréquence de démarrage par
défaut, un terminal va donc d’abord se synchroniser sur un flux MPEG2-TS.
(b) Localisation du lien aller : Une étape de localisation de la signalisation de
la voie retour s’initie alors. Il recherche dans la table NIT contenant l’organi-
sation fréquentielle de la voie aller, l’emplacement de la table RMT donnant
l’organisation des différentes voies retour possibles. Cela se fait dans la table
NIT à partir d’un descripteur (linkage_descriptor) contenant un type adéquat
(linkage_type=RCS Map Service). Ce descripteur dans la NIT donne aussi
un identifiant de flux (TS_id). Un deuxième balayage de la table NIT per-
18 CHAPITRE 1. RÉSEAUX SATELLITE GEO

F IG . 1.8 – Fonctionnement de DVB-RCS

met de trouver la fréquence du flux contenant cette table RMT (à partir d’un
satellite_delivery_system_descriptor). Le terminal peut maintenant se régler
sur cette fréquence pour trouver la table RMT.
Sur ce nouveau flux, le terminal recherche l’identifiant PID de la table RMT.
Pour le trouver, il consulte la table PAT contenant la liste des services sur ce
flux et une table PMT contenant ce PID de la table RMT recherché. Le ter-
minal scrute alors toutes les différentes sections de cette table à la recherche
de son identifiant de population (population_id), paramètre fixé par l’opé-
rateur à chaque terminal. A cet identifiant, un réseau d’interactivité est as-
1.3. VOIE RETOUR DVB-RCS 19

socié (interactive_network_id) ainsi que l’identifiant de flux (TS_id) où se

trouvent les différentes tables DVB-RCS de ce réseau. Dans un deuxième
balayage de cette table RMT, le terminal trouve la nouvelle fréquence ainsi
que des identifiants de satellite (satellite_id), de gateway (gateway_id), de
NCC (NCC_id), de supertrame (superframe_id) et de service (service_id),
paramètres servant au fonctionnement de la voie retour.
Le terminal RCST peut enfin se synchroniser sur le bon flux MPEG2-TS
sur lequel il trouve l’horloge NCR (PCR_PID) et les différentes tables SCT,
FCT, TCT, SPT, TIM, CMT, TBTP à partir du mécanisme classique de
recherche de service par les tables PAT et PMT (utilisation du service_id).
(c) synchronisation NCR : Après ces indirections successives jusqu’à la fré-
quence où se trouve la signalisation retour associée au terminal, ce dernier
peut synchroniser son horloge retour grâce à la NCR en récupérant les in-
formations sur le PID adéquat.
(d) Tables DVB-RCS : Le terminal charge aussi les différentes tables pour l’ac-
cès multiple (SCT, TCT, FCT) ainsi que la position du satellite par la table
SPT et les anomalies potentielles du lien (message de diffusion dans la table
TIM).
(e) Calcul de la position du satellite : Les informations de la table SPT per-
mettent de corriger l’emplacement du satellite et de mieux se synchroniser.
(f) Burst Time Plan (BTP) : A partir des informations des tables SCT et FCT,
le terminal connait l’organisation temporelle et fréquentielle de la voie retour
et peut enfin émettre. La table TCT donne les types des bursts du BTP.

2. Procédure de connexion : Le terminal peut donc maintenant repérer les bursts

CSC de connexion accessibles en Aloha discrétisé et envoyer un burst de
connexion vers le centre de contrôle NCC. Ce dernier s’occupe de vérifier si des
bursts SYNC et ACQ sont libres. Il s’occupe aussi de formalités administratives
et applique une éventuelle fonction CAC. Il renvoie ensuite au terminal un mes-
sage TIM de confirmation de connexion contenant un identifiant de connexion
(logon_id), un identifiant de groupe (group_id) et des identifiants (VPI (Virtual
Path Identifier) et VCI (Virtual Channel Identifier)) pour la transmission ATM
(ou un PID dans le cas MPEG2). Il renvoie aussi des descripteurs de synchroni-
sation stipulant au terminal de se synchroniser grossièrement puis finement. Un
descripteur de réseau peut aussi renvoyer l’adresse IP du terminal.
3. Procédure de synchronisation macro : Après l’envoi par le terminal d’un burst
ACQ, des corrections grossières de synchronisation peuvent être renvoyées au ter-
minal par le centre NCC à partir de la table CMT utilisant l’identifiant du terminal
logon_id.
20 CHAPITRE 1. RÉSEAUX SATELLITE GEO

4. Procédure de synchronisation fine : De même, après l’envoi d’un burst SYNC,

des corrections de synchronisation plus fine peuvent être renvoyées au terminal
par le centre NCC. Le terminal peut alors maintenant émettre dans les bursts de
trafic TRF qui lui sont alloués par la table TBTP.
5. Procédure de synchronisation de maintenance : A intervalles réguliers, le ter-
minal renvoie un message de synchronisation dans un burst SYNC à l’aide du
mécanisme de synchronisation fine précédent.
6. Procédure d’allocation de ressources : Dans le cas d’une allocation de res-
sources de type DAMA dynamique, un terminal peut utiliser un champ SAC dans
le burst SYNC de la procédure de synchronisation de maintenance (“piggyba-
cking”). Le centre de contrôle NCC alloue les ressources demandées via la table
TBTP.
Enfin, dans les bursts TRF de données alloués au terminal par la TBTP, les données
ATM ou MPEG2-TS peuvent être convoyées.

1.4 Évolution des satellites GEO

Grâce aux caractéristiques uniques du satellite en termes de déploiement, il apparaît
comme une solution potentielle pour des services de plus en plus nombreux. Il est aussi
souvent utilisé en interconnexion ou en liaison de secours. Néanmoins, les systèmes
DVB standards sont peu adaptés à des scénarios maillés.
Pour résoudre ces problèmes, les satellites de nouvelle génération se focalisent sur
de l’intelligence à bord permettant une plus grande flexibilité et évitant de repasser
par la gateway dans un double bond. Des projets comme Amerhis ou plus récemment
ULISS (ULtra fast Internet Satellite Switching) montrent l’attrait de l’intelligence à bord
pour augmenter les capacités des systèmes satellites. Le projet DIPCAST a par exemple
étudié un projet de commutation ATM à bord [28]. De même, le projet Domino 2 de
l’ESA (European Space Agency) étudiait un système en bande Ka avec ATM comme
technologie de commutation embarquée [29].
Une autre avancée technique des satellites de nouvelle génération est le multi-
faisceau permettant à un satellite de gérer plusieurs spots de taille plus petite et donc
de partager plus efficacement les ressources entre les différents utilisateurs.
Des spécifications de l’ETSI décrivent le fonctionnement d’un système régénératif
permettant de faire un réseau maillé entre les terminaux (type Amerhis) [30, 31] ; le
satellite joue alors le rôle de commutateur MPEG2. Les terminaux émettent en MPEG2
sur DVB-RCS vers le satellite qui commute ces bursts sur un lien DVB-S en descente
(voir figure 1.9). La requête de connexion vers un autre terminal se fait par le protocole
C2P (Connection Control Protocol) vers le centre NCC [32]. Le gestionnaire NCC peut
ainsi allouer différents bursts vers la bonne destination via la table TBTP. Ces timeslots
1.5. CONCLUSION 21

seront orientés par le traitement à bord du satellite sur le bon faisceau contenant le
terminal destinataire. Ces spécifications permettent de concilier le fonctionnement du
système DVB en étoile classique (star) avec un système maillé (mesh). Un autre système
de satellite régénératif est décrit dans le dernier chapitre consacré au projet ULISS.

F IG . 1.9 – Architecture maillée type Amerhis

1.5 Conclusion
Dans cette partie, nous venons de décrire le fonctionnement des systèmes DVB exis-
tants en voie aller et voie retour, ainsi que l’évolution dans un cas régénératif. Dans le
cadre de la convergence des réseaux existants, il apparaît que les systèmes DVB fondés
sur la norme MPEG2 posent problème pour une intégration dans des systèmes réseaux
terrestres.
En premier lieu, les architectures DVB découlent d’une architecture orientée vidéo
en diffusion et montrent leurs lacunes pour l’encapsulation de données hétérogènes et
pour des topologies de transmission plus symétriques. En effet, la notion de PID, par
exemple, est loin de pouvoir régler un adressage complexe. De plus, la signalisation
fondée sur les tables SI conserve une compatibilité avec MPEG2 qui rend son fonction-
nement complexe.
Ensuite, l’ajout de DVB-RCS a ouvert de nombreuses possibilités pour le dévelop-
pement de services bidirectionnels. Néanmoins, le fonctionnement de la signalisation
ajoute de la complexité aux tables existantes et l’architecture globale se retrouve avec
une voie aller et une voie retour hétérogènes. Cette hétérogénéité est toutefois le lot de
la plupart des réseaux d’accès. La structure protocolaire de DVB-RCS pose donc des
problèmes pour l’interconnexion simple à des réseaux terrestres.
Les nouvelles architectures sur un satellite régénératif ne remettent pas en cause l’ar-
chitecture globale. En effet, elles ont juste été modifiées pour prendre en charge un mode
maillé à partir du protocole C2P. Dans ce cas, la compatibilité à MPEG2 complexifie le
22 CHAPITRE 1. RÉSEAUX SATELLITE GEO

fonctionnement de l’intelligence embarquée dans le satellite, notamment avec la néces-

sité de régénération des tables SI à bord (exemple Amerhis). Un commutateur MPEG2
est un élément peu utilisé dans les réseaux terrestres, quand un satellite nécessite des
technologies matures vu sa longévité.
Enfin, plus globalement, le monde des réseaux satellite a besoin d’une architec-
ture convergente bien définie remettant en cause MPEG2-TS comme base de commu-
nication. Reprenant les idées du monde des télécommunications, les systèmes satellites
existants ont souvent une approche plus en chaîne de transmission qu’en couches pro-
tocolaires. Une nouvelle architecture devrait bien séparer les différentes fonctions dans
des niveaux protocolaires indépendants, gage de pérennité et d’évolutivité. La partie sui-
vante fait donc le tour des architectures de convergence potentielles pour une évolution
des réseaux par satellite.
Chapitre 2

Les architectures de convergence

2.1 Panorama historique . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.1 Monde des opérateurs de télécommunications . . . . . . . . . . 24
2.1.2 Monde informatique . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.3 Monde opérateur vidéo . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Convergence des communications . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Définition de la convergence . . . . . . . . . . . . . . . . . . . 27
2.2.2 Caractéristiques générales de convergence . . . . . . . . . . . . 29
2.2.2.1 Structure protocolaire . . . . . . . . . . . . . . . . . 29
2.2.2.2 Simplicité . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.2.3 Topologie distribuée . . . . . . . . . . . . . . . . . . 30
2.2.2.4 Intéropérabilité . . . . . . . . . . . . . . . . . . . . 30
2.2.2.5 Interconnexion . . . . . . . . . . . . . . . . . . . . . 31
2.2.2.6 Qualité de Service . . . . . . . . . . . . . . . . . . . 31
2.2.2.7 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2.8 Gestion . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Solutions de convergence satellite . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Convergence des architectures réseaux . . . . . . . . . . . . . . 32
2.3.1.1 Solution DVB . . . . . . . . . . . . . . . . . . . . . 32
2.3.1.2 Solution ATM . . . . . . . . . . . . . . . . . . . . . 35
2.3.1.3 Solution Ethernet . . . . . . . . . . . . . . . . . . . 37
2.3.1.4 Solution tout IP . . . . . . . . . . . . . . . . . . . . 39
2.3.1.5 Solution MPLS - MultiProtocol Label Switching . . . 41
2.3.2 Convergence fixe mobile . . . . . . . . . . . . . . . . . . . . . 44
2.3.3 Convergence par les services . . . . . . . . . . . . . . . . . . . 45
2.3.3.1 Approche DVB . . . . . . . . . . . . . . . . . . . . 46
2.3.3.2 Approche IP . . . . . . . . . . . . . . . . . . . . . . 46
2.3.3.3 Approche IMS . . . . . . . . . . . . . . . . . . . . . 47
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

23
24 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

Cette thèse porte sur la convergence dans les réseaux satellite. Il paraît donc essentiel
de s’interroger sur cette notion de convergence et de dresser un panorama des différentes
solutions existantes.
Généralement, un domaine de connaissance met un certain temps avant à converger
sur des principes de base (exemple du courant alternatif). Au départ, l’objectif est très
proche mais chaque pays, entreprise ou individu l’appréhende d’une façon différente.
Il est nécessaire ensuite de converger vers un compromis entre les différentes parties
lorsque vient le temps d’intéropérer et de réduire les coûts de production. Néanmoins,
des raisons techniques, économiques et stratégiques font que ces convergences sont dé-
licates.
Le monde des télécommunications et des réseaux est dans une phase de convergence
importante et différents acteurs s’affrontent pour imposer leur solution. Le but de cette
partie est d’exposer des solutions de convergence possibles en vue d’une application à
des réseaux satellites.
La première partie fait tout d’abord un panorama de l’historique des réseaux de
communication. Ensuite, nous dégageons plusieurs idées phares sur la convergence pour
la construction d’architectures futures. Enfin, nous proposons différentes approches de
convergence possibles pour le satellite dans l’état actuel des réseaux.

2.1 Panorama historique

Le besoin d’échange d’information entre les personnes a conduit au développement
de divers moyens de communications avec des caractéristiques et des contraintes spéci-
fiques à chaque service. Globalement, on peut dégager l’existence de trois mondes issus
de ces services [33]. En premier lieu historiquement, nous décrivons le monde des opé-
rateurs de télécommunications pour les services de téléphonie puis de transmission de
données. Ensuite, le monde des réseaux informatiques a été porté par le développement
exponentiel des capacités de traitement de l’information et par l’accroissement parallèle
des capacités de transmission de l’information. Enfin, le monde des opérateurs vidéo
pour le service de télévision s’est développé et est décrit plus précisément dans la partie
précédente pour le médium satellite.

2.1.1 Monde des opérateurs de télécommunications

Les premiers services offerts par les opérateurs de télécommunications furent le
télégraphe puis la téléphonie. Les premiers réseaux analogiques étaient purement dédiés
et établissaient manuellement des circuits électriques entre les abonnés. Ces réseaux ont
ensuite évolué en automatisant la création de ces circuits grâce à des commutateurs ou
autocommutateurs téléphoniques.
2.1. PANORAMA HISTORIQUE 25

Le besoin de transfert d’information autre que la voix est ensuite apparu et les opéra-
teurs ont développés des réseaux de transport de données avec un système comme X.25
[34] se basant sur le modèle en couches OSI (Open Systems Interconnection) de l’ISO
[35] (service Minitel en France par exemple).
Dans un premier souci de convergence, l’intégration des services sur le même sup-
port est venu par les réseaux RNIS (Réseaux Numériques à Intégration de Services) ou
ISDN (Integrated Services Digital Network) au niveau du réseau utilisateur [36]. Sur
le même support, des canaux sont réservés pour chaque service qui garde son fonc-
tionnement dédié. Au niveau du réseau de l’opérateur, la révolution ATM ou B-ISDN
(Broadband ISDN) fait adopter le transfert de paquets à la place de la commutation
de circuits en intégrant véritablement les services sur les mêmes couches protocolaires
[37, 38]. La synchronisation et le temps réel nécessaire à la téléphonie sont assurés grâce
à l’utilisation de paquets de très petite taille, permettant de répondre à la problématique
d’intégration des services de voix et de données aux caractéristiques très différentes.
Malgré les qualités d’ATM, le succès du “réseau de réseaux” Internet fondés sur
la pile protocolaire TCP/IP oblige les opérateurs à le prendre en compte. IP est donc
encapsulé dans ATM sans en utiliser toutes les possibilités. Les opérateurs perdent le
contrôle de bout en bout des services et sont relégués à un rôle d’autoroutes de l’in-
formation sans contrôle sur les services Internet. La bataille entre les services existants
des opérateurs et les services sur Internet est une clef de l’évolution des réseaux. Les
opérateurs de télécommunications proposent des services “triple play” intégrés sur le
même support. Avec le même abonnement, un accès Internet, téléphonique et télévisuel
est possible.
En parallèle, les opérateurs de télécommunications ont développé des réseaux de
téléphonie mobile. L’architecture GSM (Global System for Mobile communications) est
une réussite mondiale, dédiée à la téléphonie et orientée opérateur. Avec l’avènement
des évolutions 3G et des réseaux Wifi, les réseaux mobiles évoluent aussi vers une
intégration des services autour d’IP.
Pour conclure, les réseaux d’opérateurs ont comme service de base la téléphonie
mais ont dû évoluer vers des services multiples. Le service de base, la téléphonie, a
de fortes contraintes, il faut un délai court et peu variable ainsi qu’une bonne syn-
chronisation dans l’échange. En revanche, un taux de perte faible est acceptable ; il
serait, de toute façon, trop long de corriger l’erreur de transmission par retransmission.
Les réseaux des opérateurs de télécommunications doivent donc être synchrones pour
répondre à ces caractéristiques. Ils ont un fonctionnement assez lourd et suivent des
normes issues de l’ITU-T, de l’ETSI ou de l’ISO. Enfin, l’intelligence et la complexité
se trouvent originellement dans le réseau avec des terminaux simples aux extrémités.
Avec l’évolution convergente autour d’IP, les terminaux deviennent de plus en plus
complexes se rapprochant du modèle des réseaux informatiques. Les réseaux d’opéra-
teurs ont déjà beaucoup évolué dans le domaine de la convergence des services et des
26 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

supports mais il reste une marge importante d’évolution, notamment dans l’intégration
des concepts issus du monde informatique.

2.1.2 Monde informatique

Les réseaux informatiques viennent de l’essor de l’électronique et du développement

des ordinateurs. Le service de base est l’échange de données numériques de façon fiable
et rapide. Les facteurs de fiabilité et de débit des réseaux sont donc prédominants par
rapport au délai ou à la gigue. Les réseaux sont plus simples et orientés vers le trans-
fert de paquets numériques. Les terminaux sont plus complexes que dans les réseaux
opérateurs, capitalisant une grande part de l’intelligence de la communication.
Pour les réseaux informatiques, la notion de couche protocolaire est présente depuis
les origines. Les couches de communications de bas niveau des réseaux locaux LAN
(Local Area Network) sont issues de l’électronique et normalisées par l’IEEE (Institute
of Electrical and Electronics Engineers). Les standards les plus utilisés sont Ethernet et
Wifi [39, 40]. Ils sont respectivement les gagnants sans conteste pour les communica-
tions locales filaires et hertziennes sur les LAN. Ethernet a évolué énormément depuis
ses débuts avec les commutateurs ethernet, le gigabit ethernet et même maintenant l’in-
terconnexion à ce niveau.
Pour interconnecter tous ces réseaux informatiques hétérogènes, une architecture fût
définie à partir d’expériences pour l’armée américaine autour du projet Arpanet. L’archi-
tecture TCP/IP de l’IETF s’impose rapidement dans les années 90 pour interconnecter
tous les équipements informatiques par sa simplicité et sa adaptabilité [41]. Le protocole
IP permet des services sans connexion au-dessus de tout type de protocoles sous-jacent.
De plus, le fonctionnement de la standardisation à l’IETF est plus ouvert et moins lourd
que celui à l’ISO ou à l’ITU. Le réseau des réseaux Internet se déploie sur cette base. De
nombreuses communautés d’utilisateurs fleurissent et développent les services, des so-
ciétés comme Google sont le résultat de cette démocratisation des réseaux. IP s’impose
maintenant comme l’interface utilisateur unifiée du futur.
Originellement asynchrones, les réseaux informatiques sont maintenant confrontés
à leur évolution vers d’autres services comme la voix ou la télévision. Le principe du
surdimensionnement est de mise pour faire fonctionner les applications multimédias
mais des principes de qualité de service comme ceux d’ATM permettraient d’optimiser
l’utilisation de la bande passante et gagner en synchronisation. Pour gagner en sécurité
et en qualité, la gestion et l’ingénierie de trafic des communications doivent évoluer
et ne plus se cantonner sur les extrémités. La techniques de relayage de labels MPLS
est une proposition convergente de l’IETF qui a fait son chemin chez les opérateurs de
télécommunications.
2.2. CONVERGENCE DES COMMUNICATIONS 27

2.1.3 Monde opérateur vidéo

Les opérateurs vidéo ont mis en place des réseaux câblés, hertziens et satellites pour
la diffusion d’images de télévision sur ces différents supports. Pour rentabiliser leurs
équipements, les opérateurs utilisent une architecture de diffusion. De très nombreux
utilisateurs peuvent donc accéder au même service sans impact sur le réseau.
Très longtemps analogiques, les années 1990 et 2000 voient arriver la numérisation
des données vidéo. Elle est construite autour de la norme MPEG2. Les standards les
plus utilisés dans le monde sont issus du groupe DVB sur lequel nous nous concentrons
(voir chapitre 1). D’autres standards existent comme ceux issues de l’ATSC pour les
USA ou ISDB pour le Japon [7, 8].
L’évolution de ces standards passe par l’intégration de nouveaux services avec une
éventuelle voie retour. L’accès Internet devient un service potentiel remettant en cause
l’architecture originelle orientée diffusion unidirectionnelle de canaux de télévision. La
possibilité de la voie retour s’est imposée notamment avec le standard UDLR qui permet
d’utiliser une ligne téléphonique pour le trafic issu de l’utilisateur. Des voies retour par
câble comme DOCSIS ou DVB-C et satellite comme DVB-RCS font aussi leur appari-
tion. L’évolution des couches de communications basses de ces standards issues de la
norme MPEG2 intervient également pour augmenter les débits en s’adaptant à la qualité
instantanée du support. Globalement, l’aspect intégré entre le service de télévision et les
couches de communications complique les évolutions. Dans ce contexte de convergence
des services, le futur des architectures de communications des opérateurs vidéo se pose.

2.2 Convergence des communications

Compte tenu de ce contexte général des réseaux de télécommunications, se pose
donc la question du futur des architectures de communications en général et le rôle du
satellite en particulier. Les différents acteurs des réseaux semblent s’entendre sur un
besoin de convergence des outils et des techniques de communication. En revanche, la
forme et les critères de cette convergence restent largement ouverts. Cette partie s’at-
tache à décrire ce que signifie cette notion de convergence et détaille ensuite les éléments
importants pour une telle convergence à venir.

2.2.1 Définition de la convergence

Pour un but identique de transfert d’informations d’un point à un autre, les tech-
niques de communications varient suivant des critères différents de services, de pays,
d’objectifs, d’expériences ou encore de supports. La convergence est donc le moyen de
gommer certaines de ces différences pour arriver à un fonctionnement compatible. Le
but est de pouvoir accéder à un réseau de communication partout, à n’importe quel mo-
28 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

ment et avec n’importe quel terminal. Dans un contexte de mondialisation des échanges
et d’intégration des services, le besoin d’échanger de façon plus simple sans avoir à
changer d’appareil apparaît. La figure 2.1 donne un aperçu de la convergence des ré-
seaux sous le prisme de la solution IP. Il apparaît que le protocole IP permet de mutuali-
ser l’infrastructure réseau et également de regrouper différents services dans un terminal
unifié.

F IG . 2.1 – La convergence des réseaux par IP (source [42])

Dans ce monde des communications, les premières étapes importantes de la conver-

gence sont la numérisation des informations et la communication par paquets. Nous
les considérons comme acquises malgré de nombreux réseaux analogiques ou orien-
tés circuits encore en vigueur. En effet, les convergences protocolaires reposent sur ces
notions.
Du panorama historique précédent, nous pouvons maintenant dégager plusieurs
idées phares pour le choix d’une architecture convergente parmi les différentes solu-
tions existantes.
2.2. CONVERGENCE DES COMMUNICATIONS 29

2.2.2 Caractéristiques générales de convergence

2.2.2.1 Structure protocolaire

Tout d’abord, une idée très importante est la notion de structure protocolaire des
systèmes réseaux. Le standard d’interconnexion des systèmes ouverts OSI de l’ISO a
modélisé cette notion d’abstraction via des couches protocolaires aux fonctions bien
définies. Les différents plans de communications des modèles de réseaux opérateurs
participent à cette répartition des fonctions pour répondre aux problèmes inter-couches.
L’architecture TCP/IP permet de façon plus simple de séparer les services de la commu-
nication bas niveau par des couches d’abstraction homogènes. Tout cela permet d’avoir
une organisation du réseau et concourt à la pérennité du système.
Certaines idées issues de ce travail de structuration protocolaire des différents mo-
dèles d’architectures de communication ressortent en résumé :
– Séparation des couches : La notion consistant à considérer différents niveaux de
communications s’occupant de différentes fonctions est essentielle dans l’évo-
lution des réseaux. En effet, cela permet de prendre en compte l’hétérogénéité
des fonctionnements dans un modèle plus global. Par exemple, le fonctionne-
ment d’une couche réseau et transport de type TCP/IP permet de développer des
applications indépendamment des évolutions des communications physiques et
particulières aux différents médias transporteurs.
– Séparation des plans : La notion de plan de communication permet de donner une
autre dimension aux couches et permet de même une séparation des fonctionnali-
tés. Les plans utilisés sont généralement le plan des données, le plan de contrôle
ou de signalisation et le plan de gestion. Une approche en plans peut permettre de
construire des fonctions difficilement implantables avec l’approche en couches.
Par exemple, des mécanismes inter-couches (cross layer) permettant d’optimiser
certains mécanismes transversaux peuvent s’appuyer sur le formalisme d’un plan
de gestion pour éviter des violations de couches protocolaires, non désirables pour
une pérennité des systèmes.
Pour résumer, le grand intérêt de la structuration protocolaire est donc l’indépen-
dance et l’organisation des fonctionnements. Chaque élément peut être amélioré séparé-
ment et la solution globale est plus compréhensible. L’apprentissage de ces technologies
en est d’autant facilitée.

2.2.2.2 Simplicité

Au vu de l’évolution des différents réseaux, une prime à la simplicité apparaît. Un

exemple est le modèle TCP/IP qui a une approche simple et pragmatique ; en effet, ce
modèle s’est développé rapidement grâce à sa simplicité d’accès. La mise au point des
standards RFC (Request For Comments) relève d’une procédure plus simple, accessible
30 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

et souple que les standards ETSI ou les normes ISO. De nombreuses communautés ont
pu ainsi les utiliser facilement.
On peut souligner plusieurs caractéristiques qui conduisent à cette simplicité.
D’abord, une large diffusion permet une large et rapide démocratisation. Ensuite, la
structuration protocolaire concourt aussi grandement à cette simplicité, en organisant les
fonctionnements. En fait, cette structure permet d’organiser la complexité générale du
système. Enfin, cette approche de simplicité peut être le résultat d’un travail complexe
de distanciation et de comparaison avec d’autres domaines. La notion de convergence
cherche ainsi intrinsèquement à simplifier les fonctionnements en les rapprochant mais
le parcours pour y arriver peut être complexe ; simplicité ne veut pas dire simpliste.
Enfin, un protocole simple est plus facile à maintenir et à comprendre.

2.2.2.3 Topologie distribuée

Un autre concept important dans le futur des réseaux est la notion d’architecture dis-
tribuée. En effet, les topologies distribuées ont prouvé leur adéquation pour le passage
à l’échelle au niveau des performances, de la sécurité, de la tolérance aux pannes ou
de l’anonymat. On le voit dans l’exemple des systèmes pair à pair de téléchargement
considérés comme très performants de tous ces points de vue. Les topologies maillées
ou “mesh” sont amenées à se développer notamment dans le contexte satellite et il fau-
dra répondre à ce besoin.
D’autre part, une topologie distribuée telle que celle d’Internet permet d’appréhen-
der l’hétérogénéité des fonctionnements plus facilement. Cela oblige à considérer l’hé-
térogénéité comme paradigme plutôt que l’homogénéité. IP peut par exemple s’adapter
à toutes les situations et garantit une topologie distribuée au niveau réseau. Cette notion
distribuée oblige à considérer l’intéropérabilité.

2.2.2.4 Intéropérabilité

L’intéropérabilité est la possibilité de faire fonctionner des systèmes hétérogènes

sur une base commune. En réseaux, l’intéropérabilité peut reposer sur des standards
qui sont un moyen de convergence fort. Deux produits ou systèmes sont intéropérables
quand un ensemble suffisant des interfaces de fonctionnement sont définies et dans ces
standards. L’intéropérabilité est très importante dans de nombreux domaines où les pro-
duits sont construits par différents acteurs et doivent interagir. Vu la complexité et le
nombre d’acteurs des systèmes de communication, elle est essentielle.
Un exemple est le RTC (Réseau Téléphonique Commuté) ou PSTN (Public Swit-
ched Telephone Network). Toutes les interfaces sont des normes gérées par l’ITU-T. Il
est ainsi possible de téléphoner sans s’occuper de la marque de téléphone de son corres-
pondant ni des matériels utilisés par les différents opérateurs.
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 31

2.2.2.5 Interconnexion

Le principe d’interconnexion représente la capacité à pouvoir relier des réseaux dif-

férents et souvent hétérogènes. Cette caractéristique est très importante dans le cadre
d’une convergence. En effet, il apparaît qu’il existe de nombreuses façons de commu-
niquer en réseaux dépendantes de nombreux critères (pays, médium, services, . . .) et
qu’une convergence ne se fera pas uniquement par une homogénéisation des standards.
Il faut conserver la possibilité de réseaux hétérogènes tout en permettant une intercon-
nexion simple entre eux.

2.2.2.6 Qualité de Service

La QoS (Quality of Service) est une notion très importante dans les réseaux actuels.
En effet, l’approche convergente par le protocole IP a un fonctionnement “best effort”
et surdimensionne les ressources pour répondre à ce besoin en qualité de service des
applications. Elle représente la prise en compte par le réseau ou les applications de
critères comme la disponibilité, le débit, les délais de transmission, les taux de perte de
paquets pour véhiculer un trafic donné.
Une prise en compte de cette QoS à un niveau global plutôt que de façon dédiée à
un service est une gageure importante d’une convergence des réseaux.

2.2.2.7 Sécurité

La notion de sécurité dans les réseaux est de même primordiale et recouvre un grand
nombre de fonctions : confidentialité, intégrité, disponibilité. Pour répondre à ces pro-
blématiques, des moyens d’authentification, de contrôle, de cryptage ou de surveillance
peuvent être mis en place. De plus, la séparation des couches de communications permet
de répondre aux différents problèmes de sécurité plus spécifiquement suivant le contexte
(proche en proche ou bout en bout, service ou réseau). Globalement, la sécurité doit être
prise en compte dans la conception même d’un système de convergence réseau.

2.2.2.8 Gestion

La gestion du réseau est aussi un élément très important pour l’évolution d’un ré-
seau. Sans plan de gestion efficace et sécurisé permettant d’administrer le réseau, un
déploiement de services est impossible. Un plan de gestion générique, performant et
indépendant est donc un critère de qualité pour une convergence.
32 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

2.3 Solutions de convergence satellite

En vue de l’évolution des réseaux satellite, cette partie décrit différentes possibili-
tées de solutions de convergence des réseaux de télécommunications. Ces solutions sont
confrontées au monde satellite en vue d’étudier leur applicabilité à ces systèmes parti-
culiers. Les solutions générales de convergence des réseaux de télécommunications sont
séparées ici en trois types :
– La convergence des architectures de réseaux et de leur signalisation permet
de gommer l’hétérogénéité des supports et de fournir des outils génériques aux
couches hautes de communication.
– La convergence fixe-mobile permet de déplacer un terminal utilisateur vers n’im-
porte quel réseau.
– La convergence par les services de bout en bout du fournisseur à l’utilisateur
représente un fonctionnement intégrée dans les services eux-mêmes. Elle est es-
sentielle pour le développement de services multi-opérateurs indépendants des
différents supports.
Ces trois types de convergence peuvent interagir. La convergence des architectures
réseaux et la convergence fixe mobile peuvent être imbriquées et vont directement in-
fluencer les possibilités de la convergence des services. En effet, l’adressage d’une ar-
chitecture réseau pourra être conçu pour permettre une certaine mobilité et une architec-
ture réseau proposant une certaine QoS pourra enrichir le fonctionnement d’un service.
Nous séparons ces trois approches dans un souci de clarté et de compréhension de la
convergence car elles répondent à des problématiques différentes. Nous nous concen-
trons surtout sur la convergence des architectures de réseaux car elle nous paraît plus
importante et urgente, les autres convergences s’appuyant sur ses caractéristiques. Nous
donnons néanmoins quelques idées prédominantes sur la convergence fixe-mobile et par
les services.

2.3.1 Convergence des architectures réseaux

Cette partie se penche sur de possibles architectures de convergence des réseaux en
considérant leur applicabilité au monde satellite.

2.3.1.1 Solution DVB

La première possibilité est la solution de convergence par MPEG2-TS liée à l’ap-
proche actuelle du groupe DVB. Comme nous l’avons vu dans le chapitre 1, ce choix
se fonde sur une technologie conçue pour le service de télévision. Au fur et à mesure
des évolutions des besoins de cette architecture, l’encapsulation de données a été rendue
possible au travers des mécanismes MPE puis ULE [20, 22]. L’architecture conçue au
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 33

départ pour un lien unidirectionnel a ensuite évolué pour prendre en compte une voie
retour.
Techniquement, le système classique unidirectionnel repose sur un émetteur central
(“gateway”) diffusant un flux continu de trames de 188 octets. Chaque trame contient
un PID indiquant le type de flux. Un programme de télévision donné a un PID unique.
Après avoir récupéré des tables de correspondance entre les programmes et les PID sur
un flot identifié lui-même par un PID de signalisation particulier, un terminal client peut
facilement lire le programme de télévision numérique demandé. Le système est donc
simple pour cette application vidéo pour laquelle il a été conçu.
Pour répondre à un service de type Web au travers de cette architecture, les paquets
IP à acheminer aux clients sont encapsulés dans une structure MPE ou ULE de niveau
liaison de données avec des champs pour les adresses MAC et le type de protocole
utilisé. Une correspondance entre les adresses MAC et les PID est nécessaire par un
mécanisme statique ou des tables INT.
Dans le cadre d’une voie retour, les terminaux se partagent une ressource commune
par un tramage MF-TDMA avec un mécanisme de requête dynamique de ressources
(DAMA) régi par des tables de signalisation MPEG2-TS sur la voie aller, rendant ce
fonctionnement dépendant des couches accès de la voie aller.
Cette architecture a encore évolué afin de prendre en compte des scénarios de ré-
seaux maillés (“mesh”) par satellite permettant ainsi d’éviter un double bond pour des
communications de terminal à terminal. Dans ce cadre, une architecture MPEG2 a été
développée dans un système appelé Amerhis envoyé dans un satellite Amazonas d’His-
pasat [43, 44]. L’architecture de ce système a été unifiée et modifiée : la voie montante
se fait en DVB-RCS et la voie descendante en DVB-S. Le satellite s’occupe du transfert
entre les deux ainsi que de la génération des tables nécessaires au fonctionnement. Un
autre système de commutation à bord fondé sur un commutateur temporel à bord est
détaillé plus avant dans le chapitre 5.
Confrontons maintenant cette architecture aux différentes caractéristiques évoquées
précédemment :
Structure protocolaire : Dans un contexte DVB, la séparation des couches n’est pas
très claire. Le fonctionnement est intrinséquement dépendant de MPEG2-TS. Il
est difficile par exemple de faire évoluer MPEG2-TS indépendemment du service
de télévision, rendant les couches basses très liées au service. La couche service
n’est donc pas véritablement séparée de l’accès dans cette architecture.
Simplicité : D’un fonctionnement simple au départ, les standards DVB se sont com-
plexifiés avec l’ajout de nombreuses évolutions rendant le système difficile à im-
planter. Dans les faits, peu de systèmes prennent en charge tous les mécanismes
des normes DVB. On peut donc considérer que la convergence des services sur
une architecture DVB est complexe.
Topologie distribuée : Fondée au départ sur une topologie naturelle en étoile, les be-
34 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

soins de communications pair à pair entre terminaux ont fait évoluer l’architecture
vers une topologie plus équilibrée. Néanmoins, le fonctionnement en voie aller et
voie retour est sous-jacent, ce qui induit souvent une topologie centralisée.
Intéropérabilité : Les systèmes DVB de télévision dédiés sont souvent intéropérables
entre eux, excepté pour certains systèmes de sécurité fondé sur le système DVB-
CA (DVB - Conditional Access) qui peuvent être propriétaires. L’intégration de
services divers et le fonctionnement en voie retour engendrent une multiplicité de
fonctions, limitant l’intéropérabilité, notamment pour l’encapsulation de trafic IP
de façon non homogène.
Interconnexion : La capacité d’interconnexion des réseaux DVB est facile dans des
réseaux hétérogènes basé sur MPEG2 (support hertzien DVB-T, câble DVB-C,
satellite DVB-S). Néanmoins, l’interconnexion avec des réseaux terrestres vérita-
blement différents de type ATM ou IP reste complexe et peu adaptée. Les réseaux
DVB n’ont pas été conçus comme un véritable outil d’interconnexion.
Sécurité : La sécurité des systèmes DVB est cantonnée dans le système DVB-CA per-
mettant de crypter les communications. Le problème du système tient dans la
protection de l’algorithme secret plutôt que dans un système de clef. Le seuil
de protection était adapté pour un système de télévision payant, limitant l’intru-
sion mais il ne suffit pas pour des services plus confidentiels. Les mécanismes
d’authentification sont prévus pour l’accès à la voie retour. Néanmoins, ces méca-
nismes ne sont pas construits dans une véritable structure protocolaire. Toutes les
fonctionnalités sont regroupées dans les tables MPEG2. Il reste possible d’utiliser
un cryptage des données de plus haut niveau.
QoS : La qualité de service existe bien pour les flux vidéos ainsi que pour la voie retour
mais n’est pas considérée de façon générique pour n’importe quel service. En
effet, un ordonnancement des différents services pourra être appliqué au niveau
de la gateway pour répondre à cette problématique mais restera local au système
satellite. Une qualité de service de bout en bout n’est pas gérée. De plus, cette
qualité de service s’apparente à un mode circuit rendant difficile l’intégration de
trafic sporadique sur ce type de réseau.
Gestion : Le plan de gestion existe aussi mais se retrouve, de la même façon, mélangé
dans les tables de signalisation avec des fonctions de contrôle. Il est ainsi dépen-
dant du réseau satellite, sans liaison possible avec d’autres réseaux hétérogènes.
En conclusion, on peut dire que l’architecture DVB répond parfaitement à son ob-
jectif premier de service dédié de télévision mais répond plus difficilement à d’autres
besoins. La convergence par ce système n’est pas optimale ; en effet, les différentes
fonctionnalités ne sont pas bien séparées et l’évolutivité du système s’en retrouve limi-
tée. Son plus gros atout est le poids de l’existant poussant à rester compatible et à ne pas
enlever la brique de base MPEG2-TS de ce système.
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 35

2.3.1.2 Solution ATM

Une autre solution de convergence issue des réseaux terrestres est le standard ATM,
choix intégré dans le standard DVB-RCS comme couche de liaison par défaut.
À l’origine, ATM était censé être la technologie de convergence permettant le B-
ISDN qui remplacerait le RTC existant. Les standards ATM proposent donc des défini-
tions pour les couches de niveaux 1, 2 et 3 du modèle OSI classique en 7 couches [37].
Ils décrivent ainsi une architecture complète de communication de bout en bout réalisant
la convergence entre un système synchrone de type SDH (Synchronous Digital Hierar-
chy) et un sytème paquet asynchrone grâce à l’envoi de petites cellules de données de
53 octets [38]. Ce découpage des différents services en petits paquets permet d’éviter
qu’un paquet important gêne l’envoi de données synchrones de voix par exemple.
L’architecture d’un système ATM est orientée connexion. Pour transmettre des in-
formations entre deux nœuds via un réseau ATM, il faut réserver un numéro de VPI
(Virtual Path Identifier) et de VCI (Virtual Channel Identifier) identifiant le canal de
communication entre les deux nœuds dans le réseau. La pile protocolaire de la figure 2.2
récapitule les différentes couches : les services sont encapsulés dans une couche d’adap-
tation AAL (ATM Adaptation Layer) donnant une interface commune aux couches su-
périeures et gérant la segmentation et le réassemblage des informations en cellules. Le
transport de bout en bout se fait par ces cellules ATM commutées dans chaque nœud.
Une couche physique adapte ces cellules ATM au support.
L’architecture ATM n’a pas eu le succès escompté en raison de la convergence de
l’interface utilisateur vers la solution du monde IP et sert généralement de couche de
liaison de données. Les réseaux ATM des opérateurs sont ainsi utilisés comme réseaux
transporteurs du trafic IP. L’intégration entre le monde IP et ATM est faite par l’ap-
proche MPLS (voir plus loin).

F IG . 2.2 – Récapitulatif de l’architecture ATM (src : [45])

36 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

Dans le monde satellite, ATM a aussi été vu comme une bonne solution pour l’ar-
chitecture réseau, utilisé notamment pour le fonctionnement par défaut de la voie retour
[46]. De même, les performances ATM par satellite sont analysées dans le projet CATA-
LYST [47]. Enfin, de nombreuses études analysent les systèmes ATM embarqués dans
le satellite pour des réseaux maillés [48, 49, 50].
Comme précédement, étudions les différentes caractéristiques.
Structure protocolaire : L’approche ATM issue de l’approche OSI et des réseaux des
opérateurs est très organisée et la séparation des fonctionnalités est claire. L’inté-
gration de différents services est prévue dès sa conception.
Simplicité : Le fonctionnement est donc bien organisé simplifiant l’implantation. Le
nombre de normes et de possibilités en font néanmoins une architecture complexe
à maîtriser, développée uniquement dans les réseaux opérateurs ayant les moyens
de former le personnel à ce standard. Les plans de contrôle et de gestion sont
notamment complexes. Avec l’approche IP dominante, de nombreux mécanismes
sont redondants et alourdissent l’ensemble.
Topologie distribuée : La topologie des réseaux ATM est maillée permettant une dis-
tribution des fonctionnalités dans le réseau. Néanmoins, par son fonctionnement
en mode connecté, la topologie n’est pas complètement distribuée, les communi-
cations passant toujours sur le circuit virtuel réservé. On se trouve dans un inter-
médiaire entre un réseau IP complètement distribué et un réseau centralisé fixe. En
effet, les circuits peuvent être reroutés sur un autre chemin, reposant néanmoins
sur un mécanisme plus lourd et complexe que dans une approche IP.
Intéropérabilité : Pour ce qui est de l’interfonctionnement de systèmes ATM, l’intéro-
pérabilité est respectée grâce à des standards décrivant parfaitement les fonction-
nements.
Interconnexion : L’interconnexion de réseaux hétérogènes est possible mais com-
plexe. IP s’est révélé être un outil d’intéropérabilité plus simple et l’a supplanté
pour l’interface utilisateur de bout en bout.
Sécurité : La sécurité n’a pas été envisagée complètement dans les réseaux ATM, en
raison de son déploiement dans les cœurs de réseaux moins sensibles. L’approche
connectée peut permettre néanmoins de simplifier sa gestion par la négociation de
paramètres à la connexion. L’organisation des différentes couches de communi-
cation facilite aussi son déploiement.
QoS : La Qualité de service est inhérente à l’architecture ATM avec les différentes
classes AAL de transport. C’est un des premiers réseaux permettant l’intégration
de services aussi différents que la voix synchrone et les données asynchrones.
Gestion : La gestion fait aussi partie intégrante des réseaux ATM orientés opérateurs.
L’approche ATM comme outil de convergence satellite est très intéressante et a
été considérée dès les débuts des réseaux ATM. La voie retour DVB-RCS s’appuie
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 37

d’ailleurs sur ce standard par défaut, signe de l’influence de cette approche au mo-
ment de la standardisation. Cette approche est toujours valide et a permis de résoudre
de nombreux problèmes d’intégration.
Néanmoins, ATM était vraisemblablement trop complexe en particulier en termes de
signalisation et trop orienté opérateur pour s’imposer sur tous les systèmes. Les réseaux
locaux ainsi que les réseaux informatiques ont propagé l’interface IP comme paradigme.
L’adoption d’IP comme interface commune des services a relégué ATM dans les réseaux
opérateurs. Une convergence entre IP et ATM est fournie par l’approche MPLS.

2.3.1.3 Solution Ethernet

Une autre approche existant dans les réseaux actuels est la convergence par Ether-
net, le standard de communication unifié des réseaux locaux filaires. A la suite de nom-
breuses évolutions, le protocole Ethernet est sorti du cadre strict des LANs.
Une approche appelée UETS (Universal Ethernet Telecommunications Service) se
propose ainsi de déployer l’approche Ethernet et son adresse MAC dans les réseaux
opérateurs. L’adresse MAC sert à la commutation de bout en bout grâce à un bit indi-
quant le caractère locale ou universelle de l’adresse (bit U/L). L’approche est simple et
compatible avec IP. Au lieu d’avoir des routeurs gérant mal les capacités de traitement
au cœur des réseaux, le but est d’utiliser des commutateurs Ethernet pour simplifier l’ar-
chitecture. Cette architecture est standardisée par l’IEEE [51] et J. M. Barroso a décrit
cette architecture et ses intérêts dans plusieurs publications [52, 53, 54]. La figure 2.3
montre l’architecture UETS ; on voit que la couche MAC 802.3 sert de référence pour
différents types de trafic : encapsulation IP directe en mode best effort ou encapsulation
LLC (Link Layer Control) en mode connecté.

F IG . 2.3 – Architecture UETS (src : [52])

Dans le cadre du satellite, la littérature est très peu abondante voire inexistante sur
38 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

l’adoption d’Ethernet comme standard de convergence de base. Néanmoins, nous pou-

vons dégager les caractéristiques d’une telle opportunité :
Structure protocolaire : Chaque couche de communication et les fonctions associées
sont bien délimitées. Les services sont abstraits par des couches de communica-
tions d’intégration au support.
Simplicité : L’approche est très simple en reprenant les paradigmes des réseaux locaux
et en les étendant. On se retrouve avec une simplicité d’interconnexion et des
équipements simples à développer, Ethernet étant déjà déployé partout. Cepen-
dant, l’intégration de services IP contraints comme la VoIP (Voice over IP) peut
poser des problèmes pour une utilisation de bout en bout.
Topologie distribuée : Ethernet repose sur un réseau maillé où chaque client a une
capacité de transmission égale. Un système pair à pair est complètement envisa-
geable.
Intéropérabilité : L’intéropérabilité des systèmes Ethernet a été prouvée par la pra-
tique ; néanmoins, l’ajout de fonctionnalités dans UETS peut compliquer cette
intéropérabilité.
Interconnexion : Cette approche part aussi d’un principe d’homogénéisation des ré-
seaux par la technologie d’Ethernet comme pour ATM. A ce niveau, la gestion
de protocoles hétérogènes n’est pas assurée comme avec IP. L’interconnexion se
ferait par l’homogénéisation des fonctionnements.
Sécurité : La sécurité d’Ethernet était cantonnée à des réseaux locaux. L’usurpation
d’adresse MAC avait, par exemple, un impact simplement local. L’élargissement
du périmètre de cette adresse pose d’autres problèmes à prendre en compte. L’or-
ganisation des fonctions en couches peut toujours aider à la gestion de la sécurité.
QoS : La qualité de service est utilisée dans de nombreux commutateurs Ethernet ; elle
repose souvent au départ sur une approche Diffserv et le champ TOS (Type of
Service) d’IP au départ [55]. La qualité de service entre commutateurs Ethernet
peut être échangée via le champ CoS ajouté au niveau d’un tag de la trame [56].
Son utilisation de bout en bout peut rester problématique et doit être étudiée plus
avant (RSVP peut être envisagé).
Gestion : Le plan de gestion de ces réseaux repose la plupart du temps sur le système
classique des réseaux IP : SNMP [57]. Ce point est aussi à développer pour la
gestion de grands réseaux.
L’approche Ethernet est très intéressante du point de vue théorique pour simplifier la
convergence des réseaux usagers ou d’entreprise avec les réseaux opérateurs et ainsi op-
timiser les couches protocolaires. De nombreux réseaux opérateurs commencent à utili-
ser cette approche pour leurs réseaux d’accès voire leurs réseaux métropolitains. Cette
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 39

approche gère néanmoins difficilement l’hétérogénéité des différents réseaux transpor-

teurs. L’utilisation d’UETS de bout en bout au travers de nombreux réseaux semble
difficilement pouvoir supplanter l’approche IP. L’approche reste à approfondir et des
études supplémentaires sont nécessaires.

2.3.1.4 Solution tout IP

Le principe de cette approche tout IP est de simplifier drastiquement les couches
basses en les cantonnant à du transport proche en proche (Ethernet pour les LANs)
et de concentrer les fonctions réseaux dans IP. L’approche pousse à développer des
térarouteurs ou pétarouteurs au cœur des réseaux opérateurs, la recherche étant très
active pour optimiser et construire ce type d’équipement.
L’approche tout IP encapsule les services en paquets IP via les protocoles IETF clas-
siques TCP, UDP (User Datagram Protocol) voire RTP (Real-Time Transport Protocol)
[41, 58, 59, 60]. De plus, la qualité de service peut être gérée grâce au champ TOS
dans une approche Diffserv [55]. L’approche Intserv rajoutant un mode connecté via le
protocole RSVP (Resource ReSerVation Protocol) a prouvé son inefficacité pour le pas-
sage à l’échelle dans de grands réseaux [61, 62]. Les paquets IP sont donc les éléments
de convergence du réseau dans cette approche et sont encapsulés dans des couches 2
hétérogènes adaptées aux différents supports de transmission.
Le choix peut aussi se faire sur la version 4 ou 6 du protocole IP. IPv4 est le plus
déployé et reste le protocole du réseau Internet mondial. IPv6 garde la plupart des ac-
quis d’IPv4 en l’améliorant grâce notamment à des adresses plus longues, au routage
hiérarchique, à la gestion de la mobilité, ou à l’autoconfiguration simplifiée. Il n’apporte
néanmoins pas une révolution totale au paradigme IP. Les intérêts de la version 6 n’ont
pas encore fait basculer l’Internet, par exemple.
Dans le cadre du satellite, cette approche a été considérée dans plusieurs projets et
études. L’intégration d’IP sur la voie aller sur MPEG2-TS se fait normalement grâce au
mécanisme MPE [20] ou ULE [22] plus efficace (voir le chapitre 1). Une étude montre
que dans une approche orientée tout IP, il est plus efficace d’encapsuler directement
dans MPEG2-TS les paquets IP [63], quitte à perdre la compatibilité avec les protocoles
existants. Par ailleurs, le projet SATSIX se place dans ce travail de convergence par le
protocole IPv6 [64]. Ce projet cherche à montrer que les systèmes satellites peuvent
offrir une solution simple et rapide pour déployer des services hétérogènes.
La problématique du tout IP dans un cadre de satellite régénératif a aussi été étudiée.
Dans le cadre d’un programme militaire, Cisco a déjà développé une plate-forme IP em-
barquée pour augmenter la flexibilité du système de communications pour les forces au
sol. Les procédures classiques d’un routeur IP ont été simplifiées pour répondre aux
contraintes satellitaires [65]. Considérant les problèmes de TCP dans le contexte satel-
lite, une étude a même considéré un proxy TCP embarqué [66]. Cette approche semble
néanmoins loin d’être mise à bord d’un satellite.
40 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

Comme pour les autres approches, nous énumérons les différentes caractéristiques
de convergence :
Structure protocolaire : L’approche tout IP abstrait bien les services des couches
d’accès. De plus, les différentes fonctions sont bien séparées fonctionnelle-
ment, même si certaines entorses à l’indépendance entre les protocoles existent
(TCP/IP). L’approche est moins structurée qu’une approche ATM par exemple.
Simplicité : L’approche tout IP est une approche pragmatique (comme Ethernet) et as-
sez simple. Elle se propose de simplifier les couches accès à leur strict minimum
pour concentrer les fonctions réseaux dans la couche IP. De plus, la standardisa-
tion IETF accélère l’accès aux standards dans un fonctionnement plus direct.
Topologie distribuée : Le choix de route étant fait à chaque nœud, une approche tout
IP distribue complètement le trafic de façon très flexible. Les réseaux pairs à pairs
fonctionnent parfaitement sur Internet prouvant le caractère distribué de l’archi-
tecture.
Intéropérabilité : IP est considéré comme le protocole permettant de faire intéropérer
de très nombreux équipements. Il a de plus la qualité de ne pas avoir de prére-
quis sur les réseaux sous-jacents. L’intéropérabilité est donc très bonne avec un
système tout IP.
Interconnexion : IP a prouvé être un bon outil d’interconnexion entre réseaux hétéro-
gènes, notamment dans la création du “réseaux de réseaux” Internet.
Sécurité : La sécurité des protocoles de l’Internet, considérée comme faible au départ,
a su évoluer fortement pour répondre aux différents besoins pratiques. De nom-
breuses approches existent comme les mécanismes IPsec (IP Security) permettant
de crypter les communications au niveau IP [67].
QoS : La qualité de service est implantée dans les mécanismes Diffserv ayant prouvé
leur capacité à prioriser des trafics. Néanmoins, l’ingéniérie de trafic est moins
développée que dans un système ATM par exemple.
Gestion : Le plan de gestion repose aussi sur le système classique des réseaux IP au
travers du protocole SNMP [57]. IP étant un outil d’interconnexion, la gestion
des grands réseaux d’opérateurs est ainsi mise en place à un niveau plus bas (par
exemple ATM) pour chaque système autonome.
L’approche tout IP est un bon choix pour un système convergent car elle a le mérite
de gérer l’hétérogénéité des supports comparativement à l’approche ATM ou Ethernet.
Construit comme une couche “best effort” simple, elle a néanmoins des problèmes pour
gérer une ingéniérie de trafic. La qualité de service est de plus peu déployée au ni-
veau IP ; elle doit s’appuyer sur des mécanismes sous-jacents. IP semble être devenu le
choix incontournable pour l’interface utilisateur mais n’est pas encore l’outil unique de
convergence des architectures des réseaux d’opérateurs.
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 41

2.3.1.5 Solution MPLS - MultiProtocol Label Switching

MPLS a été construit comme un compromis entre l’approche ATM et l’approche IP.
Reprenant la structure de chemins virtuels d’ATM, la signalisation a été modifiée pour
une approche IP. Les adresses IP servent directement pour le routage des chemins.
Plus qu’un protocole, MPLS est plus une technique de virtualisation générique des
systèmes de transport opérateurs. Cette commutation multi protocolaire de labels réuni-
fie les techniques de commutation ATM ou Frame Relay autour d’un label générique.
MPLS se situe entre le niveau 3 et le niveau 2 du modèle OSI et est standardisé par
l’IETF [68].
Nous décrivons le fonctionnement d’un réseau MPLS classique à l’entrée du réseau
(figure 2.4) au cœur (2.5) et à la sortie (2.6) [69].
Entrée du réseau MPLS :
1. Lorsqu’un paquet entre dans un nuage MPLS, il est pris en charge par un routeur
de label d’entrée “ingress” appelé LER (Label Edge Routeur).
2. En fonction de la classe de traffic FEC (Forwarding Equivalence Class), le LER
consulte la table de commutation.
3. Le label associé est ajouté au paquet (fonction PUSH).
4. le paquet est enfin transmis au nœud suivant.

F IG . 2.4 – Entrée du réseau MPLS

Cœur du réseau MPLS :

1. Le paquet arrive alors sur un routeur commutateur de cœur appelé LSR (Label
Switch Router).
2. A partir la table de commutation des labels LIB (Label Information Base), le
routeur trouve le prochain label à appliquer.
3. Le LER effectue ensuite un échange des labels et une mise à jour du TTL (Time
To Live) pour éviter les boucles (fonction SWAP).
4. Le paquet est envoyé vers le nœud suivant.
42 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

F IG . 2.5 – Cœur du réseau MPLS

Sortie du réseau MPLS :

1. Le paquet arrive sur un LER “egress” de sortie.
2. Le label est retiré du paquet (fonction POP). Le paquet a été transporté de façon
transparente sur un réseau générique.
.

F IG . 2.6 – Sortie du réseau MPLS

La mise à jour des labels se fait via une signalisation de type LDP (Label Distribu-
tion Protocol) [70] ou son évolution CR-LDP (ConstRaint based LDP) [71]. Un autre
protocole de signalisation RSVP-TE (RSVP - Traffic Engineering) fondé sur RSVP a
vu le jour pour la réservation des chemins MPLS LSP (Label Switch Path) [72]. L’ap-
proche RSVP-TE est maintenant la solution la plus courante, il a été adopté par l’IETF
en 2003 [73]. Une réservation de labels se fait par une demande de l’egress vers l’in-
gress de LSR en LSR avec des messages de demande de réservation (RESV). L’ingress
confirme en retour la réservation par des messages de confirmation du chemin réservé à
l’aller (PATH).
L’évolution de MPLS a aussi suivi celle des réseaux optiques et l’approche GMPLS
(Generalized MPLS) a été définie en généralisant l’espace de commutation du label.
GMPLS permet la commutation par longueur d’onde, par intervalle temporel ou par
interface physique. Chacun de ces domaines peut être à son tour représenté par un label,
unifiant le plan de contrôle de réservation de ces ressources [74].
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 43

Dans le cadre satellite, les études ne sont pas nombreuses. Une étude des débits de
réseaux MPLS sur satellite GEO montre que les performances sont similaires à un ré-
seau classique [75]. En revanche, MPLS a été utilisé dans un cadre LEO sur des constel-
lations de satellites [76, 77].
Nous décrivons de même les caractéristiques de convergence :
Structure protocolaire : L’approche conjugue les intérêts d’IP et de ATM, permettant
une double abstraction entre les couches hautes par IP et par les couches basses
via la généralisation de commutation par label. La généricité est complètement
assurée dans cette approche. En effet, la possibilité d’utilisation de protocoles de
réservation de labels différents prouve bien l’indépendance des fonctions.
Simplicité : Le principe de généralisation de label permet une simplification de l’accès
à des réseaux hétérogènes. Néanmoins, l’approche MPLS reste assez complexe
dans ses possibilités et sa signalisation. Elle est peu déployée dans les réseaux
d’accès pour cette raison. En revanche, un sous-ensemble de MPLS appelé T-
MPLS (Transport MPLS) a été standardisé en vue de son utilisation dans les ré-
seaux d’accès [78].
Topologie distribuée : La topologie ressemble à celle d’ATM. Si les différents élé-
ments du réseau ne choisissent pas en toute indépendance la route des paquets, la
topologie n’est pas non plus centralisée. Les fonctions peuvent être distribuées.
L’utilisation de réseaux MPLS pour la création de VPN (Virtual Private Network)
par la technique VPLS (Virtual Private LAN Service) montre sa flexibilité d’uti-
lisation.
Intéropérabilité : De même que le standard IP, MPLS a été conçu avec le souci de
faire intéropérer différents équipements et différents réseaux. En revanche, la
complexité des différentes évolutions de MPLS et de sa signalisation fait que les
réseaux MPLS ne sont pas toujours compatibles entre eux.
Interconnexion : L’interconnexion entre des réseaux hétérogènes est prévu dans sa
conception même. Elle semble néanmoins plus complexe que dans une approche
tout IP.
Sécurité : Conçu et implanté dans les réseaux des opérateurs, MPLS répond aux be-
soins de sécurité tout comme pour l’approche ATM. L’approche MPLS permet
notamment d’apporter à l’approche IP la sécurité du mode connecté d’ATM. Le
fait que de nombreux réseaux d’opérateurs ait adopté MPLS garantit sa robus-
tesse.
QoS : MPLS a été de même conçu pour répondre aux problèmes d’ingéniérie de trafic
des couches IP. La qualité de service peut facilement être réservée par les pro-
tocoles de signalisation dans une approche Intserv pour des flux aggrégés. Une
approche de type Diffserv pourra ensuite être utilisée en parallèle dans chaque
LSP.
44 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

Gestion : La gestion peut aussi s’appuyer sur SNMP [57]. Un protocole appelé LMP
(Link Management Protocol) a été ajouté pour s’occuper dans le plan de gestion
des réservations de chemins permanents ou encore vérifier la connectivité des
liens physiques [79].
L’approche MPLS est un bon compromis entre une approche ATM répondant aux
besoins du réseau satellite et l’approche tout IP, standard de fait de l’interface utilisa-
teur. Elle souffre encore de problèmes de complexité ou de signalisation mais s’impose
largement dans les réseaux opérateurs. Pour preuve, l’ATM Forum gérant les évolutions
des standards ATM a été renommé MPLS forum. MPLS s’inscrit donc comme le digne
héritier de cet effort important de convergence des services.

2.3.2 Convergence fixe mobile

La convergence fixe-mobile représente la possibilité pour un équipement de se
connecter de façon homogène à un réseau fixe aussi bien qu’à un réseau mobile, malgré
les caractéristiques différentes des deux réseaux. On appelle cette notion ubiquité qui re-
couvre deux notions (figure 2.7) : on peut séparer le nomadisme qui désigne la capacité
pour l’usager de se connecter depuis différents lieux sans maintenir de communication
active pendant le déplacement et la mobilité qui permet de rester connecté pendant le
déplacement. Le nomadisme est plus simple à prendre en charge que la mobilité qui
impose aux réseaux des contraintes temporelles plus importantes.

F IG . 2.7 – Nomadisme et mobilité (src : [42])

Le nomadisme ne pose pas de problèmes majeurs d’implantation ; on peut le consi-

dérer à deux niveaux :
– Au niveau des services, la convergence s’est déjà faite autour des services Web.
L’URI (Uniform Resource Identifier) est devenue l’adresse indépendante du ré-
seau. On peut se connecter de n’importe quel endroit à Internet pour accéder à ses
mails ; le service est bien nomade.
2.3. SOLUTIONS DE CONVERGENCE SATELLITE 45

– Au niveau réseau notamment en entreprise, le nomadisme passe par des réseaux

privés virtuels (VPN) assurant un accès sécurisé depuis n’importe quel réseau à
son entreprise. Tout se passe comme si on se trouvait physiquement dans l’entre-
prise avec deux niveaux d’adressage, celui du tunnel et celui du réseau privé créé
au dessus.
La problématique de convergence de la mobilité se concentre dans le transfert au-
tomatique (handover) entre deux réseaux différents qui doit être assez rapide pour ne
pas perdre la connexion. Pour l’application téléphonique par exemple, la norme GSM
fonctionne parfaitement et garantit un temps minimal pour passer d’une cellule à une
autre du réseau. Au contraire, dans le cadre d’un réseau Wifi non dédié à un service, le
passage d’une cellule à une autre n’est pas conçu pour converger rapidement, bien qu’il
puisse être assez rapide dans certains cas. On peut ainsi considérer la mobilité à deux
niveaux :
– L’approche IEEE 802.21 définit un système de handover de niveau 2 indépen-
damment des médias. Il consiste à rajouter des primitives génériques dans chaque
réseau permettant ainsi leur intéropérabilité. L’approche semble néanmoins com-
plexe à mettre en place [80].
– Une autre approche à un plus haut niveau est Mobile IP. Elle permet de conserver
une adresse IP fixe quel que soit le réseau sous-jacent visité. Un nœud mobile
détient son adresse fixe indépendante du réseau traversé et une adresse qui évolue
suivant les réseaux traversés [81, 82]. Cette solution n’étant pas assez rapide pour
assurer un suivi de connexion, des solutions pour accélérer les handovers ont été
développées comme l’approche FMIP (Fast handover for Mobile IP) [83, 84].
Dans le monde satellite, un service de télévision mobile DVB-SH (DVB - Satellite
services to Handhelds) entre des réseaux hétérogènes terrestre et satellite a été norma-
lisé par l’ETSI à la suite du travail sur le standard de télévision mobile terrestre DVB-H
[85] [86]. Le groupe DVB permet donc une mobilité pour un service dédié. Il ne gère
pas néanmoins la convergence fixe mobile entre des standards hétérogènes. L’applica-
tion d’un handover de type 802.21 est envisageable mais nécessite un effort conséquent
d’adaptation.
Cette problématique de la convergence des systèmes fixes et mobiles est une théma-
tique importante qu’il est nécessaire d’étudier dans un cadre globale de convergence.
Néanmoins, notre travail ne s’est pas apesanti sur cet axe, considérant la convergence
des architectures de réseaux un préalable plus important dans le cadre satellite.

2.3.3 Convergence par les services

La convergence des services représente le rapprochement des implantations des dif-
férents services autour d’un socle commun. En pratique, cela peut se caractériser par une
signalisation commune aux différents services. Le but est d’avoir un fonctionnement in-
tégré de différents services intégrés. Par exemple, une convergence des services peut
46 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

permettre d’avoir une tarification unique et un fonctionnement intégré pour un service

de vidéoconférence enrichie de messagerie instantanée ou d’un tableau blanc interac-
tif. Elle dépend évidemment des capacités des couches réseaux sous-jacentes. Plusieurs
approches existent dans le monde des réseaux, décrivons les brièvement.

2.3.3.1 Approche DVB

L’approche DVB représente à son niveau une convergence des services dans un
fonctionnement commun. Les tables de signalisation SI unifient l’accès aux différents
services pour les terminaux utilisateurs. Dans un cadre de réseau uniquement DVB, il
est possible de diffuser un programme vidéo sur différents types de réseaux : satellite,
hertzien, câble. En revanche, cette approche se concentre sur le service de télévision et
l’intégration d’autres services reste lourd.

2.3.3.2 Approche IP
Les protocoles du monde IP permettent une abstraction des services et donc une
certaine convergence du fonctionnement des applications. Deux approches peuvent être
différenciées :
Approche Internet Au niveau des acteurs de l’Internet, on trouve des services de voix
comme Skype, de données avec le web HTTP (HyperText Transport Protocol)
ou le mail SMTP (Simple Mail Transport Protocol), ou de télévision sur un site
comme YouTube. Dans ce cas, ces acteurs de services utilisent IP en mode “best
effort” uniquement n’ayant pas de contrôle sur la QoS des données transportées.
Ils se fondent sur le surdimensionnement des réseaux par les opérateurs.
Approche Opérateurs Les opérateurs historiques ont, quant à eux, la possibilité de
prioriser les flux dans leur réseau pour rendre un service payant et plus efficace de
VoIP ou de IPTV (IP Television). Les nombreuses offres “triple play” se fondent
sur ce modèle. Ils peuvent aussi offrir un service sur mesure pour interconnecter
des réseaux d’entreprise.
Néanmoins, les services ont convergé du fait d’un socle IP commun mais il manque
encore un réel fonctionnement commun des applications, malgré la notion d’URI per-
mettant une certaine convergence de l’adressage indépendant des ressources. Les ser-
vices sur IP sont donc très hétérogènes, chaque opérateur ou chaque acteur de l’Internet
pouvant choisir entre de très nombreuses solutions pour les déployer.
Au niveau des réseaux satellites, le service de base du réseau est la télévision DVB.
Avec l’arrivée du standard DVB-RCS, des offres d’accès à Internet se sont généralisées
(Eutelsat par exemple). Néanmoins, l’intégration de services sur IP de type “triple play”
est rare, le service de télévision n’ayant pas été déplacé au-dessus d’IP.
La tendance à la convergence des services par IP est une réalité dans beaucoup de
réseaux mais les services historiques perdurent. IP semble bien incontournable pour la
2.4. CONCLUSION 47

convergence des services mais manque d’une approche intégrée nécessaire à un opéra-
teur. IMS est une réponse à cette convergence des services.

2.3.3.3 Approche IMS

IMS (IP Multimedia Subsystem) est une réponse des opérateurs à l’intégration des
services d’ores et déjà présente sur Internet. Elle permet par exemple d’intégrer les diffé-
rents services dans une signalisation commune fondée sur SIP (Session Initiation Proto-
col) [87]. On peut considérer IMS comme une architecture évoluée de convergence des
services permettant aux opérateurs de regrouper dans un fonctionnement uniforme leurs
gestions des différents services. Comme son nom l’indique, il repose sur la convergence
IP. L’architecture IMS a été définie par le consortium 3GPP (Third Generation Partner-
ship Project) et standardisée par l’ETSI [88]. Un tutoriel de Gilles Bertrand donne plus
de détails sur le fonctionnement et la bibliographie [89].
Au niveau satellite, l’approche IMS pourrait aider à la convergence des services avec
d’autres réseaux hétérogènes tout en permettant une gestion unifiée et garantie par un
opérateur unique. Une plate-forme IMS pour la gestion d’un service de télévion sur IP
sur satellite a été testée et détaillée par le CNES (Centre National d’Etudes Spatiales)
[90]. Néanmoins, peu d’études d’intégration d’IMS sur le satellite existent. De nom-
breux points serait intéressant à étudier dans ce cadre, notamment sur l’ajout du délai
inhérent au satellite dans le fonctionnement d’IMS.
Au niveau de la convergence des services, l’approche IMS semble très prometteuse,
réunissant l’approche des réseaux intelligents des réseaux d’opérateurs avec le monde
IP. La question de son implantation réelle sera surtout un problème stratégique et éco-
nomique entre les opérateurs traditionnels voulant récupérer la gestion des services et le
monde Internet proposant déjà une très grande flexibilité de services.

2.4 Conclusion
Dans cette partie, après un rappel général de l’historique des réseaux de communi-
cation, la notion de convergence est définie avec plusieurs caractéristiques importantes.
Trois types de convergence sont ensuite décrits et comparés en donnant les applications
dans les systèmes satellite : la convergence par les architectures réseaux, la convergence
fixe-mobile et la convergence des services.
Dans le cadre de notre étude sur la convergence dans les réseaux satellites, la pro-
blématique qui nous a paru la plus importante est la convergence par les architectures
réseaux. En effet, les systèmes satellites majoritairement déployés sont des systèmes
DVB-S par satellite GEO transparent avec des terminaux fixes. Il nous a donc paru in-
téressant de partir de cette base. Dans ce contexte, la question importante est donc com-
ment intégrer des possibilités de convergence entre l’accès satellite et les services. Nous
48 CHAPITRE 2. LES ARCHITECTURES DE CONVERGENCE

nous concentrons donc dans la suite sur cette intégration intermédiaire. La convergence
des services n’est ensuite pas dépendante du satellite et revêt donc moins d’importance
dans notre étude. Enfin, la problématique de la convergence fixe-mobile est intéressante
mais nécessiterait une étude à part entière. Nous nous cantonnons aux systèmes satellite
non mobiles.
Pour décrire les problèmes d’une convergence des architectures réseaux satellite, il
nous a paru intéressant de choisir une solution de convergence existante et de l’appliquer
aux systèmes satellites actuels. Considérant les différentes solutions décrites précédem-
ment, il nous est apparu que la solution ATM avait déjà été choisie pour la voie retour
DVB-RCS. Partant de ce constat et sachant que l’approche ATM pose des problèmes
d’intégration avec IP, il nous est apparu que la solution MPLS était une convergence
de différentes méthodes et répondait bien aux problèmes d’hétérogénéités des couches
d’accès. De plus, MPLS répond au besoin d’ingéniérie de trafic inhérent aux réseaux
satellites, habitués à ne pas perdre de ressources radio en surdimensionnant les liens.
MPLS est aussi parfaitement couplé avec l’interface IP que l’on choisit pour la conver-
gence des services sur satellite. La suite du travail consiste donc à étudier l’intégration
de services IP sur une architecture réseau convergente MPLS.
Chapitre 3

MPLS comme solution de convergence

satellite : cas unidirectionnel

3.1 Architecture IP/MPLS générale . . . . . . . . . . . . . . . . . . . . . . 51

3.2 Télévision sur IP/MPLS par satellite unidirectionnel . . . . . . . . . . . 52
3.2.1 Architecture de diffusion TV . . . . . . . . . . . . . . . . . . . 52
3.2.1.1 Couches de service de télévision . . . . . . . . . . . 54
3.2.1.2 Couches de convergence IP/MPLS . . . . . . . . . . 55
3.2.1.3 Couches d’accès satellite . . . . . . . . . . . . . . . 57
3.2.2 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.2.1 Migration de la signalisation PSI/SI . . . . . . . . . . 58
3.2.2.2 Adressage du service télévisé . . . . . . . . . . . . . 60
3.2.2.3 Confidentialité et sécurité des programmes . . . . . . 63
3.2.2.4 Synchronisation . . . . . . . . . . . . . . . . . . . . 63
3.2.2.5 Qualité de service et ordonnancement . . . . . . . . . 64
3.2.3 Analyse du système . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.3.1 Migration depuis un système actuel . . . . . . . . . . 65
Migration réseau : . . . . . . . . . . . . . . . . . . . . 65
Migration des services : . . . . . . . . . . . . . . . . . 66
3.2.3.2 Analyse quantitative . . . . . . . . . . . . . . . . . . 66
Overhead : . . . . . . . . . . . . . . . . . . . . . . . . 66
Signalisation : . . . . . . . . . . . . . . . . . . . . . . 67
Services utilisateur : . . . . . . . . . . . . . . . . . . . 67
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

49
50 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

Comme décrit dans le chapitre 1, l’application phare du satellite demeure la télé-

vision numérique en raison de la diffusion naturelle sur le support et du coût élevé
du satellite qui doit être rentabilisé par un nombre important de clients. Les systèmes
satellites les plus communs sont donc des satellites GEO transparents diffusant de la
télévision par un système reposant sur les normes MPEG2. Ce système global s’appelle
DVB-S ou DVB-S2 pour la nouvelle norme.
De plus, le satellite devient un convoyeur de trafics plus divers comme des données
Web. Il devient un moyen de couplage de réseaux multi trafics, notamment avec l’avène-
ment d’une voie retour (DVB-RCS) et l’encapsulation de trafic Internet dans le système
de télévision classique. Il apparaît donc clairement que le satellite doit être repensé en
termes de convergence.
Cette convergence est précisément un thème de prédilection dans les réseaux actuels.
Avec des évolutions comme la VoIP (Voice over IP), la vidéo sur mobile ou les accès
“triple play” voie-données-télévision, il apparaît que le monde des réseaux intéropère
et cherche à organiser cette convergence. Le chapitre 2 décrit les réseaux actuels et ce
principe de convergence. Après avoir énoncé certaines caractéristiques de convergence,
différents modèles de convergence ont été examinés.
La problématique qui nous a semblé importante pour le futur des réseaux satel-
lites est la notion d’architecture réseau de convergence. La convergence des services
ou la convergence fixe-mobile sont des points moins directement liés aux réseaux sa-
tellites classiques actuels. Pour étudier cette convergence d’architecture réseau satellite,
le choix de MPLS a paru intéressant par sa flexibilité et son adoption dans les réseaux
terrestres. IP est logiquement utilisé comme interface protocolaire pour les services.
Considérant cette construction architecturale orientée télévision du satellite et ces
différents modèles de convergence possibles, le travail de cette thèse consiste à proposer
des solutions d’évolution convergente crédibles aux réseaux satellites. Nous expliquons
ci-après la démarche adoptée pour ce travail se déclinant sur les parties suivantes.
Démarche de l’étude :
Chapitre 3 : A partir du choix d’une solution de convergence, une architecture glo-
bale fondée sur IP et MPLS est ébauchée. Comme pour le choix d’un modèle
de convergence, l’étude d’une architecture globale au travers de tous les scéna-
rios possibles s’est avérée complexe. Cela nous a donc poussé à considérer des
scénarios élémentaires. Le premier scénario détaille le fonctionnement d’un seul
service sur une architecture unidirectionnelle. Le service ne pouvait être que la té-
lévision, service historique le plus développé. Le but est donc de montrer qu’il est
possible de définir un système IPTV équivalent sur une architecture convergente.
Ce passage est en effet un verrou important à l’évolution du système DVB.
Chapitre 4 : Au delà du scénario du service de télévision dans un cas unidirectionnel,
il convenait de montrer l’intérêt de notre démarche sur un ensemble de services.
Pour cela, nous avons repris la démarche en ajoutant une voie retour à l’architec-
3.1. ARCHITECTURE IP/MPLS GÉNÉRALE 51

ture et étudié un service de télévision interactif puis d’autres services. La topolo-

gie a été conservée dans le schéma en étoile classique dans un cas transparent.
Chapitre 5 : Ce chapitre montre l’applicabilité de cette approche MPLS dans le projet
industriel ULISS de commutateur à bord du satellite. Cette étude plus pragma-
tique nous permet de valider notre approche.
Le présent chapitre s’attache donc d’abord à décrire les principes généraux de l’ar-
chitecture IP/MPLS choisie pour ensuite s’intéresser plus en détail au cas d’un service
de télévision unidirectionnel.

3.1 Architecture IP/MPLS générale

Télévision Internet
Téléphonie
Niveau services (IPTV, MPEG2, (HTTP,
(VoIP, SIP)
SAP) SMTP)
Niveau réseau IP
convergence MPLS
MPE ou ULE AAL5
Niveau accès satellite GSE MPEG2 ATM
DVB-S2 DVB-S DVB-RCS

F IG . 3.1 – Architecture IP/MPLS générale

Dans le souci de virtualisation des services et d’organisation des différentes fonc-

tions réseau, l’architecture générale IP/MPLS utilisée sépare trois principaux niveaux
protocolaires (figure 3.1) :
Niveau accès satellite : Ce niveau s’occupe donc d’accéder directement au support de
communication satellite. Ce niveau comporte une couche liaison de données sur
une couche physique. La couche liaison de données transporte les paquets réseau
dans des trames adaptées au média satellite. Les fonctions de cette couche peuvent
être la délimitation des trames, la gestion de l’accès au support, l’adressage, la
correction d’erreur, la réservation de ressources locales, la sécurité de l’accès, la
gestion du support satellite. Une couche physique s’occupe d’envoyer ces trames
d’information binaire sur le support de la façon la plus adaptée et la plus efficace.
La figure 3.1 montre les différents protocoles d’accès satellite existants que nous
avons évoqués dans le chapitre 1.
52 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

Niveau réseau : Le niveau réseau comporte une couche MPLS généralisant la façon
d’accéder au support par le label. Cette couche est très liée au fonctionnement
des couches accès de proche en proche ; le champ VPI/VCI d’ATM peut, par
exemple, être réutilisé. Un label peut également représenter un élément physique
comme une interface ou une fréquence. La couche réseau IP propose, quant à
elle, une interface commune aux services et s’occupe de la communication et de
l’adressage de bout en bout indépendant des réseaux sous-jacents (notamment en
multicast).
Niveau services : Les différents services utilisent ainsi cette interface IP pour ne pas
dépendre de la technologie des réseaux traversés. Comme expliqué dans le cha-
pitre 2, nous ne nous préoccupons pas de la convergence des services. Néanmoins,
il a fallu choisir un système de télévision sur IP pour illustrer les principes de l’ar-
chitecture globale. La télévision sur IP ou IPTV peut donc, par exemple, se fonder
sur une signalisation SAP (Session Announcement Protocol) et un transfert de pa-
quets vidéos MPEG2 sur RTP [91, 60, 92]. Un service de VoIP repose de plus en
plus sur une signalisation SIP et un transport RTP d’échantillons de voix codée
[87, 60]. Enfin, les services historiques du Web et du mail reposent sur les proto-
coles HTTP et SMTP [93, 94].
Pour déterminer si cette architecture est réaliste, il convient tout d’abord de se res-
treindre au système satellite le plus développé : le service de télévision sur un satellite
transparent unidirectionnel. Est-il envisageable d’avoir un service de IPTV équivalent à
la fois en termes de fonctionnalités et de performances ?

3.2 Service de télévision par satellite unidirectionnel sur

une architecture IP/MPLS
Le but de cette section est donc de montrer la faisabilité d’un service de télévi-
sion convergent semblable à celui qui existe aujourd’hui. Le système satellite utilisé est
géostationnaire, unidirectionnel, transparent. L’architecture IP/MPLS sur ce satellite est
tout d’abord décrite, les principaux problèmes discutés, puis la faisabilité analysée.

3.2.1 Architecture de diffusion TV

L’innovation principale de notre solution réside donc dans l’ajout d’une couche
d’abstraction au média et le passage du service de télévision au-dessus d’IP. On dé-
crit ici l’architecture globale et les détails protocolaires et fonctionnels sont repris dans
la partie suivante.
L’architecture est décrite par la figure 3.2. On considère un modèle simple de diffu-
sion avec d’un côté un fournisseur de contenu et son encodeur MPEG2 et de l’autre les
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 53

F IG . 3.2 – Nouvelle architecture de diffusion vidéo

54 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

clients de télévision et leurs décodeurs chez les abonnés. Le problème est de savoir com-
ment organiser la transmission des programmes de télévision via un satellite classique
transparent et unidirectionnel.
Nous considérons que les flux vidéos arrivent comme un flux MPEG2-TS dans le
réseau opérateur par une liaison dédiée. Cela pourrait être également un réseau MPLS
qui offrirait la possibilité de déporter facilement le fournisseur de contenu du système
de distribution. Nous ne nous intéressons donc qu’au réseau de distribution. Nous consi-
dérons également un gestionnaire du service télévisé dont le rôle consiste à récupérer
les différents flux et à les distribuer dans le réseau satellite au travers de la gateway.
On considère de même que le gestionnaire et la gateway sont directement reliés mais il
pourrait y avoir un réseau opérateur acheminant les flux entre les deux. Le gestionnaire
de télévision pourrait ainsi faire la distribution de ces flux indépendamment des réseaux
d’accès. On pourrait de plus considérer plusieurs gestionnaires de télévision dans une
approche plus distribuée pour éviter d’avoir un seul équipement. Cela pourrait être inté-
ressant dans un but de répartition de charge ou pour éviter la concentration de la gestion
de tous les programmes sur un seul équipement. Enfin, chaque terminal récupère les
flux de la gateway à la demande du client TV et lui transmet le flux demandé. Le client
peut alors décompresser le flux pour l’afficher sur une télévision. Le client TV peut être
dissocié du terminal. Par exemple, cela peut être un logiciel sur ordinateur connecté sur
le même réseau privé que le terminal. On peut envisager un service multiposte dans une
maison (exemple opérateur Free [95]).
Décrivons maintenant plus précisément chaque structure des 3 niveaux d’abstrac-
tion : la couche de service télévision, la couche de convergence IP/MPLS et la couche
d’accès satellite.

3.2.1.1 Couches de service de télévision

Le service de télévision est donc placé au-dessus d’IP depuis le gestionnaire jus-
qu’au client de télévision. La signalisation et les flux sont générés par le gestionnaire
de télévision. Le service de télévision numérique doit être conservé en l’état pour les
clients. On réutilise donc une compression MPEG2-TS même s’il sera possible ensuite
de passer à des encodages plus efficaces (MPEG4 codage H264 [14]). Sur MPEG2-
TS, plusieurs caractéristiques sont définies. Les grands aspects des services rendus aux
utilisateurs et aux diffuseurs du réseau télévisé sont :
– le visionnage de programmes vidéos avec sous-titres ou plusieurs pistes audio ;
– une gestion des bouquets de chaînes protégés ;
– le télétexte qui ajoute des informations textuelles aux programmes (actualités,
météo, . . .) ;
– les EPG qui sont des guides de programme électroniques ;
– MHP (Multimedia Home Platform) [96, 97] qui permet l’exécution d’applications
distribuées en Java (des jeux par exemple) rajoutant une pseudo-interactivité ;
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 55

cette plate-forme middleware prend tout son intérêt avec une voie retour.
Le visionnage des programmes vidéos et la gestion des bouquets de chaînes protégés
sont les points les plus importants sur lesquels nous nous concentrerons. Les systèmes
des EPG et de MHP ne seront pas détaillés ici. Le télétexte ou les guides électroniques
peuvent s’appuyer sur des travaux du groupe TV-Anytime [98] et MHP a été conçu de
façon portable au-dessus d’un middleware Java et peut donc migrer facilement.
Notre but à ce niveau n’est pas de proposer un fonctionnement convergent des ser-
vices de télévision. Nous nous fonderons sur les principes existants d’un service IPTV
classique pour étudier les problèmes de l’architecture réseau. On détaille les différents
plans fonctionnels du service :
Plan de données : Les programmes MPEG2 sont diffusés en multicast sur RTP/UDP.
RTP permet de rajouter des informations d’ordre et de synchronisation et ainsi
compléter le protocole UDP. En cas de programmes non publics sujets à abonne-
ment, un système de cryptage doit être développé. Les fonctions de multiplexage
des programmes télévisuels (anciennement transport stream) et de cryptage sont
donc gérées dans ce plan.
Plans de contrôle et gestion : Les informations sur les programmes sont diffusées en
multicast à tous les terminaux de télévision via le protocole SAP au-dessus d’UDP
[91]. Les informations sur les programmes suivent le standard SDP (Session Des-
cription Protocol) [99]. Les fonctions d’identification des programmes, de condi-
tions d’accès sont gérées ici (anciennement tables SI du système DVB). Les pro-
grammes télévisés sont, de même, regroupés en bouquet dans le plan de contrôle.
Un plan de gestion du service de télévision devra être mis en place pour permettre
la gestion des bouquets, des abonnements.
Le service de télévision s’appuie sur des couches inférieures dans le réseau opérateur
pour acheminer les programmes à tous les terminaux avec une certaine QoS adaptée aux
flux vidéos. IP et MPLS sont les couches permettant cela dans cette architecture.

3.2.1.2 Couches de convergence IP/MPLS

Le service est donc rendu complètement indépendant de l’accès satellite par
IP/MPLS. Il est donc désormais plus simple à acheminer et à traiter dans un environne-
ment hétérogène. Un pas important a été franchi vers la convergence.
Le protocole IP s’occupe du transport de bout en bout du gestionnaire TV au client
TV. Au contraire, MPLS est lié au réseau opérateur et ne dépasse pas le terminal. C’est
une couche intermédiaire gérant l’ingénierie de trafic de bout en bout dans le réseau
opérateur. Des chemins MPLS (LSP) à la demande ou permanents peuvent être créés.
Au niveau de ce réseau opérateur, on distingue un plan de données permettant de trans-
porter les flux vidéos et un plan de contrôle et de gestion servant au fonctionnement de
la couche.
56 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

Plan de données : Les flux vidéos et les informations associées sont transportés dans
des paquets IP, eux mêmes tagués par MPLS. Les labels MPLS permettent de
faire de la différentiation des flux et de leur associer une qualité de service. Des
adresses IP multicast et port UDP permettent d’identifier les flux dans un contexte
plus global et indépendant de l’accès. Le label MPLS est l’identification orientée
opérateur, les adresses IP sont orientées utilisateur et multi-réseaux. Les flux RTP
vidéos sont donc transportés dans des LSP multicast depuis le gestionnaire de
télévision jusqu’aux terminaux. Sur la liaison proche en proche de la gateway
vers les terminaux, un label représente donc un programme du gestionnaire. Le
plan d’adressage global devra être mis en place par l’opérateur du réseau.

Plans de contrôle et de gestion : Le plan de contrôle à ce niveau doit distribuer les

associations entre les labels et les adresses IP et des informations sémantiques
sur les flux comme la QoS adaptée. Dans notre application d’acheminement des
flux télévisés, plusieurs possibilités sont envisageables. La diffusion vidéo étant
de type permanent, la signalisation pour la distribution des labels peut passer par
voie de gestion via SNMP mettant à jour les informations des MIB (Management
Information Base). Une autre possibilité est de connecter les LSP vidéos grâce
au protocole RSVP-TE modifié. Nous avons choisi cette dernière solution pour
des raisons d’intégration plus simple dans un réseau MPLS plus large et de la
problématique de reroutage rapide. Dans un contexte unidirectionnel, le fonction-
nement de RSVP-TE devra être modifié. Les terminaux ne pouvant pas initier la
réservation par un message RESV, seuls des messages PATH spécifiant le label
et la QoS associée seront diffusés en aveugle sur les terminaux. La fréquence des
messages PATH devra être adaptée pour assurer une bonne réception pour les ter-
minaux. Les flux vidéos MPLS multicast seront donc mis en place par le plan de
gestion du réseau MPLS comme des circuits virtuels permanents. Un protocole
de routage multicast gérant la QoS doit être mis en place dans le réseau opérateur
pour que les messages RSVP-TE trouvent leur chemin. D’autre part, IP comporte
ICMP (Internet Control Message Protocol) et IGMP (Internet Group Management
Protocol) comme plan de contrôle. Pour le réseau d’accès satellite, ICMP ne nous
importe pas et il ne pourra pas fonctionner sans voie retour. IGMP qui s’occupe du
multicast est utilisé pour gérer les souscriptions au groupe multicast entre le client
TV et le terminal (voir la problématique sur l’adressage dans la section suivante).

Le dernier niveau important de cette architecture est le niveau accès satellite sur le
réseau d’accès. Les autres protocoles d’accès entre le gestionnaire et la gateway ou entre
le terminal et le client TV ne nous importent pas dans ce cadre satellite.
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 57

3.2.1.3 Couches d’accès satellite

A ce niveau, l’interface protocolaire supérieure est MPLS et les problématiques ne
sont donc plus liées au service ou à la couche IP.
Plan de données : L’acheminement de proche en proche sur le réseau d’accès satellite
depuis une gateway jusqu’aux terminaux peut utiliser différentes encapsulations.
Nous retenons le nouveau standard DVB-S2 car il permet de multiplexer diffé-
rents types de trafic. Il permet de plus d’assurer la compatibilité avec un système
DVB-S/MPEG2-TS classique tout en s’en désolidarisant. DVB-S2 gère donc l’as-
pect transport physique satellite via des BBFRAME encapsulées dans des PL-
FRAME. Evidemment, l’encapsulation classique dans MPEG2-TS est toujours
possible grâce à MPE ou ULE, malgré la surcharge des couches qu’elle induit.
Une nouvelle couche d’encapsulation appelée GSE est utilisée comme couche 2
du modèle OSI, permettant de faire le lien entre DVB-S2 et de multiples proto-
coles. Elle a une fonction d’adressage possible avec une adresse de destination.
Dans le cas de la télévision, GSE diffuse à tous les terminaux sans adressage.
L’encapsulateur GSE permet de fragmenter les paquets de niveau supérieur pour
s’adapter à DVB-S2. Il s’occupe aussi d’un contrôle d’erreur sur le paquet.
Plan de signalisation et de gestion : Parallèlement, une signalisation pour la gestion
de la transmission satellite est nécessaire. En effet, le lien entre les labels MPLS et
les différentes fréquences ou positions satellite doit être transmis aux terminaux.
Plusieurs approches peuvent être envisagées : une approche pourrait conserver
certains mécanismes des tables transportées par MPEG2 ; une approche plus co-
hérente avec MPLS considère les fréquences comme des labels GMPLS. D’autres
informations comme la remise à l’heure des terminaux peuvent être transportées
par SNMP ou NTP (Network Time Protocol).
Ordonnanceur : Dans la gateway, une entité de gestion est obligatoire en vue de ga-
rantir l’accès concurrent au support et la réservation de ressources nécessaires.
Cet ordonnanceur doit garantir la QoS MPLS sur le média et notamment les dif-
férentes contraintes de temps vidéo.
Plusieurs problématiques particulières méritent d’être étudiées plus en détail dans la
partie suivante.

3.2.2 Problématiques
Cette partie se concentre sur les problématiques importantes du service télévision et
de son acheminement dans un contexte satellite. Les points sont :
– la migration de la signalisation PSI/SI ;
– l’adressage et le multiplexage des programmes de la gateway jusqu’aux termi-
naux ;
58 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

– la confidentialité et sécurité des programmes ;

– la synchronisation obligatoire pour la vidéo en temps réel ;
– la qualité de service et sa mise en œuvre.

3.2.2.1 Migration de la signalisation PSI/SI

TABLES PSI/SI Correspondance

Nom Fonction Protocole
PAT (Program indique les emplacements des “cartes” de chaque SAP (Session
Association Table) programme Announcement
Protocol)
PMT (Program Map indique les PID des flux d’un programme = carte SDP (Session
Table) d’un programme Description Protocol)
CAT (Conditionnal indique les PID des paquets transportant les SDP
Access Table) systèmes de contrôle d’accès
TDST (Transport décrit le contenu du multiplexe champ protocole GSE
Stream Description
Table)
NIT (Network transporte des informations sur l’organisation SNMP ou RSVP
Information Table) physique des réseaux
SDT (Service liste les noms et paramètres associés à chaque SDP
Description Table) service d’un multiplexe
EIT (Event transmission d’événements en cours ou à venir SDP
Information Table) dans le multiplexe
TDT (Time and Data remise à l’heure de l’horloge interne du récepteur SNMP/NTP
Table)
BAT (Bouquet groupe différents services en bouquet SDP
Association Table)
RST (Running Status table transmise pour la mise à jour rapide d’un ou SDP
Table) plusieurs événements
TOT (Time Offset indique le décalage horaire SNMP
Table)
ST (Stuffing Tables) permet d’invalider des tables devenues inutiles none

TAB . 3.3 – Correspondance avec la signalisation SI

La signalisation dans le contexte MPEG2-TS est complètement regroupée dans les

tables PSI et SI. Le tableau 3.3 montre une correspondance des différentes tables avec
les protocoles de notre architecture. Il apparaît que se côtoient des informations de na-
ture diverse. On peut ainsi décomposer les fonctionnalités en deux groupes :
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 59

Description de la session
v=0 version du protocole
o=durand 2890844526 origine : o=<nom> <id session> <version> <type
2890842807 IN IP4 126.16.64.4 réseau> <type d’adresse> <addresse>
s=Tele TESA nom du programme
a=bouquet 10 Bouquet10 fonction étendue : numéro bouquet
t=2873397496 2873404696 temps d’activité de la session
Description des Médias
c=IN IP4 224.2.17.12/127 information de la connexion Ipv4 @IP/TTL
m=audio 49170 RTP/AVP 14 média audio, port, transport, format du média (MPA)
m=video 51372 RTP/AVP 31 média vidéo, port, transport, format du média (MPV)

TAB . 3.5 – Exemple de signalisation SDP pour le service télévisé

– Les fonctionnalités des tables PAT, PMT, CAT, SDT, EIT, BAT, RST sont repro-
duites dans la signalisation du service télévisé qui sera transporté dans une session
SDP indépendante du support.
– Les fonctionnalités des tables NIT, TDT, TOT sont reproduites dans la signalisa-
tion sur le lien satellite qui sera transporté par le biais des protocoles de gestion
de type SNMP ou par une signalisation réseau de type RSVP-TE.
Signalisation du service télévisé : Le tableau 3.5 montre un exemple de signalisation
SDP pour le service de télévision placé au-dessus d’IP. Pour chaque programme,
un message de session SDP est généré et diffusé sur toutes les fréquences indi-
quant les différentes caractéristiques du programme. Ces messages reprennent les
rôles des tables PAT, PMT pour l’adressage du service télévisé et le rôle de la table
CAT pour les indications de sécurité des flux. Un champ ajouté peut regrouper les
flux en bouquets comme dans la table BAT. Des champs appropriés peuvent ré-
pondre aux mêmes fonctionnalités que les tables d’information SDT, EIT, RST.
On se retrouve bien avec un service de télévision indépendant des couches infé-
rieures pouvant être transporté sur différents types de réseaux.
Signalisation satellite : Certaines informations transmises par le système de tables SI
sont liées au système satellite lui-même. Elles ne sont transmises que sur le seg-
ment satellite et sont indépendantes des services. La table NIT transporte des
informations sur les satellites utilisées en terme de positionnement ou de fré-
quence. Ces informations permettent de connaître l’emplacement des différents
programmes et de changer de fréquence au besoin. Pour répondre aux mêmes
attentes d’adressage, on se servira d’une approche MPLS et la signalisation de
60 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

fréquence et de positionnement de la table NIT sera transportée par RSVP-TE.

L’approche est néanmoins différente car, dans notre solution, la couche accès ne
voit que des labels indépendants des services supérieurs tandis que la table NIT
est liée à des services vidéos. Certains aspects de ces tables comme la mise à jour
de l’heure et du décalage horaire peuvent être faits par la gestion SNMP.
Observons maintenant plus précisément différents aspects du fonctionnement du
système reposant sur cette nouvelle organisation de signalisation.

3.2.2.2 Adressage du service télévisé

Dans l’architecture décrite précédemment, un point important est de bien com-
prendre comment les programmes télévisés sont organisés au niveau de l’adresssage.
On reste dans le contexte de la figure 3.2. Les étapes d’adressage pour la diffusion d’un
programme donné sont développées ici et illustrées dans la figure 3.3. On considère
qu’un terminal se connecte sur une fréquence freq0 et souhaite recevoir un programme
P1 sur une fréquence freq1. Les signalisations SDP et RSVP-TE sont transmises sur
toutes les fréquences.
1. Création du canal de signalisation du service télévisuel : Tout d’abord, un canal
pour la signalisation télévisuelle SAP/SDP est créé avec un label associé à ces
types de flux. Cela permet de séparer et d’organiser ce trafic dans un LSP dédié.
Pour ce faire, un message SNMP de configuration statique est envoyé sur toutes
les fréquences avec une adresse multicast (@IPsig) connue et fixée par le plan de
gestion dans les terminaux. Une autre possibilité serait de faire passer le trafic de
signalisation comme un trafic IP classique best effort (label = 0) et éviterait cette
réservation de label. L’important est que les terminaux aient accès aux données
du canal de signalisation de télévision. Le terminal reçoit donc les informations
de signalisation de télévision et peut faire un cache des programmes.
2. Association labels fréquences : On considère que le flux du programme P1 iden-
tifié par le label “labelP1” sera diffusé sur une fréquence freq1. Des messages
RSVP-TE de création des tunnels fréquentiels point à point permettent de faire
l’association entre les labels et les fréquences. De nouveaux objets RSVP-TE de-
vront être définis pour cela. On peut considérer les différentes fréquences du satel-
lite comme des canaux GMPLS. Les messages de signalisation permettent d’ob-
tenir les informations nécessaires d’association des labels avec les fréquences. On
peut associer de la même façon la position des satellites à des labels. Un terminal
peut alors changer de fréquence de réception si le flux du label “labelP1” n’est pas
sur la fréquence utilisée comme dans l’exemple. On considère à ce niveau le flux
de façon générique et découplé de la notion de service de télévision utilisateur.
3. Création d’un canal de diffusion des programmes aux terminaux : On veut
maintenant diffuser un programme P1 sur cette fréquence freq1. Pour cela, des
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 61

F IG . 3.3 – Description des étapes d’un transport de programmes télévisuels

62 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

messages RSVP-TE (ou SNMP) sont envoyés sur toutes les fréquences pour ré-
server les labels et la qualité de service adaptée aux programmes télévisés en
terme de délai et de bande passante. Les terminaux sont alors aptes à recevoir les
canaux MPLS diffusés. Néanmoins, le terminal ne désencapsule pas tous les mes-
sages dont le label a été réservé tant que le client n’a pas demandé le programme.
En effet, il ne sert à rien de faire remonter tous les programmes au niveau IP s’ils
ne sont pas regardés. Le filtrage se fait donc au niveau MPLS.

4. Diffusion des informations sur le programme P1 : Les informations SDP trans-

portées par SAP sont ensuite envoyées sur une adresse multicast fixe (@IPsigTV)
configurée par le plan de gestion. Un message SDP transporte la description d’un
programme avec notamment toutes les composantes vidéos, audios possibles et
leurs adresses IP et ports respectifs. Le tableau 3.5 montre un exemple d’adressage
de programme sur l’adressage IP_P1. Ces messages sont donc diffusés vers les
terminaux sur toutes les fréquences à intervalles réguliers. Les terminaux peuvent
ensuite mettre à jour leur table d’association des programmes en conséquence.

5. Diffusion flux du programme P1 : Les données vidéos du programme,

conformes à la signalisation SDP, sont diffusées dans le LSP MPLS réservé pré-
cédemment sur la fréquence freq1 associée. Le terminal considéré ne reçoit rien
sur la fréquence freq0. Les terminaux sur la fréquence freq1 filtrent ce flux en ne
faisant pas remonter le label tant que le programme n’est pas consulté.

6. Consultation des programmes par le client : Le client qui décide de voir un

programme commence par notifier au terminal qu’il veut voir la signalisation du
service télévisuel. Il s’abonne donc sur l’adresse IP multicast @IPsigTV. Il reçoit
alors la liste des programmes existants (filtrés ou non) sous la forme de messages
SDP. Le client est prêt à recevoir le programme sur l’adresse IP_P1.

7. Choix du programme P1 par le client : L’utilisateur décide de voir le pro-

gramme P1. Le client envoie donc au terminal un message IGMP pour s’abonner
à ce flux de télévision identifié par l’adresse @IP_P1.

8. Diffusion du programme au client : Le terminal récupère le label “labelP1” as-

socié à l’adresse IP @IP_P1 du programme et regarde sur quelle fréquence ce
label existe. Comme il trouve que le label demandé se trouve sur la fréquence
freq1, il change de fréquence de synchronisation. Ce changement de fréquence
peut occasionner un certain délai suplémentaire pour le choix entre deux pro-
grammes. Le terminal récupère alors le flux demandé en remontant les paquets
MPLS avec le label “labelP1” et diffuse le programme vers le client. L’utilisateur
peut regarder son programme de télévision.
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 63

3.2.2.3 Confidentialité et sécurité des programmes

La question de la sécurité se pose à plusieurs niveaux. Actuellement, DVB-CA s’oc-
cupe de la confidentialité des programmes grâce à un algorithme secret CSA (Com-
mon Scrambling Algorithm) et un accès conditionnel aux données cryptées grâce à des
échanges de clefs. Dans notre cas, il faut séparer la sécurité au niveau satellite, au niveau
service et au niveau contenu. Notre objectif n’est pas de définir une politique de sécurité
mais plusieurs approches sont évoquées ci-dessous pour chaque niveau.
Niveau satellite : Dans un contexte DVB-S, la sécurité d’accès au satellite n’existe pas
vraiment. Il est vrai que dans un contexte unidirectionnel de télévision, elle est
peu utile car certains programmes sont diffusés de façon publique. Il vaudra mieux
protéger les programmes à un niveau supérieur. Néanmoins, il serait possible de
considérer un cryptage de niveau 2 pour des utilisations différentes du réseau
satellite (VPN satellite par exemple).
Niveau Service : La sécurité sera assurée au niveau du service de télévision. Elle peut
ne pas être utilisée. Des clefs de déchiffrement sont distribuées par avance aux
abonnés dans les terminaux selon l’offre choisie. Ces clefs permettent de décryp-
ter les clefs de chiffrement des programmes suivant l’abonnement. Les clefs de
chiffrement de chaque programme sont diffusées dans les sessions SDP associées.
Ce mécanisme est équivalent à DVB-CA. Le cryptage peut se faire à différents ni-
veaux et suivant plusieurs méthodes comme IPsec ou SRTP (Secure RTP) selon
les besoins.
Niveau Contenu : Un mécanisme de protection du contenu de type DRM (Digital
Rights Management) pourra être mis en place suivant le type de conteneurs uti-
lisé. Dans notre cas, nous restons sur une encapsulation du format MPEG2-TS
mais des formats plus récents de type MPEG4 proposent d’autres éléments de sé-
curité. Ces systèmes sont néanmoins peu intéropérables et contraignent souvent
l’utilisation des données ainsi protégées.
Le but de cette partie est de souligner brièvement qu’une sécurité équivalente à
l’existant est possible avec cette architecture et qu’il est même possible d’en concevoir
d’autres. La séparation des couches permet également de remettre la sécurité au niveau
nécessaire en fonction de l’utilisation du réseau. La réponse aux besoins de sécurité
pourra être ainsi adaptée et réévaluée si nécessaire.

3.2.2.4 Synchronisation
Dans un premier temps, pour ce qui est du système satellite, il est nécessaire de
coordonner les récepteurs terminaux avec les envois de la gateway. Cette synchronisa-
tion est assurée par plusieurs éléments. DVB-S2 doit se synchroniser finement via des
séquences pilote reconnaissables et des délimiteurs de trames. Un codage correcteur
64 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

d’erreur permet de limiter le nombre de pertes de paquets. Les couches basses doivent
ainsi assurer un délai et une bande passante suffisante pour avoir peu de gigue et de
perte.
Ensuite, pour garantir la synchronisation des programmes, un ordonnancement adé-
quat devra être mis en place suivant la QoS MPLS (voir partie correspondante).
Pour finir, la synchronisation plus fine et le reséquencement potentiel des messages
sont assurés par RTP. Ce dernier ajoute une information pour rattraper quelques erreurs
de délai en synchronisant finement certains paquets à l’aide d’estampilles temporelles.
Cela est utile pour rattraper les retards engendrés par l’accès concurrent à un même
média. Pour le transport de flux MPEG2-TS, chaque message RTP contiendra une in-
formation temporelle déduite de l’horloge de l’émetteur de programmes et prise dans
le PCR du flux MPEG2-TS issu de l’encodeur [92]. Cette opération est effectuée par le
gestionnaire de télévision. Par ailleurs, le reséquencement de RTP ne sera pas forcément
utile dans le cas du satellite car il n’y a qu’une route empruntée.

3.2.2.5 Qualité de service et ordonnancement

Pour pouvoir regarder des programmes vidéos de façon confortable, MPLS associe
à chaque label une qualité de service en termes de délai et de bande passante. Cette QoS
doit être mise en œuvre dans chaque nœud et notamment dans la gateway pour ce qui
nous intéresse.
Le débit et les délais de transit doivent être garantis par un ordonnanceur. Il est pos-
sible de réserver statiquement un débit et un délai en allouant des slots pour chaque pro-
gramme dans le Generic Stream DVB-S2. C’est l’approche utilisée à l’heure actuelle.
Elle permet de garantir la qualité de service mais fait perdre de la bande passante al-
louée inutilement. Un multiplexage statistique ordonnancé suivant la qualité de service
de chaque flux est plus optimisé, bien que plus difficile à mettre en place. Il permettrait
d’avoir plus de bande passante pour du trafic de données.
L’ordonnancement statistique dans le cas de la télévision peut se ramener à un pro-
blème déjà traité dans la littérature. En effet, dans ce cas, il n’y a pas de différentia-
tion par utilisateur ; il est donc logique d’envoyer les flux suivant le pire cas du spot
en allouant le bon ModCod DVB-S2 suivant le bilan de liaison. De plus, il n’y a pas
d’évolution possible du codage du canal sans voie retour notifiant des changements des
caractéristiques du canal satellite. II faut donc aussi se placer dans un pire cas pour
diffuser à tout moment de façon convenable. On se retrouve donc avec un codage ho-
mogène au niveau DVB-S2 choisi suivant le bilan de liaison satellite. Cela donne donc
un flux de conteneurs de longueur fixe et de même codage à allouer. Le problème de
l’ordonnancement revient donc à une allocation de paquets de taille variable sur un ca-
nal fixe. On peut voir l’accès DVB-S2 comme un lien réseau sur lequel on envoie des
paquets dans un ordre et un timing compatible avec la qualité de service à rendre.
Dans notre cas, nous avons des flux de télévision tagués par des labels avec une
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 65

qualité de service devant garantir un délai. Ces flux devront donc être traités de façon
plus prioritaire que des flux de signalisation ou des données diverses. Les flux devront
être classifiés suivant leurs labels MPLS et la QoS associée suivant un modèle CBQ
(Class Based Queuing), qui répartit les capacités de transmission entre classes. Une
classe de transmission sera liée typiquement aux labels des programmes vidéos. Il faut
ensuite ordonnancer de façon adéquate les flux dans chaque classe de transmission ainsi
organisée. Les algorithmes alors possibles sont FIFO (First In First Out) pour émettre
les flux vidéos le plus vite possible et WFQ (Weighted Fair Queuing) pour les flux best
effort de même niveau. Il faut ensuite faire en sorte que le débit total des flux vidéos
soit inférieur à la bande passante disponible pour que des flux de priorité faible puissent
quand même être émis.

3.2.3 Analyse du système

Après avoir décrit fonctionnellement le service d’IPTV, cette partie analyse en quoi
cette approche est réaliste. Plusieurs points peuvent en effet être soulevés. Tout d’abord,
la migration depuis le système actuel doit être étudiée car il est impensable de rempla-
cer tout le système. Ensuite, une approche quantitative permettra d’évaluer l’impact en
termes de performance de cette nouvelle architecture.

3.2.3.1 Migration depuis un système actuel

La migration peut être vue selon l’aspect réseau ou l’aspect service.

Migration réseau : Dans le cas d’un système DVB-S classique, l’encapsulation avec
des trames GSE n’est pas possible et il est obligatoire de conserver MPEG2-TS. Dans
ce cas, le plus simple est d’encapsuler MPLS dans MPEG2-TS via MPE ou ULE. Il
faut donc revoir la qualité de service dans ce contexte et étudier comment le système
MPEG2-TS et les données MPLS encapsulées peuvent cohabiter. On se retrouve néan-
moins dans un cas similaire d’encapsulation de paquets MPE ou ULE de taille variable
dans des trames MPEG2-TS de taille fixes (188 octets). Il faudra aussi régler l’associa-
tion entre les PID au niveau MPEG2 et les adresses MAC au niveau MPE ou ULE.
Dans le cas d’un système DVB-S2, on peut encapsuler différents types de flux.
MPEG2-TS et GSE peuvent ainsi coexister et la réservation de ressources entre les
deux encapsulations reste à définir. Cela change potentiellement le comportement du
canal DVB-S2 qui peut être bien plus complexe à ordonnancer.
Le moyen le plus simple est le cas d’un transpondeur non utilisé dédié à cette nou-
velle architecture. Le partage des ressources et la migration se fait dans ce cas par mul-
tiplexage de fréquences.
66 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

Migration des services : La migration des services change les messages générés à
partir des informations sur les médias et les bouquets et modifie donc les outils de ges-
tion des programmes. La signalisation passe des tables SI à des messages SDP. Les
deux systèmes de télévision peuvent également fonctionner et diffuser les programmes
en parallèle. Pour l’utilisateur, il ne faudrait changer que le terminal ou son logiciel. Il
est donc assez simple d’effectuer cette migration sans impact sur le service de télévision
rendu à l’utilisateur.

3.2.3.2 Analyse quantitative

Overhead : Tout d’abord, l’empilement des couches dans un fonctionnement clas-
sique de diffusion de télévision rajoute des en-têtes : RTP (12 octets), UDP (8 octets),
IP (20 octets), MPLS (4 octets), GSE (5+4 octets) font un total de 53 octets d’en-tête.
Dans la partie utile des trames envoyées, RTP permet de concaténer plusieurs paquets
MPEG2-TS de 188 octets. Considérant qu’il convient d’éviter la fragmentation, la taille
maximale est définie à une valeur de 4 kilo-octets (4096 octets) par le protocole de
niveau 2 GSE. Il est donc possible d’encapsuler 21 paquets MPEG2-TS au maximum.

22 22
Overhead (%)
Overhead compressˆ' (%)
20 20

18 18

16 16

14 14

12 12

10 10

8 8

6 6

4 4

2 2

0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Nombre de paquets MPEG2

F IG . 3.4 – Overhead en fonction du nombre de paquets MPEG2

Comme illustré par la figure 3.4, on remarque que dans le cas de messages de 4
kilo-octets, la part d’overhead est de 1.3% (21 paquets encapsulés). Néanmoins, cette
3.2. TÉLÉVISION SUR IP/MPLS PAR SATELLITE UNIDIRECTIONNEL 67

concaténation peut engendrer un certain délai et une certaine gigue dans la diffusion
des flux MPEG2-TS. Pour minimiser complètement ces retards et améliorer le travail
de l’ordonnancement avec de plus petits paquets GSE, on peut choisir de n’encapsuler
qu’un seul paquet MPEG2-TS. On obtient dans ce cas un overhead important de 23%.
Par ailleurs, l’overhead peut être aussi minimisé par une compression d’en-tête.
Dans un cadre unidirectionnel (U-mode), le mécanisme ROHC (RObust Header Com-
pression) décrit par la RFC 3095 [100] permet de passer d’un en-tête IPv6 de 60 octets
à 2-3 octets (voir article [101]). Il peut être applicable à une pile RTP/UDP/IPv4 de
manière similaire. Même dans le cas d’un seul paquet MPEG2 transporté, l’overhead
redevient raisonnable (1-2%). En choisissant un nombre de paquets concaténés plus
important, il est même possible de réduire complètement la lourdeur de l’architecture
protocolaire proposée.
Le problème sera donc de choisir le bon nombre de paquets MPEG2 à concaténer
pour ne pas avoir trop de gigue et rester efficace. A priori, avec un mécanisme de com-
pression, l’envoi de paquets MPEG2 un par un minimise la gigue à l’arrivée et augmente
l’entrelacement possible des trames par l’ordonnanceur (comme ATM).

Signalisation : La caractéristique la plus importante est cette séparation des couches

services, réseaux et liaison de données permettant une plus grande flexibilité et évo-
lutivité. Une complexification du service de télévision ou un changement de couche
physique sera beaucoup plus facile à mettre en place. Cette caractéristique peut justifier
à elle seule l’évolution de la signalisation. Par ailleurs, il est difficile d’estimer com-
plètement l’impact de la signalisation de façon quantitative. En premier lieu, la taille
de la signalisation reste marginale en comparaison avec les debits des flux vidéos. Une
petite augmentation de celle-ci ne porte donc pas atteinte aux performances globales
du système. De plus, le choix d’un multiplexage statistique des paquets permet de ga-
gner en ressources et ainsi de minimiser l’impact du changement de signalisation. L’ap-
proche SigComp de compression de signalisation peut également être utilisée [102]. Par
ailleurs, comme le montre l’exemple d’un message SDP en comparaison avec les tables
SI, certains mécanismes inutiles hérités du standard MPEG2 peuvent être simplifiés par
l’approche en couches choisie. On peut dire globalement que la charge de signalisation
doit être similaire, voire meilleure si on optimise certains mécanismes.

Services utilisateur : L’utilisateur ne doit pas voir de différence entre le changements

de programmes dans un flux MPEG2-TS et le changement de programmes entre des
flux multicast IP. Le mécanisme reste le même : une récupération du flux demandé par
le terminal, un envoi au client de télévision et un décodage. D’autre part, la qualité de
visionnage doit aussi être similaire si l’ordonnancement est bien choisi, garantissant une
bonne synchronisation du récepteur.
On peut conclure brièvement que les performances pures du système de IPTV
68 CHAPITRE 3. SOLUTION MPLS : CAS UNIDIRECTIONNEL

peuvent concurrencer un service de télévision classique dédié. Au delà des perfor-

mances, le but essentiel était de montrer qu’il est possible de créer ce service de té-
lévision sans trop de heurts sur la qualité du service. En revanche, la relative complexité
protocolaire des différentes couches ajoutées est un faible prix au regarde des nom-
breuses perspectives d’évolution qu’offre un tel système convergent.

3.3 Conclusion
Dans cette partie, nous venons de décrire une architecture de convergence satel-
lite IP/MPLS en nous concentrant sur le service historique de télévision. Nous avons
proposé une modification de l’implantation du service de télévision par satellite pour le
rendre plus général et plus évolutif. De plus, en dépit de l’ajout de couches d’abstraction,
nous avons montré que le service de télévision est parfaitement viable. Le travail montre
ainsi qu’il est fonctionnellement possible de créer un service de télévision convergent
sur satellite. Il apparaît que le système décrit conduit à un overhead légèrement plus
important en raison de la plus grande généricité du système obtenu. De la même façon,
la surcharge de la signalisation est un peu plus élevée en raison de l’ajout d’un certain
nombre de fonctionnalités qui trouveront toute leur utilité quand il s’agira d’ajouter de
nouveaux services. En outre, des techniques de compression d’en-tête et d’autres op-
timisations liées par exemple à l’ordonnancement peuvent être mises en place à peu
de frais permettant d’obtenir des performances similaires aux solutions existantes dans
un contexte beaucoup plus général. Ce service de télévision peut donc être conservé
comme service de base de l’évolution du satellite : le maintien de son fonctionnement
dans un environnement réseau plus général est réellement important. Les intérêts de
cette approche se voient dans ses perspectives.
Tout d’abord, dans le présent chapitre, cette architecture a été intentionnellement
limitée à la voie aller du satellite, ce qui limite grandement l’interactivité et le nombre
de services possibles. Avec l’avènement d’une voie retour opérationnelle, il est possible
d’aller plus loin et l’architecture décrite prend plus de sens.
De la même façon, l’évolution des satellites transparents vers des satellites régéné-
ratifs avec intelligence embarquée (OBP) révèle la souplesse de l’architecture MPLS. Il
est possible d’appliquer les principes de GMPLS et de la commutation à plusieurs ni-
veaux entre des faisceaux, des fréquences, des espaces de temps,. . . Il est ainsi possible
de commuter plus facilement des communications unicast vers le bon faisceau, la bonne
fréquence en gagnant des ressources.
C’est ce que nous allons montrer dans les chapitres suivants.
Chapitre 4

MPLS comme solution de convergence

satellite : cas bidirectionnel

4.1 Télévision sur IP/MPLS par satellite bidirectionnel . . . . . . . . . . . 70

4.1.1 Problématiques liées à la voie retour . . . . . . . . . . . . . . . 70
4.1.1.1 Organisation système . . . . . . . . . . . . . . . . . 71
4.1.1.2 Organisation protocolaire issue de DVB-RCS . . . . 72
Approche conservatrice de DVB-RCS : . . . . . . . . . 73
Approche d’intégration avec IP/MPLS : . . . . . . . . . 73
4.1.2 Architecture IP/MPLS bidirectionnelle . . . . . . . . . . . . . 77
4.1.2.1 Couches de communications satellites . . . . . . . . 77
4.1.2.2 Couches IP/MPLS . . . . . . . . . . . . . . . . . . . 79
4.1.2.3 Service de télévision bidirectionnel . . . . . . . . . . 80
Vote orienté fournisseur : . . . . . . . . . . . . . . . . . 80
Vote orienté Terminal : . . . . . . . . . . . . . . . . . . 81
4.1.3 Problématiques de l’architecture choisie . . . . . . . . . . . . . 82
4.1.3.1 Adressage . . . . . . . . . . . . . . . . . . . . . . . 83
Identifiants IP/MPLS/GSE . . . . . . . . . . . . . . . . 83
Identifiants DVB-RCS . . . . . . . . . . . . . . . . . . 83
4.1.3.2 Résolution d’adresse . . . . . . . . . . . . . . . . . . 84
4.1.3.3 Accès à la signalisation de la voie aller . . . . . . . . 84
4.1.3.4 Migration de la signalisation . . . . . . . . . . . . . 85
4.1.3.5 Synchronisation . . . . . . . . . . . . . . . . . . . . 86
4.1.3.6 Sécurité et Confidentialité . . . . . . . . . . . . . . . 86
4.1.3.7 Compatibilité unidirectionnelle/bidirectionnelle . . . 88
4.2 Multi-services sur une architecture IP/MPLS satellite bidirectionnelle . 88
4.2.1 Architecture satellite IP/MPLS triple play . . . . . . . . . . . . 89
4.2.2 Service de Téléphonie . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

69
70 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

Les réseaux satellites ont été standardisés par le groupe DVB en se focalisant sur le
service de télévision. Dans un contexte de convergence de services, une nouvelle archi-
tecture satellite doit être construite de façon moins dédiée à la télévision mais conser-
ver ce service avec une qualité et des fonctionnalités équivalentes. Il est donc impor-
tant de commencer par étudier l’évolution de ce service particulier dans une approche
de convergence par satellite. Le chapitre précédent a étudié un exemple d’architecture
convergente sur un satellite géostationnaire, transparent et unidirectionnel. Le but était
de montrer la faisabilité d’un service de télévision avec notre architecture.
À partir de l’architecture déjà décrite, dans ce chapitre, nous allons étudier main-
tenant un système de télévision en ajoutant une interactivité à l’aide d’une voie retour
satellite. On se retrouve ainsi dans le contexte d’un service de télévision interactif sur
une architecture satellite IP/MPLS bidirectionnelle. Le satellite reste géostationnaire et
transparent.
Ensuite, dans ce même contexte, l’intégration d’autres services sur cette architecture
est discutée mettant en valeur l’utilité de l’approche convergente MPLS.

4.1 Service de télévision interactif par satellite bidirec-

tionnel sur une architecture IP/MPLS convergente
Dans ce scénario, nous nous proposons donc de nous focaliser sur un service de té-
lévision interactif fondé sur une voie retour. Une voie retour terrestre est envisageable
grâce au mécanisme UDLR utilisé dans de nombreux réseaux [25, 103]. Ce mécanisme
repose sur un tunnel au travers d’un réseau terrestre pour envoyer les paquets IP vers la
gateway. Nous considérons dans ce travail uniquement le cas d’une voie retour satellite,
avec comme objectif la possibilité de services “triple play” tout satellite. Cette voie re-
tour de communication par satellite est donc décrite par le standard DVB-RCS sur lequel
il paraît normal de s’appuyer (voir chapitre 1). La première partie montre les probléma-
tiques système et protocolaire liées à l’adjonction de cette voie retour et propose des
solutions. Une deuxième partie s’attache ensuite à décrire un exemple d’architecture bi-
directionnelle pour la télévision par satellite. Les différents niveaux de communication
de l’accès aux services sont décrits. Ensuite, les principales problématiques apparaissant
dans ce contexte sont détaillées et différentes solutions sont proposées à chaque fois.

4.1.1 Problématiques liées à la voie retour

L’ajout d’une voie retour satellite de type DVB-RCS à un système de télévision de
type DVB-S ou DVB-S2 pose tout d’abord des problèmes d’organisation du système.
Ensuite, l’évolution protocolaire faite sur la voie aller dans le travail précédent implique
des évolutions protocolaires sur le DVB-RCS que nous nous devons d’étudier.
4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 71

4.1.1.1 Organisation système

F IG . 4.1 – Organisation système du satellite bidirectionnel envisagé

Tout d’abord, pour faciliter l’étude, nous considérons un seul satellite géostation-
naire transparent gérant les voies aller et la voie retour. Les deux sens de communica-
tion pourraient être décorrélés sur deux satellites sans changer le fonctionnement. Une
passerelle satellite diffuse en TDMA vers de nombreux terminaux (RCST) sur plusieurs
fréquences. Ces RCST se partagent en MF-TDMA une ressource temporelle et fréquen-
tielle unique pour communiquer en retour vers la passerelle.
Comme le montre la figure 4.1, un terminal reçoit donc sur une fréquence particu-
lière une signalisation lui permettant de faire fonctionner sa voie retour en termes de
synchronisation et d’accès. Il doit donc rester synchronisé sur cette fréquence “freq3”.
Dans un système convergent, le terminal va potentiellement potentiellement consulter
sur une autre fréquence “freq1” un programme “prog1” de télévision, sous l’injonction
d’un utilisateur. Ce changement de programmes va donc obliger à consulter deux fré-
quences en même temps : celle du programme demandé et celle de la signalisation de la
voie retour. Le choix système de la configuration physique sur laquelle notre architec-
ture se fonde est donc un problème important.
Plusieurs solutions peuvent être envisagées :
– Une première solution consiste à se focaliser sur un seul système de réception
ou “tuner” ce qui paraît le plus simple et le moins cher. Dans ce cas, lors d’une
requête de l’utilisateur pour regarder un programme télévisé situé sur une autre
fréquence de réception, il faut transférer les communications existantes ainsi que
la signalisation pour la voie retour sur cette nouvelle fréquence. Le temps de chan-
72 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

gement de programme peut être très grand et le délai engendré sur les autres ser-
vices également. Une importante signalisation va de même devoir être déployée
pour gérer ce passage. La signalisation de voie retour devra en effet être envoyée
sur toutes les fréquences ce qui peut surcharger inutilement le système. Elle peut
aussi être émise suite à la requête de l’utilisateur. Cette solution engendre une
complexité et un temps de passage d’un programme à l’autre important. On ne la
retiendra pas pour notre architecture.
– Une autre solution consiste à avoir deux systèmes de réception. De nombreux
systèmes existants ont déjà un double système pour lire un programme et en en-
registrer un autre en même temps. La présence d’un second tuner peut donc être
utilisée pour recevoir de la signalisation simultanément à un programme. Dans ce
cas, un changement de programme se passe plus rapidement car un système de
réception peut par exemple s’occuper du service de télévision tandis que l’autre
peut continuer à recevoir d’autres données, la signalisation de voie retour et des
données utilisateurs. Cette solution semble la plus intéressante dans notre cas mal-
gré son coût plus élevé. En revanche, dans une approche de convergence, il serait
dommage de dédier complètement une fréquence à la signalisation. Il faut garder
la possibilité de pouvoir transférer sur une même fréquence la signalisation de
voie retour, des programmes de télévision et potentiellement des données utilisa-
teurs.
– Une dernière possibilité est d’avoir un multiplexe temporel TDMA de réception
assez important pour contenir tous les programmes et tous les services, de sorte
que les récepteurs n’aient pas besoin de changer de fréquence de réception. Le
filtrage se ferait par l’allocation de slots temporels aux différents services ou par
des tags. Cette solution est envisageable et simplifierait l’accès mais elle nécessite
des contraintes technologiques différentes sur le satellite et les récepteurs. Nous
ne considérons pas cette approche non plus, bien qu’elle soit plus simple sur le
papier. Si la technologie évolue, cette solution pourra être facilement adoptée.

4.1.1.2 Organisation protocolaire issue de DVB-RCS

DVB-RCS est le standard décrivant le fonctionnement d’une voie de communica-
tion retour par satellite entre les terminaux des clients et une passerelle d’opérateur. Il
semble logique de s’appuyer sur cette norme pour notre architecture de voie retour. Le
fonctionnement de DVB-RCS est décrit dans le chapitre 1. Certains arguments nous
poussent néanmoins à faire évoluer son fonctionnement dans le cadre de notre objectif
de convergence.
L’architecture sur la voie aller du chapitre précédent repose sur une encapsulation
GSE sur DVB-S2 et se démarque de MPEG2. La signalisation de la voie aller qui mélan-
geait la signalisation du réseau et la signalisation du service télévision a été réorganisée.
Sur le lien DVB-RCS, la signalisation repose sur un mécanisme MPEG2-TS quand l’ar-
4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 73

chitecture voulue s’en affranchit. Il apparaît de plus qu’une partie de la signalisation

est bien liée au fonctionnement physique du satellite alors qu’une partie est liée à la
réservation de ressources ce qui peut faire double emploi avec un mécanisme RSVP. Le
choix de migration de cette signalisation doit donc être étudié plus avant.
De plus, en considérant l’approche MPLS, certaines fonctions et couches de com-
munication deviennent redondantes. La complexité de certains mécanismes de DVB-
RCS et de sa signalisation peuvent aussi être revus pour une meilleure compréhension
et évolutivité d’un système convergent.
Deux possibilités sont alors envisageables pour la construction d’une architecture
de voie retour satellite au vu des problèmes évoqués. Nous décrivons tout d’abord une
approche conservatrice de DVB-RCS, puis une approche d’intégration avec IP/MPLS.

Approche conservatrice de DVB-RCS : L’approche la plus directe consiste à se re-

poser sur une approche DVB-RCS existante en modifiant son fonctionnement. Dans ce
cas, il faut faire évoluer la signalisation de la voie retour qui est véhiculée sur la voie
aller. Comme le montre la figure 4.2, les mécanismes de synchronisation de la voie
retour du terminal sont très proches du fonctionnement de DVB-RCS. La différence
majeure consiste à déplacer la signalisation DVB-RCS de la voie aller au-dessus de la
couche de convergence MPLS car il est logique que cette signalisation de voie retour
soit indépendante de l’accès de la voie aller.
Au niveau de la localisation du service de signalisation de voie retour, on utilise le
même mécanisme que dans le standard DVB-RCS grâce aux tables NIT, PAT et PMT.
Une fois la signalisation retour repositionnée sur la voie aller, les mécanismes DVB-
RCS se déroulent à l’identique, sauf l’allocation d’un “labelRCST” au terminal en lieu
et place d’un champ VPI/VCI. En effet, l’encapsulation du trafic se fait selon MPLS sur
ATM et le champ VPI/VCI d’ATM transporte donc un label sur la voie retour.
Cette méthode a le mérite de garder la compatibilité avec l’existant et de ne pas avoir
à remodeler entièrement le fonctionnement de la voie retour. Néanmoins, elle fait perdre
les avantages de l’approche MPLS car deux types de signalisation vont devoir cohabiter
et le système est entravé par des fonctionnements qui nuisent à son évolutivité.

Approche d’intégration avec IP/MPLS : Cette nouvelle approche garde le principe

de séparation des couches mis en place dans l’approche compatible grâce à l’architec-
ture MPLS. Elle va néanmoins plus loin néanmoins en revoyant le fonctionnement de
DVB-RCS dans une approche d’intégration avec les protocoles IP/MPLS existants.
Tout d’abord, le but est d’unifier autour d’IP et de MPLS le fonctionnement de la
signalisation et de se passer totalement de MPEG2-TS. Au niveau de la voie aller, le
tableau 4.2 montre la fonction des différentes tables et leur correspondance possible au-
dessus d’IP. On propose un exemple d’évolution de l’allocation des ressources (table
TBTP) un peu plus loin. L’objectif est de conserver les mêmes mécanismes que les
74 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

F IG . 4.2 – Approche conservatrice de DVB-RCS

tables SI existantes mais en se détachant de l’approche MPEG2-TS. Pour la signalisation

4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 75

F IG . 4.3 – Approche d’intégration avec IP/MPLS

76 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

sur la voie retour, on garde naturellement les mécanismes de signalisation au-dessus de

la voie retour (champ CSC, SYNC).

Forward Link Signalling (FLS) Correspondance

Nom Fonction Niveau Protocole
SCT (Superframe Composition indique l’organisation en physique IP_SCT
Table) supertrames et trames de tout le
réseau retour
FCT (Frame Composition indique le partitionnement des physique IP_FCT
Table) trames en slots temporels
TCT (Time-slot Composition indique les paramètres de chaque physique IP_TCT
Table) slot temporel
SPT (Satellite Position Table) contient des informations physique IP_SPT
d’éphémeride de correction des
bursts
CMT (Correction Message indique aux RCST des physique IP_CMT
Table) corrections physiques à effectuer
TBTP (Terminal Burst Time alloue les slots temporels aux accès IP_TBTP
Plan) RCST
TIM (Terminal Information contient des messages de gestion IP_TIM
Message) configuration
PCR Insertion TS Packet - NCR donne une horloge de référence physique IP_NCR
(Network Clock Reference) pour la synchronisation retour

TAB . 4.2 – Correspondance des tables SI pour la voie retour

D’autre part, au niveau de la localisation du service de signalisation de voie retour,

on utilise le mécanisme décrit dans le chapitre précédent pour trouver la fréquence d’un
programme fondé sur SNMP et RSVP. La localisation se fait donc maintenant grâce à
un label “labelSigRCS” sur une fréquence “freqFLS”.
Enfin, le protocole BOOTP (Bootstrap Protocol) est utilisé pour se connecter au
réseau en lieu et place de la requête de connexion dans le slot CSC [104]. Des évolutions
telles que DHCP (Dynamic Host Configuration Protocol) peuvent être envisagées [105].
Les différentes étapes de synchronisation sont décrites ci-après et illustrées par la
figure 4.3 :
1. Procédure initiale de synchronisation : Après la synchronisation de la voie aller,
la recherche du service de voie retour se fait par une fréquence GMPLS, un label
et une adresse IP multicast. Ensuite, le terminal peut recevoir sur ce label et cette
adresse IP la nouvelle signalisation de voie retour. Grâce à cette signalisation,
le terminal peut se synchroniser, récupérer différentes informations de gestion,
calculer la position du satellite et recevoir le plan de communication. Les étapes
sont les mêmes mais la signalisation est maintenant indépendante de la couche
accès de la voie aller.
2. Procédure de connexion : Au lieu du mécanisme classique de connexion de
4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 77

DVB-RCS, les bursts CSC servent à envoyer en Aloha [106] une requête du proto-
cole BOOTP. La gateway renvoie l’adresse IP du RCST et son masque, l’adresse
IP de la gateway et le label du RCST équivalent au VPI/VCI. On ajoute aussi des
informations sur le besoin de synchronisation physique grossière et fine.
3. Procédures de synchronisation : Les mécanismes sont conservés en l’état en
utilisant la nouvelle signalisation sur la voie aller pour la correction de la syn-
chronisation (IP_CMT).
4. Procédure d’allocation de ressources : Le mécanisme DAMA est conservé mais
le plan d’allocation de type TBTP se fait par un mécanisme au-dessus d’IP orienté
label et non plus par logon_id.
Cette approche permet une intégration plus simple dans un réseau hétérogène et rend
la gestion indépendante des technologies satellite. Le mécanisme pourrait être déployé
sur d’autres types réseaux dans le cadre d’une gestion unifiée.
Nous choisissons de développer la dernière approche bien que cela casse la compa-
tibilité avec les systèmes existants. L’approche est plus convergente avec d’autres types
de réseaux et permet d’évoluer vers une gestion unique.
Nous nous reposons donc sur une voie aller avec double système de réception et sur
l’approche d’intégration de DVB-RCS pour décrire une architecture satellite de com-
munication bidirectionnelle dans la partie suivante. Nous proposons enfin des solutions
détaillées pour différents problèmes à traiter.

4.1.2 Architecture IP/MPLS bidirectionnelle

Pour décrire cette architecture bidirectionnelle pour un service de télévision interac-
tif, on repart de la même architecture que celle du chapitre précédent. Comme le montre
la figure 4.4, un fournisseur de contenus envoie des programmes à un gestionnaire de
télévision qui s’occupe de diffuser les programmes dans le réseau satellite via une ga-
teway vers les RCSTs des utilisateurs. Nous nous contentons de montrer les différences
par rapport au cas unidirectionnel. La première différence est donc l’ajout d’un lien re-
tour, en pointillé sur la figure. De plus, une hypothèse importante est l’utilisation de deux
systèmes de réception pour chaque terminal comme justifié dans la partie précédente.
Nous allons décrire chaque couche de communication globalement en nous foca-
lisant sur les changements liés à l’ajout de la voie retour. Tout d’abord, nous traitons
le fonctionnement des couches satellites de bas niveau, puis nous nous penchons sur
les couches de convergence IP et MPLS et enfin sur le service de télévision interactif
lui-même. Certains détails seront repris dans la partie suivante.

4.1.2.1 Couches de communications satellites

La topologie que nous avons considérée étant en étoile et donc dans un mode asy-
métrique, nous séparons la présentation des communications sur les deux voies : la voie
78 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

F IG . 4.4 – Architecture du service de télévision sur une liaison satellite bidirectionnelle

4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 79

aller de la gateway aux terminaux et la voie retour des terminaux à la gateway.

Voie aller : L’architecture physique de la voie aller est décrite dans le chapitre 3 et
repose sur GSE et DVB-S2 pour le plan de données. Des messages RSVP et
SNMP remplacent la signalisation réseau de la voie aller (par exemple la table
NIT). Comme nous considérons deux systèmes de réception, nous avons deux
couches DVB-S2 agrégées dans un niveau GSE unique. On considère alors une
seule adresse MAC par terminal. Le niveau de filtrage du RCST peut donc se faire
sur les fréquences (label GMPLS), l’adresse MAC dans GSE ou l’adresse IP. La
voie aller transporte la signalisation nécessaire au bon fonctionnement de la voie
retour.
D’autre part, l’ajout de la voie retour permet au terminal de renvoyer des informa-
tions d’état du canal à la gateway qui peut adapter en conséquence les paramètres
de la couche DVB-S2 en fonction des conditions de réception (mode ACM).
Voie Retour : Le fonctionnement de la voie retour choisie est l’approche intégrée à
IP/MPLS. La signalisation est donc modifiée en s’orientant vers un mécanisme
semblable à SNMP au dessus d’IP. La connexion n’utilise plus de logon_id et
group_id mais des labels et des adresses IP à la place. L’attribution de la ressource
se fait selon les labels. Au niveau du plan de données, l’encapsulation se fait par
AAL5 et ATM comme dans la norme DVB-RCS. La différence est l’utilisation
du champ VPI/VCI comme label. Cette couche gère la segmentation et réassem-
blage des cellules ATM. En outre, il n’y a pas d’encapsulation multi-protocole sur
ATM : on choisit un seul protocole par label [107].

4.1.2.2 Couches IP/MPLS

On se retrouve maintenant avec deux voies aller permettant de faire passer du trafic
en broadcast et en unicast (adresse MAC dans GSE) de la gateway vers les terminaux et
une voie retour permettant à ces terminaux d’envoyer du trafic unicast vers la gateway.
MPLS et IP sont donc utilisés dans un environnement de communication bidirection-
nelle plus classique.
MPLS : En voie retour et en voie aller, des labels étiquettent les communications pour
les associer à des chemins virtuels (LSP) auxquels différentes caractéristiques
peuvent être adjointes. Par exemple, le label a été utilisé dans le service de télévi-
sion unidirectionnel pour séparer les différents canaux de télévision. On en garde
le principe. Pour la voie retour, le premier label représente le terminal en lui-même
et permet à la gateway de séparer les flux des terminaux et donc de réassembler
les paquets d’après les cellules ATM. On peut associer plusieurs labels à un même
terminal. Ce premier niveau de label est géré par une table MPLS_TBTP rema-
niée (voir partie suivante et table 4.4). On peut aussi utiliser un autre niveau de
label et une signalisation RSVP-TE pour séparer différents types de trafic suivant
80 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

leurs propriétés bien que cela augmente l’overhead. A chaque LSP, on peut par
exemple associer une qualité de service. Dans notre cas, la voie retour ne servira
qu’en mode best effort et un seul niveau de label suffira donc par conséquent.
IP : Le protocole de l’Internet est désormais pleinement utilisé avec la voie retour.
Pour le fonctionnement de la communication dans les deux sens, la pile IP doit
être configurée avec une adresse IP qui est récupérée à la connexion du termi-
nal (BOOTP). Une fois la pile IP fonctionnelle, il est possible de l’utiliser pour
tout type de trafic. Les différentes signalisations IP peuvent maintenant être utili-
sées normalement en mode bidirectionnel. Néanmoins, certaines optimisations
peuvent être faites dans cette topologie en étoile pour les messages IGMP et
RSVP.

4.1.2.3 Service de télévision bidirectionnel

Le service de télévision repose sur le même fonctionnement que précédemment avec
une signalisation SDP/SAP pour les informations sur les programmes, eux mêmes trans-
portés par RTP/UDP sur IP.
Désormais, il est possible de réfléchir à l’évolution interactive du service de base
passif grâce à ce lien retour. L’adjonction de l’interactivité dans un service de télévision
constitue une dimension importante dans le contexte de la démocratisation d’Internet,
des blogs et des podcasts. De plus en plus de personnes ont l’habitude de commenter, de
critiquer ce qu’ils voient donc d’interagir avec un service. Offrir un tel service optionnel
est donc un plus. L’interactivité ne consiste pas seulement à ajouter des informations au
flux de programmes comme pour des applications telles que le téletexte ou les guides
de programmes électroniques (EPG) qui n’ont pas besoin de voie retour. L’interacti-
vité peut amener à un échange de messages entre l’utilisateur final et le fournisseur de
contenus en vue d’un enrichissement du service de télévision.
Comme exemple, nous décrivons un service de vote électronique sur un programme.
Nous tâchons de garder une compatibilité entre un mode unidirectionnel et bidirection-
nel. Les figures 4.5 et 4.6 montrent deux tramages possibles des envois pour ce service.

Vote orienté fournisseur : Comme le montre la figure 4.5, un utilisateur regardant sur
sa télévision un programme particulier peut appuyer sur un bouton de sa télécommande,
ce qui génère un envoi d’une requête HTTP depuis un client de télévision (interne ou
externe au terminal) au fournisseur directement. Ce fournisseur peut ensuite traiter cette
requête de façon adaptée et stocker ou utiliser des informations d’une base de données.
Il renvoie une réponse adaptée au client de télévision. Cette réponse peut être superposée
au flux vidéo émis sur la télévision.
A partir de cette séquence, on peut décliner un service de vote comme suit :
– l’utilisateur appuie d’abord sur sa télécommande pour voir un menu (requête
HTTP) ;
4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 81

F IG . 4.5 – Exemple de déroulement d’un service de télévision interactif orienté fournis-

seur

– le serveur du fournisseur lui renvoie le menu général qui se superpose au pro-

gramme courant (réponse HTTP) ;
– l’utilisateur demande maintenant le service de vote sur le programme en cours
(requête HTTP) ;
– le serveur répond avec la page de vote ;
– l’utilisateur vote pour un des choix possibles ;
– le serveur enregistre ce vote dans ses bases et renvoie un message de confirma-
tion ;
Cette méthode mélangeant la télévision et le web a le mérite d’être très flexible et
permet tout type de services de la même façon que sur le web. Le problème qui subsiste
est le délai inhérent au satellite qui va rendre la navigation lente. Il est possible que pour
certains services cela n’incommode pas trop l’utilisateur qui pourra attendre en regar-
dant la télévision mais dans le cas de votes multiples et rapides, le mécanisme ne sera
sûrement pas assez réactif. Un autre mécanisme orienté terminal est décrit maintenant.

Vote orienté Terminal : Comme le montre la figure 4.6, un mécanisme orienté ter-
minal est également envisageable. Un utilisateur regardant sa télévision va maintenant
interagir uniquement avec son terminal local faisant office de serveur HTTP. Le terminal
dialoguera ensuite avec le fournisseur pour envoyer des informations en post-traitement.
Le service de vote peut alors se décliner de la façon suivante :
– l’utilisateur demande un menu général avec sa télécommande ;
– une requête HTTP est envoyée par le client de télévision au terminal ;
– la réponse HTTP est donnée par le terminal qui connaît déjà cette requête clas-
sique (on peut envisager la présence d’un cache) ;
– l’utilisateur demande maintenant le service de vote relatif au programme en
cours ;
82 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

F IG . 4.6 – Exemple de déroulement d’un service de télévision interactif orienté terminal

– le terminal lui renvoie une page d’attente s’il n’a pas la page souhaitée et effectue
une requête auprès du fournisseur pour l’obtenir. On pourrait également envisager
que le terminal reçoive intégralement le service de vote et l’exécute localement
(applet, script, ... ) ;
– Une fois l’information récupérée depuis le fournisseur, le terminal renvoie au
client la bonne information.
– L’utilisateur peut maintenant voter, le terminal envoie une confirmation de vote et
fait suivre cette requête de vote en post-traitement vers le fournisseur ;
Ce mécanisme est très réactif contrairement au précédent et l’utilisateur obtient alors
un confort de navigation accrue. En revanche, ce système induit une dépendance vis
à vis du terminal, ce qui nécessite d’être lié au diffuseur pour le faire fonctionner. Ce
système est moins flexible et moins indépendant du réseau sous-jacent. Sa mise en place
est en outre plus complexe. Un fonctionnement hybride suivant les services peut aussi
être envisagé.

4.1.3 Problématiques de l’architecture choisie

Nous allons maintenant détailler les points clés liés à l’architecture convergente
IP/MPLS retenue. Nous ne nous attachons qu’à l’approche d’intégration IP/MPLS non
conservatrice. Parmi ces points difficiles, nous pouvons citer :
– l’adressage ;
– la résolution d’adresse ;
– le mécanisme d’accès à la signalisation de la voie aller ;
– la migration de la signalisation avec l’exemple de l’allocation de ressources
(TBTP) ;
– la synchronisation ;
– la sécurité ;
4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 83

– la compatibilité unidirectionnelle bidirectionnelle ;

4.1.3.1 Adressage
L’adressage est modifié avec l’approche IP/MPLS sur GSE pour la voie aller et
IP/MPLS sur ATM pour la voie retour. Certains identifiants d’adressage deviennent re-
dondants et il convient de faire un tri en vue d’une migration de la signalisation. Nous
décrivons tout d’abord les identifiants IP/MPLS/GSE qui sont maintenant à la base de
la transmission et du filtrage et ensuite les identifiants utilisés dans DVB-RCS avec leur
utilité et leur possible modification.

Identifiants IP/MPLS/GSE
– adresse MAC (48 bits) : L’adresse MAC est utilisée pour identifier les RCSTs en
voie aller. Elle peut aussi servir dans notre cas à identifier un groupe restreint de
RCSTs en multicast.
– label MPLS (20 bits) : le label MPLS est utilisé comme un identifiant générique
de tunnel. Il encapsule les paquets sur la voie aller et sur la voie retour. On peut
aussi empiler les labels pour hiérarchiser la communication.
– adresse IP (32 bits) : l’adresse IP identifie le terminal de bout en bout d’un réseau
de façon indépendante du satellite.
– port UDP (16 bits) : le port UDP (source et destination) représente un service
générique au dessus d’IP.

Identifiants DVB-RCS
– population_id (16 bits) : Il identifie le terminal satellite RCST avant le démarrage
et permet de trouver l’identifiant de réseau interactif (interactive_network_id) as-
socié au terminal. Il peut être remplacé par l’adresse MAC en changeant le mé-
canisme de recherche de signalisation de la voie aller mais induit un overhead
important. Un label du même type peut être utilisé le cas échéant.
– interactive_network_id (16 bits) : Cet identifiant permet d’organiser en plusieurs
réseaux d’interaction les RCSTs. Ce mécanisme peut être associé à un label.
– superframe_id (8 bits) : Il désigne une supertrame fréquentielle et temporel au
niveau physique. Il est conservé en l’état mais peut être associé à un label GMPLS.
– frame_id (8 bits) : Il désigne une trame fréquentielle et temporelle physique. Il
est aussi conservé en l’état mais peut être associé à un label GMPLS.
– timeslot_id (8 bits) : Il désigne un intervalle temporel physique. Le traitement est
le même que pour les précédents.
– satellite_id (8 bits) : Il désigne un satellite en particulier, une adresse MAC ou
une adresse IP pourra être utilisée.
– NCC_id (8 bits) : Il représente l’identifiant d’un NCC, une adresse IP pourra le
remplacer.
84 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

– gateway_id (8 bits) : Il représente l’identifiant d’une passerelle. Une adresse IP

pourra aussi le remplacer.
– route_id (16 bits) : Cet identifiant est utilisé dans un système et repère la route
destination de descente du satellite. Un label peut avantageusement remplacer cet
identifiant.
– logon_id (16 bits) : Il identifie le terminal et il est associé à la connexion. On
n’utilise plus cet identifiant qui est remplacé par l’adresse MAC pour l’adressage
du terminal et par un label pour le mécanisme d’allocation TBTP.
– group_id (8 bits) : Il permet d’adresser un ensemble de terminaux. Cette fonction
n’est plus utilisée non plus. Elle est remplacée par des groupes multicast aux
niveaux MAC et IP.
– channel_id (4 bits) : Cet identifiant permet de créer des canaux virtuels séparés
depuis un terminal. Il est remplacé par les labels MPLS.
L’approche plus générique IP/MPLS peut donc permettre de simplifier les nombreux
identifiants utilisés dans DVB-RCS.

4.1.3.2 Résolution d’adresse

Un des problèmes apparaissant est la résolution d’adresse entre les adresses IP et le
niveau MAC sur la gateway. En effet, certains trafics sont unicast entre la gateway et
chaque terminal. Il faut donc un mécanisme pour que la passerelle connaisse l’adresse
MAC du destinataire. Le mécanisme le plus simple est une table statique. Comme la
gateway attribue aussi les adresses, elle peut facilement connaître les adresses MAC de
tous les RCST. Néanmoins, différents mécanismes sont commentés dans la RFC 4947
[108]. Au niveau de la voie retour, il n’y aura pas de problème car les communications
sont forcément dirigées sur la gateway et aucun mécanisme d’adressage n’est nécessaire.

4.1.3.3 Accès à la signalisation de la voie aller

Le mécanisme d’accès à la signalisation de la voie aller se fait sans voie retour,
puisque cette dernière est optionnelle. Le mécanisme se découpe en 3 phases et on
donne une méthode “orientée label” pour le mettre en œuvre :
– Au début, un terminal est synchronisé avec n’importe quel transpondeur. Sur tous
les transpondeurs, un message en diffusion donne la fréquence aller où l’on peut
trouver une première signalisation générale de voie retour suivant un identifiant du
terminal. Ces messages peuvent être envoyés par un mécanisme au dessus d’UDP
(SNMP, RSVP) qui indique maintenant la fréquence, le label et l’adresse IP de la
signalisation de voie retour générale.
– Une fois que l’on est positionné sur la nouvelle fréquence, on peut trouver la liste
des identifiants des terminaux et leur réseau de voie retour associé par le même
type de message au dessus d’UDP. Les identifiants des terminaux peuvent être
4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 85

les adresses MAC ou un label associé à chaque terminal physique (équivalent

population_id). Le réseau de voie retour peut être identifié par une fréquence aller
de signalisation retour (label GMPLS) et un label particulier au-dessus.
– Le terminal peut maintenant obtenir sur cette dernière fréquence de signalisation,
les différentes informations pour faire fonctionner la voie retour : horloge, tra-
mage MF-TDMA, position du satellite.

4.1.3.4 Migration de la signalisation

La signalisation nécessaire au fonctionnement de la voie retour DVB-RCS se dé-
coupe en deux parties : celle sur la voie retour et celle sur la voie aller. Nous regardons
pour ces deux parties les modifications possibles.
La signalisation sur la voie retour se trouve encapsulée dans différents bursts spéci-
fiques : CSC, SYNC, ACQ. Il convient de séparer dans cette signalisation les différentes
fonctions. Les bursts SYNC et ACQ sont conservés à l’identique pour la synchronisa-
tion physique de la communication. Le burst CSC permet une demande de connexion
à la passerelle. Ce mécanisme peut être remplacé par le protocole réseau plus classique
BOOTP. Enfin, un champ SAC dans le burst SYNC permet de faire des demandes de
ressources et est conservé. Il pourra être complémentaire d’un mécanisme de réservation
de ressources de bout en bout tel que celui de RSVP.
La deuxième partie de la signalisation DVB-RCS est constituée par des tables SI
spécifiques sur la voie aller. Le mécanisme d’accès à cette signalisation DVB-RCS de la
voie aller repose d’ailleurs aussi sur les mécanismes d’indirection entre les tables SI (cf.
point précédent pour la migration de ce mécanisme). L’ensemble de ces tables est réper-
torié dans le tableau 4.2 avec le niveau protocolaire et les correspondances à construire.
Il est important de modifier cette signalisation pour atteindre une indépendance avec le
fonctionnement de la voie aller donc au dessus d’IP. On pourra ainsi faire évoluer les
couches de bas niveau de la voie aller sans remettre en cause le fonctionnement de la
voie retour. D’autre part, la migration de l’adressage permet de simplifier le contenu de
ces tables.
Pour la migration de ces tables, plusieurs solutions sont possibles. Une utilisation
du protocole SNMP serait par exemple un bon choix. Nous décrivons un exemple de
modification des différentes informations d’une TBTP classique vers une IP_TBTP. Cet
exercice pourrait être appliqué à toutes les tables de façon similaire. La table 4.4 donne
donc un exemple de migration de cette table TBTP dans la nouvelle approche. Tous les
en-têtes issus de MPEG2-TS sont enlevés car des mécanismes similaires existent dans
les protocoles sous-jacents. On garde uniquement un numéro de version de la signali-
sation IP_TBTP. On conserve évidemment aussi la fonction de la table qui consiste à
associer des blocs de slots de capacité retour aux terminaux. La différence ici est que
l’on n’alloue plus les slots à un logon_id, un group_id ou un channel_id mais unique-
ment à un label qui peut représenter tout cela suivant son utilisation. On n’associe plus
86 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

directement des ressources à un terminal, à un groupe ou à un canal mais à des labels

uniquement. La séparation entre les canaux, les terminaux, les réseaux interactifs se fait
avec le mécanisme de label.

4.1.3.5 Synchronisation

Le mécanisme de synchronisation de la voie retour est important. La synchronisation

est faite avec une précision de l’ordre de la nanoseconde. Cela nécessite un mécanisme
très fin en voie aller.
Dans l’approche DVB-S et DVB-RCS classique, la synchronisation de la voie retour
est donnée par le NCC via la PCR (Program Clock Reference) existant dans MPEG2-
TS. On appelle cette horloge la NCR (Network Clock Reference).
Dans une approche DVB-S2 en voie aller, la voie descendante n’est pas aussi ré-
gulière qu’avec DVB-S. Les paquets MPEG2-TS sont potentiellement gigués avec des
BBFRAMEs de tailles différentes et l’horloge est à son tour giguée. Un mécanisme
de correction décrit dans la norme DVB-S2 permet de calculer cette gigue et de faire
fonctionner la synchronisation.
Le plus simple dans une approche d’indépendance des couches serait d’avoir un
mécanisme de synchronisation de voie retour de type NTP (Network Time Protocol)
[109]. La précision de NTP ne semble pas suffisante pour la voie retour. NTP n’a pas
été conçu pour le réseau satellite avec des délais de propagation importants. Il faudrait
trouver un mécanisme au dessus d’IP répondant à cette précision.
Une autre façon est de reprendre le même mécanisme que la NCR existante au des-
sus de MPLS en s’assurant que ce canal MPLS soit le moins gigué possible au niveau
de la gateway en lui associant une qualité de service adéquate. Il faudrait dans ce cas
étudier si on peut avoir une précision identique que les mécanismes existants.

4.1.3.6 Sécurité et Confidentialité

Même si ce travail ne se concentre pas sur la sécurité, ce point est important dans tout
réseau d’opérateur. La diffusion sur la voie aller engendre des contraintes de sécurité
importantes car tous les terminaux ont potentiellement accès à toutes les informations
émises sur le support. L’ensemble des protocoles et mécanismes mis en œuvre devront
être revus à travers ce prisme.
Parmi les points importants, on peut citer la confidentialité des données et notam-
ment le cryptage des programmes. Comme indiqué dans le chapitre précédent, cette
confidentialité des programmes peut être créée à différents niveaux protocolaires : ac-
cès, réseau, service. L’ajout d’une voie retour permet de créer une protection par clef
publique et clef privée plus efficace et de renouveler ces clefs régulièrement (méca-
nismes IPsec par exemple).
4.1. TÉLÉVISION SUR IP/MPLS PAR SATELLITE BIDIRECTIONNEL 87

DVB-RCS TBTP MPLS_TBTP

Syntax bits Fonction Correspon- Syntax bits
dance
Termi-
nal_burst_time_plan(){ IP_Terminal_burst_time_plan(){
table_id 8 identifiant de la table port UDP X
section_syntax_indicator 1 doit être à "1" X X
reserved_for_future_use 1 X X X
reserved 2 X X X
section_length 12 nombre de bits de la longueur X
section UDP
interactive_network_id 16 identifiant de réseau label MPLS X 16
retour
reserved 2 X X X
version_number 5 numéro de version de la IP_TBTP version_number 5
table
current_next_indicator 1 applicabilité courante ou X X
future
section_number 8 numéro de section IP X
last_section_number 8 dernier numéro de section IP X
Group_ID 8 identifiant de service de adresse X
groupe multicast
Superframe_count 16 identifiant de superframe IP_TBTP Superframe_count 16
frame_loop_count 5+3 nombre de trames IP_TBTP frame_loop_count 5+3
applicables
for for
(i=0 ;i<=frame_loop_count ;i++) (i=0 ;i<=frame_loop_count ;i++)
{ {
frame_number 5+3 numéro de trame dans la IP_TBTP frame_number 5+3
supertrame
BTP_loop_count 11+5 nombre de bloc de slots IP_TBTP BTP_loop_count 11+5
alloués
for (j=0 ;j<= for (j=0 ;j<=
BTP_loop_count ;j++){ BTP_loop_count ;j++){
Logon_ID 16 identifiant du terminal IP_TBTP la- 20
belRCST+labelChannelID
Multiple_channels_flag 1 indique la présence d’un X X
channel_ID
Assignment_type 2 nature de l’assignement IP_TBTP Assignment_type 2
de slot
1 état de la file NCC IP_TBTP 1
VBDC_queue_empty_flag VBDC_queue_empty_flag
Start_slot 11+1 numéro du slot de départ IP_TBTP Start_slot 11+1
If
(Multiple_channels_flag )
Channel_ID 4+4 numéro de canal supérieur X X
Assignment_count} 8 nombre de slots alloués IP_TBTP Assignment_count} 8
} }
CRC_32 32 valeur du CRC UDP CRC32 X
} }
148 68

TAB . 4.4 – Évolution de la table TBTP

88 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

4.1.3.7 Compatibilité unidirectionnelle/bidirectionnelle

La plupart des systèmes de télévision par satellite existants fonctionnent en mode
unidirectionnel et continueront de fonctionner dans ce mode. Il convient donc d’avoir
des fonctionnements compatibles avec les deux modes : un réseau de terminaux sa-
tellites unidirectionnels et bidirectionnels doit pouvoir être constitué avec une même
gestion. Les services proposés ne seront évidemment pas les mêmes. Dans un des cas,
le service de télévision sera classique et dans l’autre, il pourra être interactif.
Pour la consultation des programmes en eux-mêmes, on conserve le même fonc-
tionnement pour les deux types de terminaux. Les terminaux bidirectionnels peuvent
en plus faire fonctionner la voie retour en consultant la signalisation nécessaire et avoir
accès à des services interactifs télévisuels associés aux différents programmes. Ces ser-
vices ajoutés peuvent interagir sur le programme de télévision classique ou ajouter une
surcouche au programme uniquement pour les terminaux interactifs. Par exemple, un
service de vote en ligne peut avoir une incidence sur l’affichage d’un programme de
tous les terminaux tandis qu’un service de messagerie instantanée sur un programme va
sûrement avoir uniquement un impact sur les terminaux bidirectionnels.
Au niveau de l’architecture réseau, la compatibilité en mode unidirectionnel et bidi-
rectionnel peut également se poser. En effet, le protocole RSVP-TE devra par exemple
fonctionner dans les deux cas. Le protocole devra peut être évoluer pour prendre en
compte ce mode unidirectionnel. De même, le protocole IGMP devra fonctionner dans
les deux modes. A partir de ce mode en diffusion sur la voie aller et de cette topolo-
gie en étoile centrée sur la gateway, il apparaît de plus que ces protocoles n’ont pas
toujours besoin d’utiliser la voie retour. Au niveau du fonctionnement et de l’adres-
sage, il ne semble pas intéressant par exemple que les programmes soient demandés via
IGMP sur la voie retour par le terminal dans la mesure où ils sont diffusés en broad-
cast contrairement à l’ADSL. En outre, le temps de changement de programmes serait
plus important. Au niveau de la synchronisation et de la qualité de service du service,
les terminaux peuvent aussi rester en mode passif. L’architecture réseau peut donc être
optimisée grâce à cette topologie particulière.

4.2 Multi-services sur une architecture IP/MPLS satel-

lite bidirectionnelle
L’architecture IP/MPLS décrite pour le services de télévision a pour objectif princi-
pal de simplifier le développement d’offres “triple play”. Cette partie cherche à montrer
cette facilité fonctionnelle d’intégration de nouveaux services grâce à cette architecture.
Dans cette partie, nous revenons tout d’abord rapidement sur l’architecture globale
IP/MPLS “triple play”. Nous avons choisi d’illustrer son fonctionnement au travers du
service de téléphonie (VoIP).
4.2. MULTI-SERVICES SUR UNE ARCHITECTURE IP/MPLS SATELLITE BIDIRECTIONNELLE89

Nous décrivons ensuite seulement l’exemple de la voix sur IP (VoIP) et son intégra-
tion sur ce type d’architecture. En effet, le service de télévision a déjà été étudié et un
accès au réseau mondial Internet ne pose pas de véritables problèmes d’intégration vue
l’architecture choisie.

4.2.1 Architecture satellite IP/MPLS triple play

Le système étudié prend comme précédemment le cas d’un réseau d’accès satellite
de type GEO transparent bidirectionnel. Les couches de communication de proche en
proche sont donc issues des standards DVB. Comme expliqué dans les paragraphes pré-
cédents, nous considérons également pour chaque terminal deux voies aller en diffusion
reposant sur le standard DVB-S ou DVB-S2 avec les mécanismes d’encapsulation MPE
ou ULE sur MPEG2-TS pour DVB-S et GSE pour DVB-S2. Une voie retour utilise le
standard DVB-RCS avec l’encapsulation AAL/ATM.
Ces couches de communication d’accès dépendantes du satellite sont abstraites par
une couche MPLS. MPLS permet de gérer le réseau satellite de la même manière que
le reste des réseaux terrestres. Un chemin LSP de bout en bout d’un gestionnaire de
service aux terminaux satellites pourra être réservé et géré avec la même signalisation
de type RSVP-TE. L’adressage IP sert pour la mise en place du chemin et repose sur des
tables de routage mises à jour par des protocoles de routage unicast et multicast. MPLS
complète ainsi les possibilités réseau du protocole IP.
Le protocole IP sert enfin comme interface commune aux services qui auront ainsi
une base commune de fonctionnement. Comme le montre la figure 4.7, les différents
gestionnaires de services peuvent accéder de la même manière au réseau de distribution
générique vers les terminaux des utilisateurs.
Cette figure illustre l’intégration de différents services avec l’architecture IP/MPLS
choisie. Un terminal a la possibilité d’accéder à un service “triple play” vidéo, voix,
données via le même accès satellite. On se retrouve avec trois groupes bien séparés par
l’architecture :
les fournisseurs de services qui proposent des prestations de manière uniforme sans
s’occuper de problématiques réseaux ;
les réseaux d’interconnexion qui relient les fournisseurs de services aux utilisateurs.
On peut séparer les cœurs de réseau MPLS et les réseaux d’accès ; dans notre cas,
le réseau d’accès des utilisateurs est le réseau satellite. Néanmoins, les services
pourraient être distribués de la même façon sur un réseau d’accès terrestre de type
ADSL par exemple.
les utilisateurs des services qui accèdent par le même médium à de nombreux services
intégrés.
Les différents services “triple play” sont le service de télévision, le service d’accès
Internet ainsi qu’un service de téléphonie. Le service de télévision est largement décrit
90 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

F IG . 4.7 – Intégration de nouveaux services sur une architecture IP/MPLS

4.2. MULTI-SERVICES SUR UNE ARCHITECTURE IP/MPLS SATELLITE BIDIRECTIONNELLE91

dans les chapitres précédents. Le service d’accès Internet peut être mis en place sans
véritables problèmes, les choix d’implantation dépendront de l’opérateur. Le trafic In-
ternet peut par exemple suivre un LSP permanent entre les terminaux et les passerelles
d’accès au service. Enfin, nous décrivons un service de voix sur IP comme exemple de
service supplémentaire plus complexe. En plus de ces services classiques, il est possible
de mettre en place facilement un service d’interconnexion de réseaux d’entreprises se
servant des tunnels MPLS (exemple VPLS). Une implantation de ce type de services
dépendra également de l’opérateur.

4.2.2 Service de Téléphonie

F IG . 4.8 – Session SIP de communication téléphonique VoIP

92 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL

Vue l’architecture, on considère un système de voix sur IP (VoIP) pour gérer le

service de téléphonie. Un gestionnaire de téléphonie s’occupe de ce service et les ter-
minaux satellites s’y connectent via le réseau MPLS générique. On pourrait répartir le
gestionnaire sur plusieurs plates-formes pour un passage à l’échelle. Il sert de serveur
de base de données “registrar” pour le service de téléphonie. Il a également le rôle de
passerelle vers un réseau RTC ou GSM. Enfin, c’est un proxy SIP pour les terminaux.
On considère que le téléphone est directement relié aux terminaux qui jouent le rôle de
client SIP avec une adresse IP publique. On ne considère pas les cas de NAT (Network
Address Translation) et la gestion de plusieurs téléphones dans un réseau client.
Nous décrivons donc le fonctionnement d’une session de VoIP comme le montre
la figure 4.8. Lorqu’un terminal de VoIP A veut communiquer avec un autre, il utilise
l’URI du destinataire et génère une requête de connexion (message INVITE). Le des-
tinataire doit s’être au préalable enregistrer (REGISTER) au gestionnaire. Le terminal
VoIP interroge le gestionnaire via un chemin LSP de signalisation dédiée ou de façon
routée directement. Le gestionnaire proxy SIP trouve le destinataire dans sa base de don-
nées de registrar et peut alors relayer le message INVITE vers l’adresse IP liée à l’URI
récupérée. Le proxy indique qu’il essaye de se connecter (100 Trying) au terminal A.
De même, le terminal renvoie l’état du processus de connexion : tout d’abord l’état d’es-
sai (100 Trying) puis lorsque le téléphone B sonne (180 Ringing). Lorsque l’utilisateur
décroche, un message de confirmation de connexion est envoyée (200 Ok) par le proxy.
Le terminal A renvoie alors un acquittement (ACK) via le proxy également. En paral-
lèle, un mécanisme de réservation RSVP-TE est enclenché par les terminaux LER A et
B. A la confirmation, un LSP est donc créé entre les deux correspondants qui peuvent
l’utiliser pour communiquer. Les terminaux SIP pourront par exemple limiter le nombre
de connexions simultanées.
De nombreuses améliorations ou optimisations sont possibles pour développer une
réelle offre de téléphonie sans modifier le réseau physique satellite. Au niveau des per-
formances, les caractéristiques du lien satellite comme le délai important nécessitent de
bien régler l’allocation des ressources, la stratégie de qualité de service ou le codage de
la voix [110]. D’autre part, une approche d’intégration de la téléphonie avec d’autres
services de type IMS pourrait être envisageable.
L’intérêt de l’approche MPLS est de généraliser la notion de tunnel pour l’ensemble
des services. Le déploiement de la voie sur IP est ainsi simplifié et peut être déployé de
bout en bout de réseaux hétérogènes sans difficultés.

4.3 Conclusion
Ce chapitre se concentre tout d’abord sur l’ajout d’une interactivité à un service
de télévision par une voie retour DVB-RCS. Il analyse les problèmes d’intégration de
cette voie retour dans l’approche IP/MPLS choisie. La possibilité d’intégration d’autres
4.3. CONCLUSION 93

services sur cette architecture est ensuite décrite, avec notamment l’exemple de la télé-
phonie.
Cette facilité à intégrer de nouveaux services montre l’utilité d’une structure pro-
tocolaire telle que celle proposée. En effet, les réseaux satellites ont des difficultés à
percer et à concurrencer des offres ADSL en partie en raison de leur organisation histo-
rique orientée vers la télévision. Remettre une base architecturale plus générale et plus
évolutive en séparant bien les différentes fonctions réseaux et services peut permettre
de redonner du souffle au réseaux satellite. Le monde des réseaux de communication
évoluant rapidement, la capacité d’adaptation et la flexibilité d’une architecture sont des
atouts essentiels.
Le chapitre suivant se propose d’appliquer le principe de l’architecture IP/MPLS au
projet industriel ULISS de satellite régénératif hybride. L’objectif est de confronter notre
approche à d’autres topologies de réseaux, notamment dans le cas de réseaux maillés,
ainsi qu’à un contexte industriel.
94 CHAPITRE 4. SOLUTION MPLS : CAS BIDIRECTIONNEL
Chapitre 5

Application au projet ULISS

5.1 Le projet ULISS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.1.1 Organisation générale . . . . . . . . . . . . . . . . . . . . . . 98
5.1.2 Etapes de fonctionnement . . . . . . . . . . . . . . . . . . . . 100
5.2 Convergence IP/MPLS dans ULISS . . . . . . . . . . . . . . . . . . . 103
5.2.1 Approche par encapsulation . . . . . . . . . . . . . . . . . . . 103
5.2.2 Approche compatible DVB . . . . . . . . . . . . . . . . . . . . 104
5.2.3 Approche d’intégration avec les protocoles IP/MPLS . . . . . . 108
5.3 Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . . . . 110

95
96 CHAPITRE 5. APPLICATION AU PROJET ULISS

Les travaux précédents ont développé une architecture de convergence IP/MPLS ap-
pliquée à un système de télécommunications par satellite transparent. Dans un premier
temps, les études portaient sur l’intégration fonctionnelle et architecturale de la télévi-
sion de type IPTV sur un canal satellite unidirectionnel. Les impacts d’une voie retour
ont ensuite été étudiés de la même manière. Dans cette dernière partie de thèse, nous
allons nous focaliser sur un contexte système plus précis : celui du projet ULISS (ULtra
fast Internet Satellite Switching) qui utilise un satellite hybride mêlant une approche ré-
générative et transparente. Le projet ULISS définit notamment une nouvelle architecture
de communication permettant le transfert direct de paquets entre terminaux. La topolo-
gie est donc maillée : les terminaux sont en point à point et communiquent directement
en un seul bond. Les services d’une telle architecture sont donc différents que dans un
mode diffusion d’une architecture classique transparente. Typiquement, ULISS pourra
servir à interconnecter plusieurs réseaux entre eux, comme des réseaux privés d’entre-
prise (VPN). Nous allons donc tout d’abord présenter le fonctionnement du système
ULISS et son architecture. Ensuite, nous présenterons l’application de notre démarche
vers une convergence IP/MPLS et nous en étudierons les impacts sur le système.

F IG . 5.1 – Vue d’ensemble du projet ULISS [111]

5.1. LE PROJET ULISS 97

5.1 Le projet ULISS

ULISS est un projet commun entre l’ESA1 , Thales Alenia Space, le DLR2 , Alcatel-
Lucent, le Lyrtech et TeSA [111]. La figure 5.1 montre une vue d’ensemble du projet.
Le but de ce projet est de préparer les futures charges utiles satellite pour des services
multimédias entre terminaux en bande Ka. Pour cela, quatre objectifs sont fixés :
– définir un scénario d’un système satellite (100 spots et plus de 20GHz de largeur
de bande commutées) ;
– démontrer la faisabilité du commutateur embarqué et des technologies associées ;
– implanter le concept de commutation par bursts RBS (Radio Burst Switching) ;
– valider les performances dans un environnement DVB-RCS existant.
La nouveauté du système réside dans le concept de commutation par burst RBS
issu du mécanisme OBS (Optical Burst Switching) des réseaux optiques qui permet
de réduire le calcul à bord [112]. Le principe réside dans l’envoi en avance des en-
têtes des paquets pour configurer la commutation de ces derniers (cf figure 5.2). Le
commutateur hybride a ainsi une partie régénérative minimale analysant les en-têtes et
configurant la partie transparente. Les performances générales du commutateur peuvent
être ainsi augmentées sensiblement avec un impact limité sur le coût du système. Grâce
à cette technique et à l’évolution de la puissance des processeurs actuels, l’architecture
d’ULISS permet des communications ATM ou MPEG2 sans passer par une gateway et
ce sur de nombreux spots avec de très larges bandes [113, 114, 115, 116].

F IG . 5.2 – Principe du Radio Burst Switching dans le projet ULISS

Dans ce projet, nous nous intéressons plus particulièrement à l’architecture de com-

munication définie autour de ce commutateur hybride. Nous regardons tout d’abord l’or-
1
European Space Agency
2
Deutsches zentrum für Luft- und Raumfahrt
98 CHAPITRE 5. APPLICATION AU PROJET ULISS

ganisation générale de cette architecture ; nous décrivons ensuite les différentes étapes
de fonctionnement.

5.1.1 Organisation générale

F IG . 5.3 – Organisation générale du système ULISS

Le fonctionnement général du projet ULISS est issu des standards DVB-S et DVB-
RCS. En revanche, l’architecture ULISS est maintenant organisée autour d’une charge
utile hybride, modifiant le fonctionnement classique sur les voies aller et retour. La
principale nouveauté est donc le RBS, permettant d’alléger le fonctionnement de la
charge utile. La figure 5.3 montre les différents éléments du réseau et les différentes
voies de communications qui sont détaillées ci-après.
Eléments du réseau :
Satellite : Le satellite joue le rôle de commutateur temporel hybride RBS. Il est consti-
tué d’une partie transparente avec une grille de commutation temporelle configu-
rée via une partie régénérative gérant la signalisation. Chaque intervalle de temps
sur une fréquence donnée est ainsi orienté dynamiquement vers un autre couple
temps-fréquence sur un spot descendant particulier. Des redirections multicast
vers plusieurs destinations sont aussi possibles.
BCC (Beam Control Centre) : Les fonctions du NCC de DVB-RCS sont maintenant
réparties dans des BCCs dans une architecture distribuée. Ce fonctionnement ré-
pond en effet plus facilement à des problématiques de passage à l’échelle de la
5.1. LE PROJET ULISS 99

signalisation. Un BCC se partage avec le satellite toute la signalisation de contrôle

et de gestion d’un spot. Une caractéristique importante est qu’il se trouve dans le
même spot de descente que les terminaux qu’il gère. En effet, la signalisation
descendante du satellite vers le BCC et vers les terminaux est regroupée dans un
même canal.
SNC (Satellite Network Controller) : Le contrôleur du réseau s’occupe de la gestion
centrale du satellite. Il est relié par des liaisons terrestres dédiées aux différents
BCCs. Les BCC lui délèguent certaines requêtes des terminaux. Il determine de
nombreux éléments du réseau comme la taille de la supertrame ou des intervalles
de temps MF-TDMA. Il configure aussi la table de label et le commutateur à bord
du satellite. La réservation des labels passe donc par lui via le BCC.
Terminal : C’est l’élément d’accès au système satellite chez l’utilisateur. En plus des
capacités de reception DVB-S et d’émission DVB-RCS classiques, il reçoit des
trames DVB-RCS provenant directement d’autres terminaux.
Nous décrivons maintenant chaque voie de communication dont les couches proto-
colaires sont reproduites dans le tableau 5.4.
Voies de communications :
TDL (Transport Data Link) : Ce canal transporte les données utilisateur et intercon-
necte directement les terminaux à travers le satellite. Les bursts de données émis
par les terminaux sont aiguillés vers le bon destinataire grâce à des en-têtes BHP
(Burst Header Packet) émis en avance sur une porteuse de signalisation montante
ULS (voir plus loin). Un burst de données peut contenir 2 trames MPEG2-TS ou 7
cellules ATM. De plus, un BHP particulier est reservé pour la communication de
contrôle avec le BCC du spot reposant sur le protocole C2P (Connection Control
Protocol) [32]. Cette signalisation vers le BCC utilise le mécanisme DULM (Data
Unit Labelling Method) issu du standard DVB-RCS pour s’affranchir du choix
entre MPEG2 et ATM (cf chapitre 1). Cette signalisation de plus haut niveau se
trouve donc dans le canal TDL car elle est indépendante de l’accès DVB.
FLS (Forward Link Signaling) : Cette signalisation peut être émise sur des fré-
quences particulières ou non depuis le gestionnaire du spot BCC vers les ter-
minaux. Elle peut être transmise en mode DVB-S pur sur des fréquences dédiées
connues des terminaux ou via un canal de données avec un BHP réservé à cette
signalisation. Elle contient la plupart des tables DVB permettant le fonctionne-
ment DVB-S et DVB-RCS (NIT, PAT, PMT, RMT, SPT, TCT, FCT, SCT, TBTP,
TIM), à l’exception de la signalisation de synchronisation (CMT, NCR) directe-
ment émise par le satellite via la signalisation sur le lien descendant (DLS).
ULS (Up Link Signaling) : Cette voie correspond à la signalisation montante des ter-
minaux vers le satellite. Quelques fréquences lui sont réservées de façon adjacente
aux canaux de données (TDL). En effet, les BHP permettant au satellite de mettre
100 CHAPITRE 5. APPLICATION AU PROJET ULISS

en place sa trame de commutation sont émis sur ce lien. Les différents bursts de
contrôle de la voie retour DVB-RCS (CSC, SYNC) sont aussi transmis sur ce lien
vers la partie contrôle du satellite.
DLS (Down Link Signaling) : Ce lien transporte toute la signalisation du satellite vers
les éléments au sol. Les entités de contrôle du satellite engendrent des informa-
tions de synchronisation vers les terminaux (NCR, table CMT), renvoient les BHP
associés au tramage de descente et agrègent dans des tables CSCT et SACT la si-
gnalisation CSC et SAC émise par les terminaux vers le BCC associé.
Observons maintenant le fonctionnement du système étape par étape.

5.1.2 Etapes de fonctionnement

Pour mieux comprendre pas à pas le fonctionnement du système ULISS, nous dé-
crivons chaque étape depuis la mise en route d’un terminal jusqu’à sa transmission de
paquets vers un terminal situé dans un autre spot. Le séquencement de ces diverses
étapes est résumé par la figure 5.4. Nous nous intéressons ici exclusivement au plan de
contrôle et les messages sont donc échangés entre le terminal et le BCC. Le fonctionne-
ment est proche de celui de DVB-RCS mais diffère par la place régénérative du satellite
et par la gestion des BHP.
Procédure de synchronisation initiale : A l’image du fonctionnement de DVB-RCS,
un terminal se connectant au réseau doit tout d’abord se synchroniser en récep-
tion sur une fréquence par défaut. Sur cette fréquence, un mécanisme d’indirec-
tion permet de trouver la fréquence de la signalisation FLS au travers des tables
NIT, PAT, PMT, RMT à partir des identifiants de configuration par défaut du ter-
minal (population_id). En plus de ce mécanisme classique DVB, la fréquence de
la signalisation DLS est déduite de celle de la signalisation FLS. Si ce n’est pas
possible, un mécanisme d’indirection à partir des tables DVB doit être mis en
place. Grâce à ces deux voies de communication, la synchronisation de l’émis-
sion du terminal peut être mise en place. L’horloge NCR est directement envoyée
par le satellite pour la synchronisation temporelle. Les tables TCT, FCT, SCT,
TBTP donnent le plan MF-TDMA temporel et fréquentiel des bursts (BTP) sur
la voie retour. La table SPT donne le positionnement du satellite pour corriger la
synchronisation.
Procédure de connexion : Pour se connecter au système ULISS, le terminal envoie à
la partie contrôle du satellite un burst classique CSC avec ses paramètres. Le sa-
tellite agrège toutes les requêtes du spot dans une table CSCT pour les transmettre
sur un flux descendant de signalisation (DLS) vers le BCC du spot. Le satellite
renvoie au terminal une confirmation de réception du burst, l’accès étant en Slot-
ted Aloha et donc avec des collisions potentielles. Le BCC renvoie sur la signali-
sation de voie retour (FLS) un message TIM unicast d’acceptation de connexion
5.1. LE PROJET ULISS 101

avec les identifiants et les informations de connexion : logon_id, group_id, em-

placements des bursts SYNC, PID ou VPI/VCI de transmission et un label BHP
de signalisation vers le BCC.
Procédure de synchronisation fine : L’horloge NCR étant directement gérée par le
satellite, la procédure de synchronisation complémentaire devient plus simple :
seule une procédure de synchronisation fine est conservée par rapport à DVB-
RCS. Le burst ACQ n’est donc plus utilisé. La procédure de synchronisation fine
est mise en œuvre grâce à un burst SYNC envoyé au satellite auquel ce dernier
répond avec une table CMT dans la signalisation du lien descendant DLS. Cette
procédure de correction fine est activée régulièrement au cours de la connexion
pour garantir la qualité de l’émission. Dans ce burst, en plus des informations
temporelles de synchronisation, un champ SAC de requête de ressources peut être
“piggybacké”.
Procédure de requête de label : Le terminal est maintenant synchronisé et reconnu
par le réseau. Lorsqu’il veut communiquer avec un autre terminal dans un autre
spot, il faut qu’il demande une valeur de label BHP représentant cette direction.
Ce mécanisme se fait dans le canal de signalisation DULM sur le canal de don-
nées (TDL) avec le label BHP reçu dans la procédure de connexion ; le protocole
C2P est donc utilisé. Le terminal envoie donc une requête de label au BCC qui le
transmet au gestionnaire du satellite (SNC). Ce dernier vérifie si une connexion
est possible et alloue des labels pour la communication. Il transmet ensuite la re-
quête au terminal destinataire qui accepte la connexion et sauvegarde les labels
d’émission et de réception. Ce terminal destinataire renvoie la confirmation C2P
au premier terminal via son BCC et le SNC. Le premier terminal se met à jour
avec ces labels contenus dans la réponse et peut maintenant transmettre directe-
ment vers le terminal destinataire via la partie transparente du satellite.
Procédure d’allocation de ressources : Avant de pouvoir transmettre sur la voie TDL
des données dans des bursts de trafic TRF, il faut demander des ressources grâce
au champ SAC dans le burst SYNC. La table TBTP renvoie le plan d’allocation
des bursts de données en fonction des logon_id des terminaux. Une fois des bursts
TRF réservés, il suffit d’y transmettre les informations utilisateurs ainsi qu’un en-
tête de burst BHP contenant le label correspondant sur la voie ULS associée.
Ce fonctionnement reprend donc largement les bases des systèmes DVB mais per-
met déjà quelques évolutions :
– le principe de séparation des fonctions de synchronisation bas niveau vers le sa-
tellite repris des systèmes régénératifs DVB.
– une indépendance du fonctionnement à l’intérieur du plan de données qui ne ma-
nipule que des slots temporels grâce au mécanisme RBS.
– un début de simplification des fonctionnements (disparation de la macro-
synchronisation).
102 CHAPITRE 5. APPLICATION AU PROJET ULISS

F IG . 5.4 – Etapes de fonctionnement d’ULISS

– la communication directe entre terminaux avec un fonctionnement hybride grâce

au RBS.
– la dissémination des fonctions de gestion de réseaux dans une architecture plus
distribuée (BCC, SNC).
Le système reste encore dans un fonctionnement DVB qui rend difficile une intégra-
tion forte avec d’autres types de réseaux. De la même façon, la découpe fonctionnelle
et son implantation rend le système beaucoup trop dépendant de l’architecture satellite
5.2. CONVERGENCE IP/MPLS DANS ULISS 103

sous-jacente. La question de la convergence d’un tel système pose le problème de son

évolution vers d’autres fonctionnements. Dans une démarche cohérente avec celle déjà
adoptée dans les chapitres précédents, nous allons maintenant proposer des évolutions
possibles vers une architecture IP/MPLS.

5.2 Convergence IP/MPLS dans ULISS

La problématique est ici aussi la convergence des réseaux avec l’ensemble des en-
jeux associés : virtualisation, simplicité, topologie distribuée, intéropérabilité,QoS, ges-
tion, sécurité. Les bénéfices majeurs sont surtout une intégration plus simple et efficace
des services et l’évolutivité du système par la séparation des fonctions (cf chapitre 2).
Le choix de l’architecture IP/MPLS repose sur les mêmes arguments que dans les
chapitres précédents. En outre, le label utilisé pour décrire une destination dans ULISS
est en parfaite adéquation avec l’approche MPLS. Cette propriété n’est pas surprenante
dans la mesure où l’approche RBS est issue de l’approche OBS des réseaux optiques.
Cela confirme l’intérêt d’utiliser MPLS en conjonction avec IP afin de profiter de la
complémentarité de leurs fonctionnalités. L’approche connectée des tunnels LSP MPLS
s’applique très bien aux tunnels dans ULISS ; MPLS prend ainsi tout son sens dans ce
contexte.
Dans une démarche incrémentale, on peut dégager plusieurs approches d’évolution
convergente de l’architecture ULISS vers IP et MPLS. Tout d’abord, nous décrivons ra-
pidement l’approche d’intégration par encapsulation la plus simple. Ensuite, nous sui-
vons une approche compatible conservant les mécanismes existants mais en séparant
les différentes couches. La dernière partie propose une approche d’intégration avec les
protocoles IP/MPLS s’attachant moins à une compatibilité avec le contexte DVB.

5.2.1 Approche par encapsulation

La première approche d’intégration de l’architecture IP/MPLS dans ULISS consiste
à utiliser le système ULISS de façon transparente comme un réseau overlay. Le système
ULISS serait alors considéré comme la couche accès encapsulant une couche réseau IP
sur MPLS. Les services pourraient être ainsi déployés sur IP. Dans ce cas, sur le plan de
données, on aurait une pile IP/MPLS/ATM/DVB-ULISS. Sur le plan de la signalisation,
des connexions RSVP de haut niveau devront se traduire au niveau du réseau satellite
par une connexion C2P et des allocations de ressources par le champ SAC, dupliquant
les mécanismes.
Cette approche a le mérite d’être complètement indépendante du système satellite et
permet d’intégrer deux architectures sans les modifier. C’est l’approche typique qu’uti-
liserait un opérateur terrestre utilisant le réseau satellite car il ne s’encombrerait pas à
rédéfinir les fonctionnements d’ULISS. Dans notre cas, cette approche ne résout rien
104 CHAPITRE 5. APPLICATION AU PROJET ULISS

car elle duplique les systèmes et ne permet aucune intégration des mécanismes proto-
colaires. L’évolution des protocoles DVB n’est en effet pas remise en cause dans cette
approche, que l’on ne peut pas qualifier de véritable convergence. Nous n’étudions donc
pas plus longuement cette approche, dont le principal intérêt est de poser le premier ja-
lon de la logique d’intégration de deux architectures.

5.2.2 Approche compatible DVB

Une approche plus intéressante dans notre optique d’intégration est d’appliquer le
modèle de convergence IP/MPLS tout en gardant l’essentiel des mécanismes DVB. L’es-
sentiel est de séparer les différentes fonctions et les plans avec MPLS et IP. Dans le cas
du mécanisme RBS, nous séparons les bursts de trafic dans le plan de données de la
signalisation transportée dans les BHP comme cela est proposé dans les travaux sur les
architectures optiques OBS [117]. Néanmoins, les deux trafics sont liés par un déca-
lage temporel et on pourrait considérer le BHP comme un en-tête déporté sur la même
pile protocolaire. Nous reprenons les différentes voies de communication définies dans
ULISS en expliquant les changements (cf tableau 5.4) :

FLS : Le besoin de séparer la signalisation de l’accès induit ici une lourdeur de la pile
protocolaire. Deux cas différents doivent être étudiés :
– Si DVB-S est utilisé, MPLS devra être encapsulé avec les mécanismes MPE ou
ULE au dessus de MPEG2-TS. La pile protocolaire induite serait FLS/MPEG2-
TS/MPLS/MPE ou ULE/MPEG2-TS/DVB-S. Comme la signalisation FLS est
conservée à l’identique, il lui faut un flot MPEG2-TS. En virtualisant cette
signalisation, on obtient une couche MPEG2-TS utilisée pour la signalisation
et une couche pour l’accès. Pour le MPEG2-TS bas niveau, un PID par défaut
sera reservé pour la signalisation FLS ainsi qu’un label MPLS. MPE ou ULE
seront utilisés en broadcast.
– Si cette signalisation envoyée par le centre de contrôle BCC utilise le mé-
canisme RBS dans un fonctionnement DVB-RCS-ULISS, la pile protoco-
laire pourra être simplifiée. Dans ce cas, on aurait directement FLS/MPEG2-
TS/DVB-RCS-ULISS avec dans le plan ULS un envoi de label MPLS dans
les BHP. L’abstraction de la signalisation se fait par le choix du label MPLS.
Ce cas permet de simplifier la lourdeur protocolaire et unifie l’accès entre les
terminaux et le BCC.
TDL : Le mécanisme RBS permet déjà de séparer les couches. Le label contenu dans
les BHP peut être assimilé à un label MPLS. Pour chaque burst de trafic, on se
retrouve avec un premier niveau MPLS. Les bursts de données sont ensuite di-
ménsionnés pour transporter 7 cellules ATM ou 2 trames MPEG2. On se retrouve
donc avec deux cas :
5.2. CONVERGENCE IP/MPLS DANS ULISS 105

Système ULISS
Plan de données Plan de la signalisation
TDL Label Reservation FLS DLS ULS
Services C2P NIT, PAT, PMT, RMT, SPT,
SACT,
IP FCT, TCT, SCT, TBTP, BHP,
CSCT, NCR,
TIM CSC,
MPE/ULE AAL5 DULM CMT BHP
SYNC
MPEG2-TS ATM MPEG2-TS ATM MPEG2-TS MPEG2-TS
DVB-RCS-ULISS DVB-RCS-ULISS DVB-RCS- DVB-S DVB-RCS-ULISS DVB-RCS-
ULISS ULISS

Approche Compatible
Plan de données Plan de la signalisation
TDL Label Reservation FLS DLS ULS
Services RSVP NIT, PAT, PMT, RMT, SPT, SACT,CSCT,
FCT, TCT, SCT, TBTP, TIM CMT
MPLS-
IP MPEG2-TS MPEG2-TS NCR,
BHP,
MPLS-
MPLS CSC,
BHP
SYNC
MPE/ULE AAL5 MPE/ULE AAL5 MPE/ULE MPE/ULE
MPEG2-TS ATM MPEG2-TS ATM MPEG2-TS MPEG2-TS
DVB-RCS-ULISS-MPLS DVB-RCS-ULISS-MPLS DVB-RCS- DVB-S DVB-RCS-ULISS DVB-RCS-
ULISS ULISS

Approche d’intégration IP/MPLS

Plan de données Plan de la signalisation
TDL Label Reservation FLS DLS ULS
Services RSVP SNMP, RSVP, IP_SPT, IP_FCT, IP_SACT,
IP_TCT, IP_SCT, IP_TBTP, IP_CSCT, MPLS-
IP_TIM IP_CMT NCR, BHP,
IP MPLS- BOOTP
BHP CSC,
MPLS SYNC
MPE/ULE AAL5 MPE/ULE AAL5 MPE/ULE MPE/ULE
MPEG2-TS ATM-MPLS MPEG2-TS ATM MPEG2-TS MPEG2-TS
DVB-RCS-ULISS-MPLS DVB-RCS-ULISS-MPLS DVB-RCS- DVB-S DVB-RCS-ULISS DVB-RCS-
ULISS ULISS

TAB . 5.4 – Couches protocolaires du système ULISS et leurs évolutions

– Si MPEG2-TS est utilisé, le trafic IP/MPLS est encapsulé dans MPE ou ULE.
Comme une couche MPLS est déjà présente, le trafic IP pourrait être directe-
ment encapsulé dans MPE ou ULE. Un deuxième niveau MPLS est aussi pos-
sible grâce à l’empilement de label. Dans ce dernier cas, une pile protocolaire
serait donc Services/IP/MPLS/MPE ou ULE/MPEG2-TS/DVB-RCS-ULISS-
MPLS.
– Le fonctionnement est plus simple avec la couche ATM qui est plus adaptée.
En effet, le champ VPI/VCI peut être utilisé comme un deuxième label MPLS,
malgré un certain viol des couches dans ce cas. La couche AAL fait l’adapta-
tion avec IP. La pile résultante est Services/IP/AAL/ATM-MPLS/DVB-RCS-
ULISS-MPLS.

ULS : Cette voie de signalisation montante contient deux types de signalisation : les
BHP, en-têtes des bursts TRF et les bursts CSC et SYNC issus de la signalisation
106 CHAPITRE 5. APPLICATION AU PROJET ULISS

classique DVB-RCS. Les BHP sont considérés comme des en-têtes MPLS conte-
nant un label. Les bursts CSC et SYNC sont considérés comme de la signalisation
au niveau accès et n’ont donc pas vocation à être abstraits sur IP et MPLS.
DLS : Cette voie de signalisation descendante émise par le satellite peut être séparée
en deux types :
– Une partie de la signalisation est dépendante du temps et est donc très liée au
fonctionnement de l’accès. On trouve l’horloge NCR et les BHP. La commu-
nication dépend complètement de leur synchronisation et donc on ne modifie
par leur fonctionnement sur MPEG2-TS. Néanmoins, les en-têtes BHP sur la
signalisation DLS ne sont pas forcément utiles et pourraient être remplacés par
le deuxième niveau MPLS dans le plan de données.
– L’autre partie de la signalisation correspond à des tables générées ou agré-
gées à bord du satellite (SACT, CSCT, CMT). Cette signalisation n’est pas
dépendante de l’accès et doit être abstraite au dessus de MPLS comme pour
la FLS. La pile protocolaire résultante, forcément sur MPEG2-TS pour la
première signalisation, est SACT, CSCT, CMT/MPEG2-TS/MPLS/MPE ou
ULE/MPEG2-TS.
Nous nous intéressons maintenant aux étapes modifiées illustrées dans la figure 5.5.
Cette figure ne montre pas les diverses couches accès envisageables.
Procédure de synchronisation initiale : Le fonctionnement est similaire avec la si-
gnalisation abstraite au dessus de MPLS. Le NCR est conservé au niveau accès.
Des valeurs par défaut doivent être attribuées au label et au PID de MPEG2-TS.
Procédures de connexion, de synchronisation et d’allocation : De la même ma-
nière, cette approche compatible conserve les fonctionnements à l’identique en
rajoutant la couche MPLS d’abstraction quand il y en a la possibilité.
Procédure de requête de label : Le mécanisme de requête de label d’ULISS par pro-
tocole C2P est indépendant des couches d’accès par les fonctions DULM et RBS.
Il peut donc être changé sans impact sur l’architecture. Comme on réserve mainte-
nant des labels MPLS, cela est plus simple d’unifier la signalisation de réservation
de labels autour du protocole standard RSVP-TE.
Cette approche est une étape permettant :
– d’intégrer MPLS dans l’architecture ULISS ;
– de séparer la partie de la signalisation qui est indépendante de l’accès.
Dans cette approche, on conserve néanmoins des fonctionnements et des identifiants
issus des deux architectures qui font double emploi. La signalisation n’est donc pas en-
core homogène. L’étape suivante consiste donc à casser la compatibilité avec les méca-
nismes DVB et à harmoniser la signalisation avec l’approche IP/MPLS plus répandue
dans les réseaux terrestres.
5.2. CONVERGENCE IP/MPLS DANS ULISS 107

F IG . 5.5 – Etapes de fonctionnement pour l’approche compatible de convergence

108 CHAPITRE 5. APPLICATION AU PROJET ULISS

5.2.3 Approche d’intégration avec les protocoles IP/MPLS

En allant plus loin dans le processus de convergence, la compatibilité avec les mé-
canismes DVB existants ne sera pas conservée. En revanche, grâce à cette couche de
convergence, l’intégration dans un réseau plus global sera facilitée, de nouveaux ser-
vices pourront être déployés sans changer le fonctionnement des couches basses et cet
accès pourra être remodelé sans toucher aux services.
On remplace désormais les mécanismes DVB et MPEG2 par des mécanismes IP et
MPLS : le paradigme de la séparation des couches est conservé mais la signalisation
est déplacée. Certaines parties de la signalisation sont reprises au travers de protocoles
existants et d’autres parties doivent être redéfinies au dessus d’IP. On reprend l’ap-
proche développée dans le chapitre précédent pour la migration de la signalisation. Les
différentes voies de communication sont conservées comme dans l’approche compa-
tible. Le tableau 5.4 donne les différentes piles protocolaires. La différence majeure est
l’utilisation d’IP pour le transport de la signalisation.
Nous décrivons de nouveau les différentes étapes de fonctionnement :

Procédure de synchronisation initiale : Les fonctions nécessaires sont les mêmes

mais la signalisation est maintenant prise en charge par les protocoles SNMP
et RSVP-TE. Lorsqu’un terminal se connecte au réseau, il se synchronise sur sa
fréquence de départ et trouve la signalisation SNMP générale à partir du label
MPLS dédié “router alert”. Il trouve aussi des informations RSVP-TE concer-
nant l’association des labels et des fréquences. A partir de son adresse MAC et
d’autres informations de gestion, il trouve la signalisation de voie retour. Les an-
ciens identifiants de DVB sont remplacés par des labels ou par l’adresse MAC.
Les différentes tables sont appelés : IP_SPT, IP_TCT, IP_FCT, IP_SCT, IP_TIM,
IP_TBTP. Le mécanisme de synchronisation NCR est conservé à l’identique au
niveau physique.
Procédure de connexion : Le contenu des bursts CSC est maintenant modifié pour uti-
liser le protocole BOOTP. Une requête est envoyée avec l’adresse MAC du termi-
nal au BCC via le satellite. Le message de confirmation TIM unicast est supprimé
ainsi que le timer associé ; il pourrait être remplacé par un message IP_CMT de
synchronisation. Le BCC renvoie la réponse BOOTP avec la configuration IP
du terminal remplaçant les identifiants de connexion (logon_id, group_id). Des
options au fonctionnement classique de BOOTP peuvent être envisagées. Le la-
bel MPLS RBS permettant de communiquer directement avec le BCC peut par
exemple être inclus. Il pourrait être aussi ajouté dans la signalisation SNMP ou
avoir une valeur par défaut.
Procédure de synchronisation fine : La synchronisation reste identique à l’exception
de la table CMT implantée au dessus d’IP (IP_CMT).
5.2. CONVERGENCE IP/MPLS DANS ULISS 109

F IG . 5.6 – Approche de convergence avec les protocoles IP/MPLS

Procédure de requête de label : Cette fonction avait déjà été déplacée et utilise le pro-
tocole RSVP-TE en lieu et place de C2P.
Procédure d’allocation de ressources : La requête de ressources reste liée à l’accès
110 CHAPITRE 5. APPLICATION AU PROJET ULISS

à l’intérieur du burst SYNC. Sur la voie ULS, le champ SAC est conservé mais
modifié avec des identifiants IP. La partie contrôle du satellite agrège maintenant
les requêtes au dessus d’IP dans un mécanisme IP_SACT. Le plan d’allocation
des bursts est donné par la table IP_TBTP, migration de la table TBTP.
Cette approche permet d’aller plus loin dans la convergence en unifiant la signalisa-
tion dans une approche orientée vers IP et MPLS. Les anciens identifiants satellite ne
sont plus utilisés.

5.3 Conclusion et perspectives

Ce travail sur le projet ULISS donne un exemple industriel de l’application d’un
modèle de convergence à un système dédié satellite. Tous les intérêts de la convergence
en termes de réutilisabilité et de pérennité s’appliquent comme décrit dans le chapitre 2.
En termes de performance, la migration vers l’approche convergente décrite est rai-
sonnable dans le cas d’ULISS. En effet, l’overhead sur le plan de données est identique
dans la mesure où le label RBS est réutilisé. En revanche, il y a un overhead sur la si-
gnalisation dû à l’empilement de couches. L’importance de cette surcharge d’en-têtes
pour la signalisation peut être pondérée par les bénéfices induits par la convergence.
D’autre part, par rapport aux études précédentes avec un satellite transparent, nous
nous retrouvons avec un commutateur temporel embarqué qui change complètement la
topologie qui est alors maillée. Les services d’un tel système sont complètement diffé-
rents de la télévision en diffusion et s’orientent plus vers des communications point à
point entre terminaux comme de l’interconnexion de site par VPN ou de la vidéoconfé-
rence. Il paraît normal que dans cette optique le fonctionnement orienté télévision des
couches protocolaires satellites évoluent. L’utilisation de MPEG2-TS comme structure
de communication de base reste néanmoins difficilement contournable car il est la base
de nombreux fonctionnements d’ULISS.
Pour aller plus loin, il serait intéressant de confronter l’approche DVB-S2 en voie
retour au système ULISS. Cette approche pourrait être utilisée pour des transferts im-
portants entre deux terminaux avec un gain d’efficacité spectrale important. Il faudrait
dans ce cadre revoir le tramage de la couche physique fondé sur DVB-RCS, avec no-
tamment des problématiques autour de la synchronisation ou du partage des ressources
(BBFRAME).
Une autre perspective est l’intégration des différentes couches d’accès autour du
protocole GSE. La convergence des couches accès vers un modèle plus uniforme parait
intéressant ainsi que la remise en cause du fonctionnement voie aller et retour classique
de DVB. ULISS va déjà dans cette direction et remet en cause certains paradigmes de
l’architecture DVB.
Conclusion

Les nouveaux usages des réseaux de télécommunications se traduisent par la volonté

des utilisateurs d’être connectés partout, n’importe quand et à partir de n’importe quel
terminal. Cela implique un besoin de convergence dans les réseaux de communication
rendant homogène l’accès à des services et des réseaux hétérogènes. Pour ne pas être
marginalisés, les systèmes de communication par satellite doivent relever ce défi.
Ne nécessitant pas d’infrastructures terrestres lourdes et ayant une large couverture,
le satellite est notamment considéré comme un élément important pour réduire la frac-
ture numérique. En témoigne le développement d’offres fixes ou mobiles DVB-RCS
ou DVB-SH. Le succès du service de télévision a modelé et largement conditionné les
architecture de communications sous-jacentes. Cela a, du même coup, complexifié la
transmission de flux bidirectionnels et l’intégration dans les réseaux terrestres. Il paraît
alors naturel de se poser la question de l’évolution convergente des réseaux satellite.
Un état de l’art général des systèmes de télécommunication par satellite nous a per-
mis d’illustrer les problématiques de convergence liées aux standards DVB.
Nous avons alors proposé des critères afin d’évaluer dans le contexte satellite les
différentes solutions de convergence existantes. Nous avons également classifié les ap-
proches en trois types : convergence fixe-mobile, convergence par les services et conver-
gence des architectures de réseaux. Cette dernière nous est apparu comme la plus fonda-
mentale pour les systèmes de communication par satellite. La combinaison des techno-
logies IP et MPLS est celle qui répondait le mieux aux besoins. La technologie IP s’est
imposée comme l’interface unique des services ; elle est désormais incontournable. Elle
présente néanmoins des lacunes qui sont bien compensées par MPLS, conçu comme
une technologie permettant de rapprocher les principes des réseaux opérateurs (ATM
par exemple) avec les technologies IP. Elle offre, en outre, des capacités d’ingénierie de
trafic efficaces.
Plusieurs scénarios ont été étudiés pour valider notre approche. Tout d’abord, il pa-
raissait fondamental de se concentrer sur le service historique de télévision. Nous avons
montré que nous savions répondre aux besoins de ce service à l’aide de protocoles ap-
propriés. La solution est à la fois satisfaisante fonctionnellement et en termes de per-
formances. Notre contribution a consisté à mettre en place une structure protocolaire
séparant les services des couches basses, tant pour le plan de données que pour le plan

111
112 CONCLUSION

de contrôle.
L’étape suivante consiste à enrichir les services. Nous avons ajouté un lien retour
pour un scénario de télévision interactive. Les principales problématiques sont résolues,
en particulier l’évolution des différents adressages, de la signalisation ou des méca-
nismes de synchronisation. Des exemples d’interactivité ont été traités et nous avons
montré la simplicité de mise en œuvre de notre solution. Un nouveau scénario de télé-
phonie sur IP est alors proposé, démontrant la facilité d’intégration de différents services
sur notre architecture. Bien évidemment, c’est dans le contexte de services classiques
du monde Internet que notre solution prend tout son sens.
La dernière partie de notre travail se place dans le cadre du projet industriel ULISS
de commutateur hybride embarqué. Ce dernier scénario est original dans la mesure où
l’on est dans un contexte maillé avec un satellite régénératif. L’architecture IP/MPLS est
alors appliquée pour montrer la flexibilité de notre approche. Notre proposition d’évolu-
tion de la signalisation d’ULISS dans un cadre IP/MPLS permet une ingénierie de trafic
de bout en bout intégrée aux réseaux terrestres.
Cette thèse propose une approche transversale de la convergence dans les réseaux
satellite. Elle a le mérite de clarifier les différentes problématiques. L’effort que nous
avons porté, en particulier sur la signalisation, sur la séparation entre le système satellite
et le service, constitue un travail pionnier.
Cette séparation protocolaire proposée va pouvoir naturellement faciliter l’évolution
des services et des couches de communication satellite. En effet, il serait aisé de passer
d’un service de télévision MPEG2 à une compression MPEG4 plus performante sans
modifier la structure du réseau sous-jacent. De la même façon, un changement de codage
ou de modulation satellite n’aurait pas d’impact direct sur les services. Nous proposons
donc une meilleure organisation permettant une réduction des coûts.
Les perspectives dans le cadre de cette thèse repose tout d’abord sur l’optimisation
et l’évaluation des mécanismes réseaux tels que l’allocation des ressources, l’ordonnan-
cement ou la synchronisation. L’ordonnancement GSE dans un cadre DVB-S2 adaptatif
reste par exemple un problème ouvert. Les problématiques de sécurité ou de gestion
réseau sont également des sujets de recherches importants.
Pour la convergence des architectures de réseaux, nous avons fait le choix des tech-
nologies IP et MPLS ; d’autres solutions de convergence de type tout IP sont envisa-
geables notamment dans une approche IPv6. Cette approche tout IP pourrait ouvrir des
perspectives différentes. Il serait également intéressant de comparer les deux approches,
par exemple pour la gestion de la qualité de service ou pour la capacité à s’intégrer aux
systèmes satellites existants.
Plus largement, la convergence par les services dans un cadre plus général que les
seuls réseaux satellite et la convergence fixe-mobile constituent à elles seules des pistes
d’études et de réflexion importantes.
Liste des communications

Conférences Internationales avec comité de lecture

• E. Dubois, C. Baudoin, C. Haardt, E. Chaput, A.-L. Beylot. “IP/MPLS Satellite
Network Convergence in ULISS Project”, 10th ESA International Workshop on
Signal Processing for Space Communications (SPSC 2008), Rhodes, Grèce, 2008.
• E. Dubois, C. Baudoin, E. Chaput, A.-L. Beylot. “Interactive television service
over an IP/MPLS convergent satellite architecture”, Advanced Satellite Mobile
Systems Conference, Bologne, 2008.
• T. Bchini, E. Dubois, E. Chaput, A.-L. Beylot. “QoS of TV Broadcast Traffic
Over Convergent IP Solution for DVB-S”, AIAA International Communications
Satellite Systems Conference (ICSSC 2008), San Diego, USA, 2008.
• E. Dubois, C. Baudoin, E. Chaput, A.-L. Beylot. “Television Services over an
IP/MPLS Convergent Satellite System”, AIAA International Communications Sa-
tellite Systems Conference (ICSSC 2007), Seoul, Corée, 2007.

Séminaires nationaux
• E. Dubois, C. Baudoin, C. Haardt, E. Chaput, A.-L. Beylot. “Service de Télévi-
sion par satellite sur une architecture IP/MPLS convergente”, Journées Rescom
- RESCOM’08, Marne-La-Vallée, 07/02/2008-08/02/2008.
• E. Dubois, C. Baudoin, C. Haardt, E. Chaput, A.-L. Beylot. “Service de Télévision
par satellite sur une architecture IP/MPLS convergente”, Colloque des doctorants
- EDIT’07, Toulouse, 24/05/2007-25/05/2007.
• E. Dubois, C. Baudoin, C. Haardt, E. Chaput, A.-L. Beylot. “Convergence dans
les systèmes de communication par satellite”, 4ème Séminaire FéRIA - Ré-
seaux et Protocoles : Communications par satellite dans les Réseaux, Toulouse,
20/04/2007.

113
114 CONCLUSION
Bibliographie

[1] J. FASSON : « Etude d’une architecture IP intégrant un lien satellite géosta-

tionnaire. ». Thèse de doctorat, Institut National Polytechnique de Toulouse,
Toulouse, décembre 2004. 1, 10
[2] A. C. C LARKE : « Extra terrestrial relays : can rocket stations give world wide
radio coverage ? ». Wireless World, 51:305–308, octobre 1945. Site web : http:
//lakdiva.org/clarke/1945ww/. 4
[3] NASA : « Nasa satellite communications », mai 2005. Site web : http://www.
hq.nasa.gov/office/pao/History/commsat.html. 4
[4] H. W. T HIBEDEAU : « DTH History », 2000. Site web : http://www.
satelliteretailers.com/dish_installation.html. 4
[5] ISO/IEC : « Information technology - Generic coding of moving pictures and
associated audio information : Systems. ». ISO/IEC 13812-1, avril 1996. 4, 9
[6] D. W OOD : « Satellites, science and success, the dvb story. ». EBU Technical
Review, 20(S2):4–11, 1995. 4
[7] ATSC : « ATSC direct-to-home satellite broadcast standard ». A/81, juillet 2003.
4, 27
[8] ITU-T : « Transmission system for advanced multimedia services provided
by integrated services digital broadcasting in a broadcasting-satellite channel ».
BO.1408-1, avril 2002. 4, 27
[9] H. B ENOIT : « Digital television : MPEG-1, MPEG-2 and principles of the DVB
system. ». John Wiley & Sons, Inc., New York, NY, USA, 1997. 4
[10] H. B ENOIT : « La télévision par satellite, analogique et numérique ». Dunod,
2005. 4
[11] H. B ENOIT : « La télévision numérique, satellite, câble, TNT, ADSL ». Dunod,
2006. 4
[12] ISO/IEC : « Information technology - Generic coding of moving pictures and
associated audio information : Vidéo. ». ISO/IEC 13812-2. 8
[13] ISO/IEC : « Information technology - Generic coding of moving pictures and
associated audio information : Audio. ». ISO/IEC 13812-3. 8

115
116 BIBLIOGRAPHIE

[14] ISO/IEC : « Technologies de l’information – Codage des objets audiovisuels –

Partie 10 : codage visuel avancé ». ISO/CEI 14496-10, 2005. 8, 54
[15] ETSI : « Digital Video Broadcasting (DVB) : Specification for Service Informa-
tion (SI) in DVB systems. ». EN 300 468 v1.6.1, novembre 2004. 10
[16] ETSI : « Digital Video Broadcasting (DVB) : Guidelines on implementation and
usage of Service Information (SI). ». ETSI TR 101 211 V1.6.1, 2004. 10
[17] ETSI : « Digital Video Broadcasting (DVB) : Framing structure, channel coding
and modulation for 11/12 GHz satellite services. ». ETSI EN 300 421 V1.1.2,
1997. 12
[18] ETSI : « Digital Video Broadcasting (DVB) : Second generation framing struc-
ture, channel coding and modulation systems for broadcasting, interactive ser-
vices, news gathering and other broadband satellite applications. ». EN 302 307
v1.1.1, mars 2005. 12
[19] ETSI : « Digital Video Broadcasting (DVB) : User guidelines for the second
generation system for broadcasting, interactive services, news gathering and other
broadband satellite applications (DVB-S2) ». EN 102 376 v1.1.1, février 2005.
12
[20] ETSI : « Digital Video Broadcasting (DVB) : DVB specification for data broad-
casting. ». EN 301 192 v1.4.1, novembre 2004. 13, 32, 39
[21] ETSI : « Digital Video Broadcasting (DVB) : A guideline for data broadcas-
ting. ». TR 101 202 v1.2.1, janvier 1999. 13
[22] G. FAIRHURST et B. C OLLINI -N OCKER : « Unidirectional Lightweight En-
capsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport
Stream. ». IETF RFC 4326, décembre 2005. Site web : http://www.ietf.org/rfc/
rfc4326.txt. 13, 32, 39
[23] G. FAIRHURST et A. M ATTHEWS : « A comparison of IP transmission using
MPE and a new lightweight encapsulation ». In Proc. IEEE Seminar on IP Over
Satellite - The next Generation : MPLS, VPN and DRM Delivered Services, pages
106–120, juin 2003. 13
[24] ETSI : « Digital Video Broadcasting (DVB) ; Generic Stream Encapsulation
(GSE) protocol ». TS 102 606 v1.1.1, octobre 2007. 13, 14
[25] E. D UROS, W. DABBOUS, H. I ZUMIYAMA, N. F UJII et Y. Z HANG : « A link-
layer tunneling mechanism for unidirectional links. ». IETF RFC 3077, mars
2001. Site web : http://www.ietf.org/rfc/rfc3077.txt. 14, 70
[26] ETSI : « Digital Video Broadcasting (DVB) : Interaction channel for satellite
distribution systems. ». EN 301 790 v1.3.1, 2003. 14
BIBLIOGRAPHIE 117

[27] ETSI : « Digital Video Broadcasting (DVB) : Interaction channel for satellite
distribution systems ; Guidelines for the use of EN 301 790. ». EN 101 790 v1.21,
janvier 2003. 14
[28] J. FASSON, E. C HAPUT et C. F RABOUL : « IP multicast architectures over next-
generation GEO satellites ». In Proc. VTC 2004-Spring Vehicular Technology
Conference 2004 IEEE 59th, volume 5, pages 2826–2830 Vol.5, 2004. 20
[29] ESA : « Development of GEO Ka-band multimedia system (Domino 2) ». http:
//telecom.esa.int/telecom/www/object/index.cfm?fobjectid=2194, 2003. 20
[30] ETSI : « Satellite Earth Stations and Systems (SES) ; Broadband Satellite Mul-
timedia (BSM) ; Regenerative Satellite Mesh - B (RSM-B) ; DVB-S/DVB-RCS
family for regenerative satellites ; Part 1 : system overview ». TS 102 429-1
v1.1.1, octobre 2006. 20
[31] ETSI : « Satellite Earth Stations and Systems (SES) ; Broadband Satellite Mul-
timedia (BSM) ; Regenerative Satellite Mesh - B (RSM-B) ; DVB-S/DVB-RCS
family for regenerative satellites ; Part 1 : General description ». TS 102 188-1
v1.1.2, juillet 2004. 20
[32] ETSI : « Satellite Earth Stations and Systems (SES) ; Broadband Satellite Mul-
timedia (BSM) ; Regenerative Satellite Mesh - B (RSM-B) ; DVB-S/DVB-RCS
family for regenerative satellites ; Part 3 : Connection Control Protocol ». TS 102
429-3 v1.1.1, octobre 2006. 20, 99
[33] G. P UJOLLE : « Les réseaux édition 2005. ». Eyrolles, septembre 2004. 24
[34] ITU-T : « Interface between Data Terminal Equipment (DTE) and Data Circuit-
terminating Equipment (DCE) for terminals operating in the packet mode and
connected to public data networks by dedicated circuit ». ITU-T X25, octobre
1996. 25
[35] ISO/IEC : « Information technology – Open Systems Interconnection – Basic
reference model : the basic model ». ISO/IEC 7498-1, 1994. 25
[36] ITU-T : « Integrated services digital networks (ISDNs) ». ITU-T I.120, mars
1993. 25
[37] ITU-T : « B-ISDN general network aspects ». ITU-T I.311, août 1996. 25, 35
[38] ITU-T : « B-ISDN ATM layer specification ». ITU-T I.361, février 1999. 25,
35
[39] IEEE : « Standards 802.3 ». IEEE Std 802.3. Site web : http://standards.ieee.
org/getieee802/802.3.html. 26
[40] IEEE : « Standards 802.11 ». IEEE Std 802.11. Site web : http://standards.
ieee.org/getieee802/802.11.html. 26
118 BIBLIOGRAPHIE

[41] J. P OSTEL : « Internet protocol, DARPA internet program protocol specifica-

tion ». IETF RFC 791, septembre 1981. Site web : http://www.ietf.org/rfc/
rfc791.txt. 26, 39
[42] B. VAUTRIN et S. L. D Û : « Les réseaux : demain ». Groupe Amé-
nagement Numérique des Territoires - CETE de l’Ouest. Site web :
http://www.ant.equipement.gouv.fr/IMG/pdf/Le_point_sur_-_Reseaux_
demain_cle0dc111.pdf. 28, 44
[43] ESA : « Interactive broadband DVB-RCS/S OBP communication system (AME-
RHIS) ». http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=
7923. 33
[44] HISPASAT : « Amerhis, a multimedia revolution ». http://www.hispasat.com/
Detail.aspx?sectionsId=20&lang=en. 33
[45] « Le modèle ATM ». http://www.oleola.org/reseaux/atm/atm-1-2.php. 35
[46] IEEE : « IEE Colloquium on ATM over Satellite ». In Proc. IEE Colloquium on
ATM Over Satellite (Digest No : 1996/224), pages –, 1996. 36
[47] P. KOMISARCZUK, M. H ADJITHEODOSIOU, F. C OAKLEY et C. S MYTHE : « B-
ISDN implementation via satellite : the CATALYST project ». In Proc. Tenth UK
Teletraffic Symposium, 10th. Performance Engineering in Telecommunications
Network, pages 11/1–11/6, 1993. 36
[48] R. M ANKARIOUS : « A full mesh Asynchronous Transfer Mode (ATM) satel-
lite communications network ». In IEEE Military Communications Conference
MILCOM ’95, Conference Record, volume 1, pages 11–15 vol.1, 1995. 36
[49] I. M ERTZANIS, G. S FIKAS, R. TAFAZOLLI et B. E VANS : « Protocol architec-
tures for satellite ATM broadband networks ». IEEE Communications Magazine,
37(3):46–54, 1999. 36
[50] C.-K. T OH et V. L I : « Satellite ATM network architectures : an overview ».
IEEE Network, 12(5):61–71, 1998. 36
[51] IEEE : « Ethernet in the first mile ». IEEE Std 802.3ah, juin 2004. 37
[52] J. M. BARROSO : « From computer networks to the computer on net ». IEEE
Communications Magazine / Global Communications Newsletter, pages 2–4, oc-
tobre 2005. 37
[53] J. M. BARROSO : « Universal Ethernet Telecommunications Service : Towards
a new layer 2 based Internet ». Exploiting the Knowledge Economy, IOS Press,
pages 1615–1622, octobre 2006. 37
[54] J. M. BARROSO et G. I. F ERNANDEZ : « Ethernet Fabric Routing (UETS/EFR)
- A hierarchical, scalable and secure ultrahigh speed switching architecture ». In
Proc. 25th IEEE International Conference on Computer Communications INFO-
COM 2006, pages 1–5, 2006. 37
BIBLIOGRAPHIE 119

[55] S. B LAKE, D. B LACK, M. C ARLSON, E. DAVIES, Z. WANG et W. W EISS :

« An architecture for differentiated services ». IETF RFC 2475, décembre 1998.
Site web : http://www.ietf.org/rfc/rfc2475.txt. 38, 39
[56] IEEE : « Virtual bridged local area networks ». IEEE Std 802.1Q, 2005. Site
web : http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf. 38
[57] D. H ARRINGTON, R. P RESUHN et B. W IJNEN : « An architecture for describing
Simple Network Management Protocol (SNMP) management frameworks ».
IETF RFC 3411, décembre 2002. Site web : http://www.ietf.org/rfc/rfc3411.txt.
38, 40, 44
[58] J. P OSTEL : « Transmission Control Protocol ». IETF RFC 793, septembre 1981.
Site web : http://www.ietf.org/rfc/rfc793.txt. 39
[59] J. P OSTEL : « User Datagram Protocol ». IETF RFC 768, août 1980. Site web :
http://www.ietf.org/rfc/rfc768.txt. 39
[60] H. S CHULZRINNE, S. C ASNER, R. F REDERICK et V. JACOBSON : « RTP : A
Transport Protocol for Real-time applications ». IETF RFC 1889, janvier 1996.
Site web : http://www.ietf.org/rfc/rfc1889.txt. 39, 52
[61] R. B RADEN, D. C LARK et S. S HENKER : « Integrated services in the internet
architecture : an overview ». IETF RFC 1633, juin 1994. Site web : http://www.
ietf.org/rfc/rfc1633.txt. 39
[62] R. B RADEN, L. Z HANG, S. B ERSON, S. H ERZOG et S. JAMIN : « Resource
ReSerVation Protocol (RSVP) – version 1 functional specification. ». IETF RFC
2205, septembre 1997. Site web : http://www.ietf.org/rfc/rfc2205.txt. 39
[63] H. F OLLSCHER : « A new approach to IP-based transmission of audio and video
content via DVB-networks. ». In European Information Society Technologies
(IST) Mobile & Wireless Communications Summit, juin 2005. 39
[64] « Satsix project web site ». http ://www.ist-satsix.org/. 39
[65] C ISCO : « Next generation global services : enabling new capabilities and be-
haviors », 2006. Site web : http://www.cisco.com/web/strategy/docs/gov/
NGGS_Space_Overview_3_30_06.pdf. 39
[66] M. L UGLIO, M. S ANADIDI, M. G ERLA et J. S TEPANEK : « On-board satellite
"split TCP" proxy ». IEEE Journal on Selected Areas in Communications, 22(2):
362–370, février 2004. 39
[67] S. K ENT et K. S EO : « Security architecture for the internet protocol ». IETF
RFC 4301, décembre 2005. Site web : http://www.ietf.org/rfc/rfc4301.txt. 40
[68] E. ROSEN, A. V ISWANATHAN et R. C ALLON : « MultiProtocol Label Switching
architecture. ». IETF RFC 3031, janvier 2001. Site web : http://www.ietf.org/
rfc/rfc3031.txt. 41
120 BIBLIOGRAPHIE

[69] B. B ENDUDUH et J. M. F OURCADE : « Mpls ». Rapport technique, FrameIP,

2001. Site web : http://www.frameip.com/mpls/. 41
[70] L. A NDERSSON, P. D OOLAN, N. F ELDMAN, A. F REDETTE et B. T HOMAS :
« LDP specification ». IETF RFC 3036, janvier 2001. Site web : http://www.
ietf.org/rfc/rfc3036.txt. 42
[71] B. JAMOUSSI, L. A NDERSSON, R. C ALLON, R. DANTU, L. W U, P. D OOLAN,
T. W ORSTER, N. F ELDMAN, A. F REDETTE, M. G IRISH, E. G RAY, J. H EINA -
NEN , T. K ILTY et A. M ALIS : « Constraint-based LSP setup using LDP ». IETF
RFC 3212, janvier 2002. Site web : http://www.ietf.org/rfc/rfc3212.txt. 42
[72] D. AWDUCHE, L. B ERGER, D. G AN, T. L I, V. S RINIVASAN et G. S WALLOW :
« RSVP-TE : Extensions to RSVP for LSP tunnels. ». IETF RFC 3209, décembre
2001. Site web : http://www.ietf.org/rfc/rfc3209.txt. 42
[73] L. A NDERSSON et G. S WALLOW : « The Multiprotocol Label Switching
(MPLS) working group decision on MPLS signaling protocols. ». IETF RFC
3468, février 2003. Site web : http://www.ietf.org/rfc/rfc3468.txt. 42
[74] E. M ANNIE : « Generalized multi-protocol label switching (GMPLS) archi-
tecture. ». IETF RFC 3945, octobre 2004. Site web : http://www.ietf.org/rfc/
rfc3945.txt. 42
[75] P. T RUCHLY et M. U RBANOVIC : « MPLS throughput over GEO satellites ». In
Proc. th International Symposium ELMAR-2006 focused on Multimedia Signal
Processing and Communications, pages 305–308, juin 2006. 43
[76] A. D ONNER, M. B ERIOLI et M. W ERNER : « MPLS-based satellite constellation
networks ». IEEE Journal on Selected Areas in Communications, 22(3):438–448,
avril 2004. 43
[77] L. W OOD : « Internetworking with satellite constellations. ». Thèse de doc-
torat, University of Surrey, juin 2001. Site web : http://www.ee.surrey.ac.uk/
Personal/L.Wood/publications/PhD-thesis/wood-phd-thesis.pdf. 43
[78] ITU-T : « Architecture of Transport MPLS (T-MPLS) layer network ».
G.8110.1/Y.1370.1, novembre 2006. 43
[79] J. L ANG : « Link Management Protocol (LMP) ». IETF RFC 4204, octobre
2005. Site web : http://www.ietf.org/rfc/rfc4204.txt. 44
[80] IEEE : « Media independent handover services ». IEEE Draft Std 802.21, mai
2005. 45
[81] C. P ERKINS : « IP mobility support for IPv4 ». IETF RFC 3344, août 2002. Site
web : http://www.ietf.org/rfc/rfc3344.txt. 45
[82] D. J OHNSON, C. P ERKINS et J. A RKKO : « Mobility support in IPv6 ». IETF
RFC 3775, juin 2004. Site web : http://www.ietf.org/rfc/rfc3775.txt. 45
BIBLIOGRAPHIE 121

[83] R. KOODLI : « Fast handovers for mobile IPv6 ». IETF RFC 4068, juillet 2005.
Site web : http://www.ietf.org/rfc/rfc4068.txt. 45
[84] R. KOODLI et C. P ERKINS : « Mobile IPv4 fast handovers ». IETF RFC 4988,
octobre 2007. Site web : http://www.ietf.org/rfc/rfc4988.txt. 45
[85] ETSI : « Digital Video Broadcasting (DVB) ; Transmission System for Handheld
Terminals (DVB-H) ». EN 302 304 V1.1.1, novembre 2004. 45
[86] ETSI : « Digital Video Broadcasting (DVB) ; Framing Structure, channel coding
and modulation for Satellite Services to Handheld devices (SH) below 3 GHz ».
EN 302 583 V1.1.1, mars 2008. 45
[87] J. ROSENBERG, H. S CHULZRINNE, G. C AMARILLO, A. J OHNSTON, J. P. R.
S PARKS, M. H ANDLEY et E. S CHOOLER : « SIP : Session Initiation Protocol ».
IETF RFC 3261, juin 2002. Site web : http://www.ietf.org/rfc/rfc3261.txt. 47,
52
[88] ETSI : « Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN) ; IP Multimedia Subsystem (IMS) ; Functional
architecture ». ES 282 007 V2.0.0, mai 2008. 47
[89] G. B ERTRAND : « The IP Multimedia Subsystem in Next Generation Net-
works ». Rapport technique, ENST Bretagne, mai 2007. 47
[90] T. A HMED, I. D JAMA, A. NAFAA, P. G ÉLARD, C. D ONNY et M. J ÉRÔME :
« Towards efficient IPTV multicast support over satellite networks using an IMS-
based architecture ». In Proc of. The 57th Annual IEEE Broadcast Symposium,
Washington, D.C., USA, octobre 2007. 47
[91] M. H ANDLEY, C. P ERKINS et E. W HELAN : « SAP : Session Announcement
Protocol ». IETF RFC 2974, octobre 2000. Site web : http://www.ietf.org/rfc/
rfc2974.txt. 52, 55
[92] D. H OFFMAN, G. F ERNANDO, V. G OYAL et M. C IVANLAR : « RTP payload
format for MPEG1/MPEG2 video. ». IETF RFC 2250, janvier 1998. Site web :
http://www.ietf.org/rfc/rfc2250.txt. 52, 64
[93] R. F IELDING, J. G ETTYS, J. M OGUL, H. F RYSTYK, L. M ASINTER, P. L EACH
et T. B ERNERS -L EE : « HyperText Transfer Protocol – HTTP/1.1 ». IETF RFC
2616, juin 1999. Site web : http://www.ietf.org/rfc/rfc2616.txt. 52
[94] J. K LENSIN : « Simple mail transfer protocol ». IETF RFC 2821, avril 2001.
Site web : http://www.ietf.org/rfc2821.txt. 52
[95] « Multiposte Free : chacun sa TV ! ». http://www.free.fr/adsl/pages/television/
multiposte.html, 2008. 54
[96] ETSI : « Digital Video Broadcasting (DVB) ; Multimedia Home Platform (MHP)
Specification 1.0.3 ». TS 101 812 V1.3.2 (2006-08), août 2006. 54
122 BIBLIOGRAPHIE

[97] « Site web MHP ». http://www.mhp.org/. 54

[98] « Site web TV-Anytime ». http://www.tv-anytime.org/. 55
[99] M. H ANDLEY, V. JACOBSON et C. P ERKINS : « SDP : Session Description
Protocol ». IETF RFC 4566, juillet 2006. Site web : http://www.ietf.org/rfc/
rfc2327.txt. 55
[100] C. B ORMANN, C. B URMEISTER, M. D EGERMARK, H. F UKUSHIMA, H.
H ANNU, L.-E. J ONSSON, R. H AKENBERG, T. KOREN, K. L E, Z. L IU, A.
M ARTENSSON, A. M IYAZAKI, K. S VANBRO, T. W IEBKE, T. YOSHIMURA et
H. Z HENG : « RObust Header Compression (ROHC) : framework and four pro-
files : RTP, UDP, ESP, and uncompressed. ». IETF RFC 3095, juillet 2001. Site
web : http://www.ietf.org/rfc/rfc3095.txt. 67
[101] H. W. L I, J. H ONG et P. H ONG : « Performance analysis of ROHC U-mode in
wireless links. ». IEE Proceedings Communications, 151:549–551, 2004. 67
[102] R. P RICE, C. B ORMANN, J. C HRISTOFFERSSON, H. H ANNU, Z. L IU et J. RO -
SENBERG : « Signaling Compression (SigComp) ». IETF RFC 3320, janvier
2003. Site web : http://www.ietf.org/rfc/rfc3320.txt. 67
[103] UD CAST : « Comment assurer l’intégration complète des liens de diffusion dans
l’internet. ». UDLR white paper V1, décembre 2001. 70
[104] B. C ROFT et J. G ILMORE : « Bootstrap Protocol (BOOTP) ». IETF RFC951,
septembre 1985. Site web : http://www.ietf.org/rfc/rfc951.txt. 76
[105] R. D ROMS : « Dynamic Host Configuration Protocol ». IETF RFC 2531, mars
1997. Site web : http://www.ietf.org/rfc/rfc2531.txt. 76
[106] N. A BRAMSON : « The aloha system–another alternative for computer communi-
cation ». In Proceedings of Fall Joint Computer Conference, AFIPS Conference,
volume 37, pages 281–285, 1970. 77
[107] E. D ECKER, P. L ANGILLE, A. R IJSINGHANI et K. M C C LOGHRIE : « Multi-
protocol encapsulation over ATM adaptation layer 5. ». IETF RFC 1483, juillet
1993. Site web : http://www.ietf.org/rfc/rfc1493.txt. 79
[108] G. FAIRHURST et M.-J. M ONTPETIT : « Address resolution mechanisms for IP
datagrams over MPEG-2 networks ». IETF RFC 4947, juillet 2007. Site web :
http://www.ietf.org/rfc/rfc4947.txt. 84
[109] D. L. M ILLS : « Network Time Protocol (version 3) : specification, imple-
mentation and analysis ». IETF RFC 1305, mars 1992. Site web : http:
//www.ietf.org/rfc/rfc1305.txt. 86
[110] N. J EGHAM, S. L OHIER, G. ROUSSEL et A.-L. B EYLOT : « Performance
of Voice over IP in DVB-RCS and iDirect satellite networks ». In AIAA In-
ternational Communications Satellite Systems Conference (ICSSC), San Diego,
10/06/08-12/06/08, page (electronic medium), 2008. 92
BIBLIOGRAPHIE 123

[111] ESA : « ULISS web site ». http://telecom.esa.int/telecom/www/object/

index.cfm?fobjectid=20327. 96, 97
[112] L. X U, H. P ERROS et G. ROUSKAS : « Techniques for optical packet switching
and optical burst switching ». IEEE Communications Magazine, 39:136–142,
janvier 2001. 97
[113] O. H ERRERO et X. M AUFROID : « Innovative hybrid optical/digital ultra-fast
packet-switched processor for meshed satellite networks ». IEEE Journal on
Selected Areas in Communications, 22(2):250–260, 2004. 97
[114] C. H AARDT et D. V ERCHÈRE : « Radio burst switching for satellite
communication, an alternative to traditional switching payloads ». Rap-
port technique, Alcatel Strategy/Technology White Paper, octobre 2002.
Site web : http://www.alcatel.com/doctypes/articlepaperlibrary/pdf/WP/
T0210-Radio_burst-EN.pdf. 97
[115] C. H AARDT et N. C OURVILLE : « Internet switching by satellite : An ultra
fast processor with radio burst switching. ». In Proceedings of the First Sympo-
sium on potentially Disruptive Technologies and theirs Impact in Space Program,
Marseille, France, juillet 2005. 97
[116] C. H AARDT et N. C OURVILLE : « Internet by satellite : a flexible processor with
radio burst switching ». In Satellite and Space Communications, 2006 Interna-
tional Workshop on, pages 58–62, septembre 2006. 97
[117] F. FARAHMAND, J. J UE, V. VOKKARANE, J. J. P. C. RODRIGUES et M. M.
F REIRE : « A layered architecture for supporting optical burst switching ». In
AICT-SAPIR-ELETE ’05 : Proceedings of the Advanced Industrial Conference on
Telecommunications/Service Assurance with Partial and Intermittent Resources
Conference/E-Learning on Telecommunications Workshop, pages 213–218, Wa-
shington, DC, USA, 2005. IEEE Computer Society. 104
124 BIBLIOGRAPHIE
 Convergence dans les réseaux satellite
Résumé : Les réseaux satellite ont été standardisés par le groupe DVB en se fo-
calisant sur le service de télévision. Dans un contexte de convergence, notamment
caractérisé par l’émergence des offres “triple play”, les nouvelles architectures de
télécommunication par satellite doivent être conçues de façon plus ouverte. Après
une description du contexte des réseaux satellites DVB, nous recensons les solutions
de convergence applicables à ces réseaux. Notre choix s’est porté sur les technolo-
gies convergentes IP et MPLS pour proposer une telle architecture de convergence.
Pour en évaluer les qualités, plusieurs scénarios sont alors envisagés. Le premier se
concentre sur le service historique de télévision avec un satellite transparent et unidi-
rectionnel. Nous montrons que la solution IP/MPLS permet d’offrir le même service
avec des performances similaires et surtout ajoute une structure protocolaire aug-
mentant l’évolutivité. Les scénarios suivants s’occupent d’un service de télévision
interactif avec voie retour et d’un service de voix sur IP et mettent en valeur la faci-
lité de leur mise en œuvre. Le dernier scénario applique notre approche convergente
IP/MPLS au projet de satellite régénératif hybride ULISS. Cela a permis de montrer
la flexibilité de l’architecture et d’étendre les possibilités de services du projet.
Mots Clés : Convergence, MPLS, satellite, IP, DVB, télévision

Convergence in satellite networks

Abstract : Satellite networks have been built by the DVB group and dedica-
ted to digital television service. However, in the current service convergence trend,
a future satellite network architecture has to be built in a less dedicated way to fit
heterogeneous services. This work begins with a description of DVB satellite net-
works. Then, network convergence solutions are studied for the satellite context. IP
and MPLS have then been chosen to build a satellite convergent architecture. Seve-
ral scenarios are examined so as to evaluate this architecture. A first one deals with
the historical television service in a unidirectional, transparent satellite context. We
show the feasibility of such a scenario with similar performances and better protocol
organisation which simplifies satellite evolution. The next scenarios concern an in-
teractive television service with a return link and a voice over IP service. The ability
of deploying new services in a simple manner is thus highlighted. The last scenario
applies our convergent approach to the ULISS industrial project of a regenerative
hybrid satellite. It shows the flexibility of our architecture and expand ULISS service
capabilities.
Keywords : Convergence, MPLS, satellite, IP, DVB, television