FR2878104A1 - Systeme de transmission de flux multidiffusion - Google Patents

Abstract

Système de transmission de flux multidiffusion entre au moins une source de flux multidiffusion d'au moins un fournisseur de services et au moins une zone de diffusion comprenant une pluralité de terminaux utilisateurs.Selon l'invention, ledit système comprend :- un serveur central de gestion des flux multidiffusion,- un terminal pilote associé à chaque zone de diffusion, ledit serveur central de gestion étant apte à :* recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles,* sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone,et ledit terminal pilote étant apte à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.Application à la distribution de programmes multidiffusion.

Description

La présente invention concerne un système de transmission de flux

multidiffusion entre au moins une source de flux multidiffusion d'au moins un fournisseur de services et au moins une zone de diffusion comprenant une pluralité de terminaux utilisateurs.

L'invention trouve une application particulièrement avantageuse dans le domaine de la transmission de flux multidiffusion à travers des réseaux de transport non prévus pour la mise en oeuvre des mécanismes de multidiffusion, tel que l'Internet (IP).

Le terme de multidiffusion est équivalent ici aux autres termes :.o souvent utilisés dans ce domaine technique, tels que diffusion multipoints , diffusion de groupes ou encore le terme anglo-saxon de multicast . Dans la suite de ce mémoire, on utilisera indifféremment les termes de multidiffusion et de multicast , ce dernier étant largement employé.

