FR2875356A1 - Decouverte et selection intelligente dans un reseau de multidiffusion - Google Patents

Abstract

L'invention concerne un procédé de distribution de données dans un réseau de multidiffusion (encore appelé « réseau multicast ») comprenant au moins un groupe de multidiffusion (encore appelé « groupe multicast »).Le procédé comprend la mise en oeuvre d'un serveur d'annonces distant apte à mettre à disposition d'un ou plusieurs récepteurs des données utiles relatives à un ou plusieurs serveurs de source de données, chaque serveur de source de données pouvant délivrer des données sur au moins un groupe multicast. Lesdites données utiles sont aptes à être lues ultérieurement afin qu'un choix d'un ou plusieurs de ces serveurs source puisse alors être établi par l'intermédiaire de moyens de sélection.L'invention concerne aussi le serveur d'annonces et le système permettant de mettre en oeuvre ce procédé.

Description

L'invention concerne la distribution de données dans un réseau de

multidiffusion (encore appelé réseau multicast ) comprenant au moins un groupe de multidiffusion (encore appelé groupe multicast ), chaque groupe multicast étant alimenté en données diverses par des serveurs de

source de données (encore appelés serveurs source ), ces données pouvant alors être lues à distance par des terminaux utilisateurs connectés au réseau multicast.

Le mécanisme multicast, par exemple internet ( IP ) ou autre, permet aujourd'hui de diffuser sur une architecture multicast une même information 10 vers un nombre quasiment illimité d'utilisateurs.

En particulier, la technologie Internet de multidiffusion (encore appelée technologie IP Multicast ), normalisée par l'IETF (Internet Engineering Task Force), vise à permettre la diffusion de paquets de données (texte, son, vidéo, etc.) à plusieurs adresses IP simultanément. Cet aménagement permet de traiter les applications de diffusion en minimisant les volumes de paquets circulant sur le Réseau. A cet effet, l'IETF a réattribué une plage d'adresses IP (dite de classe D) allant à ce jour de 224.0.1.0 à 239.255.255.255.

Un protocole appelé IGMP (Internet Group Management Protocol) permet à tout terminal utilisateur de s'inscrire à l'adresse IP de groupe d'un groupe multicast qui l'identifie, afin de recevoir les contenus susceptibles d'être diffusés à ce groupe particulier.

En référence à la figure 1, est illustrée le mécanisme de fonctionnement de la version 2 d'IGMP (notée IGMPv2). L'utilisateur fait une requête 40, via son terminal 300, d'un contenu multicast, identifié par une adresse IP (classe IP 224.0.0.0/8), grâce à ce protocole IGMPv2. L'informationrequête fournie par IGMPv2 joue alors le rôle d'interface de commande entre l'utilisateur 300 et le réseau 200. A l'issue de la demande IGMP formulée par l'utilisateur 300, les protocoles réseaux se chargent ensuite d'acheminer de façon optimale le flux multicast 50 de l'ensemble des serveurs source 100 (ici les flux de données 51, 52, 53 provenant des serveurs source 101, 102 et 103) vers l'utilisateur 300.

L'IGMPv2 possède cependant une limitation: aujourd'hui plusieurs serveurs source (101, 102, 103,...) peuvent émettre sur une même adresse 35 IP multicast. Lorsqu'un utilisateur 300 fait une requête IGMPv2 pour un flux 2 2875356 50, il risque alors de récupérer l'ensemble du trafic émis par l'ensemble 100 des serveurs source.

En référence à la figure 2, une nouvelle version du protocole IGMP, IGMP version 3 (IGMPv3), tente de pallier ce problème en fournissant une interface plus évoluée. Cette interface permet à un utilisateur 300 de requérir (en 40) non plus une adresse multicast seule mais le couple (adresse multicast; adresse du serveur source 103). IGMPv3 autorise donc le terminal 300 à recevoir les données du flux IP multicast en provenance seulement du ou des serveur(s) source(s) qu'il a requis. IGMPv3 permet ainsi un filtrage par le serveur source et offre une plus grande souplesse dans le déploiement des services multicast. On voit sur la figure 2, que le terminal utilisateur 300 ne reçoit que le flux 53 (représenté par une flèche pleine) provenant du serveur source 103 qu'il a requis, et non les flux de données 51 et 52 provenant respectivement des serveurs source 101 et 102 (représentés respectivement par des flèches en pointillé et en étoile).

Cependant, si cette dernière version IGMPv3 semble améliorer la situation en diminuant sensiblement le nombre d'informations échangées sur le réseau 200 et en proposant à l'utilisateur 300 une possibilité de choisir le ou les serveur(s) source de son choix parmi l'ensemble 100 de ceux qui alimentent son ou ses groupe(s) multicast, elle ne permet pas de fournir à l'utilisateur les critères pour établir ce choix, hormis le critère lié à la connaissance personnelle qu'il a du serveur source.

