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

Decouverte et selection intelligente de serveurs dans un reseau de multidiffusion

Info

Publication number
EP1794983A1
EP1794983A1 EP05798962A EP05798962A EP1794983A1 EP 1794983 A1 EP1794983 A1 EP 1794983A1 EP 05798962 A EP05798962 A EP 05798962A EP 05798962 A EP05798962 A EP 05798962A EP 1794983 A1 EP1794983 A1 EP 1794983A1
Authority
EP
European Patent Office
Prior art keywords
server
data
multicast
source
useful data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05798962A
Other languages
German (de)
English (en)
Inventor
David Roy
Thierry Levesque
Franck Geslin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1794983A1 publication Critical patent/EP1794983A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Definitions

  • the invention relates to the distribution of data in a multicast network (also called “multicast network") comprising at least one multicast group (also called “multicast group”), each multicast group being supplied with various data by source servers of data (also called “source servers”), this data can then be read remotely by user terminals connected to the multicast network.
  • a multicast network also called “multicast network”
  • multicast group also called “multicast group”
  • source servers also called “source servers”
  • the multicast mechanism for example Internet (“IP”) or other, today allows to broadcast on a multicast architecture the same information to an almost unlimited number of users.
  • multicast Internet technology also called technology "IP Multicast”
  • I 1 IETF Internet Engineering Task Force
  • I 1 IETF Internet Engineering Task Force
  • I 1 IETF reassigned a range of IP addresses (so-called class D) to date from 224.0.1.0 to 239.255.255.255.
  • a protocol called IGMP Internet Group Management Protocol
  • IGMPv2 Internet Group Management Protocol
  • the user makes a request 40, via its terminal 300, a multicast content, identified by an IP address (IP class 224.0.0.0/8), with this IGMPv2 protocol.
  • IP class 224.0.0.0/8 IP address
  • the query-information provided by IGMPv2 then acts as a control interface between the user 300 and the network 200.
  • the network protocols are then loaded.
  • the IGMPv2 however has a limitation: today several source servers (101, 102, 103, ...) can emit on the same address
  • IP multicast When a user 300 makes an IGMPv2 request for a stream
  • IGMPv3 IGMP version 3
  • This interface allows a user 300 to request (at 40) not only a single multicast address but the pair (multicast address, address of the source server 103).
  • IGMPv3 therefore allows the terminal 300 to receive the multicast IP stream data from only the source server (s) it has requested.
  • IGMPv3 allows filtering by the source server and offers greater flexibility in the deployment of multicast services. It can be seen in FIG. 2 that the user terminal 300 only receives the stream 53 (represented by a full arrow) from the source server 103 that it has requested, and not the data streams 51 and 52 respectively originating from the source servers. 101 and 102 (represented by dashed and star arrows, respectively).
  • multicast technology gives the possibility of easily combining the offers of a plurality of service providers (ie source servers) on various transmission systems, and with the multiplication of services offered (television, telephone, data and internet applications).
  • service providers ie source servers
  • multiplication of services offered television, telephone, data and internet applications.
  • a plurality of service providers ie source servers
  • bit rates low bit rate, ADSL bit rate, cable bit rate, etc.
  • data transmission media cable, telephone network, terrestrial, optical, etc.
  • 300 receiving terminals computer, mobile phone, PDA, STB, ...)
  • this choice of server (s) source "blind"" is not suitable, for example the service to which the user is subscribed and / or the terminal he uses.
  • a first objective of the invention is to enable the user 300 to discover multicast source servers, in particular for the IGMPv3 protocol.
  • a second object of the invention is to provide the user 300 with characteristics of multicast sources so that he can establish an intelligent choice of multicast content.
  • a third objective of the invention is thus to generate an optimization of multicast architectures and "intelligent" multicast services.
  • the invention proposes, according to a first aspect, a method for distributing data in a multicast network (also called “multicast network”) comprising at least one multicast group (also called “multicast group”) , characterized in that it comprises the implementation of a remote announcement server capable of making available to one or more receivers useful data relating to one or more data source servers and / or to the streams delivered by these, each data source server can deliver data on at least one multicast group, said useful data being readable later so that a choice of one or more of these source servers can then be established by via selection means, and in that said payloads comprise at least one of the following fields: identification of each source server; bandwidth of the stream delivered by each source server; identification of terminals adapted to each source server; availability of each source server; priorities given to a source server vis-à-vis another source server.
  • said useful data comprise information on the location of each source server.
  • the useful data are made available in a structured format, for example using tags in XML format; a first additional step of receiving and reading the useful data by at least one of the receivers, and a second additional step consisting in said choice of one or more source servers from the reading of the useful data by means of said means of selection;
  • the receiver is a multicast server (also called a "multicast server"), and the selection means are located on this multicast server or on a user terminal then receiving at least a portion of the useful data broadcast by the multicast server;
  • the receiver is a user terminal, and the selection means are located on this user terminal;
  • the advertisement server delivers the useful information on a unicast network (also called “unicast network”);
  • the advertisement server delivers the useful information on a multicast network, the ad server then itself being a data source server that can deliver the payload data to at least one multicast group;
  • the selection means are actuated manually or are actuated automatically by an executable adapted from selected selection parameters;
  • the useful data relating to each source server are then stored in memory in at least one user terminal; the method further comprises the implementation of an application software that makes it possible to consult the useful data stored in memory, to allow manual or automatic selection of at least one source server among those for which the useful data are stored from selected selection parameters, to issue a request to each data server thus selected, and to receive a data stream from each source server thus required;
  • the request is of type IGMPv3.
  • the invention proposes a computer program implementing the above method.
  • the invention proposes an advertisement server connected to a multicast network (also called “multicast network”) comprising at least one multicast group (also called “multicast group”), characterized in that is capable, remotely, of making available to one or more receivers useful data relating to one or more data source servers and / or the streams delivered by them, each data source server being able to deliver data on at least one multicast group, said useful data being able to be read later so that a choice of one or more of these source servers can then be established via selection means, and in that said useful data include at least one of the following fields: identification of each source server; bandwidth of the stream delivered by each source server; identification of terminals adapted to each source server; availability of each source server; priorities given to a source server vis-à-vis another source server.
  • the structured format is an XML format
  • the ad server is itself a data source server that can deliver the payload on at least one multicast group.
  • the invention provides a computer program adapted to be implemented on an ad server according to the above characteristics.
  • the invention proposes a user terminal comprising reception means for receiving via a network at least a portion of the useful data broadcast by an announcement server according to the above characteristics.
  • the invention proposes a computer program that can be implemented on the user terminal above.
  • the invention proposes a system for distributing data in a multicast network (also called “multicast network”) comprising at least one multicast group (also called “multicast group”), characterized in that includes:
  • At least one remote data source server At least one remote data source server
  • Said ad server Means for reading useful data provided remotely by the advertisement server;
  • Means for selecting at least one data source server from the read user data are provided.
  • multicast server Also called “multicast server”
  • the selection means are located on this multicast server or on a user terminal then receiving at least a portion of the useful data broadcast by the multicast server;
  • the reading means are included in a user terminal, and in that the selection means are located on this user terminal;
  • the selection means can be actuated manually or can be activated automatically by an executable adapted from selected selection parameters; the system further comprises a memory for storing the useful data relating to each source server;
  • this memory is included in at least one user terminal
  • the system further comprises means for storing and implementing an application software that makes it possible to consult the useful data stored in memory, to allow manual or automatic selection of at least one source server among those for which the user data is stored at from selected selection parameters, to send a request to each data server thus chosen, and to receive a data stream from each source server thus required; the request is of type IGMPv3.
  • Figure 1 schematically shows an operating mechanism of version 2 of IGMP (denoted IGMPv2).
  • FIG. 2 schematically represents an operating mechanism of IGMP version 3 (denoted IGMPv3).
  • Figure 3 schematically shows the main parts included in a data broadcast system according to the invention.
  • FIG. 4 represents a data distribution system in a multicast network according to the invention, accompanied by illustrative examples of implementation.
  • FIG. 5 represents a method of implementing a method according to the invention at the level of the user.
  • FIGS. 6a and 6b show a first example of application of the invention for, respectively, the case of a WAN type network and a radio-type network.
  • Figure 7 shows a second example of application of the invention.
  • FIG. 8 represents a third example of application of the invention.
  • the system that can implement the invention is composed of three main parts:
  • the set 100 of the data source servers The set 100 of the data source servers;
  • the network 200 The network 200;
  • the set 300 of the user terminals The set 300 of the user terminals.
  • the set 100 of the source servers covers any type of source servers supplying one or more multicast group (s). Each of these source servers is therefore identified by its personal IP address and a multicast group address.
  • These source servers can be simple "passive" data sources (thus delivering simple information on the user's request) or "active” data sources (which allow a certain distance interactivity with the user by means of an interface).
  • the data sent can be of any type (sound, videos, files, television, etc.).
  • the network 200 comprises at least one multicast portion, that is to say that it comprises at least one multicast server managing at least one multicast group. These multicast groups are supplied with data by the set 100 of the source servers.
  • the network 200 may also include transmissions in unicast mode (also called "unicast"), particularly as regards the transmission of data to certain users.
  • unicast also called "unicast”
  • Internet service providers can encapsulate this data in IP format.
  • IP routers including those that relay packets across the entire Internet, which manage to date much of I 1 IP multicast and unicast.
  • the transmission of data can be carried out by any possible means: telephone network, cable network, optical fiber, airway (satellite, by means of base stations, relays, etc.), or other ...
  • the set 300 of the user terminals receives the data streams sent by source servers via the network 200.
  • These user terminals may be of any type, such as a fixed computer 301, a laptop 302, a personal digital assistant 303 ( or “PDA” for “Personal Digital Assistant"), a mobile phone 304, a set-top box 305 (or “STB” for “Set Top Box”), an IGMP gateway 306.
  • the set 300 of these terminals must necessarily be able to connect to the network 200 (via for example an IP interface), and therefore include means to connect to it and possibly navigate there.
  • a terminal can thus have a multicast IP interface, for example with IGMPv3 multicast capabilities.
  • the invention applies very well to IP multicast architectures (fixed network, wireless, mobile) that support the IGMPv3 interface.
  • an advertisement server 400 is to be added to the architecture of the system according to the invention.
  • This advertisement server 400 is located on the network 200. Its role is to announce multicast source servers (referenced here 101, 102, 103, 104, 105, 106) and to inform on useful data (such as characteristics related).
  • this advertisement server 400 is connected (via the network 200 multicast or private unicast) to specific source servers (101, 102, 103, 104, 105, 106), these supplying one or more multicast groups. .
  • the ad server 400 can thus know the bit rate, the address, the bandwidth, the location of each of the source servers. These characteristics can be calculated at the level of the advertisement server and / or provided by each of the source servers concerned. In particular, these characteristics can be regularly updated.
  • This advertisement server 400 is thus able to organize and structure these characteristics of source servers to then make available to one or more receivers (such as a user terminal, an operator or another server) useful data relating to the source servers and / or feeds delivered by them.
  • This useful data delivered by the ad server is chosen to aid a judicious subsequent choice (established at the user terminal, an operator or a server) of one or more of these source servers.
  • This useful data may comprise at least one of the following information:
  • the ad server may also, in addition or alternatively, provide at least one of the following useful data:
  • suitable terminals can be identified to each source server by analyzing the throughput of each source server.
  • one source server may be given priority over another, since both source servers provide the same type of data, on the basis that they do not have the same technical characteristics (not the same bandwidth, not the same flow, etc.).
  • a priority may be assigned to a first source server with respect to a second source server when the terminal used is a mobile phone, and instead a priority may be assigned to the second source server with respect to the first source server.
  • source server when the terminal used is a computer connected to the ADSL it will be possible to use, for example, the useful data rate or location to determine the priorities).
  • this useful data is structured.
  • XML tags tained in a useful data file
  • the advertisement server 400 therefore implements a useful data model defined by the invention.
  • a computer program comprising instructions necessary for carrying out the method according to the invention can be implemented on the advertisement server 400.
  • a user terminal may comprise reception means and a program computer for receiving via the network 200 at least a portion of the useful data broadcast by the announcement server.
  • SourceClassifier a source server of IGMPv3 type
  • NetworkLocationlnformation of type "string”; This element is a character string that provides information on the location of the source server (in accordance with the previously mentioned useful data item (2)).
  • the location can for example be a set ("pool") of IP addresses, a GSM cell, a GPS coordinate, a Wifi terminal, etc.
  • This tag can allow a network operator to distribute on its network several sources for the same flow.
  • the user 301 will select, thanks to this beacon, the source server 101, and the user 310 the source server 102, for localization reasons, and even if the source servers 101 and 102 feed the server. same multicast group on which the users 301 and 310 are connected. The propagation of the multicast stream is thus limited and the transit times of the multicast stream are thus improved.
  • Example of use It can make it possible to define for the same stream several source servers delivering each the same content but to different bit rates (eg 512Kbit / s, 1 Mbps, 2Mbits / s ). The user can then connect to the source that delivers the stream in accordance with its service contract, ie with the bandwidth it has in reception.
  • bit rates eg 512Kbit / s, 1 Mbps, 2Mbits / s
  • the user 304 (here using a terminal of "mobile phone” type) will thus rather choose the source server 103 which delivers 64kBytes / s whereas the user 311 (using here a terminal of "computer” type on ADSL ”) will instead choose the source server 104 which delivers 1 M Bytes / s), even if the source servers 103 and 104 feed the same multicast group on which the users 304 and 31 1 are connected.
  • - TargetTerminalInformation of type string; This element provides technical characteristics on the terminal that targets the source (according to the useful data (5) previously mentioned).
  • Example of use It can prevent a multicast source server from transmitting permanently. For example, stop 3 out of 4 multicast source servers in off-peak hours.
  • the advertisement server 400 then delivers this useful data in 60 in multicast mode (the ad server 400 is then itself a data source server) or in unicast mode through the same network as the streams. multicast or through a separate network.
  • the protocol for announcing and selecting IGMP multicast sources can be as follows:
  • the broadcast multicast IP address must be known to the terminals.
  • This useful data (or the "structured" file, for example in XML) are then received and read remotely from the advertisement server 400, by at least one of the receivers which required this payload, the receiver being for example a user terminal 301, 310, 304, 311, 305 or 312 and / or a server relaying these data to terminals, multicast or unicast.
  • This choice can be made at the receiver itself.
  • the selection means are then located on this receiver.
  • the receiver is a server or an operator
  • at least part of the useful data can then be transmitted (by means of a "multicast” or “unicast” mode) to the user terminal (301, 310, 304,
  • the selection means are then located on this terminal.
  • the selection means can be operated manually (keyboard, mouse, touch screen, ...) or be automatically activated for example by an executable adapted from selected selection parameters.
  • the useful data relating to each source server are then optionally stored in memory, for example at the user terminal or at a server.
  • the user 301, 310, 304, 311, or 312 can then, in the knowledge of the useful data relating to the source servers, send a request 40 to the source server (s) that he has selected (s) so that the it sends him in 50 the data he possesses.
  • This request 40 may for example be of IGMPv3 type (as defined above).
  • the user connects, via the user interface 1200 of his terminal, to the channel of the multicast source server advertisement server (for example IGMPv3) or connects to an Internet server (which itself retrieved the useful data from the advertisement server) and then retrieves the useful data (ie, for each multicast group, the list of source servers and the useful data).
  • the multicast source server advertisement server for example IGMPv3
  • an Internet server which itself retrieved the useful data from the advertisement server
  • the user then stores in 20 in the memory 1300 of the terminal the payload.
  • the transport protocol may include a specific mechanism for detecting a possible updating of the useful data taking into account the selections that have just been made from the multicast sources.
  • the useful data can then be used by an application layer 1400 (i.e. an application software) provided in the terminal, to establish the choice of a multicast source in an "intelligent" manner, from these useful data.
  • the application software 1400 thus makes it possible to consult the useful data stored in memory, and to make it possible to choose manually or automatically (via selection means) at least one source server among those for which the user data is stored. If this choice is established automatically, it may however be dependent on predetermined general selection parameters, or previously determined by the user.
  • This application software 1400 once the selection is made, makes it possible to send a request 40 to each data server thus selected, and to receive at 50 a data stream from each source server thus required.
  • This application layer 1400 may also update the useful database (located in the memory 1300), taking into account the selection that has just been made.
  • the method of the invention makes it possible, on the one hand, to announce to the user the source servers and, on the other hand, to offer a means of classifying these source servers according to certain criteria, thereby enabling a user ( via its multicast group or its unicast connection) to choose the most appropriate multicast source for it.
  • the invention thus makes it possible to define how the user terminal can discover and choose, knowingly, one or more server (s) source (s), and for example subscribe (by storing in memory 1300).
  • Example 1 Referring to Figure 6, this first example illustrates an application of said tag "NetworkLocationlnformation".
  • This tag provides information on the location of the source servers 101 and 102 of a multicast stream.
  • this beacon can be used by a fixed terminal 301, for example located on a WAN type network 200, to receive the stream 50 (after request 40) of the nearest multicast source server 101 or else , this time referring to FIG. 6b, by a mobile terminal 303 to cling to the source server diffusing in its cell (here it can be seen that the mobile terminal 303 moves 90, it then passes from the cell 201 to the cell 202 , and can change source server (from 101 to 102) thanks to the location tag).
  • said tag "Bandwidthlnformation" is used in this example to allow terminals 301 heterogeneous (in terms of rates) to hang on to the source server 102 that delivers the service in accordance with their service contract.
  • a terminal 301 connected to an ADSL link 512Kbits will connect to the source delivering the service at a rate of 512Kbits while a second terminal with an upper bandwidth, for example equal to 2Mbits, will connect to the source server 101 delivering the same service but at a much higher quality than the 512Kbit source.
  • This tag can be used, for example, in a context where a terminal 303 has several network interfaces, for example a mobile terminal with a GPRS interface and a UMTS interface.
  • the use of the "TargetTerminalInformation" tag can be used to characterize which terminals are targeted by a source server 101 or 102. It can therefore be considered that a source server 101 is responsible for broadcasting on the network 201 a service for GPRS terminals and another source server 102 is responsible for broadcasting on the network 202 the same service for UMTS terminals. During the displacement 90 of the terminal 303, the latter will then be able to switch from a GPRS interface to a UMTS interface, without losing the data received.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

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 œuvre 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 œuvre ce procédé.

Description

Découverte et sélection intelligente dans un réseau de multidiffusion
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 vers un nombre quasiment illimité d'utilisateurs.
En particulier, la technologie Internet de multidiffusion (encore appelée technologie « IP Multicast »), normalisée par I1IETF (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, I1IETF 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'information-requê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
IP multicast. Lorsqu'un utilisateur 300 fait une requête IGMPv2 pour un flux
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 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 optimisation des architectures multicast et des services multicast "intelligents".
1. 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 œuvre 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 et/ou aux flux délivrés par ceux-ci, 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, et en ce que lesdites données utiles comprennent au moins un des champs suivants : identification 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 ; priorités données à un serveur source vis-à-vis d'un autre serveur source.
D'autres caractéristiques possibles de ce procédé sont :
- lesdites données utiles comprennent une information sur la localisation de chaque serveur source.
- les données utiles sont mises à disposition selon un format structuré, 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 œuvre 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 procédé ci-dessus. 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 et/ou aux flux délivrés par ceux-ci, 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, et en ce que lesdites données utiles comprennent au moins un des champs suivants : identification 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 ; priorités données à un serveur source vis-à-vis d'un autre serveur source.
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 programme d'ordinateur apte à être mis en œuvre sur un serveur d'annonces selon les caractéristiques ci-dessus.
Selon un cinquième aspect, l'invention propose un terminal utilisateur comprenant des moyens de réception pour recevoir via un réseau au moins une partie des données utiles diffusées par un serveur d'annonce selon les caractéristiques ci-dessus. Selon un sixième aspect, l'invention propose un programme d'ordinateur apte à être mis en œuvre sur le terminal utilisateur ci-dessus.
Selon un septè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 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 œuvre 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 œuvre. La figure 5 représente un procédé de mise en œuvre d'un procédé 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 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 œuvre 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 I1IP 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 et/ou aux flux délivrés par ceux-ci. 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.
On notera qu'un programme d'ordinateur comportant des instructions nécessaires à la réalisation du procédé selon l'invention peut être mis en oeuvre sur le serveur d'annonces 400. Par ailleurs, un terminal utilisateur peut comprendre des moyens de réception et un programme d'ordinateur pour recevoir via le réseau 200 au moins une partie des données utiles diffusées par le serveur d'annonce.
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 à 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 310 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 : II 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 1 M Octets/s), même si les serveurs source 103 et 104 alimentent le même groupe multicast sur lequel les utilisateurs 304 et 31 1 sont connectés. - TargetTerminalInformation : 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 : II peut permettre d'éviter à un serveur de 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) 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 œuvre 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 sources multicast. 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 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
"TargetTerminalInformation". 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 "TargetTerminalInformation" 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" encodιng="UTF-8"?>
<xs:schema xmlns:xs="http://www. w3.org/2001 /XMLSchema" elemβπtFormDefault=' quahfied' attrιbuteFormDefault="unqualιfιed">
<xs:θlθment name="IGMPv3SourceManagement"> <xs :complexType> <xs:sequence>
<xs:element name="SιnglelGMPv3Servιce" type="IGMPv3ServιceTypθ" maxOccurs="unbounded"/> </xs'sequence> </xs :complexType> </xs.element>
<xs complexType name=' IGMPv3ServιceTypθ"> <xs'sequence>
<xs élément name="MultιcastAddress" type= 'xs:strιng '/> <xs.elθment name="Port" type="xs:ιnteger" mιnOccurs="0"/> <xs:element name="SSMSource" type="OneSource" maxOccurs="unbounded"/> </xs'sequence>
<xs:attrιbute name="ServιceName" type="xs.strιng"/> <xs.attπbute name="SeglD" type="lnteger16"/> </xs OomplexType>
<xs'ComplexType name="OneSource"> <xs'sequence>
<xs:element name="SourceAddress" type="xs stπng"/>
<xs.element name="SourceClassιfιer" type="SourcβClassιfιerType" rnιnOccurs="0"/> </xs-sequence>
<xs attπbute name="SourceName" type="xs stπng"/> </xs i∞mplexTypθ>
<xs:complexType name="SourceClassιfιerType"> <xs sequencβ>
<xs:element name="Prιorιtylnformatιon" type="xs integer" mιnOccurs="0"/> <xs élément name="NetworkLocatιonlnformatιon" type="xs:strιng" mιnOccurs="0"/> <xs:element name="Bandwιdthlnformatιon" type="xs.long" mιnOccurs="0"/> <xs.element name="TargetTermιnallnformatιon" type="xs:stπng" mιnOccurs="0"/> <xs:element name="SourceAvaιlabilιtylnformatιon" type="AvaιlabιlιtyType" mιnOccurs="07> <xs:element name="Pπvatelnformatιon" type="PrιvateType" mιnOccurs="0" maxOccurs=' unbounded"/> </xs'sequence> </xs:complexType>
<xs complexType πame="PπvateType"> <xs.sequencθ>
<xs élément name="Type" type="Strιng64"/> <xs élément name="Value" type="xs:strιng"/> </xs sequence> </xs .complexType>
<xs complexType name="AvaιlabιlιtyType"> <xs.sequeπce>
<xs:element name="StartTime" type="xs:dateT!me"/> <xs-element name=''StopTιme" type="xs'dateTιme"/> </xs'sequence> </xs'complexType> <xs simpieType name="Strιng64"> <xs: restriction base="xs:strιng"> <xs.maxl_ength value="64"/> </xs:restπctιon> </xs:sιmpleType>
<xs'sιmpleType name= 'Integeri 6"> <xs restriction base="xs:ιnteger"> <xsτnaxl_ength value="16"/> </xs:restrιctιon> </xs sιmpleType> </xs'schema>

Claims

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 et/ou aux flux délivrés par ceux-ci, 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, et en ce que lesdites données utiles comprennent au moins un des champs suivants: identification 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 ; priorités données à un serveur source vis-à-vis d'un autre serveur source.
2. Procédé selon la revendication précédente, caractérisé en ce que lesdites données utiles comprennent une information sur la localisation 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 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 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 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 et/ou aux flux délivrés par ceux-ci, 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, et en ce que lesdites données utiles comprennent au moins un des champs suivants : identification 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 ; priorités données à un serveur source vis-à-vis d'un autre serveur source.
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é 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. Programme d'ordinateur apte à être mis en oeuvre sur un serveur d'annonces selon l'une quelconque des revendications 16 à 20.
22. Terminal utilisateur caractérisé en ce qu'il comprend des moyens de réception pour recevoir via un réseau au moins une partie des données utiles diffusées par un serveur d'annonce selon l'une quelconque des revendications 16 à 20.
23. Programme d'ordinateur apte à être mis en oeuvre sur un terminal utilisateur selon la revendication précédente.
24. 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.
25. 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 mutticast.
26. Système selon la revendication précédente, 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.
27. 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.
28. 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.
29. Système selon la revendication précédente, caractérisé en ce que la mémoire est incluse dans au moins un terminal utilisateur.
30. 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.
31. Système selon la revendication précédente, caractérisé en ce que la requête est de type IGMPv3.
EP05798962A 2004-09-13 2005-09-12 Decouverte et selection intelligente de serveurs dans un reseau de multidiffusion Withdrawn EP1794983A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0409676A FR2875356A1 (fr) 2004-09-13 2004-09-13 Decouverte et selection intelligente dans un reseau de multidiffusion
PCT/FR2005/050728 WO2006030152A1 (fr) 2004-09-13 2005-09-12 Decouverte et selection intelligente dans un reseau de multidiffusion

Publications (1)

Publication Number Publication Date
EP1794983A1 true EP1794983A1 (fr) 2007-06-13

Family

ID=34948582

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05798962A Withdrawn EP1794983A1 (fr) 2004-09-13 2005-09-12 Decouverte et selection intelligente de serveurs dans un reseau de multidiffusion

Country Status (4)

Country Link
US (1) US20080075077A1 (fr)
EP (1) EP1794983A1 (fr)
FR (1) FR2875356A1 (fr)
WO (1) WO2006030152A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8116317B2 (en) * 2006-01-31 2012-02-14 Microsoft Corporation Preventing quality of service policy abuse in a network
JP4535169B2 (ja) * 2008-06-02 2010-09-01 コニカミノルタビジネステクノロジーズ株式会社 ネットワークシステム、画像処理装置、画像データ格納方法、および画像データ送信プログラム
US8018934B2 (en) * 2009-03-20 2011-09-13 Cisco Technology, Inc. Switched unicast in an internet protocol television environment
US20120140645A1 (en) * 2010-12-03 2012-06-07 General Instrument Corporation Method and apparatus for distributing video
US11354815B2 (en) * 2018-05-23 2022-06-07 Samsung Electronics Co., Ltd. Marker-based augmented reality system and method

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020133573A1 (en) * 1998-11-12 2002-09-19 Toru Matsuda Method and apparatus for automatic network configuration

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108706A (en) * 1997-06-09 2000-08-22 Microsoft Corporation Transmission announcement system and method for announcing upcoming data transmissions over a broadcast network
US6446108B1 (en) * 1997-07-18 2002-09-03 Lucent Technologies Inc. Method for wide area network service location
US6845393B1 (en) * 1999-06-14 2005-01-18 Sun Microsystems, Inc. Lookup discovery service in a distributed system having a plurality of lookup services each with associated characteristics and services
US6604142B1 (en) * 2000-05-05 2003-08-05 Telefonaktiebolaget Lm Ericsson (Publ) Method of filtering responses to gatekeeper discovery multicast request message
US6862594B1 (en) 2000-05-09 2005-03-01 Sun Microsystems, Inc. Method and apparatus to discover services using flexible search criteria
US6720052B1 (en) 2000-08-24 2004-04-13 The Coca-Cola Company Multilayer polymeric/inorganic oxide structure with top coat for enhanced gas or vapor barrier and method for making same
US7110784B2 (en) * 2002-08-23 2006-09-19 Matsushita Electric Industrial Co., Ltd. Wireless communication system
US7228356B2 (en) * 2002-12-12 2007-06-05 Alcatel Canada Inc. IGMP expedited leave triggered by MAC address

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020133573A1 (en) * 1998-11-12 2002-09-19 Toru Matsuda Method and apparatus for automatic network configuration

Also Published As

Publication number Publication date
US20080075077A1 (en) 2008-03-27
FR2875356A1 (fr) 2006-03-17
WO2006030152A1 (fr) 2006-03-23

Similar Documents

Publication Publication Date Title
EP3054652B1 (fr) Ajustement dynamique du mode de transmission dans un systeme de communication satellite
US10856014B2 (en) Control plane architecture for multicast cache-fill
US20020023164A1 (en) Method and apparatus for client-side authentication and stream selection in a content distribution system
US20100077438A1 (en) Apparatus and method for obtaining media content
US20010029525A1 (en) Method of utilizing a single uniform resource locator for resources with multiple formats
US20090040957A1 (en) Prepositioning Data For Wireless Applications
US20100011398A1 (en) Method and System for Automatic IP TV Program Generation
JP2009541877A (ja) ウェブ・オブジェクトを制御する方法、システム、装置、及びコンピュータ・プログラム（放送情報をキャッシュする方法及び装置）
US20090070217A1 (en) Targeted Advertisement Transmission and Delivery in a Bandwidth Limited Multicast Wireless System
EP1794983A1 (fr) Decouverte et selection intelligente de serveurs dans un reseau de multidiffusion
EP2273786B1 (fr) Contrôle d&#39;accès à un contenu numérique
US10893315B2 (en) Content presentation system and content presentation method, and program
US11165878B2 (en) System for automated content delivery to high-speed data service client using redirection of internet protocol service flows independent of physical media delivery mechanisms
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d&#39;un flux de données selon un mode de transmission multipoint
US8181213B2 (en) IP-based hometown TV program delivery system
EP2984786B1 (fr) Architecture centralisée pour l&#39;établissement de fédérations de distributeurs de contenus
US20090037970A1 (en) IP-based hometown TV program delivery system
Tong et al. A peer-to-peer streaming CDN for supporting OTT video broadcast service in mobile networks
WO2009042304A1 (fr) Transmission ciblée de publicité et diffusion dans un système sans fil multidiffusion à largeur de bande limitée
WO2009095590A1 (fr) Procede de transmission de contenus vod
WO2012131279A1 (fr) Procede de repartition de flux de donnees multicast dans des groupes de diffusion multicast
WO2016156386A1 (fr) Système de diffusion de contenus audio et/ou vidéo par un réseau wifi local, et appareils mettant en œuvre le procédé
Naor Multicast Content Distribution over IP Networks
Hareesh et al. Chaining Algorithm and Protocol for Peer-to-Peer Streaming Video on Demand System
WO2012042163A1 (fr) Procede d&#39;expedition dans un reseau d&#39;acces a sauts multiples

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070405

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FRANCE TELECOM

17Q First examination report despatched

Effective date: 20111208

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20130527

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20131008