Architecture d’étude

Cette partie propose une vision d’ensemble des systèmes DVB-S comme support d’IP. Cette architecture d’étude est un cas classique d’IP sur DVB-S.

3.2.2.1.

Une vision d’ensemble de l’architecture

Cette structure satellite classique s’appuie sur une liaison DVB-S unidirectionnelle. Le lien DVB-S inonde les terminaux du système via un satellite monofaisceau et transparent (sans intelligence à bord). Le satellite est donc assimilable à un hub spatial qui répète et amplifie le signal vers le sol dans une couverture équivalente à 1/3 à 1/4 de la surface du globe.

Si le lien aller utilise le DVB-S, dans la plupart des cas, il n’est pas envisageable que la voie retour repose sur cette même technologie. En effet, d’une part le coût d’une gateway par utilisateur, ou même par regroupement d’abonnés, reste prohibitif, et d’autre part le système DVB-S ne peut fonctionner pour un grand nombre de gateways. Le lien retour doit utiliser une autre technologie, et le plus simple apparaît comme un retour terrestre. L’accès Internet via satellite est donc traditionnellement accompagné d’une voie de retour terrestre fondée sur la technologie en place, le RTC (Réseau Téléphonique Commuté). C’est pour ce type de configuration asymétrique que le protocole UDLR a été créé [15]. La figure suivante présente alors cette architecture (Figure 3.9) dans le cadre d’un service d’accès à Internet, et nous reviendrons plus en détail dans la partie suivante sur les piles de protocoles mises en jeu.

Figure 3.9 Architecture classique IP sur DVB-S comme accès à Internet

Ce type d’architecture est adapté aux applications diffusées et quasi unidirectionnelles comme le caching, le pushing, ou la VoD.

Un tel système est généralement contrôlé et géré par un NCC (Network Control Centre) et un MNMC (Mission and Network Management Centre). Ces éléments ne sont toutefois pas représentés sur la figure ci-dessus, et peuvent être incorporés à une gateway.

Ce système fonctionne en bande Ku avec un C/N de 6.9 dB [34]. Les terminaux sont équipés de petites paraboles (60 cm de diamètre) et la gateway dispose d’une antenne de quelques mètres de diamètre (3 à 6 mètres). A l’émission on dispose d’un débit utile par canal de 38 Mbits/s pour un FEC de ¾. Une gateway peut ainsi être équipée de plusieurs transpondeurs et émettre ainsi à plus fort débit sur différents canaux. Toutefois, il faut noter qu’un équipement uniquement dédié au transport de datagrammes n’est pas courant, et l’offre IP doit le plus souvent partager la bande passante avec d’autres services tels que la télévision numérique, les radios ou les services de NVoD (Near Video on Demand) directes sur DVB.

3.2.2.2.

Les couches protocolaires

Les couches protocolaires mises en œuvre se retrouvent dans la gateway et les terminaux, puisque l’un émet en DVB-S et l’autre reçoit. La figure suivante (Figure 3.10) présente la mise en œuvre de l’UDLR sur cette architecture via une connexion PPP sur RTC comme voie retour.

Internet Internet FAI FAI Satellite GEO Transparent RTC RTC DV B-S D V_B -S IP MPEG-2 TS DVB-S MPE UDLR Gateway Terminal Satellite Terminal Satellite IP MPEG-2 TS DVB-S MPE UDLR Terminal Satellite Internet Internet FAI FAI Satellite GEO Transparent RTC RTC DV B-S D V_B -S IP MPEG-2 TS DVB-S MPE UDLR Gateway Terminal Satellite Terminal Satellite IP MPEG-2 TS DVB-S MPE UDLR Terminal Satellite

Figure 3.10 Couches protocolaires entre une gateway et un terminal mettant en jeu un lien retour terrestre

L’illustration propose un aperçu des différents niveaux de protocoles qui entrent en jeu dans une communication entre une gateway (ou un agent routeur du FAI) et le terminal utilisateur connecté au système DVB-S. Le protocole UDLR n’intervient ici que sur le lien retour : les datagrammes à destination de l’interface air sont traités par la couche IP comme si cette interface était bidirectionnelle. C’est la couche UDLR qui intercepte le datagramme et l’encapsule via GRE (Generic Routing Encapsulation) dans un nouveau datagramme, émis cette fois-ci sur l’interface du réseau terrestre. A la réception du datagramme, le traitement est effectué jusqu’au niveau IP. Le protocole GRE restitue le datagramme original au niveau 3 comme s’il provenait de la couche MPE. Si cette solution rajoute tout de même de l’overhead en encapsulant des datagrammes dans des datagrammes, elle a l’énorme mérite d’être transparente pour l’utilisateur et donc le niveau transport et applicatif.

