WO2006051210A1 - Systeme de transmission de flux multidiffusion - Google Patents

Systeme de transmission de flux multidiffusion Download PDF

Info

Publication number
WO2006051210A1
WO2006051210A1 PCT/FR2005/002777 FR2005002777W WO2006051210A1 WO 2006051210 A1 WO2006051210 A1 WO 2006051210A1 FR 2005002777 W FR2005002777 W FR 2005002777W WO 2006051210 A1 WO2006051210 A1 WO 2006051210A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
zone
multicast stream
service provider
management server
Prior art date
Application number
PCT/FR2005/002777
Other languages
English (en)
Inventor
Pierrick Seite
Thierry Levesque
David Roy
Original Assignee
France Telecom
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 filed Critical France Telecom
Publication of WO2006051210A1 publication Critical patent/WO2006051210A1/fr

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
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • 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
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains

Definitions

  • the present invention relates to a multicast stream transmission system between at least one multicast stream source of at least one service provider and at least one broadcast area comprising a plurality of user terminals.
  • the invention finds a particularly advantageous application in the field of multicast stream transmission through unscheduled transport networks for the implementation of multicast mechanisms, such as the Internet (IP).
  • IP Internet
  • multicasting is equivalent here to the other terms often used in this technical field, such as “multipoint broadcast”, “group broadcasting” or the Anglo-Saxon term “multicast”. In the remainder of this thesis, the terms “multicast” and “multicast” will be used interchangeably, the latter being widely used.
  • IP multicast services such as audio / video streaming, file transfer to a community of users, or IPTV, allow network resources to be shared by sharing the same information with a set of users interested in the same content, this set of users constituting a broadcast area ("hotspot" in English terminology).
  • the multicast transmission mode implies that the transport network under consideration is capable of routing such networks. flux.
  • a multicast service provides that it is the user who triggers the flow transfer by subscribing to the service, or group of multicast streams.
  • an access network operator may wish to limit the potential number of groups to which users can subscribe, these limitations may also evolve in time and space according to the needs of the services, for example such multicast stream group is available only in such a broadcast area and for such time slot as is the case with local TV dropping.
  • the protocols for managing user subscriptions to multicast multicast groups are currently well known and standardized by the IETF, for example the IGMPv2 / RFC2236 protocol.
  • the first solution for hosting multicast services in an IP access network, especially radio, consisting of broadcast zones is to place in each zone one or more application server (s).
  • this solution called “local servers”, has the merit of simplicity, it can be very expensive in terms of servers, especially if the same service provider wants to broadcast in several areas.
  • the management of third-party service providers is relatively heavy since they must be hosted within the access network. The number of potential service providers is then clearly limited. In reality, this solution offers little interest because too far from the context in which the invention is located.
  • FIG. 1 illustrates this type of known mechanism in a context which is also that of the invention.
  • Service providers A and B respectively have multicast stream sources denoted respectively A1, A2 and B1. Each of these multicast sources issues one or more multicast streams. These flows are blocked by access routers RA1 and RA2 as long as they have not received a subscription request. Static IP tunnels (tunnel IP1 and tunnel IP2) are previously configured between the access routers RA1 and RA2 of each service provider and the access router RA3 of the zone intended for the service.
  • a user equipped with a terminal connected to the access network via an AP2 access point and wishing to receive multicast content from the service provider A, issues a subscription request to the IP address of the corresponding multicast streams, typically using the aforementioned IGMP protocol.
  • This subscription request is processed by the access router RA3, the latter being configured to encapsulate the subscription message in the IP2 tunnel whose end is the access router RA1 of the service provider A. It is therefore implicitly assumed that RA3 knows which tunnel to borrow based on the multicast IP address requested, we will come back to this point a little further.
  • the router RA1 then unencapsulates the message and responds to the subscription request by forwarding the requested multicast stream (s) through the IP2 tunnel whose end is the access router RA3.
  • RA3 unencapsulates the data and sends them in multicast within the IP subnet constituted by the broadcasting zone of which the user is a part, and therefore through the access point AP2 to which the terminal of the connection is connected. this user.
  • the user In a standard multicast service platform operation, the user is aware of the multicast stream address and issues a subscription request to the corresponding multicast group by specifying that address in his request. If multiple users served by the same access point subscribe to different multicast groups, the rate can quickly exceed the capacity of the access point if all flows are delivered at the same time. Management of regularization of access to multicast services may then be necessary.
  • the principle of this regularization of flows is to allow the subscription only to a certain number of multicast groups during a given period of time. In this case, the problem is to announce to users only the available streams, ie those that are potentially accessible and prohibit access to others. It is recalled that this service announcement is used to obtain the necessary information for the user to manage his subscription, namely multicast IP addresses flows, port number, flow description, etc.
  • a technical problem to be solved by the object of the present invention is to propose a multicast stream transmission system. between at least one multicast stream source of at least one service provider and at least one broadcast area comprising a plurality of user terminals, which could effectively meet the need for dynamic management of the multicast resource via a non-multicast transport network , while allowing low-cost interconnection of the access network with a large number of content providers.
  • the solution to this technical problem consists, according to the present invention, in that said system comprises: a central server for managing multicast flows, a pilot terminal associated with each broadcasting zone, said central management server being able to:
  • the invention introduces the notion of centralized management of the multicast subscription because the proposed solution allows the dynamic association of the multicast sources and the multicast resources. broadcast areas, while prohibiting subscriptions to non-broadcast groups in the area. To do this, it is proposed by the system according to the invention to defer the management of the subscription on the central server, this management is done on behalf of end users.
  • the central management server manages the broadcast schedule for all broadcast areas; it determines the time and location of each multicast stream.
  • the central management server transmits to the pilot terminal belonging to the architecture of the broadcast area that it represents, typically behind the access router, an order of subscription including the address of the selected multicast stream.
  • the pilot terminal subscribes to the desired multicast group on behalf of the users present in the broadcast area by issuing a subscription request by means of a subscription protocol. This request passes through the access router of the broadcast area which transmits it to the corresponding multicast source.
  • the management of multicast subscription at the platform level provides great flexibility in the management of the multicast resource and allows fine control, by broadcast area, of the bandwidth used. by multicast services.
  • Another aspect addressed by the invention relates to the transport of flows in the case of third-party content providers.
  • the IP tunnel mechanism described above with reference to the second known solution of the state of the art clearly allows multicast traffic to be passed through a purely unicast network by means of IP tunnels.
  • this mechanism assumes that a router receiving a subscription request can associate the corresponding tunnel, that is by determining the end of the tunnel according to the multicast address of the requested flows.
  • the standard mechanisms for subscribing to multicast flow groups are based on the IGMPv2 / RFC2236 protocol which only allows the user to specify the desired multicast address.
  • the tunnel / multicast address association can only be statically configured at the access routers of each broadcast zone.
  • a disadvantage of this standard method is its static nature and its lack of flexibility in terms of reconfigurability. Indeed, the fact that a source can transmit on several different multicast addresses can lead to correspondence tables of significant size.
  • the multicast stream address is likely to be commonly modified.
  • a service provider wishes to add or modify a multicast address, it must be configured, or reconfigured, at all access routers of the potentially client broadcast areas of the new multicast service. .
  • all multicast addresses must be different regardless of the source and the service provider. This latter constraint can be difficult to overcome if the access network obtains its supply from independent or even competing service providers.
  • Another technical problem to be solved by the object of the present invention is to substitute for the conventional subscription mechanism based on tunnel matching / multicast address a simpler mechanism to implement for access routers and also more stable vis-à-vis any changes made to multicast addresses by service providers.
  • the solution to this second technical problem consists, according to the present invention, in that said central management server is able to receive from the service provider an address of the sending source of the selected multicast stream, and in that said message from the central server management system at the pilot terminal also includes the address of said sending source. It is also provided by the invention that the address of said source is included in said subscription request.
  • an access router for routing said subscription request has a correspondence table associating the address of said sending source to an access tunnel to the corresponding service provider.
  • the invention proposes a solution to the transport problem which remains always based on IP tunnel mechanisms, in which a tunnel must be configured between the service provider and each zone of the tunnel. intended dissemination.
  • the tunneling / multicast address association constraint is eliminated by using, for example, the IGMPv3 / RFC3376 protocol which allows a user to specify, at the subscription request, the address of the chosen multicast source which will be associated with identifying the endpoint of the tunnel in a look-up table.
  • access routers do not have to maintain tunnel association / multicast address lists since they can simply use the address of the multicast source, which can be considered fixed in contrast to the multicast group addresses. , to identify the end of the tunnel to borrow.
  • the address of the multicast source is communicated by the pilot terminal, on behalf of the users of the broadcast area, using the IGMPv3 protocol, during the subscription request.
  • the service provider side the impact is relatively small since it is limited to the configuration of a tunnel by broadcast area.
  • the system proposed by the invention does not require any service evolution or particular applications or protocols, since the management of the multicast resource is entirely supervised by the central management server
  • the invention proposes that the message from the central server to the pilot terminal also comprises an authentication of said message. This arrangement makes it possible to prevent the pilot terminal from receiving subscription orders from entities other than the central management server.
  • the invention also relates to a central management server for a multicast stream transmission system, remarkable in that said server is able to:
  • Another aspect of the central management server consists, according to the invention, in that it is able to receive from the service provider an address of the sending source of the selected multicast stream, and in that said message of the central management server the pilot terminal also includes the address of said transmitting source.
  • a computer program product for a central management server is notable in that it includes program code instructions on a computer readable medium for carrying out the operations of:
  • the invention also relates to a pilot terminal for a multicast stream transmission system, remarkable in that said pilot terminal is able to transmit to the service provider a subscription request, common to all user terminals of the associated zone, for the multicast stream selected for said zone by the central management server.
  • a computer program product for a pilot terminal is remarkable in that it includes program code instructions on a computer readable medium for carrying out the operations of transmitting to destination of the service provider a subscription request, common to all terminals users of the associated zone, for the multicast stream selected for said zone by the central management server.
  • an access router for a multicast stream transmission system is remarkable in that said access router, intended to route said subscription request, has a correspondence table associating the address of said source transmitting to an access tunnel to the corresponding service provider.
  • FIG. 2 is a diagram giving the architecture of a multicast stream transmission system according to the invention.
  • FIG. 3 is an operating diagram of the transmission system of FIG. 2.
  • FIG. 2 shows an architecture of a transmission system according to the invention in which service providers A and B, respectively hosting sources A1. , A2 and B1 multicast stream, want to supply, via a non-multicast IP transport network, such as the Internet, ZD1 and ZD2 broadcast zones of an access network. Each of these multicast sources can broadcast multiple groups of multicast streams.
  • the broadcasting zones ZD1 and ZD2 are respectively connected to the access network via the access routers RA3 and RA4. Each of these zones hosts respectively a pilot terminal TP1 and TP2 and access points AP1, AP2 on the one hand, and AP3, AP4 on the other hand.
  • Service providers A and B are respectively connected to the IP transport network by the access routers RA1 and RA2.
  • the access network integrates a central SC multicast flow management server, including control and control of multicast content provisioning.
  • the central server SC manages the activation and access to the multicast resource on behalf of the end users, and interfaces with the service providers.
  • the central management server SC receives from service providers A and B the addresses of the available multicast streams, as well as the unicast addresses of the sources of the corresponding streams.
  • the central server SC also manages the distribution of the streams within zones ZD1 and ZD2 connected to the same access network. This management consists of selecting for each zone and each time slot one or more of the available streams.
  • Each of the pilot terminals TP1 and TP2, representatives of the user terminals of their respective zone is informed of the multicast address of the stream, or streams, selected and the unicast address of the source of the stream, or streams, selected (s) by a message transmitted by the central server SC or by consulting a table maintained by said central server.
  • each zone ZD1 or ZD2 transmits to the service provider A or B, according to the selection made by the central management server SC, a subscription request, common to all the users of the zone, for the selected multicast stream (s).
  • This subscription request includes multicast stream and unicast addresses of sources received from the central server SC.
  • These subscription requests are relayed by the access routers, RA3 and RA4, which, in order to route the corresponding subscription request, have a simple correspondence table associating the sending source address with an IP access tunnel. corresponding service provider.
  • FIG. 3 For the sake of simplification, the diagram shown in this figure only refers to a single diffusion zone, but it is very clear that It extends easily to supplying multicast streams of any number of zones.
  • a static IP tunnel is previously configured between the access router of the service provider and that of the broadcast area considered. It is assumed that the IP transport network is the Internet.
  • the multicast source, A1 or A2, of the service provider A for example, transmits a multicast stream with which a multicast IP address is associated.
  • the multicast stream is blocked by the access router, RA1 in the example chosen, since no subscription request has been registered by the latter.
  • the multicast stream does not transit through the transport network, here the Internet.
  • the service provider provides the central management server SC with a description of the IP multicast service. This description includes in particular the multicast IP address and the address of the corresponding sending source.
  • the central management server SC then establishes a broadcast program by associating with each zone at least one selected multicast stream and a broadcast schedule. In fact, the multicast content management platform plays a role of production control.
  • the central management server SC issues a subscription order to the pilot terminal TP of the ZD broadcast area concerned. This order specifies the IP addresses of the group and that of the multicast source to which the pilot terminal must subscribe. 3.
  • the TP pilot terminal interprets the subscription order and issues an IGMPv3 request on its IP subnet specifying the desired multicast group and source.
  • the subscription request issued by the pilot terminal is received and processed by the access router of the broadcast area which encapsulates it and transmits it in the IP tunnel whose end is the access router of the service provider. services concerned.
  • the zone access router determines the right tunnel end by the address of the sending source indicated in the IGMPv3 protocol subscription message.
  • the service provider's access router receiving a subscription request on the IP tunnel interface, forward the multicast stream whose IP address corresponds to the requested one to the end of the tunnel, namely the router access to the broadcast area.
  • the multicast stream is encapsulated in the tunnel whose origin is the access router of the ZD zone from which the multicast subscription request originates.
  • the broadcast zone access router de-encapsulates the multicast data and sends it multicast over its IP subnet, which includes the access points.
  • the multicast stream is then received by the interface of the terminal of the end user but is not returned to the application layers before the latter makes the request.
  • the client user's terminal-embedded multicast application issues a subscription request for the desired multicast stream, this stream already being received at the interface.
  • This request is in fact limited in scope to the interface and can only relate to the flow to which the pilot terminal has previously subscribed. Indeed, if the requested flow is not present on the interface, the request remains vain because it is not propagated in the network.
  • the process described above is limited to a single broadcast area for reasons of simplification of the description. However, if several broadcast areas were to be affected by the broadcast of the same multicast content, that is to say from the same multicast source, simply repeat steps 2 to 7 for each zone.
  • IGMPv3 makes it possible to assign the same multicast address to different multicast streams, namely from different multicast sources. This feature facilitates interconnection with independent service providers that can very well use the same multicast IP addresses for their content.