Or la technologie multicast donnant la possibilité de combiner facilement les offres d'une pluralité de fournisseurs de service (i.e. serveurs source) sur des systèmes de transmissions variés, et qu'avec la multiplication des services proposés (télévision, téléphone, données et applications internet,...) à des débits différents (faible débit, débit ADSL, débit de câble, ...), avec la diversification des supports de transmission des données (câble, réseau téléphonique, hertzien, optique,.. .) et des terminaux 300 de réception (ordinateur, téléphone portable, PDA, STB,...), avec l'augmentation et la diversification des sources de données, il peut s'avérer que ce choix de serveur(s) source à l'aveugle (i.e. sans connaissance de caractéristiques techniques du serveur source) ne soit pas adapté, par exemple au service auquel l'utilisateur est abonné et/ou au terminal qu'il utilise.

La vitesse des échanges d'informations et l'encombrement du réseau ne sont donc pas encore suffisamment optimisés.

Un premier objectif de l'invention est de permettre à l'utilisateur 300 de découvrir des serveurs source multicast, notamment pour le protocole 5 IGMPv3.

Un deuxième objectif de l'invention est de présenter à l'utilisateur 300 des caractéristiques de sources multicast afin qu'il puisse établir un choix intelligent d'un contenu multicast.

Un troisième objectif de l'invention est d'engendrer ainsi une 10 optimisation des architectures multicast et des services multicast "intelligents".

A ces effets, l'invention propose, selon un premier aspect, un procédé de distribution de données dans un réseau de multidiffusion (encore appelé réseau multicast ) comprenant au moins un groupe de multidiffusion (encore appelé groupe multicast ), caractérisé en ce qu'il comprend la mise en oeuvre d'un serveur d'annonces distant apte à mettre à disposition d'un ou plusieurs récepteurs des données utiles relatives à un ou plusieurs serveurs de source de données, chaque serveur de source de données pouvant délivrer des données sur au moins un groupe multicast, lesdites données utiles étant aptes à être lues ultérieurement afin qu'un choix d'un ou plusieurs de ces serveurs source puisse alors être établi par l'intermédiaire de moyens de sélection.

D'autres caractéristiques possibles de ce procédé sont: - lesdites données utiles comprennent au moins un des champs suivants: identification de chaque serveur source; information sur la localisation de chaque serveur source; bande passante du flux délivré par chaque serveur source; identification des terminaux adaptés à chaque serveur source; disponibilité de chaque serveur source; - les données utiles sont mises à disposition selon un format structuré, 30 au moyen par exemple de balises au format XML; - une première étape supplémentaire de réception et de lecture des données utiles par au moins un des récepteurs, et une deuxième étape supplémentaire consistant audit choix d'un ou plusieurs serveurs source à partir de la lecture des données utiles par l'intermédiaire desdits moyens de sélection; - le récepteur est un serveur multidiffusion (encore appelé serveur multicast ), et les moyens de sélection sont localisés sur ce serveur multicast ou sur un terminal utilisateur recevant alors au moins une partie des données utiles diffusées par le serveur multicast; - le récepteur est un terminal utilisateur, et les moyens de sélection sont localisés sur ce terminal utilisateur; - le serveur d'annonces délivre les informations utiles sur un réseau unidiffusion (encore appelé réseau unicast ) ; - le serveur d'annonces délivre les informations utiles sur un réseau multicast, le serveur d'annonces étant alors lui-même un serveur de source de données pouvant délivrer les données utiles sur au moins un groupe multicast; - les moyens de sélection sont actionnées manuellement ou sont actionnés automatiquement par un exécutable adapté à partir de paramètres de sélection déterminés; - les données utiles relatives à chaque serveur source sont ensuite stockées en mémoire; - les données utiles relatives à chaque serveur source sont ensuite stockées en mémoire dans au moins un terminal utilisateur; - le procédé comprend en outre la mise en oeuvre d'un logiciel applicatif qui permet de consulter les données utiles stockées en mémoire, de permettre de choisir manuellement ou automatiquement au moins un serveur source parmi ceux pour lesquels les données utiles sont stockées à partir de paramètres de sélection déterminés, d'émettre une requête vers chaque serveur de données ainsi choisi, et de recevoir un flux de données de chaque serveur source ainsi requis; - la requête est de type IGMPv3.

Selon un deuxième aspect, l'invention propose un programme d'ordinateur mettant en oeuvre le logiciel applicatif.

Selon un troisième aspect, l'invention propose un serveur d'annonces connecté à un réseau de multidiffusion (encore appelé réseau multicast ) comprenant au moins un groupe de multidiffusion (encore appelé groupe multicast ), caractérisé en ce qu'il est apte, à distance, à mettre à disposition d'un ou plusieurs récepteurs des données utiles relatives à un ou plusieurs serveurs de source de données, chaque serveur de source de données pouvant délivrer des données sur au moins un groupe multicast, lesdites données utiles étant aptes à être lues ultérieurement afin qu'un choix d'un ou plusieurs de ces serveurs source puisse alors être établi par l'intermédiaire de moyens de sélection.

D'autres caractéristiques possibles de ce serveur d'annonces sont: - il est apte à recevoir d'au moins un serveur source, à travers le réseau multicast ou unicast, des données utiles et, après les avoir éventuellement analyser et interpréter, à les mettre à disposition en aval sous un format structuré ; - le format structuré est un format XML; - il est apte à délivrer les données utiles sur un réseau unidiffusion (encore appelé réseau unicast ) ; - il est apte à délivrer les données utiles sur un réseau multicast, le serveur d'annonces étant alors lui-même un serveur de source de données pouvant délivrer les données utiles sur au moins un groupe multicast.