3.2.2.3.

La signalisation du trafic

La signalisation du trafic IP n’est pas une mince affaire et soulève un grand nombre de problèmes, questions que se posent en commun industriels et chercheurs dans un groupe de travail de l’IETF, IP sur DVB [33]. En effet la résolution d’adresse (AR), élément clef de la signalisation du trafic IP sur satellite n’est pas une tâche aisée puisqu’elle n’est ni réglementée ni associée à une couche protocolaire. Pourtant, il est certain qu’il faut faire le lien entre l’adresse IPv4 (IPv6), l’adresse MAC utilisée dans MPE et le PID des paquets MPEG-2 TS.

Dans ce cadre un certain nombre de méthodes ont vu le jour [35] : des méthodes statiques privées ou des méthodes dynamiques comme la méthode MMT (Multicast Map Table) que nous avons utilisée dans DIPCAST [28], ou encore la méthode AIT (Application Information Table) utilisée dans MHP (Multimedia Home Platform) [36].

Les méthodes statiques présentent une solution simple mais coûteuse pour le niveau 3. Ces solutions de type privé proposent d’utiliser un seul PID pour contenir tout le trafic IP. Aussi, toutes les données sont contenues dans le même TS et le filtrage doit être fait au niveau IP ou MPE (ou équivalent). Cela implique donc que toutes les stations intéressées par le trafic IP doivent écouter et recevoir cet unique TS.

Les méthodes dynamiques utilisent la signalisation SI, des tables privées ou des protocoles spécifiques. Ces tables permettent ainsi d’indiquer le PID correspondant à une adresse IP ou un groupe d’adresses IP. La norme DVB propose une solution générale utilisant cette méthode par le biais de la table INT (IP/MAC Notification Table) [14]. Cette solution n’est en rien obligatoire et a été proposée après le protocole MPE. Tout comme la méthode MPE est recommandée par la norme, la signalisation via les tables INT est aussi conseillée.

La solution INT propose un mécanisme pour véhiculer les localisations dans un réseau DVB des différents flux contenant des datagrammes (ou des trames Ethernet). Elle s’appuie sur trois notions principales :

• La plateforme IP/MAC (IP/MAC platform) : identifiée par son platform_id, elle regroupe des flux IP/MAC et/ou des récepteurs. Il s’agit d’un espace d’adressage sans conflit qui peut cohabiter avec d’autres plateformes sur le même multiplex comme être présent sur différents multiplexes.

• Le flux IP/MAC (IP/MAC stream) : il s’agit du flux encapsulé qui doit être signalé sur le multiplexe. Ce flux peut contenir une adresse IP et/ou une adresse MAC.

• L’identifiant de plateforme (Platform_id) : il identifie de manière unique une plateforme et son attribution est centralisée par le projet DVB.

Si cette méthode est utilisée, cela est notifié préférentiellement dans la table NIT (la table BAT peut aussi faire l’affaire). Le descripteur utilisé permet d’accéder au programme correspondant aux informations de la plateforme IP/MAC (table PMT) via la table PAT. La table PMT localise la table INT. En fonction de l’adresse cherchée, la table INT indique un numéro de service qui permet de trouver dans la table PAT, le PID de la table PMT correspondante, et enfin le flux IP/MAC. Cette procédure est illustrée dans la figure ci-dessous par un schéma récapitulatif du processus d’interrogation des différentes tables (Figure 3.11).

Les tables INT supportent les sous-réseaux, les adresses IPv4, IPv6, MAC ainsi que les adresses multicast de type (*, G) comme (S, G)1_{. Ces tables permettent la gestion d’un réseau FAI,}

de la sécurité des flux, de l’identification, etc.… (cf. norme ETSI EN 301 192 [14])

La méthode INT propose donc un jeu de descripteurs pour gérer l’IP sur un réseau DVB. Toutefois cette méthode ne donne pas de pistes quand à l’attribution des PID en fonction des adresses IP, ni sur la résolution d’adresse au niveau MAC. Ce mécanisme s’inscrit donc bien dans la démarche du DVB : proposer un standard ouvert. Cependant, la brèche est ouverte aux solutions propriétaires tant que des questions majeures subsistent : la réservation des PIDs est- elle statique ou dynamique ? Y a-t-il une translation entre PIDs et adresses IP ? Où déclarer les PIDs disponibles ? Comment gérer les nouveaux abonnés ?