Landscapes

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

Abstract

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

Description

SYSTEME DE TRANSMISSION DE FLUX MULTIDIFFUSION
La présente invention concerne un système de transmission de flux multidiffusion entre au moins une source de flux multidiffusion d'au moins un fournisseur de services et au moins une zone de diffusion comprenant une pluralité de terminaux utilisateurs. L'invention trouve une application particulièrement avantageuse dans le domaine de la transmission de flux multidiffusion à travers des réseaux de transport non prévus pour la mise en œuvre des mécanismes de multidiffusion, tel que l'Internet (IP).
Le terme de « multidiffusion » est équivalent ici aux autres termes souvent utilisés dans ce domaine technique, tels que « diffusion multipoints », « diffusion de groupes » ou encore le terme anglo-saxon de « multicast ». Dans la suite de ce mémoire, on utilisera indifféremment les termes de « multidiffusion » et de « multicast », ce dernier étant largement employé.
Les services multidiffusion sur IP, comme le « streaming » audio/vidéo, le transfert de fichiers vers une communauté d'utilisateurs ou la télévision sur IP, permettent de mutualiser les ressources de réseau en faisant partager la même information à un ensemble d'utilisateurs intéressés par le même contenu, cet ensemble d'utilisateurs constituant une zone de diffusion (« hotspot » en terminologie anglo-saxonne). Dans le cadre, par exemple, d'une architecture de réseau où les fournisseurs de services sont interconnectés à un réseau d'accès via un réseau de transport, le mode de transmission multidiffusion implique que le réseau de transport considéré soit capable de router de tels flux.
Le fonctionnement d'un service multidiffusion, ou multicast, prévoit que ce soit l'utilisateur qui déclenche le transfert de flux en s'abonnant au service, ou groupe de flux multicast. Afin de contrôler l'utilisation de la bande passante, un opérateur de réseau d'accès peut souhaiter limiter le nombre potentiel de groupes auxquels les utilisateurs peuvent s'abonner, ces limitations pouvant également évoluer dans le temps et l'espace en fonction des besoins des services, par exemple tel groupe de flux multicast n'est disponible que dans telle zone de diffusion et pour telle plage horaire, comme c'est le cas du décrochage local en télévision.
Les protocoles de gestion des souscriptions d'utilisateurs à des groupes de diffusion multicast sont actuellement parfaitement connus et standardisés par l'IETF, on citera par exemple le protocole IGMPv2/RFC2236.
En ce qui concerne le transport, plusieurs solutions permettent aujourd'hui à un opérateur de réseau d'offrir des services multicast sans avoir recours à un réseau de transport spécifique entre les sources de flux multicast et les zones de diffusion.
La première solution d'hébergement de services multicast dans un réseau d'accès IP, notamment radio, composé de zones de diffusion est de placer dans chaque zone un ou plusieurs serveur(s) d'application. Si cette solution, dite « à serveurs locaux », a le mérite de la simplicité, elle peut être fort coûteuse en terme de serveurs, surtout si un même fournisseur de services souhaite diffuser dans plusieurs zones. De plus, la gestion de fournisseurs de services tiers est relativement lourde puisque ils doivent être hébergés au sein même du réseau d'accès. Le nombre de fournisseurs de services potentiels est alors clairement limité. En réalité, cette solution n'offre que peu d'intérêt car trop éloignée du cadre dans lequel se situe l'invention.
La seconde solution, qui est aussi la plus classiquement mise en œuvre pour véhiculer le trafic multicast au travers d'un réseau unicast tel l'Internet, est d'utiliser les mécanismes dits « de tunnels IP ». La figure 1 illustre ce type de mécanisme connu dans un contexte qui est aussi celui de l'invention.
Les fournisseurs de services A et B disposent respectivement de sources de flux multidiffusion notées respectivement A1 , A2 et B1. Chacune de ces sources multicast émet un ou plusieurs flux multidiffusion. Ces flux sont bloqués par les routeurs d'accès RA1 et RA2 tant que ces derniers n'ont pas reçu de demande de souscription. Des tunnels IP statiques (tunnel IP1 et tunnel IP2) sont préalablement configurés entre les routeurs d'accès RA1 et RA2 de chaque fournisseur de services et le routeur d'accès RA3 de la zone de diffusion visée par le service. Un utilisateur, équipé d'un terminal connecté au réseau d'accès via un point d'accès AP2 et souhaitant recevoir un contenu multicast en provenance du fournisseur de services A, émet une demande de souscription à l'adresse IP des flux multicast correspondants, typiquement à l'aide du protocole IGMP précité. Cette demande de souscription est traitée par le routeur d'accès RA3, ce dernier étant configuré pour encapsuler le message de souscription dans le tunnel IP2 dont l'extrémité est le routeur d'accès RA1 du fournisseur de service A. On suppose donc implicitement que RA3 sache déterminer quel tunnel emprunter en fonction de l'adresse IP multicast demandée, on reviendra sur ce point un peu plus loin. Le routeur RA1 désencapsule alors le message et répond à la demande de souscription en faisant suivre le(s) flux multidiffusion demandé(s) à travers le tunnel IP2 dont l'extrémité est le routeur d'accès RA3. A la réception, RA3 désencapsule les données et les fait suivre en multicast au sein du sous-réseau IP constitué par la zone de diffusion dont l'utilisateur fait partie, et donc à travers le point d'accès AP2 auquel est connecté le terminal de cet utilisateur.
Dans un fonctionnement standard de plateforme de services de multidiffusion, l'utilisateur a connaissance de l'adresse des flux multicast et émet une demande de souscription au groupe multicast correspondant en spécifiant cette adresse dans sa demande. Si plusieurs utilisateurs desservis par un même point d'accès s'abonnent à des groupes multicast différents, le débit peut vite dépasser la capacité du point d'accès considéré si tous les flux sont délivrés en même temps. Une gestion de régularisation de l'accès aux services multicast peut alors s'avérer nécessaire. Le principe de cette régularisation des flux est de n'autoriser la souscription qu'à un certain nombre de groupes multicast pendant un laps de temps donné. Dans ce cas, le problème revient à n'annoncer aux utilisateurs que les flux disponibles, c'est à dire ceux qui sont potentiellement accessibles et interdire l'accès aux autres. On rappelle que cette annonce de service est utilisée pour obtenir les informations nécessaires à l'utilisateur pour gérer sa souscription, à savoir adresses IP multicast des flux, numéro de port, description des flux, etc.
Aussi, un problème technique à résoudre par l'objet de la présente invention est de proposer un système de transmission de flux multidiffusion entre au moins une source de flux multidiffusion d'au moins un fournisseur de services et au moins une zone de diffusion comprenant une pluralité de terminaux utilisateurs, qui pourrait répondre efficacement au besoin de gestion dynamique de la ressource multicast via un réseau de transport non multicast, tout en permettant une interconnexion à bas coût du réseau d'accès avec un grand nombre de fournisseurs de contenus.
La solution à ce problème technique consiste, selon la présente invention, en ce que ledit système comprend : - un serveur central de gestion des flux multidiffusion, - un terminal pilote associé à chaque zone de diffusion, ledit serveur central de gestion étant apte à :
* recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles,
* sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone, et ledit terminal pilote étant apte à émettre à destination du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion. Ainsi, afin de répondre de manière efficace au besoin de gestion et de contrôle dynamique de la ressource multicast, l'invention introduit la notion de gestion centralisée de la souscription multicast du fait que la solution proposée permet l'association dynamique des sources multicast et des zones de diffusion, tout en interdisant les souscriptions aux groupes non diffusés dans la zone. Pour ce faire, il est proposé par le système conforme à l'invention de déporter la gestion de la souscription sur le serveur central, cette gestion se faisant au nom des utilisateurs finaux.
Le fonctionnement détaillé du système de transmission de flux multicast, objet de l'invention, sera donné plus loin. Il suffit ici d'en retenir le principe général fondé sur l'idée que les souscriptions au groupe multicast ne sont plus gérées par les utilisateurs eux-même mais sont contrôlées par un serveur central de gestion. Ce serveur gère la souscription au nom des utilisateurs et joue le rôle d'interface auprès de tous les fournisseurs de services qui lui adressent une description de leurs contenus.
Le serveur central de gestion gère le planning de diffusion pour toutes les zones de diffusion ; il détermine l'heure et le lieu de diffusion de chaque flux multicast. Lorsqu'un flux sélectionné doit être diffusé dans une zone donnée, le serveur central de gestion émet à destination du terminal pilote appartenant à l'architecture de la zone de diffusion qu'il représente, typiquement derrière le routeur d'accès, un ordre de souscription en indiquant notamment l'adresse du flux multicast sélectionné. Le terminal pilote s'abonne alors au groupe multicast désiré au nom des utilisateurs présents dans la zone de diffusion en émettant une demande de souscription grâce à un protocole de souscriptions. Cette demande transite par le routeur d'accès de la zone de diffusion qui la transmet vers la source multicast correspondante.
En résumé, la gestion de la souscription multicast au niveau de la plateforme, telle que proposée par l'invention, apporte une grande souplesse dans la gestion de la ressource multicast et permet un contrôle fin, par zone de diffusion, de la bande passante utilisée par les services multicast.
Un autre aspect abordé par l'invention concerne le transport de flux dans le cas de fournisseurs de contenus tiers. Le mécanisme de tunnels IP qui a été décrit plus haut en référence à la deuxième solution connue de l'état de la technique permet clairement de faire transiter un trafic multicast à travers un réseau purement unicast au moyen de tunnels IP. Cependant, ce mécanisme suppose qu'un routeur recevant une demande de souscription puisse y associer le tunnel correspondant, c'est à dire en déterminant l'extrémité du tunnel en fonction de l'adresse multicast des flux demandés. Or, les mécanismes standard de souscriptions aux groupes de flux multicast sont basés sur le protocole IGMPv2/RFC2236 qui ne permet à l'utilisateur que de spécifier l'adresse multicast désirée. Dans le contexte de l'invention, l'association tunnel/adresse multicast ne peut être configurée que statiquement au niveau des routeurs d'accès de chaque zone de diffusion.
Un inconvénient de cette méthode standard est son caractère statique et son manque de souplesse en terme de reconfigurabilité. En effet, le fait qu'une source peut émettre sur plusieurs adresses multicast différentes peut conduire à des tables de correspondance de dimension importante.
D'autre part, étant associée à un contenu spécifique, l'adresse de flux multicast est susceptible d'être couramment modifiée. Ainsi, à chaque fois qu'un fournisseur de services souhaite ajouter, ou modifier, une adresse multicast, celle-ci doit être configurée, ou reconfigurée, au niveau de tous les routeurs d'accès des zones de diffusion potentiellement clientes du nouveau service multicast. De plus, toutes les adresses multicast doivent être différentes quels que soient la source et le fournisseur de services. Cette dernière contrainte peut être difficile à surmonter si le réseau d'accès s'approvisionne auprès de fournisseurs de services indépendants, voire concurrents.
Aussi, un autre problème technique à résoudre par l'objet de la présente invention est de substituer au mécanisme classique de souscription basé sur la correspondance tunnel/adresse multicast un mécanisme plus simple à mettre en œuvre pour les routeurs d'accès et également plus stable vis à vis des éventuelles modifications apportées aux adresses multicast par les fournisseurs de services.
La solution à ce deuxième problème technique consiste, selon la présente invention, en ce que ledit serveur central de gestion est apte à recevoir du fournisseur de services une adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice. II est alors également prévu par l'invention que l'adresse de ladite source émettrice est incluse dans ladite demande de souscription.
En conséquence, l'invention prévoit avantageusement qu'un routeur d'accès destiné à acheminer ladite demande de souscription dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.
Ainsi, l'invention propose une solution au problème de transport qui reste toujours basée sur les mécanismes de tunnels IP, dans laquelle un tunnel doit être configuré entre le fournisseur de services et chaque zone de diffusion visée. Mais on s'affranchit de la contrainte d'association tunnel/adresse multicast en utilisant, par exemple, le protocole IGMPv3/RFC3376 qui permet à un utilisateur de spécifier, lors de la demande de souscription, l'adresse de la source multicast choisie qui sera associée à l'identification de l'extrémité du tunnel dans une table de correspondance. De cette manière, les routeurs d'accès n'ont pas à maintenir de listes d'association tunnel/adresse multicast puisqu'ils peuvent utiliser simplement l'adresse de la source multicast, laquelle peut être considérée comme figée contrairement aux adresses de groupes multicast, pour identifier l'extrémité du tunnel à emprunter. L'adresse de la source multicast est communiquée par le terminal pilote, au nom des utilisateurs de la zone de diffusion, grâce au protocole IGMPv3, lors de la demande de souscription. Enfin, la notion de contrôle centralisé de la souscription multicast fait que la solution proposée par l'invention, bien que basée sur des tunnels statiques, permet l'association dynamique des sources multicast et des zones de diffusion.
On comprend que l'évolution d'architecture résultant de l'invention est complètement transparente pour l'utilisateur final qui n'a pas besoin de mise à jour applicative spécifique. En particulier, il n'est pas nécessaire d'implémenter le protocole de souscriptions IGMPv3 dans tous les terminaux utilisateurs, mais uniquement au niveau du terminal pilote.
De même, du coté fournisseur de services, l'impact est relativement faible puisqu'il est limité à la configuration d'un tunnel par zone de diffusion. En effet, le système proposé par l'invention ne nécessite pas d'évolution de service ni d'applications ou protocoles particuliers, puisque la gestion de la ressource multicast est entièrement supervisée par le serveur central de gestion
Afin de sécuriser la communication entre le serveur central de gestion et le terminal pilote d'une zone de diffusion, l'invention propose que le message du serveur central au terminal pilote comprenne également une authentification dudit message. Cette disposition permet d'éviter que le terminal pilote ne reçoive des commandes de souscription provenant d'autres entités que le serveur central de gestion. L'invention concerne également un serveur central de gestion pour un système de transmission de flux multidiffusion, remarquable en ce que ledit serveur est apte à :
* recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles,
* sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone,
Un autre aspect du serveur central de gestion consiste, selon l'invention, en ce qu'il est apte à recevoir du fournisseur de services une adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice.
De même, un produit programme d'ordinateur pour un serveur central de gestion est remarquable en ce qu'il comprend des instructions de code de programme sur un support lisible par un ordinateur pour la mise en oeuvre des opérations consistant à :
* recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles,
* sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone, lorsque ledit programme est exécuté sur un ordinateur dudit serveur central de gestion.
L'invention concerne encore un terminal pilote pour un système de transmission de flux multidiffusion, remarquable en ce que ledit terminal pilote est apte à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.
En ce sens, un produit programme d'ordinateur pour un terminal pilote selon l'invention est remarquable en ce qu'il comprend des instructions de code de programme sur un support lisible par un ordinateur pour la mise en œuvre des opérations consistant à émettre à destination du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.
Enfin, un routeur d'accès pour un système de transmission de flux multidiffusion selon l'invention est remarquable en ce que ledit routeur d'accès, destiné à acheminer ladite demande de souscription, dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.
La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
La figure 2 est un schéma donnant l'architecture d'un système de transmission de flux multidiffusion conforme à l'invention.
La figure 3 est un diagramme de fonctionnement du système de transmission de la figure 2. Sur la figure 2 est représentée une architecture d'un système de transmission selon l'invention dans laquelle des fournisseurs de services A et B, hébergeant respectivement des sources A1 , A2 et B1 de flux multidiffusion, souhaitent alimenter, via un réseau de transport IP non multicast, comme l'Internet, des zones ZD1 et ZD2 de diffusion d'un réseau d'accès. Chacune de ces sources multicast peut diffuser plusieurs groupes de flux multicast.
Les zones ZD1 et ZD2 de diffusion sont respectivement connectées au réseau d'accès via les routeurs d'accès RA3 et RA4. Chacune de ces zones héberge respectivement un terminal pilote TP1 et TP2 et les points d'accès AP1 , AP2 d'une part, et AP3, AP4 d'autre part. Les fournisseurs de services A et B sont respectivement connectés au réseau de transport IP par les routeurs d'accès RA1 et RA2.
Le fournisseur A de services souhaitant alimenter les zones ZD1 et ZD2, des tunnels IP1 et IP2 sont respectivement établis statiquement entre RA1 et RA3 et entre RA1 et RA4. De même, le fournisseur de services B souhaitant alimenter la zone ZD1 de diffusion, un tunnel IP3 est alors établi statiquement entre RA2 et RA3. On notera que le nombre de tunnels IP dépend seulement du nombre de fournisseurs de services et est indépendant du nombre de sources multicast par fournisseur de services. Dans le mode de réalisation particulier de la figure 2, le réseau d'accès intègre un serveur central SC de gestion de flux multicast, incluant le contrôle et la commande de l'approvisionnement en contenus multicast. Le serveur central SC gère l'activation et l'accès à la ressource multicast pour le compte des utilisateurs finaux, et réalise l'interface avec les fournisseurs des services.
Plus particulièrement, le serveur central de gestion SC reçoit des fournisseurs de services A et B les adresses des flux multicast disponibles, ainsi que les adresses unicast des sources des flux correspondants. Le serveur central SC gère également la diffusion des flux au sein des zones ZD1 et ZD2 connectées au même réseau d'accès. Cette gestion consiste à sélectionner pour chaque zone et chaque tranche horaire un ou plusieurs des flux disponibles. Chacun des terminaux pilotes TP1 et TP2, représentants en quelque sorte des terminaux utilisateurs de leur zone respective, est informé de l'adresse multicast du flux, ou des flux, sélectionné(s) et l'adresse unicast de la source émettrice du flux, ou des flux, sélectionné(s) par un message transmis par le serveur central SC ou par consultation d'une table maintenue à jour par ledit serveur central.
De son côté, le terminal pilote de chaque zone ZD1 ou ZD2 émet à destination du fournisseur de service A ou B, selon la sélection réalisée par le serveur central de gestion SC, une demande de souscription, commune à tous les utilisateurs de la zone, pour le(s) flux multicast sélectionné(s). Cette demande de souscription comprend les adresses multicast de flux et unicast de sources reçues du serveur central SC.
Ces demandes de souscriptions sont relayées par les routeurs d'accès, RA3 et RA4, qui, pour acheminer la demande de souscription correspondante, disposent d'une simple table de correspondance associant l'adresse de source émettrice à un tunnel d'accès IP au fournisseur de services correspondant.
Le fonctionnement du système de transmission conforme à l'invention va être maintenant décrit en regard de la figure 3. Par souci de simplification, le diagramme montré sur cette figure ne fait référence qu'à une seule zone de diffusion, mais il bien clair qu'il s'étend aisément à l'approvisionnement en flux multicast d'un nombre quelconque de zones. Un tunnel IP statique est préalablement configuré entre le routeur d'accès du fournisseur de services et celui de la zone de diffusion considérée. On suppose que le réseau de transport IP est l'Internet.
1.a. La source multicast, A1 ou A2, du fournisseur A de services par exemple, émet un flux multicast auquel est associée une adresse IP multicast.
Le flux multicast est bloqué par le routeur d'accès, RA1 dans l'exemple choisi, puisque aucune demande de souscription n'a été enregistrée par ce dernier.
Le flux multicast ne transite donc pas par le réseau de transport, ici l'Internet.
1.b. Le fournisseur de services fournit au serveur central SC de gestion une description du service IP multicast. Cette description comprend notamment l'adresse IP multicast et l'adresse de la source émettrice correspondante. Le serveur central de gestion SC établit alors un programme de diffusion en associant à chaque zone au moins un flux multicast sélectionné et un horaire de diffusion. En fait, la plateforme de gestion du contenu multicast joue ici un rôle de régie de production.
2. A l'instant prévu par le programme de diffusion, le serveur central de gestion SC émet un ordre de souscription au terminal pilote TP de la zone de diffusion ZD concernée. Cet ordre précise les adresses IP du groupe et celle de la source multicast auxquels le terminal pilote doit s'abonner. 3. Le terminal pilote TP interprète l'ordre de souscription et émet une demande selon le protocole IGMPv3 sur son sous-réseau IP en précisant le groupe et la source multicast désirés.
4. La demande de souscription émise par le terminal pilote est reçue et traitée par le routeur d'accès de la zone de diffusion qui l'encapsule et la transmet dans le tunnel IP dont l'extrémité est le routeur d'accès du fournisseur de services concerné. En fait, le routeur d'accès de la zone détermine la bonne extrémité de tunnel grâce à l'adresse de la source émettrice indiquée dans le message de souscription au protocole IGMPv3.
5. Le routeur d'accès du fournisseur de services, recevant une demande de souscription sur l'interface du tunnel IP, fait suivre le flux multicast dont l'adresse IP correspond à celle demandée vers l'extrémité du tunnel, à savoir le routeur d'accès de la zone de diffusion. En d'autres termes, le flux multicast est encapsulé dans le tunnel dont l'origine est le routeur d'accès de la zone ZD d'où émane la demande de souscription multicast.
6. Le routeur d'accès de la zone de diffusion désencapsule les données multicast et les fait suivre, en multicast, sur son sous-réseau IP dont font partie les points d'accès. Le flux multicast est alors reçu par l'interface du terminal de l'utilisateur final mais n'est pas remonté vers les couches applicatives avant que ce dernier n'en fasse la demande.
7. Afin de pouvoir consommer le service IP multicast, l'application multicast embarquée par terminal de l'utilisateur client émet une demande de souscription concernant le flux multicast désiré, ce flux étant déjà reçu au niveau de l'interface. Cette demande a en fait une portée limitée à l'interface et ne peut concerner que le flux auquel le terminal pilote s'est préalablement abonné. En effet, si le flux demandé n'est pas présent sur l'interface, la demande reste vaine car elle n'est pas propagée dans le réseau. Le processus décrit ci-dessus est limité à une seule zone de diffusion pour des raisons de simplification de la description. Cependant, si plusieurs zones de diffusion devaient être concernées par la diffusion d'un même contenu multicast, c'est à dire en provenance d'une même source multicast, on répétera simplement les étapes 2 à 7 pour chaque zone. Enfin, on notera que cette architecture et l'utilisation du protocole
IGMPv3 permet d'attribuer une même adresse multicast à des flux multicast différents, à savoir issus de sources multicast différentes. Cette caractéristique facilite l'interconnexion avec des fournisseurs de services indépendants qui peuvent très bien utiliser les mêmes adresses IP multicast pour leurs contenus.