Selon un quatrième aspect, l'invention propose un système de distribution de données dans un réseau de multidiffusion (encore appelé réseau multicast ) comprenant au moins un groupe de multidiffusion (encore appelé groupe multicast ), caractérisé en ce qu'il comprend: É au moins un serveur de source de données distant; É ledit serveur d'annonces; É des moyens de lecture des données utiles fournies à distance par le serveur d'annonces; É des moyens de sélection d'au moins un serveur de sources de données à partir des données utiles lues.

D'autres caractéristiques de ce système sont: - les moyens de lecture sont situés sur un serveur multidiffusion (encore appelé serveur multicast ), et en ce que les moyens de sélection sont localisés sur ce serveur multicast ou sur un terminal utilisateur recevant alors au moins une partie des données utiles diffusées par le serveur multicast; - les moyens de lecture sont inclus dans un terminal utilisateur, et en ce que les moyens de sélection sont localisés sur ce terminal utilisateur; - les moyens de sélection sont actionnables manuellement ou sont actionnables automatiquement par un exécutable adapté à partir de paramètres de sélection déterminés; - le système comprend en outre une mémoire pour stocker les 5 données utiles relatives à chaque serveur source; - cette mémoire est incluse dans au moins un terminal utilisateur; - le système comprend en outre les moyens pour mémoriser et mettre en oeuvre un logiciel applicatif qui permette de consulter les données utiles stockées en mémoire, de permettre de choisir manuellement ou automatiquement au moins un serveur source parmi ceux pour lesquels les données utiles sont stockées à partir de paramètres de sélection déterminés, d'émettre une requête vers chaque serveur de données ainsi choisi, et de recevoir un flux de données de chaque serveur source ainsi requis; - la requête est de type IGMPv3.

D'autres caractéristiques, buts et avantages de l'invention apparaîtront mieux à la lecture de la description détaillée suivante de l'invention, donnée à titre d'exemple non limitatif et faite en référence aux dessins annexés auxquels La figure 1 représente schématiquement un mécanisme de fonctionnement de la version 2 d'IGMP (notée IGMPv2).

La figure 2 représente schématiquement un mécanisme de fonctionnement de la version 3 d'IGMP (notée IGMPv3).

La figure 3 représente schématiquement les parties principales comprises dans un système de diffusion de données selon l'invention.

La figure 4 représente un système de distribution de données dans un réseau multicast selon l'invention, accompagné d'exemples illustratifs de mise en oeuvre.

La figure 5 représente un procédé de mise en oeuvre d'un procédé 30 selon l'invention au niveau de l'utilisateur.

Les figures 6a et 6b représentent un premier exemple d'application de l'invention pour, respectivement, le cas d'un réseau de type WAN et d'un réseau de type hertzien.

La figure 7 représente un deuxième exemple d'application de 35 l'invention.

La figure 8 représente un troisième exemple d'application de l'invention.

En référence à la figure 3, le système pouvant mettre en oeuvre l'invention est composé de trois parties principales: l'ensemble 100 des serveurs source de données; le réseau 200; l'ensemble 300 des terminaux utilisateur.

L'ensemble 100 des serveurs source recouvre tout type de serveurs source alimentant un ou plusieurs groupe(s) multicast. Chacun de ces serveurs source est donc repéré par son adresse IP personnelle et par une adresse de groupe multicast. Ces serveurs source peuvent être de simples sources de données passives (délivrant alors de simples informations sur requête de l'utilisateur) ou des sources de données actives (qui permettent une certaine interactivité à distance avec l'utilisateur au moyen d'une interface). Les données envoyées peuvent être de tout type (sonores, vidéos, des fichiers, télévisuelles, etc.).

Le réseau 200 comprend au moins une partie multicast, c'est à dire qu'il comprend au moins un serveur multicast gérant au moins un groupe multicast. Ces groupes multicast sont alimentés en données par l'ensemble 100 des serveurs source. Le réseau 200 peut aussi comprendre des transmissions en mode unidiffusion (encore appelé unicast ), notamment pour ce qui est de la transmission de données vers certains utilisateurs. Des fournisseurs de service Internet peuvent par exemple se charger d'encapsuler ces données en format IP. Ce sont des routeurs IP, parmi tous ceux qui relaient les paquets sur toute l'étendue d'Internet, qui gèrent à ce jour une grande partie de l'IP multicast et unicast. La transmission des données peut être réalisée par toutes les voies possibles: réseau téléphonique, réseau câblé, fibre optique, voie aérienne (par satellite, au moyen de stations de base, relais, etc.), ou autres...

L'ensemble 300 des terminaux utilisateur reçoit les flux de données envoyées par des serveurs source via le réseau 200. Ces terminaux utilisateur peuvent être de tous types, tels qu'un ordinateur fixe 301, un ordinateur portable 302, un assistant numérique personnel 303 (ou PDA pour Personal Digital Assistant ), un téléphone portable 304, un boîtier décodeur 305 (ou STB pour Set Top Box ), une passerelle IGMP 306. L'ensemble 300 de ces terminaux doit nécessairement pouvoir se connecter au réseau 200 (via par exemple une interface IP), et comprendre donc des moyens pour s'y connecter et pour éventuellement y naviguer. Un terminal peut ainsi avoir une interface IP multicast, avec par exemple des capacités multicast IGMPv3.