Les services multidiffusion sur IP, comme le streaming audio/vidéo, [s le transfert de fichiers vers une communauté d'utilisateurs ou la télévision sur IP, permettent de mutualiser les ressources de réseau en faisant partager la même information à un ensemble d'utilisateurs intéressés par le même contenu, cet ensemble d'utilisateurs constituant une zone de diffusion ( hotspot en terminologie anglo-saxonne). Dans le cadre, par exemple, zo d'une architecture de réseau où les fournisseurs de services sont interconnectés à un réseau d'accès via un réseau de transport, le mode de transmission multidiffusion implique que le réseau de transport considéré soit capable de router de tels flux.

Le fonctionnement d'un service multidiffusion, ou multicast, prévoit que ce soit l'utilisateur qui déclenche le transfert de flux en s'abonnant au service, ou groupe de flux multicast. Afin de contrôler l'utilisation de la bande passante, un opérateur de réseau d'accès peut souhaiter limiter le nombre potentiel de groupes auxquels les utilisateurs peuvent s'abonner, ces limitations pouvant également évoluer dans le temps et l'espace en fonction des besoins des services, par exemple tel groupe de flux multicast n'est disponible que dans telle zone de diffusion et pour telle plage horaire, comme c'est le cas du décrochage local en télévision.

Les protocoles de gestion des souscriptions d'utilisateurs à des groupes de diffusion multicast sont actuellement parfaitement connus et standardisés par l'IETF, on citera par exemple le protocole IGMPv2/RFC2236.

En ce qui concerne le transport, plusieurs solutions permettent io aujourd'hui à un opérateur de réseau d'offrir des services multicast sans avoir recours à un réseau de transport spécifique entre les sources de flux multicast et les zones de diffusion.

La première solution d'hébergement de services multicast dans un réseau d'accès IP, notamment radio, composé de zones de diffusion est de placer dans chaque zone un ou plusieurs serveur(s) d'application. Si cette solution, dite à serveurs locaux , a le mérite de la simplicité, elle peut être fort coûteuse en terme de serveurs, surtout si un même fournisseur de services souhaite diffuser dans plusieurs zones. De plus, la gestion de fournisseurs de services tiers est relativement lourde puisque ils doivent être hébergés au sein même du réseau d'accès. Le nombre de fournisseurs de services potentiels est alors clairement limité. En réalité, cette solution n'offre que peu d'intérêt car trop éloignée du cadre dans lequel se situe l'invention.

La seconde solution, qui est aussi la plus classiquement mise en oeuvre pour véhiculer le trafic multicast au travers d'un réseau unicast tel l'Internet, est d'utiliser les mécanismes dits de tunnels IP . La figure 1 illustre ce type de mécanisme connu dans un contexte qui est aussi celui de l'invention.

Les fournisseurs de services A et B disposent respectivement de sources de flux multidiffusion notées respectivement Al, A2 et BI. Chacune de ces sources multicast émet un ou plusieurs flux multidiffusion. Ces flux sont _,o bloqués par les routeurs d'accès RAI et RA2 tant que ces derniers n'ont pas reçu de demande de souscription. Des tunnels IP statiques (tunnel IPI et tunnel IP2) sont préalablement configurés entre les routeurs d'accès RAI et RA2 de chaque fournisseur de services et le routeur d'accès RA3 de la zone de diffusion visée par le service. Un utilisateur, équipé d'un terminal connecté au réseau d'accès via un point d'accès A,P2 et souhaitant recevoir un contenu multicast en provenance du fournisseur de services A, émet une demande de souscription à l'adresse IP des flux multicast correspondants, typiquement à l'aide du protocole IGMP précité. Cette demande de souscription est traitée par le routeur d'accès RA3, ce dernier étant configuré pour encapsuler le message de souscription dans le tunnel IP2 dont l'extrémité est le routeur d'accès RAI du fournisseur de service A. On suppose donc implicitement que RA3 sache déterminer quel tunnel emprunter en fonction de l'adresse IP o multicast demandée, on reviendra sur ce point un peu plus loin. Le routeur RAI désencapsule alors le message et répond à la demande de souscription en faisant suivre le(s) flux multidiffusion demandé(s) à travers le tunnel IP2 dont l'extrémité est le routeur d'accès RA3. A la réception, RA3 désencapsule les données et les fait suivre en multicast au sein du sous-réseau IP constitué :s par la zone de diffusion dont l'utilisateur fait partie, et donc à travers le point d'accès AP2 auquel est connecté le terminal de cet utilisateur.

Dans un fonctionnement standard de plateforme de services de multidiffusion, l'utilisateur a connaissance de l'adresse des flux multicast et émet une demande de souscription au groupe multicast correspondant en :?o spécifiant cette adresse dans sa demande. Si plusieurs utilisateurs desservis par un même point d'accès s'abonnent à des groupes multicast différents, le débit peut vite dépasser la capacité du point d'accès considéré si tous les flux sont délivrés en même temps. Une gestion de régularisation de l'accès aux services multicast peut alors s'avérer nécessaire. Le principe de cette régularisation des flux est de n'autoriser la souscription qu'à un certain nombre de groupes multicast pendant un laps de temps donné. Dans ce cas, le problème revient à n'annoncer aux utilisateurs que les flux disponibles, c'est à dire ceux qui sont potentiellement accessibles et interdire l'accès aux autres. On rappelle que cette annonce de service est utilisée pour obtenir les informations nécessaires à l'utilisateur pour gérer sa souscription, à savoir adresses IP multicast des flux, numéro de port, description des flux, etc. Aussi, un problème technique à résoudre par l'objet de la présente invention est de proposer un système de transmission de flux multidiffusion entre au moins une source de flux multidiffusion d'au moins un fournisseur de services et au moins une zone de diffusion comprenant une pluralité de terminaux utilisateurs, qui pourrait répondre efficacement au besoin de gestion dynamique de la ressource multicast via un réseau de transport non multicast, tout en permettant une interconnexion à bas coût du réseau d'accès avec un grand nombre de fournisseurs de contenus.

La solution à ce problème technique consiste, selon la présente invention, en ce que ledit système comprend: - un serveur central de gestion des flux multidiffusion, ao - un terminal pilote associé à chaque zone de diffusion, ledit serveur central de gestion étant apte à : * recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles, * sélectionner parmi les flux disponibles au moins un flux multidiffusion [5 à diffuser dans ladite zone, et ledit terminal pilote étant apte à émettre à destination du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.

Ainsi, afin de répondre de manière efficace au besoin de gestion et de contrôle dynamique de la ressource multicast, l'invention introduit la notion de gestion centralisée de la souscription multicast du fait que la solution proposée permet l'association dynamique des sources multicast et des zones de diffusion, tout en interdisant les souscriptions aux groupes non diffusés dans la zone. Pour ce faire, il est proposé par le système conforme à l'invention de déporter la gestion de la souscription sur le serveur central, cette gestion se faisant au nom des utilisateurs finaux.

Le fonctionnement détaillé du système de transmission de flux multicast, objet de l'invention, sera donné plus loin. II suffit ici d'en retenir le principe général fondé sur l'idée que les souscriptions au groupe multicast ne sont plus gérées par les utilisateurs eux-même mais sont contrôlées par un serveur central de gestion. Ce serveur gère la souscription au nom des utilisateurs et joue le rôle d'interface auprès de tous les fournisseurs de services qui lui adressent une description de leurs contenus.

Le serveur central de gestion gère le planning de diffusion pour toutes les zones de diffusion; il détermine l'heure et le lieu de diffusion de chaque flux multicast. Lorsqu'un flux sélectionné doit être diffusé dans une zone donnée, le serveur central de gestion émet à destination du terminal pilote appartenant à l'architecture de la zone de diffusion qu'il représente, typiquement derrière le routeur d'accès, un ordre de souscription en indiquant notamment l'adresse du flux multicast sélectionné. Le terminal pilote s'abonne io alors au groupe multicast désiré au nom des utilisateurs présents dans la zone de diffusion en émettant une demande de souscription grâce à un protocole de souscriptions. Cette demande transite par le routeur d'accès de la zone de diffusion qui la transmet vers la source multicast correspondante.

En résumé, la gestion de la souscription multicast au niveau de la plateforme, telle que proposée par l'invention, apporte une grande souplesse dans la gestion de la ressource multicast et permet un contrôle fin, par zone de diffusion, de la bande passante utilisée par les services multicast.

Un autre aspect abordé par l'invention concerne le transport de flux dans le cas de fournisseurs de contenus tiers.

Le mécanisme de tunnels IP qui a été décrit plus haut en référence à la deuxième solution connue de l'état de la technique permet clairement de faire transiter un trafic multicast à travers un réseau purement unicast au moyen de tunnels IP. Cependant, ce mécanisme suppose qu'un routeur recevant une demande de souscription puisse y associer le tunnel correspondant, c'est à dire en déterminant l'extrémité du tunnel en fonction de l'adresse multicast des flux demandés. Or, les mécanismes standard de souscriptions aux groupes de flux multicast sont basés sur le protocole IGMPv2/RFC2236 qui ne permet à l'utilisateur que de spécifier l'adresse multicast désirée. Dans le contexte de l'invention, l'association tunnel/adresse multicast ne peut être configurée que statiquement au niveau des routeurs d'accès de chaque zone de diffusion.

Un inconvénient de cette méthode standard est son caractère statique et son manque de souplesse en terme de reconfigurabilité. En effet, le fait qu'une source peut émettre sur plusieurs adresses multicast différentes peut conduire à des tables de correspondance de dimension importante.

D'autre part, étant associée à un contenu spécifique, l'adresse de flux multicast est susceptible d'être couramment modifiée. Ainsi, à chaque fois qu'un fournisseur de services souhaite ajouter, ou modifier, une adresse multicast, celle-ci doit être configurée, ou reconfigurée, au niveau de tous les routeurs d'accès des zones de diffusion potentiellement clientes du nouveau service multicast. De plus, toutes les adresses multicast doivent être différentes quels que soient la source et le fournisseur de services. Cette :.o dernière contrainte peut être difficile à surmonter si le réseau d'accès s'approvisionne auprès de fournisseurs de services indépendants, voire concurrents.

Aussi, un autre problème technique à résoudre par l'objet de la présente invention est de substituer au mécanisme classique de souscription [5 basé sur la correspondance tunnel/adresse multicast un mécanisme plus simple à mettre en oeuvre pour les routeurs d'accès et également plus stable vis à vis des éventuelles modifications apportées aux adresses multicast par les fournisseurs de services.

La solution à ce deuxième problème technique consiste, selon la zo présente invention, en ce que ledit serveur central de gestion est apte à recevoir du fournisseur de services une adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice.

zs Il est alors également prévu par l'invention que l'adresse de ladite source émettrice est incluse dans ladite demande de souscription.

En conséquence, l'invention prévoit avantageusement qu'un routeur d'accès destiné à acheminer ladite demande de souscription dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.

Ainsi, l'invention propose une solution au problème de transport qui reste toujours basée sur les mécanismes de tunnels IP, dans laquelle un tunnel doit être configuré entre le fournisseur de services et chaque zone de diffusion visée. Mais on s'affranchit de la contrainte d'association tunnel/adresse multicast en utilisant, par exemple, le protocole IGMPv3/RFC3376 qui permet à un utilisateur de spécifier, lors de la demande de souscription, l'adresse de la source rulticast choisie qui sera associée à l'identification de l'extrémité du tunnel dans une table de correspondance. De cette manière, les routeurs d'accès n'ont pas à maintenir de listes d'association tunnel/adresse multicast puisqu'ils peuvent utiliser simplement l'adresse de la source multicast, laquelle peut être considérée comme figée contrairement aux adresses de groupes multicast, pour identifier l'extrémité du o tunnel à emprunter. L'adresse de la source multicast est communiquée par le terminal pilote, au nom des utilisateurs de la zone de diffusion, grâce au protocole IGMPv3, lors de la demande de souscription. Enfin, la notion de contrôle centralisé de la souscription multicast fait que la solution proposée par l'invention, bien que basée sur des tunnels statiques, permet l'association [s dynamique des sources multicast et des zones de diffusion.

On comprend que l'évolution d'architecture résultant de l'invention est complètement transparente pour l'utilisateur final qui n'a pas besoin de mise à jour applicative spécifique. En particulier, il n'est pas nécessaire d'implémenter le protocole de souscriptions IGMPv3 dans tous les terminaux utilisateurs, zo mais uniquement au niveau du terminal pilote.

De même, du coté fournisseur cle services, l'impact est relativement faible puisqu'il est limité à la configuration d'un tunnel par zone de diffusion. En effet, le système proposé par l'invention ne nécessite pas d'évolution de service ni d'applications ou protocoles particuliers, puisque la gestion de la ressource multicast est entièrement supervisée par le serveur central de gestion Afin de sécuriser la communication entre le serveur central de gestion et le terminal pilote d'une zone de diffusion, l'invention propose que le message du serveur central au terminal pilote comprenne également une authentification dudit message. Cette disposition permet d'éviter que le terminal pilote ne reçoive des commandes de souscription provenant d'autres entités que le serveur central de gestion.

L'invention concerne également un serveur central de gestion pour un système de transmission de flux multidiffusion, remarquable en ce que ledit serveur est apte à : * recevoir dudit fournisseur de services des adresses des flux 5 multidiffusion disponibles, * sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone, Un autre aspect du serveur central de gestion consiste, selon l'invention, en ce qu'il est apte à recevoir du fournisseur de services une [o adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice.

De même, un produit programme d'ordinateur pour un serveur central de gestion est remarquable en ce qu'il comprend des instructions de code de [5 programme sur un support lisible par un ordinateur pour la mise en oeuvre des opérations consistant à : * recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles, * sélectionner parmi les flux disponibles au moins un flux multidiffusion 20 à diffuser dans ladite zone, lorsque ledit programme est exécuté sur un ordinateur dudit serveur central de gestion.

L'invention concerne encore un terminal pilote pour un système de transmission de flux multidiffusion, remarquable en ce que ledit terminal pilote est apte à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.

En ce sens, un produit programme d'ordinateur pour un terminal pilote selon l'invention est remarquable en ce qu'il comprend des instructions de code de programme sur un support lisible par un ordinateur pour la mise en oeuvre des opérations consistant à émettre à destination du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.

Enfin, un routeur d'accès pour un système de transmission de flux multidiffusion selon l'invention est remarquable en ce que ledit routeur d'accès, destiné à acheminer ladite demande de souscription, dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.

La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste w l'invention et comment elle peut être réalisée.

La figure 2 est un schéma donnant l'architecture d'un système de transmission de flux multidiffusion conforme à l'invention.

La figure 3 est un diagramme de fonctionnement du système de transmission de la figure 2.

Sur la figure 2 est représentée une architecture d'un système de transmission selon l'invention dans laquelle des fournisseurs de services A et B, hébergeant respectivement des sources AI, A2 et BI de flux multidiffusion, souhaitent alimenter, via un réseau de transport IP non multicast, comme l'Internet, des zones ZD1 et ZD2 de diffusion d'un réseau d'accès. Chacune zo de ces sources multicast peut diffuser plusieurs groupes de flux multicast.

Les zones ZD1 et ZD2 de diffusion sont respectivement connectées au réseau d'accès via les routeurs d'accès RA3 et RA4. Chacune de ces zones héberge respectivement un terminal pilote TP1 et TP2 et les points d'accès API, AP2 d'une part, et AP3, AP4 d'autre part. Les fournisseurs de services A et B sont respectivement connectés au réseau de transport IP par les routeurs d'accès RAI et RA2.

Le fournisseur A de services souhaitant alimenter les zones ZD1 et ZD2, des tunnels IPI et IP2 sont respectivement établis statiquement entre RAI et RA3 et entre RAI et RA4. De même, le fournisseur de services B souhaitant alimenter la zone ZD1 de diffusion, un tunnel IP3 est alors établi statiquement entre RA2 et RA3. On notera que le nombre de tunnels IP dépend seulement du nombre de fournisseurs de services et est indépendant du nombre de sources multicast par fournisseur de services. Dans le mode de i0 réalisation particulier de la figure 2, le réseau d'accès intègre un serveur central SC de gestion de flux multicast, incluant le contrôle et la commande de l'approvisionnement en contenus multicast. Le serveur central SC gère l'activation et l'accès à la ressource multicast pour le compte des utilisateurs finaux, et réalise l'interface avec les fournisseurs des services.

Plus particulièrement, le serveur central de gestion SC reçoit des fournisseurs de services A et B les adresses des flux multicast disponibles, ainsi que les adresses unicast des sources des flux correspondants. Le serveur central SC gère également la diffusion des flux au sein des zones ZD1 io et ZD2 connectées au même réseau d'accès. Cette gestion consiste à sélectionner pour chaque zone et chaque tranche horaire un ou plusieurs des flux disponibles. Chacun des terminaux pilotes TP1 et TP2, représentants en quelque sorte des terminaux utilisateurs de leur zone respective, est informé de l'adresse multicast du flux, ou des flux, sélectionné(s) et l'adresse unicast de la source émettrice du flux, ou des flux, sélectionné(s) par un message transmis par le serveur central SC ou par consultation d'une table maintenue à jour par ledit serveur central.

De son côté, le terminal pilote de chaque zone ZD1 ou ZD2 émet à destination du fournisseur de service A ou B, selon la sélection réalisée par le serveur central de gestion SC, une demande de souscription, commune à tous les utilisateurs de la zone, pour le(s) flux multicast sélectionné(s). Cette demande de souscription comprend les adresses multicast de flux et unicast de sources reçues du serveur central SC.

Ces demandes de souscriptions sont relayées par les routeurs d'accès, RA3 et RA4, qui, pour acheminer la demande de souscription correspondante, disposent d'une simple table de correspondance associant l'adresse de source émettrice à un tunnel d'accès IP au fournisseur de services correspondant.

Le fonctionnement du système de transmission conforme à l'invention va être maintenant décrit en regard de la figure 3. Par souci de simplification, le diagramme montré sur cette figure ne fait référence qu'à une seule zone de diffusion, mais il bien clair qu'il s'étend aisément à l'approvisionnement en flux multicast d'un nombre quelconque de zones.

2878104 Il Un tunnel IP statique est préalablement configuré entre le routeur d'accès du fournisseur de services et celui de la zone de diffusion considérée. On suppose que le réseau de transport IP est l'Internet.

1.a. La source multicast, Al ou A2, du fournisseur A de services par exemple, émet un flux multicast auquel est associée une adresse IP multicast. Le flux multicast est bloqué par le routeur d'accès, RAI dans l'exemple choisi, puisque aucune demande de souscription n'a été enregistrée par ce dernier. Le flux multicast ne transite donc pas par le réseau de transport, ici l'Internet.

1.b. Le fournisseur de services fournit au serveur central SC de gestion ro une description du service IP multicast. Cette description comprend notamment l'adresse IP multicast et l'adresse de la source émettrice correspondante. Le serveur central de gestion SC établit alors un programme de diffusion en associant à chaque zone au moins un flux multicast sélectionné et un horaire de diffusion. En fait, la plateforme de gestion du is contenu multicast joue ici un rôle de régie de production.

2. A l'instant prévu par le programme de diffusion, le serveur central de gestion SC émet un ordre de souscription au terminal pilote TP de la zone de diffusion ZD concernée. Cet ordre précise les adresses IP du groupe et celle de la source multicast auxquels le terminal pilote doit s'abonner.

3. Le terminal pilote TP interprète l'ordre de souscription et émet une demande selon le protocole IGMPv3 sur son sous-réseau IP en précisant le groupe et la source multicast désirés.

4. La demande de souscription émise par le terminal pilote est reçue et traitée par le routeur d'accès de la zone de diffusion qui l'encapsule et la transmet dans le tunnel IP dont l'extrémité est le routeur d'accès du fournisseur de services concerné. En fait, le routeur d'accès de la zone détermine la bonne extrémité de tunnel grâce à l'adresse de la source émettrice indiquée dans le message de souscription au protocole IGMPv3.

5. Le routeur d'accès du fournisseur de services, recevant une demande de souscription sur l'interface du tunnel IP, fait suivre le flux multicast dont l'adresse IP correspond à celle demandée vers l'extrémité du tunnel, à savoir le routeur d'accès de la zone de diffusion. En d'autres termes, le flux multicast est encapsulé dans le tunnel dont l'origine est le routeur d'accès de la zone ZD d'où émane la dernande de souscription multicast.

6. Le routeur d'accès de la zone de diffusion désencapsule les données multicast et les fait suivre, en multicast, sur son sous-réseau IP dont font partie les points d'accès. Le flux multicast est alors reçu par l'interface du terminal de l'utilisateur final mais n'est pas remonté vers les couches applicatives avant que ce dernier n'en fasse la demande.

7. Afin de pouvoir consommer le service IP multicast, l'application multicast embarquée par terminal de l'utilisateur client émet une demande de souscription concernant le flux multicast désiré, ce flux étant déjà reçu au niveau de l'interface. Cette demande a en fait une portée limitée à l'interface et ne peut concerner que le flux auquel le terminal pilote s'est préalablement abonné. En effet, si le flux demandé n'est pas présent sur l'interface, la demande reste vaine car elle n'est pas propagée dans le réseau.

Le processus décrit ci-dessus est limité à une seule zone de diffusion pour des raisons de simplification de la description. Cependant, si plusieurs zones de diffusion devaient être concernées par la diffusion d'un même contenu multicast, c'est à dire en provenance d'une même source multicast, on répétera simplement les étapes 2 à 7 pour chaque zone.

Enfin, on notera que cette architecture et l'utilisation du protocole IGMPv3 permet d'attribuer une même adresse multicast à des flux multicast différents, à savoir issus de sources multicast différentes. Cette caractéristique facilite l'interconnexion avec des fournisseurs de services indépendants qui peuvent très bien utiliser les mêmes adresses IP multicast pour leurs contenus.

Claims (12)

REVENDICATIONS

1. Système de transmission de flux multidiffusion entre au moins une source de flux multidiffusion d'au moins un fournisseur de services et au moins une zone de diffusion comprenant une pluralité de terminaux utilisateurs, caractérisé en ce que ledit système comprend: - un serveur central de gestion des flux multidiffusion, - un terminal pilote associé à chaque zone de diffusion, ledit serveur central de gestion étant apte à : * recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles, * sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone, et ledit terminal pilote étant apte à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.

2. Système selon la revendication 1, caractérisé en ce que ledit serveur central de gestion est apte à recevoir du fournisseur de services une adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice.

3. Système selon la revendication 2, caractérisé en ce que l'adresse de ladite source émettrice est incluse dans ladite demande de souscription.

4. Système selon la revendication 3, caractérisé en ce qu'un routeur d'accès destiné à acheminer ladite demande de souscription dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.

5. Système selon l'une des revendications 3 ou 4, caractérisé en ce que ladite demande de souscription est effectuée selon le protocole IGMPv3.

6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le message du serveur central au terminal pilote comprend également une authentification dudit message.

7. Serveur central de gestion pour un système de transmission de flux multidiffusion selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit serveur est apte à : * recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles, * sélectionner parmi les flux disponibles au moins un flux multidiffusion ro à diffuser dans ladite zone.

10. Serveur central de gestion selon la revendication 7, caractérisé en ce qu'il est apte à recevoir du fournisseur de services une adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice.

11. Serveur central de gestion selon des revendications 7 ou 8, caractérisé en ce que le message du serveur central au terminal pilote comprend également une authentification dudit message.

12. Produit programme d'ordinateur pour un serveur central de gestion selon la revendication 7, caractérisé en ce qu"il comprend des instructions de code de programme sur un support lisible par un ordinateur pour la mise en oeuvre des opérations consistant à : * recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles, * sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone, lorsque ledit programme est exécuté sur un ordinateur dudit serveur central de gestion.

11. Terminal pilote pour un système cle transmission de flux multidiffusion selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit terminal pilote est apte à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la rs zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.

12. Produit programme d'ordinateur pour un terminal pilote selon la revendication 11, caractérisé en ce qu'il comprend des instructions de code de programme sur un support lisible par un ordinateur pour la mise en oeuvre des opérations consistant à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.

ro 13. Routeur d'accès pour un système cle transmission de flux multidiffusion selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit routeur d'accès, destiné à acheminer ladite demande de souscription, dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.