Claims

REVENDICATIONS
1. Système de transmission de flux multidiffusion entre au moins une source de flux multidiffusion d'au moins un fournisseur de services et au moins une zone de diffusion comprenant une pluralité de terminaux utilisateurs, caractérisé en ce que ledit système comprend : - un serveur central de gestion des flux multidiffusion, - un terminal pilote associé à chaque zone de diffusion, ledit serveur central de gestion étant apte à :
* recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles,
* sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone et émettre à destination du terminal pilote associé un ordre de souscription audit flux multidiffusion sélectionné, et ledit terminal pilote étant apte à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.
2. Système selon la revendication 1 , caractérisé en ce que ledit serveur central de gestion est apte à recevoir du fournisseur de services une adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice.
3. Système selon la revendication 2, caractérisé en ce que l'adresse de ladite source émettrice est incluse dans ladite demande de souscription.
4. Système selon la revendication 3, caractérisé en ce qu'un routeur d'accès destiné à acheminer ladite demande de souscription dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.
5. Système selon l'une des revendications 3 ou 4, caractérisé en ce que ladite demande de souscription est effectuée selon le protocole IGMPv3.
6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le message du serveur central au terminal pilote comprend également une authentification dudit message.
7. Serveur central de gestion pour un système de transmission de flux multidiffusion selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit serveur est apte à :
* recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles,
* sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone.
8. Serveur central de gestion selon la revendication 7, caractérisé en ce qu'il est apte à recevoir du fournisseur de services une adresse de la source émettrice du flux multidiffusion sélectionné, et en ce que ledit message du serveur central de gestion au terminal pilote comprend également l'adresse de ladite source émettrice.
9. Serveur central de gestion selon des revendications 7 ou 8, caractérisé en ce que le message du serveur central au terminal pilote comprend également une authentification dudit message.
10. Produit programme d'ordinateur pour un serveur central de gestion selon la revendication 7, caractérisé en ce qu'il comprend des instructions de code de programme sur un support lisible par un ordinateur pour la mise en œuvre des opérations consistant à : * recevoir dudit fournisseur de services des adresses des flux multidiffusion disponibles,
* sélectionner parmi les flux disponibles au moins un flux multidiffusion à diffuser dans ladite zone, lorsque ledit programme est exécuté sur un ordinateur dudit serveur central de gestion.
11. Terminal pilote pour un système de transmission de flux multidiffusion selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit terminal pilote est apte à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.
12. Produit programme d'ordinateur pour un terminal pilote selon la revendication 11 , caractérisé en ce qu'il comprend des instructions de code de programme sur un support lisible par un ordinateur pour la mise en œuvre des opérations consistant à émettre en direction du fournisseur de services une demande de souscription, commune à tous les terminaux utilisateurs de la zone associée, pour le flux multidiffusion sélectionné pour ladite zone par le serveur central de gestion.
13. Routeur d'accès pour un système de transmission de flux multidiffusion selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit routeur d'accès, destiné à acheminer ladite demande de souscription, dispose d'une table de correspondance associant l'adresse de ladite source émettrice à un tunnel d'accès au fournisseur de services correspondant.
PCT/FR2005/002777 2004-11-12 2005-11-07 Systeme de transmission de flux multidiffusion WO2006051210A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0412058 2004-11-12
FR0412058A FR2878104A1 (fr) 2004-11-12 2004-11-12 Systeme de transmission de flux multidiffusion