Ainsi, l'invention s'applique très bien aux architectures IP multicast (réseau fixe, sans fil, mobile) qui supportent l'interface IGMPv3.

En référence à la figure 4, une entité particulière, un serveur d'annonces 400, est à ajouter à l'architecture du système selon l'invention.

Ce serveur d'annonces 400 est localisé sur le réseau 200. Son rôle est d'annoncer des serveurs sources multicast (référencés ici 101, 102, 103, 104, 105, 106) et de renseigner sur des données utiles (telles que des caractéristiques techniques) y afférant.

A cet effet, ce serveur d'annonces 400 est connecté (via le réseau 200 multicast ou privé unicast) à des serveurs source déterminés (101, 102, 103, 104, 105, 106), ceux-ci alimentant un ou plusieurs groupes multicast. Cette connexion permet au serveur d'annonces de recevoir de ces serveurs source des données lui permettant d'être renseigné sur des caractéristiques particulières de ces serveurs source: par exemple, le serveur d'annonces 400 peut ainsi connaître le débit, l'adresse, la bande passante, la localisation de chacun des serveurs source. Ces caractéristiques peuvent être calculées au niveau du serveur d'annonces et/ou fournies par chacun des serveurs source concernés. En particulier, ces caractéristiques pourront être régulièrement réactualisées.

Ce serveur d'annonces 400 est donc apte à organiser et à structurer ces caractéristiques de serveurs source pour mettre ensuite à disposition d'un ou plusieurs récepteurs (tels qu'un terminal utilisateur, un opérateur ou un autre serveur) des données utiles relatives aux serveurs source. Ces données utiles délivrées par le serveur d'annonces étant choisies pour aider à un choix ultérieur judicieux (établi au niveau du terminal utilisateur, d'un opérateur ou d'un serveur) d'un ou plusieurs de ces serveurs source.

Ces données utiles peuvent comprendre au moins une des informations suivantes: (1) identification de chaque serveur source; (2) information sur la localisation de chaque serveur source (localisation spatiale, ...) ; (3) bande passante du flux délivré par chaque serveur source; (4) disponibilité de chaque serveur source (date de début d'émission de données, date de fin d'émission de données).

Ces dernières données utiles peuvent être obtenues assez directement. Le serveur d'annonces peut aussi, en complément ou en alternative, fournir au moins une des données utiles suivantes (5) identification des terminaux adaptés à chaque serveur source; (6) priorités données à un serveur source vis à vis d'un autre serveur source.

Ces dernières données utiles peuvent en particulier prendre en compte les caractéristiques techniques des serveurs source (dont les données utiles (1) à (4) listées précédemment font partie).

On pourra par exemple identifier des terminaux adaptés (téléphone mobile, ordinateur, PDA, STB,...) à chaque serveur source par une analyse du débit de chaque serveur source.

On pourra par exemple donner une priorité à un serveur source plutôt qu'à un autre, ces deux serveurs source fournissant un même type de données, sur la base qu'ils n'ont pas les mêmes caractéristiques techniques (pas la même bande passante, pas le même débit, etc.).

On pourra aussi donner des priorités d'un serveur source sur un autre serveur source selon le terminal utilisé. Ainsi, par exemple, une priorité pourra être attribuée à un premier serveur source vis à vis d'un deuxième serveur source lorsque le terminal utilisé est un téléphone portable, et au contraire une priorité pourra être attribuée au deuxième serveur source vis à vis du premier serveur source lorsque le terminal utilisé est un ordinateur connecté sur l'ADSL (on pourra utiliser par exemple la donnée utile débit ou localisation pour déterminer les priorités).

Afin de pouvoir être reçues et lues ultérieurement par différents types de récepteurs, ces données utiles sont structurées. On pourra par exemple utiliser des balises XML (contenues dans un fichier de données utiles) comme structure pour transporter les données utiles (voir par exemple Annexes 1 et 2).

Le serveur d'annonces 400 implémente donc un modèle de données utiles défini par l'invention.

Dans le modèle présenté par l'algorithme XML en Annexe 1 et présenté schématiquement en annexe 2, on retrouvera dans l'ensemble des groupes multicast ( IGMPv3SourceManagement ), chaque groupe multicast ( SinglelGMPv3Service ) avec son adresse IP multicast ( MulticastAddress ), puis chaque serveur source ( SSMSource ) avec son adresse IP unicast ( SourceAddress ) dans chaque groupe multicast.

Dans le fichier XML, pourront être retrouvés ainsi, pour chaque serveur source, les critères génériques (dans SourceClassifier ) caractérisant un serveur source (ici un serveur source de type IGMPv3), au moyen par exemple des balises suivantes: - Prioritylnformation: de type entier ; Cet élément est conforme 15 à la donnée utile (6) précédemment évoquée.

Exemple d'utilisation: Via cette balise on peut envisager un mécanisme de diffusion multicast redondant où pour un même flux on dispose de deux serveurs source multicast: un primaire et un secours. En référence à la figure 4, l'utilisateur 312 choisira ainsi le serveur source 105 comme serveur source primaire et plutôt le serveur source 106 comme serveur source secondaire, même si les serveurs source 105 et 106 alimentent le même groupe multicast sur lequel l'utilisateur 312 est connecté.

- NetworkLocationlnformation: de type string ; Cet élément est une chaîne de caractères qui fournit une information sur la localisation du serveur source (conformément à la donnée utile (2) précédemment évoquée). La localisation peut par exemple être un ensemble ( pool ) d'adresses IP, une cellule GSM, une coordonnée GPS, une borne Wifi etc...

Exemple d'utilisation: Cette balise peut permettre à un opérateur réseau de répartir sur son réseau plusieurs sources pour un même flux. En référence à la figure 4, l'utilisateur 301 choisira, grâce à cette balise, le serveur source 101, et l'utilisateur 302 le serveur source 102, pour des raisons de localisation, et même si les serveurs source 101 et 102 alimentent le même groupe multicast sur lequel les utilisateurs 301 et 310 sont connectés. Est ainsi limité la propagation du flux multicast et sont ainsi améliorés les temps de transit du flux multicast.

Bandwidthlnformation: de type long; Cet élément fournit en Kbits/s le débit du flux en sortie du serveur source (conformément à la donnée utile (3) précédemment évoquée).

Exemple d'utilisation: Il peut permettre de définir pour un même flux plusieurs serveurs source délivrant chacune le même contenu mais à des débits différents (ex. 512Kbit/s, 1 Mbits/s, 2Mbits/s...). L'utilisateur peut alors se connecter à la source qui délivre le flux en accord avec son contrat de service, autrement dit avec la bande passante qu'il dispose en réception.

En référence à la figure 4, l'utilisateur 304 (utilisant ici un terminal de type téléphone mobile ) choisira ainsi plutôt le serveur source 103 qui délivre 64kOctets/s alors que l'utilisateur 311 (utilisant ici un terminal de type ordinateur sur ADSL ) choisira plutôt le serveur source 104 qui délivre 1M Octets/s), même si les serveurs source 103 et 104 alimentent le même groupe multicast sur lequel les utilisateurs 304 et 311 sont connectés.