Publications (1)

Publication Number Publication Date
WO2006051210A1 true WO2006051210A1 (fr) 2006-05-18

Family

ID=34950646

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/002777 WO2006051210A1 (fr) 2004-11-12 2005-11-07 Systeme de transmission de flux multidiffusion

Country Status (2)

Country Link
FR (1) FR2878104A1 (fr)
WO (1) WO2006051210A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030142671A1 (en) * 2002-01-28 2003-07-31 Derango Mario F. Reservation proxy function supporting filtering of multicast traffic in packet-based communication systems

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030142671A1 (en) * 2002-01-28 2003-07-31 Derango Mario F. Reservation proxy function supporting filtering of multicast traffic in packet-based communication systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HIGGINS L ET AL: "Tunneling multicast traffic through non-multicast-aware networks and encryption devices", MILCOM 2001. PROCEEDINGS. COMMUNICATIONS FOR NETWORK-CENTRIC OPERATIONS: CREATING THE INFORMATION FORCE. MCLEAN, VA, OCT. 28 - 30, 2001, IEEE MILITARY COMMUNICATIONS CONFERENCE, NEW YORK, NY : IEEE, US, vol. VOL. 1 OF 2, 28 October 2001 (2001-10-28), pages 296 - 300, XP010579024, ISBN: 0-7803-7225-5 *

Also Published As

Publication number Publication date
FR2878104A1 (fr) 2006-05-19

Similar Documents

Publication Publication Date Title
EP3054652B1 (fr) Ajustement dynamique du mode de transmission dans un systeme de communication satellite
US6523069B1 (en) Transmission of multicast media between networks
US7296091B1 (en) System and method for receiving over a network a broadcast from a broadcast source
Sweha et al. Angelcast: cloud-based peer-assisted live streaming using optimized multi-tree construction
EP1966978B1 (fr) Procédé d'affectation dynamique d'ensembles d'adresses par dhcp, entité de gestion, relais et programme d'ordinateur correspondants
US8379641B2 (en) Light host management protocol on multicast capable router
EP3694146B1 (fr) Procédé de traitement de flux audiovidéo en conférence multipartite, dispositifs, système et programme correspondants
JP5575915B2 (ja) Ｉｐｔｖのための階層型サービス再販機構
EP1687975B1 (fr) Diffusion sécurisée et personnalisée de flux audiovisuels par un systeme hybride unicast/multicast
US9160683B2 (en) Providing PIM-SSM support for MRSVP-TE based multicast virtual private networks
EP2744168B1 (fr) Système, procédé et serveur d'optimisation de diffusion en continu et en direct pour optimiser la distribution de contenu en direct sur un réseau de distribution de contenu
US11245618B2 (en) Multicast traceroute facility with batch query processing for multiple flows and reservation of resources for requested link metrics
CN113301096A (zh) 内容分发网络中节点间数据传输方法、系统及节点设备
US8621083B2 (en) System and method for multicasting through a localized computer network
US20100067518A1 (en) Multicast Systems, Methods, and Computer Program Products
EP1207632B1 (fr) Procédé d'adressage dans un réseau d'accès ou d'infrastructure satellites pouvant servir de support à des transferts de données en mode non-connecté
FR3074004B1 (fr) Systeme de communication de groupe pour la transmission de donnees multimedia
AU2011249457B2 (en) Source selection by routers
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d'un flux de données selon un mode de transmission multipoint
EP2273786A1 (fr) Contrôle d'accès à un contenu numérique
EP1794983A1 (fr) Decouverte et selection intelligente de serveurs dans un reseau de multidiffusion
WO2006051210A1 (fr) Systeme de transmission de flux multidiffusion
FR2880752A1 (fr) Methode de construction d'une adresse de diffusion unique par un serveur et serveur utilisant cette methode
Brandt et al. A flexible reflector for media streams
EP2633642B1 (fr) Procédés de communication, dispositif de communication, entité de gestion, programme d'ordinateur et support d'informations pour la distribution hybride de données

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase

Ref document number: 05817308

Country of ref document: EP

Kind code of ref document: A1