- TargetTerminallnformation: de type string; Cet élément fournit des caractéristiques techniques sur le terminal que vise la source (conformément à la donnée utile (5) précédemment évoquée).

Ex d'utilisation: Identification du type de terminal (PDA, PC), des capacités d'accès réseau du terminal...

- SourceAvailabilitylnformation: de type complexe; Cet élément fournit les heures de début et de fin de disponibilité de la source multicast (conformément à la donnée utile (4) précédemment évoquée).

Exemple d'utilisation: Il peut permettre d'éviter à un serveur de 25 source multicast d'émettre en permanence. Par exemple stopper 3 serveurs source multicast sur 4 en heures creuses.

On pourra aisément imaginer d'autres types de balises (i.e. données utiles) représentant ultérieurement des critères de sélection de serveurs source.

On pourra aussi combiner entre eux ces critères de sélection pour donner de nouveaux critères de sélection.

Sur requête, le serveur d'annonces 400 délivre alors en 60 ces données utiles en mode multicast (le serveur d'annonces 400 étant alors lui-même un serveur de source de données) ou en mode unicast au travers du même réseau que les flux multicast où au travers d'un réseau à part.

Le protocole d'annonce et de sélection des sources multicast IGMP peut ainsi par exemple se présenter comme suit: une couche de données utiles au format XML.

- une couche transport multicast sur UDP/IP pour bénéficier d'une distribution optimale des données utiles ou une couche unicast sur TCP/IP pour une distribution à la demande. Si l'annonce se fait en multicast, l'adresse IP multicast de diffusion doit être connue des terminaux.

Ces données utiles (ou encore le fichier structuré , par exemple en XML) sont alors reçues et lues à distance du serveur d'annonces 400, par au moins un des récepteurs qui a requis ces données utiles, le récepteur étant par exemple un terminal utilisateur 301, 310, 304, 311, 305 ou 312 et/ou un serveur relayant ces données vers des terminaux, en multicast ou en unicast.

Une fois que ces données utiles ont été reçues et lues par le récepteur, est établi un choix, par l'intermédiaire de moyens de sélection, d'un ou plusieurs serveurs source, en se basant sur les données utiles lues.

Ce choix peut être opéré au niveau du récepteur lui-même. Les moyens de sélection sont alors localisés sur ce récepteur.

Dans le cas où le récepteur est un serveur ou un opérateur, au moins une partie des données utiles peuvent alors être transmises (au moyen d'un mode multicast ou unicast ) au terminal utilisateur (301, 310, 304, 311, 305 ou 312) qui opère alors le choix. Les moyens de sélection sont alors localisés sur ce terminal.

Les moyens de sélection peuvent être actionnés manuellement (clavier, souris, écran tactile,...) ou être actionnés automatiquement par exemple par un exécutable adapté à partir de paramètres de sélection déterminés.

Les données utiles relatives à chaque serveur source (choisi ou non) 30 sont ensuite éventuellement stockées en mémoire, par exemple au niveau du terminal utilisateur ou au niveau d'un serveur.

L'utilisateur 301, 310, 304, 311, ou 312 peut alors, en connaissance des données utiles relatives aux serveurs source, envoyer une requête 40 vers le ou les serveur(s) source qu'il a sélectionné(s) pour que celui-ci lui envoie en 50 les données qu'il possède. Cette requête 40 peut être par exemple de type IGMPv3 (comme définie précédemment).

En référence à la figure 5, est présenté un exemple de mise en oeuvre de l'invention au niveau de l'utilisateur, ou plutôt de son terminal.

L'utilisateur se connecte, via l'interface utilisateur 1200 de son terminal, sur le canal du serveur d'annonces de serveurs de sources multicast (par exemple IGMPv3) ou se connecte à un serveur Internet (qui a lui-même récupéré les données utiles du serveur d'annonces) et récupère alors en 10 les données utiles (c'est à dire, pour chaque groupe multicast, la liste des serveurs sources et les données utiles).

L'utilisateur stocke alors en 20 dans la mémoire 1300 du terminal les données utiles. Le protocole de transport pourra inclure un mécanisme spécifique afin de détecter une mise à jour éventuelle des données utiles prenant en compte les sélections qui viennent d'être réalisées des sourcesmulticast. Les données utiles peuvent ensuite être utilisées par une couche applicative 1400 (i.e. un logiciel applicatif) prévue dans le terminal, afin d'établir le choix d'une source multicast de façon "intelligente", à partir de ces données utiles.

Le logiciel applicatif 1400 permet ainsi de consulter les données utiles stockées en mémoire, et de permettre de choisir manuellement ou automatiquement (via des moyens de sélection) au moins un serveur source parmi ceux pour lesquels les données utiles sont stockées. Si ce choix est établi automatiquement, il peut cependant être dépendant de paramètres de sélection généraux prédéterminés, ou déterminés antérieurement par l'utilisateur. Ce logiciel applicatif 1400, une fois que la sélection est faite, permet d'émettre une requête 40 vers chaque serveur de données ainsi sélectionné, et de recevoir en 50 un flux de données de chaque serveur source ainsi requis.

Cette couche applicative 1400 pourra aussi réaliser une mise à jour 30 de la base de données utiles (localisée dans la mémoire 1300), en prenant en compte la sélection qui vient d'être faite.

Ainsi, le procédé de l'invention permet d'une part d'annoncer à l'utilisateur les serveurs source et d'autre part d'offrir un moyen de classifier ces serveurs source en fonction de certains critères, permettant ainsi à un utilisateur (via son groupe multicast ou sa connexion unicast) de choisir la source multicast la plus judicieuse pour lui.

Contrairement aux techniques précédentes, l'invention permet donc de définir comment le terminal utilisateur peut découvrir et choisir, sciemment, un ou plusieurs serveur(s) source(s), et par exemple s'y abonner (en stockant en mémoire 1300).

Exemple 1:

En référence à la figure 6, ce premier exemple illustre une application de ladite balise "NetworkLocationlnformation". Cette balise fournit une information sur la localisation des serveurs source 101 et 102 d'un flux multicast. En référence à la figure 6a, cette balise peut être utilisée par un terminal fixe 301, par exemple localisé sur un réseau 200 de type WAN, pour recevoir le flux en 50 (après requête 40) du serveur source multicast 101 le plus proche ou bien, en référence cette fois. à la figure 6b, par un terminal mobile 303 pour se raccrocher au serveur source diffusant dans sa cellule (on voit ici que le terminal mobile 303 effectue un déplacement 90; il passe alors de la cellule 201 à la cellule 202, et peut changer de serveur source (de 101 à 102) grâce à la balise de localisation).

Avantages pouvant être procurés par l'utilisation de cette balise: optimisation de la diffusion des contenus multicast sur les réseaux 20 WAN.

- amélioration de la QoS, limitation des temps de transit.

gestion de la mobilité, continuité de service.

Exemple 2:

En référence à la figure 7, ladite balise "Bandwidthlnformation" est utilisée dans cet exemple pour permettre à des terminaux 301 hétérogènes (en terme de débits) de se raccrocher au serveur source 102 qui délivre le service en accord avec leur contrat de services. Ainsi, un terminal 301 raccordé à une liaison ADSL 512Kbits se connectera à la source délivrant le service à un débit de 512Kbits alors qu'un second terminal avec une bande passante supérieure, égale par exemple à 2Mbits, se connectera sur le serveur source 101 délivrant le même service mais à une qualité nettement supérieure à la source 512Kbits.

Avantages pouvant être procurés par l'utilisation de cette balise: Homogénéisation des services.

Exemple 3:

En référence à la figure 8, on propose ici d'illustrer ladite balise "TargetTerminallnformation". Cette balise peut être par exemple utilisée dans un contexte où un terminal 303 possède plusieurs interfaces réseaux, par exemple un terminal mobile avec une interface GPRS et une interface UMTS. L'utilisation de la balise "TargetTerminallnformation" peut permettre de caractériser quels terminaux sont visés par un serveur source 101 ou 102. On peut donc considérer qu'un serveur source 101 se charge de diffuser sur le réseau 201 un service pour les terminaux GPRS et un autre serveur source 102 se charge de diffuser sur le réseau 202 le même service pour les terminaux UMTS. Lors du déplacement 90 du terminal 303, celui-ci va alors pouvoir basculer d'une interface GPRS à une interface UMTS, sans perdre les données reçues.

Avantages pouvant être procurés par l'utilisation de cette balise: service personnalisé par parc de terminaux.

Annexe 1 <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmins:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="IGMPv3SourceManagement"> <xs:complexType> <xs:sequence> <xs:element name="SingletGMPv3Service" type="IGMPv3ServiceType" maxOccurs="unbounded"l> </xs:sequence> <Ixs:complexType> </xs:element> <xs:complexType name="IGMPv3ServiceType"> <xs:sequence> <xs:element name="MulticastAddress" type="xs:string"/> <xs:element name="Port" type="xs:integer" minOccurs="0"/> <xs:element name="SSMSource" type="OneSource" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ServiceName" type="xs:string"/> <xs:attribute name="SegID" type="Integerl6"/> </xs:complexType> <xs:complexType name="OneSource"> <xs:sequence> <xs:element name="SourceAddress" type="xs:string"/> <xs:element name="SourceClassifier" type="SourceClassifierType" rninOccurs="O"/> </xs:sequence> <xs:attribute name="SourceName" type="xs:string"l> </xs:complexType> <xs:complexType name="SourceClassifierType"> <xs:sequence> <xs:element name="PriorityInformation" type="xs:integer" minOccurs="0"/> <xs:element name="NetworkLocationlnformation" type="xs:string" minOccurs="0"/> <xs:element name="BandwidthInformation" type="xs:long" minOccurs="0"/> <xs:element name="TargetTerminallnformation" type="xs:string" minOccurs="0"/> <xs:element name="SourceAvailabilitylnformation" type="AvailabilityType" minOccurs="0"/> <xs:element narre="PrivateInformation" type="PrivateType" minOccurs="O" maxOccurs="unbounded"I> </xs:sequence> </xs:complexType> <xs:complexType name="PrivateType"> <xs:sequence> <xs:element name="Type" type="String64"/> <xs:element name="Value" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:complexType name="AvailabilityType"> <xs:sequence> <xs:element name="StartTime" type="xs:dateTime"/> <xs:element name="StopTime" type="xs:dateTime"/> <Ixs:sequence> </xs:complexType> <xs:simpleType name="String64"> <xs:restriction base="xs:string"> <xs:maxLength value="64"/> </xs: restriction> </xs:simpleType> <xs:simpleType name="Integerl6"> <xsrestriction base="xs:integer"> <xs:maxLength value="16'!> </xs:restriction> </xs:simpleType> </xs:schema> IGIv1Pv3ServiceType {-Mu Rica stAddress rOneSource SoutceAddress SSfvlSource - Source Classifer - ur -------------------------------1- -- Source Availaliilitylrrfornlation I I. ------ SottrceCla ssliter Type -------------------r- .",= Pt-Io n talion s ii - IletworkLocation Infonnation;; 3t:.y.7.s 37-7:s ':''i -Bandwidtlilnfor[nation - 7'i Tal yetTer minaIInlormation ------A vaiiabilityType Situ tme -StopTime

N

r. PrivateType ?Pnvatefittbrm O.m -Value

Claims (28)

REVENDICATIONS

1. Procédé de distribution de données dans un réseau de multidiffusion (encore appelé réseau multicast ) comprenant au moins un groupe de multidiffusion (encore appelé groupe multicast ), caractérisé en ce qu'il comprend la mise en oeuvre d'un serveur d'annonces distant apte à mettre à disposition d'un ou plusieurs récepteurs des données utiles relatives à un ou plusieurs serveurs de source de données, chaque serveur de source de données pouvant délivrer des données sur au moins un groupe multicast, lesdites données utiles étant aptes à être lues ultérieurement afin qu'un choix d'un ou plusieurs de ces serveurs source puisse alors être établi par l'intermédiaire de moyens de sélection.

2. Procédé selon la revendication précédente, caractérisé en ce que lesdites données utiles comprennent au moins un des champs suivants: identification de chaque serveur source; information sur la localisation de chaque serveur source; bande passante du flux délivré par chaque serveur source; identification des terminaux adaptés à chaque serveur source; disponibilité de chaque serveur source.

3. Procédé selon l'une des revendications précédentes, caractérisé en ce que les données utiles sont mises à disposition selon un format structuré.

4. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que les données utiles sont mises à disposition selon un format structuré au moyen de balises au format XML.

5. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une première étape supplémentaire de réception et de lecture des données utiles par au moins un des récepteurs, et une deuxième étape supplémentaire consistant audit choix d'un ou plusieurs serveurs source à partir de la lecture des données utiles par l'intermédiaire desdits moyens de sélection.

6. Procédé selon la revendication 5, caractérisé en ce que le récepteur est un serveur multidiffusion (encore appelé serveur multicast ), et en ce que les moyens de sélection sont localisés sur ce serveur multicast ou sur un terminal utilisateur recevant alors au moins une partie des données utiles diffusées par le serveur multicast.

7. Procédé selon la revendication 5, caractérisé en ce que le récepteur est un terminal utilisateur, et en ce que les moyens de sélection sont localisés sur ce terminal utilisateur.

8. Procédé selon la revendication précédente, caractérisé en ce que le 5 serveur d'annonces délivre les informations utiles sur un réseau unidiffusion (encore appelé réseau unicast ).

9. Procédé selon l'une des revendications 6 et 7, caractérisé en ce que le serveur d'annonces délivre les informations utiles sur un réseau multicast, le serveur d'annonces étant alors lui-même un serveur de source de données pouvant délivrer les données utiles sur au moins un groupe multicast.

10. Procédé selon l'une des revendications 5 à 9, caractérisé en ce que les moyens de sélection sont actionnées manuellement ou sont actionnés automatiquement par un exécutable adapté à partir de paramètres de sélection déterminés.

11. Procédé selon l'une des revendications précédentes, caractérisé en ce que les données utiles relatives à chaque serveur source sont ensuite stockées en mémoire.

12. Procédé selon l'une des revendications 1 à 10, caractérisé en ce 20 que les données utiles relatives à chaque serveur source sont ensuite stockées en mémoire dans au moins un terminal utilisateur.

13. Procédé selon l'une des deux revendications précédentes, caractérisé en ce qu'il comprend en outre la mise en oeuvre d'un logiciel applicatif qui permette de consulter les données utiles stockées en mémoire, de permettre de choisir manuellement ou automatiquement au moins un serveur source parmi ceux pour lesquels les données utiles sont stockées à partir de paramètres de sélection déterminés, d'émettre une requête vers chaque serveur de données ainsi choisi, et de recevoir un flux de données de chaque serveur source ainsi requis.

14. Procédé selon la revendication précédente, caractérisé en ce que la requête est de type IGMPv3.

15. Programme d'ordinateur mettant en oeuvre le procédé selon l'une des revendications 13 et 14.

16. Serveur d'annonces connecté à un réseau de multidiffusion (encore 35 appelé réseau multicast ) comprenant au moins un groupe de multidiffusion (encore appelé groupe multicast ), caractérisé en ce qu'il est apte, à distance, à mettre à disposition d'un ou plusieurs récepteurs des données utiles relatives à un ou plusieurs serveurs de source de données, chaque serveur de source de données pouvant délivrer des données sur au moins un groupe multicast, lesdites données utiles étant aptes à être lues ultérieurement afin qu'un choix d'un ou plusieurs de ces serveurs source puisse alors être établi par l'intermédiaire de moyens de sélection.

17. Serveur d'annonces selon la revendication précédente, caractérisé en ce qu'il est apte à recevoir d'au moins un serveur source, à travers le réseau multicast, des données utiles et, après les avoir éventuellement analyser et interpréter, à les mettre à disposition en aval sous un format structuré.

18. Serveur d'annonces selon la revendication précédente, caractérisé 15 en ce que le format structuré est un format XML.

19.Serveur d'annonces selon l'une des revendications 16 à 18, caractérisé en ce qu'il est apte à délivrer les données utiles sur un réseau unidiffusion (encore appelé réseau unicast ).

20.Serveur d'annonces selon l'une des revendications 16 à 19, caractérisé en ce qu'il est apte à délivrer les données utiles sur un réseau multicast, le serveur d'annonces étant alors lui-même un serveur de source de données pouvant délivrer les données utiles sur au moins un groupe multicast.

21.Système de distribution de données dans un réseau de multidiffusion (encore appelé réseau multicast ) comprenant au moins un groupe de multidiffusion (encore appelé groupe multicast ), caractérisé en ce qu'il comprend: au moins un serveur de source de données distant; un serveur d'annonces selon l'une des revendications 16 à 20 des moyens de lecture des données utiles fournies à distance par le serveur d'annonces; des moyens de sélection d'au moins un serveur de données à partir des données utiles lues.

22. Système selon la revendication précédente, caractérisé en ce que les moyens de lecture sont situés sur un serveur multidiffusion (encore appelé serveur multicast ), et en ce que les moyens de sélection sont localisés sur ce serveur multicast ou sur un terminal utilisateur recevant alors au moins une partie des données utiles diffusées par le serveur multicast.

23. Système selon la revendication 21, caractérisé en ce que les moyens de lecture sont inclus dans un terminal utilisateur, et en ce que les moyens de sélection sont localisés sur ce terminal utilisateur.

24. Système selon l'une des trois revendications précédentes, caractérisé en ce que les moyens de sélection sont actionnables manuellement ou sont actionnables automatiquement par un exécutable adapté à partir de paramètres de sélection déterminés.

25.Système selon l'une des quatre revendications précédentes, caractérisé en ce qu'il comprend en outre une mémoire pour stocker les données utiles relatives à chaque serveur source.

26. Système selon la revendication précédente, caractérisé en ce que la mémoire est incluse dans au moins un terminal utilisateur.

27. Système selon l'une des deux revendications précédentes, caractérisé en ce qu'il comprend en outre les moyens pour mémoriser et mettre en oeuvre un logiciel applicatif qui permette de consulter les données utiles stockées en mémoire, de permettre de choisir manuellement ou automatiquement au moins un serveur source parmi ceux pour lesquels les données utiles sont stockées à partir de paramètres de sélection déterminés, d'émettre une requête vers chaque serveur de données ainsi choisi, et de recevoir un flux de données de chaque serveur source ainsi requis.

28. Système selon la revendication précédente, caractérisé en ce que la requête est de type IGMPv3.