EP2055042A2 - Mecanisme pour la gestion de connexions de recepteurs / decodeurs - Google Patents

Mecanisme pour la gestion de connexions de recepteurs / decodeurs

Info

Publication number
EP2055042A2
EP2055042A2 EP07823727A EP07823727A EP2055042A2 EP 2055042 A2 EP2055042 A2 EP 2055042A2 EP 07823727 A EP07823727 A EP 07823727A EP 07823727 A EP07823727 A EP 07823727A EP 2055042 A2 EP2055042 A2 EP 2055042A2
Authority
EP
European Patent Office
Prior art keywords
request
communication device
decoder
receiver
multimedia file
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
EP07823727A
Other languages
German (de)
English (en)
Inventor
Patrick Leprince
David Libault
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.)
InterDigital CE Patent Holdings SAS
Original Assignee
Thomson Licensing SAS
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 Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of EP2055042A2 publication Critical patent/EP2055042A2/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
    • 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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/748—Negotiation of resources, e.g. modification of a request
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/806—Broadcast or multicast traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity

Definitions

  • the present invention relates to the field of Information and Communication Technologies.
  • the present invention relates more particularly to a mechanism for managing receiver / decoder connections.
  • the present invention relates to the case in which multiple receivers / set-top boxes (STBs) in English language, are associated with an ADSL gateway ("Asymmetric Digital Subscriber Line” or “Digital Subscriber Line Flow”). asymmetrical ").
  • a mechanism for refusing the connection of a receiver / decoder to a multicast stream if the ADSL bandwidth used by the streams sent to the other receivers / decoders is too large, must be implemented.
  • One solution could be for the gateway to "spy" on the Internet Group Management Protocol (IGMP) packets sent by each receiver / decoder, then, using the service plan describing the characteristics of each stream, calculate the total bandwidth used.
  • IGMP Internet Group Management Protocol
  • a receiver / decoder To receive a multicast stream, a receiver / decoder must send an IGMP "join" packet in multicast. This packet is echoed along the multicast router chain for one router to direct the requested stream to the port of another router where the request was received. No acknowledgment to this "join" packet is sent back to the receiver / decoder.
  • the gateway decides to intercept this IGMP packet and block it so as not to overload the bandwidth, there is no way to indicate the lack of flow to the receiver / decoder.
  • the TV screen remains black.
  • a communication system in one embodiment, includes receivers / decoders that have the ability to observe the subnet to which they are coupled.
  • a multicast router couples one or more group (s), such as groups of video programs, to the receivers / decoders as requested by the receivers / decoders.
  • a receiver / decoder leaves a first group, for example, and thus sends a "leave" message to the router, the other (or the other) receiver (s) / decoder (s) know (know) that it (s) ) must send a join message if they are subscribed to this first group. Thus, the router knows immediately that it must couple this first group to the subnet.
  • the present invention intends to overcome the drawbacks of the prior art by proposing a solution to prevent the screen remains black, when no flow is transmitted to the receiver / decoder, in the case where the bandwidth would risk to be overloaded.
  • the present invention relates, in its most general sense, to a communication device, connected on the one hand to a communication network and on the other hand to at least one receiver / decoder, characterized in that it comprises selection means between the following different possibilities, according to the bandwidth available on the communication network, on receipt of a request from said receiver / decoder:
  • said device further comprises means for operating a service plan containing all the multicast addresses and at least one characteristic of the corresponding streams, for example the name of the program, the codes used or the bandwidth used.
  • said device further comprises means for operating a table of the streams being received on each of the receivers / decoders connected to said communication device, said request being established from viewed IGMP requests.
  • said device comprises means for calculating the bandwidth of the communication network used and means for calculating the bandwidth of the communication network required by receiving a new on-demand stream of a new IGMP request, from the service plan and the flow table.
  • said device is compatible ADSL ("Asymmetric Digital Subscriber Line").
  • said device has in a configuration table a URL ("uniform resource locator") and comprises means for recovering said preconfigured multimedia file from said URL and means for transmitting said multimedia file to said streamed receiver / decoder multicast and loop.
  • the multimedia file is retrieved from said URL using the Hypertext Transfer Protocol (HTTP).
  • said device comprises means for formatting said multimedia file.
  • the multimedia file may include video, animations and / or a voice message.
  • said device comprises modulation and demodulation means.
  • the present invention also relates to a communication method implementing a communication device, connected on the one hand to a communication network and on the other hand to at least one receiver / decoder, characterized in that it comprises a step of selecting between the following different possibilities, according to the bandwidth available on the communication network, upon receipt of a request from said receiver / decoder:
  • said method further comprises a step of operating a service plan containing all the multicast addresses and at least one characteristic of the corresponding streams, for example the name of the program, the codes used or the bandwidth used.
  • the method furthermore comprises a step of exploiting a table of the streams being reception on each of the receivers / decoders connected to said communication device, said request being established from viewed IGMP requests.
  • said method further comprises a step of calculating the bandwidth of the communication network used and a step of calculating the bandwidth of the communication network required by receiving a new stream on request of a new IGMP query, from the service plan and the flow table.
  • said communication device has in a configuration table a URL ("uniforrn resource locator") and said method includes a step of recovering said preconfigured multimedia file from said URL and a step of transmitting said multimedia file to the said Receiver / decoder in multicast and loop flow.
  • a URL uniforrn resource locator
  • HTTP Hypertext Transfer Protocol
  • HTTP Hypertext Transfer Protocol
  • MPEG Moving Picture Experts Group
  • FIGS 1 and 3 illustrate an embodiment of the method according to the present invention
  • FIG. 2 illustrates the communication device according to the present invention.
  • Figure 4 illustrates an IGMP packet.
  • the communication device (or residential gateway) (1) shown in FIGS. 1 and 2, comprises:
  • An interface (15) to an external communication network, for example a DSL interface, or an interface to a fiber optic network;
  • a plurality of Ethernet interfaces (21, 22, 23, 24).
  • the communication device retrieves a "service plan" containing all the multicast addresses and the characteristics of the corresponding streams (program name, coded and bandwidth used).
  • the communication device maintains, from viewed IGMP requests, a table of the streams being received. From this table and the service plan, it calculates the bandwidth used, as well as the additional bandwidth required by a new IGMP request. From the bandwidth (for example ADSL) available, the communication device decides whether this request should be transmitted without modification, redirected to a stream of inferior quality, or refused by broadcasting a preconfigured multimedia file.
  • the service plan reflects the available offer on the network so as to address a park of several decoders in the residence of the user.
  • the offer may be different per user but the IP address: Port is unique per service.
  • the list of parameters associated with each service may change depending on the needs on the gateway.
  • the service plan provided to the gateway has the following form: Service Name, IP Address: Service Port, Video Encoding Type, Audio Encoding Type, Stream Throughput Kbit / s service.
  • the gateway needs to know the type of video codec and possibly audio, if a sound message is presented to the user, so as to transmit information in the correct coding format.
  • the gateway does not know the capacity of the decoder that calls it but the assumption can be made that a decoder does not request a stream that only corresponds to its decoding capacity.
  • the service plan is not necessarily in the form of a table.
  • the IGMP protocol transiting between the set-top boxes and the IGMP switches allows the gateway (for example ADSL) to know for all the equipment of its network those who subscribe to these streams, to build the table of flows being received.
  • the gateway for example ADSL
  • This flow table includes in parameter an IP address corresponding to that of the stream to be received associated with a recipient receiver address.
  • a flow table is therefore a list of source stream IP address pair and associated recipient IP address pair.
  • Table 1 sample flow table
  • the flow table is not necessarily in the form of a table.
  • the gateway upon receipt of a request from said receiver / decoder, can modify the request to request a flow of lesser quality.
  • a description of changes made to IGMP packets is given here.
  • IGMP is defined by RFC 2236.
  • An IGMP packet is formed of 8 bytes, and is in the form shown in Figure 4.
  • Max Resp Time describes the value of a timer used in state machines implementing the protocol
  • Group Address is the multicast address of the group you want to subscribe to or want to leave
  • the gateway has resources to modify IGMP requests received from the STB before transmitting them to the AN.
  • the "Group Address" field of the Type Membership Report (0x16) command is modified from the service table.
  • requests received from the Membership Query access network will be sent with the changed Group Address field to the STB.
  • the gateway may not transmit the IGMP request to the access network, and itself produce a video stream, possibly representing a still image, which it will transmit to the STB in the form of multicast packets.
  • the residential gateway represented in FIG. 1, has in its configuration table a URL ("uniform resource locator") to which a video file is retrieved by HTTP.
  • This video file after formatting, is sent to the STB by the gateway as a multicast stream, loop.
  • ADSL bandwidth is not used during the loop broadcast.
  • This file contains information explaining to the user the reason for the non-broadcast of the requested channel (for example: "The ADSL subscription you have does not allow you to simultaneously view 2 High Definition streams. go to hc tp: // www ozange-ft. corner "). It could also contain animations, because it is a video file, as well as a voice message.
  • the recovery of the "service plan" allows the communication device to know the audio and video codecs used for each multicast address and thus to send a preconfigured multimedia file encoded in the same way.
  • the invention is described in the foregoing by way of example. It is understood that the skilled person is able to realize different variants of the invention without departing from the scope of the patent.

Abstract

La présente invention se rapporte à un dispositif de communication, comprenant des moyens de modulation et de démodulation, relié d'une part à un réseau de communication et d'autre part à au moins un récepteur/décodeur, caractérisé en ce qu'il comprend des moyens de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance dudit récepteur/décodeur : transmettre audit réseau la requête sans modification; ou modifier la requête pour demander un flux de qualité moindre; ou refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré. La présente invention se rapporte également à un procédé de communication.

Description

MECANISME POUR LA GESTION DE CONNEXIONS DE RECEPTEURS / DECODEURS
Domaine de l' invention
La présente invention se rapporte au domaine des Technologies de l'Information et de la Communication.
La présente invention se rapporte plus particulièrement à un mécanisme pour la gestion de connexions de récepteurs / décodeurs.
Etat de la technique
La présente invention concerne le cas dans lequel de multiples récepteurs/décodeurs ou set-top boxes (STBs) en langue anglaise, sont associées à une passerelle ADSL (« Asymmetric Digital Subscriber Line » en anglais, ou « Ligne d'abonné numérique à débit asymétrique ») . Un mécanisme, permettant de refuser la connexion d'un récepteur/décodeur à un flux multicast si la bande passante ADSL utilisée par les flux envoyés sur les autres récepteurs/décodeurs est trop importante, doit être mis en place.
Une solution pourrait consister, pour la passerelle, à "espionner" les paquets IGMP (« Internet Group Management Protocol ») envoyées par chaque récepteur/décodeur, puis, à l'aide du plan de service décrivant les caractéristiques de chaque flux, calculer la bande passante totale utilisée.
Pour recevoir un flux multicast, un récepteur/décodeur doit envoyer un paquet IGMP "join" en multicast. Ce paquet est répercuté le long de la chaîne de routeurs multicast pour qu'un routeur dirige le flux demandé vers le port d'un autre routeur où la demande a été reçue. Aucun acquittement à ce paquet « join » n'est envoyé en retour au récepteur/décodeur.
Si la passerelle décide d'intercepter ce paquet IGMP et de le bloquer pour ne pas surcharger la bande passante, on ne dispose d'aucun moyen pour signifier l'absence de flux au récepteur/décodeur. L'écran de la TV reste noir.
L'art antérieur connaît, par la demande de brevet américain US 2003/0035378 (Motorola) , un procédé et un appareil pour la gestion de données multicast dans un sous -réseau IP. Un système de communication, dans un mode de réalisation, comprend des récepteurs/décodeurs qui ont la possibilité d'observer le sous-réseau auquel elles sont couplées. Un routeur multicast couple un ou plusieurs groupe (s), tels que des groupes de programmes vidéo, aux récepteurs/décodeurs tel que cela est demandé par les récepteurs/décodeurs. Si un récepteur/décodeur quitte un premier groupe, par exemple, et envoie ainsi un message « leave » au routeur, l'autre (ou les autres) récepteur (s) /décodeur ( s) sait (savent) qu'elle(s) doit (doivent) envoyer un message « join » si elle (s) est (sont) abonnée (s) à ce premier groupe. Ainsi, le routeur sait immédiatement qu' il doit coupler ce premier groupe au sous-réseau.
L'art antérieur connaît également, par la demande de brevet américain US 2005/237952 (Marconi Communications) , un procédé et un dispositif pour les conférences avec un contrôle de bande passante. Ce document ne décrit pas de dispositif de communication comportant des moyens de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance d'un récepteur/décodeur :
• transmettre audit réseau la requête sans modification ; ou
• modifier la requête pour demander un flux de qualité moindre ; ou
• refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré .
L'art antérieur connaît également, par l'article technique « Multicasting in Differentiated Service Domains » (Baij an Yang et al, IEEE Global Télécommunications Conférence, 17 novembre 2003), des solutions de gestion de la qualité de service dans des réseaux de communication. Ce document ne décrit pas de dispositif de communication comportant des moyens de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance d'un récepteur/décodeur :
• transmettre audit réseau la requête sans modification ; ou
• modifier la requête pour demander un flux de qualité moindre ; ou
• refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré .
L'art antérieur connaît également, par la demande de brevet américain US 2006/146857, un mécanisme de contrôle d'admission pour des récepteurs multicast. Ce document ne décrit pas de dispositif de communication comportant des moyens de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance d'un récepteur/décodeur :
• transmettre audit réseau la requête sans modification ; ou
• modifier la requête pour demander un flux de qualité moindre ; ou
• refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré .
Expose de l'invention
La présente invention entend remédier aux inconvénients de l'art antérieur en proposant une solution permettant d'éviter que l'écran reste noir, lorsqu'aucun flux n'est transmis au récepteur/décodeur, dans le cas où la bande passante risquerait d'être surchargée .
A cet effet, la présente invention concerne, dans son acception la plus générale, un dispositif de communication, relié d'une part à un réseau de communication et d'autre part à au moins un récepteur/décodeur, caractérisé en ce qu'il comprend des moyens de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance dudit récepteur/décodeur :
• transmettre audit réseau la requête sans modification ; ou • modifier la requête pour demander un flux de qualité moindre ; ou
• refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré .
De préférence, ledit dispositif comporte en outre des moyens d'exploitation d'un plan de service contenant toutes les adresses multicast et au moins une caractéristique des flux correspondants, par exemple le nom du programme, les codées utilisés ou la bande passante utilisée.
Avantageusement, ledit dispositif comporte en outre des moyens d'exploitation d'une table des flux en cours de réception sur chacun des récepteurs/décodeurs connectés audit dispositif de communication, ladite requête étant établie à partir de requêtes IGMP vues.
De préférence, ledit dispositif comporte des moyens de calcul de la bande passante du réseau de communication utilisée et des moyens de calcul de la bande passante du réseau de communication requise par la réception d'un nouveau flux sur demande d'une nouvelle requête IGMP, à partir du plan de service et de la table des flux.
Avantageusement, ledit dispositif est compatible ADSL (« Asymmetric Digital Subscriber Line ») .
Selon une variante avantageuse, ledit dispositif possède dans une table de configuration une URL (« uniform resource locator « ) et comporte des moyens pour récupérer ledit fichier multimédia préconfiguré depuis ladite URL et des moyens de transmission dudit fichier multimédia au dit récepteur/décodeur en flux multicast et en boucle. De préférence, le fichier multimédia est récupéré depuis ladite URL au moyen du protocole HTTP (« Hypertext Transfer Protocol ») .
Selon un mode de mise en œuvre particulier, ledit dispositif comporte des moyens de mise en forme dudit fichier multimédia.
Ledit fichier multimédia peut comprendre de la vidéo, des animations et/ou un message vocal.
De préférence, ledit dispositif comporte des moyens de modulation et de démodulation.
La présente invention se rapporte également à un procédé de communication mettant en œuvre un dispositif de communication, relié d'une part à un réseau de communication et d'autre part à au moins un récepteur/décodeur, caractérisé en ce qu'il comprend une étape de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance dudit récepteur/décodeur :
• transmettre audit réseau la requête sans modification ; ou
• modifier la requête pour demander un flux de qualité moindre ; ou
• refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré .
De préférence, ledit procédé comporte en outre une étape d'exploitation d'un plan de service contenant toutes les adresses multicast et au moins une caractéristique des flux correspondants, par exemple le nom du programme, les codées utilisés ou la bande passante utilisée.
Avantageusement, le procédé comporte en outre une étape d'exploitation d'une table des flux en cours de réception sur chacun des récepteurs/décodeurs connectés audit dispositif de communication, ladite requête étant établie à partir de requêtes IGMP vues.
Selon un mode de réalisation, ledit procédé comporte en outre une étape de calcul de la bande passante du réseau de communication utilisée et une étape de calcul de la bande passante du réseau de communication requise par la réception d'un nouveau flux sur demande d'une nouvelle requête IGMP, à partir du plan de service et de la table des flux.
Selon une variante avantageuse, ledit dispositif de communication possède dans une table de configuration une URL (« uniforrn resource locator » ) et le dit procédé comporte une étape de récupération ledit fichier multimédia préconfiguré depuis ladite URL et une étape de transmission dudit fichier multimédia au dit récepteur/décodeur en flux multicast et en boucle.
Le dispositif et le procédé selon la présente invention possèdent de nombreux avantages :
• ils n'entraînent pas de modification de la STB ;
• ils ne nécessitent pas de capacité de calcul supplémentaire dans le récepteur/décodeur (passerelle), car il n'y pas d'encodage vidéo ;
• il est possible de définir une URL différente pour chaque cas de refus de service ;
• il est possible d'ajouter dans la commande HTTP (« Hypertext Transfer Protocol » ou « protocole de transfert hypertexte ») envoyée par la passerelle les paramètres permettant au serveur HTTP de générer "à la volée" le fichier MPEG (« Moving Picture Experts Group ») d'information ; et • il est possible d'effectuer une redirection vers un autre flux avec un débit moins élevé et une moins bonne résolution.
Brève description des dessins
On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux Figures dans lesquelles :
• les Figures 1 et 3 illustrent un mode de réalisation du procédé selon la présente invention ;
• la Figure 2 illustre le dispositif de communication selon la présente invention ; et
• la Figure 4 illustre un paquet IGMP.
Description détaillée des modes de réalisation de l'invention
Le dispositif de communication (ou passerelle résidentielle) (1), représenté sur les Figures 1 et 2, comporte :
• un processeur (11) ;
• une mémoire vive (31) ;
• une mémoire de stockage (32) ;
• une interface (15) vers un réseau de communication externe, par exemple une interface DSL, ou une interface vers un réseau à fibre optique ;
• une interface W-Lan (14) ;
• une interface DECT (12) ;
• une interface Bluetooth (13) ; et
• une pluralité d'interfaces Ethernet (21, 22, 23, 24) .
Le dispositif de communication (ou passerelle résidentielle) (1), récupère un « plan de service » contenant toutes les adresses multicast et les caractéristiques des flux correspondants (nom du programme, codées et bande passante utilisée). Le dispositif de communication maintient, à partir des requêtes IGMP vues, une table des flux en cours de réception. A partir de cette table et du plan de service, il calcule la bande passante utilisée, ainsi que la bande passante supplémentaire requise par une nouvelle requête IGMP. A partir de la bande passante (par exemple ADSL) disponible, le dispositif de communication décide si cette requête doit être transmise sans modification, redirigée vers un flux de qualité inférieure, ou bien refusée en diffusant un fichier multimédia préconfiguré.
Dans un mode de réalisation, le plan de service reflète l'offre disponible sur le réseau de manière à adresser un parc de plusieurs décodeurs dans la résidence de l'utilisateur. L'offre peut être différente par utilisateur mais l'adresse IP:Port est unique par service . La liste des paramètres associés à chaque service peut évoluer en fonction des besoins sur la passerelle .
Dans un mode de mise en œuvre particulier, le plan de service fourni à la passerelle possède la forme suivante : Nom du Service, adresse IP:Port du service, type de codage de la video, type de codage de l'audio, débit flux de service en Kbit/s.
Dans le cadre de la présente invention, la passerelle a besoin de connaître le type de codée video et éventuellement audio, si un message sonore est présenté à l'utilisateur, de manière à transmettre une information dans le bon format de codage. La passerelle ne connaît pas la capacité du décodeur qui l'appelle mais l'hypothèse peut être faite qu'un décodeur ne demande un flux qui ne correspond qu'à sa capacité de décodage.
Un exemple de plan de service est représenté ci-dessous
Table 1 : exemple de plan de service
Dans la pratique, le plan de service n'est pas nécessairement sous la forme d'un tableau.
Le protocole IGMP transitant entre les décodeurs (set-top boxes) et les commutateurs IGMP (switchs/routeurs) permet à la passerelle (par exemple ADSL) de connaître pour l'ensemble des équipements de son réseau ceux qui sont abonnés à ces flux, pour construire la table des flux en cours de réception.
Cette table de flux comporte en paramètre une adresse IP correspondant à celle du flux à recevoir associée à une adresse de récepteur destinataire.
Une table de flux est donc une liste de couple d'adresse IP de flux source et d'adresse IP de destinataire associé.
Soit par exemple:
Table 1 : exemple de table de flux
Dans la pratique, la table de flux n'est pas nécessairement sous la forme d'un tableau.
La passerelle, à réception d'une requête en provenance dudit récepteur/décodeur, peut modifier la requête pour demander un flux de qualité moindre. Un descriptif des modifications apportées aux paquets IGMP est donné ici. Le protocole IGMP est défini par la RFC 2236.
Un paquet IGMP est formé de 8 octets, et se présente sous la forme illustrée Figure 4.
• Type décrit la commande envoyée
• Max Resp Time décrit la valeur d'un timer utilisé dans les machines d'état implémentant le protocole
• Checksum permet de vérifier l'intégrité des données du paquet
• Group Address est l'adresse multicast du groupe auquel on veut s'abonner ou que l'on veut quitter
La passerelle dispose des ressources lui permettant de modifier les requêtes IGMP reçues depuis la STB avant de les émettre vers le réseau d'accès.
Ainsi, par exemple, pour que la STB reçoive un flux de qualité inférieure à ce qu'elle avait demandé, le champ "Group Address " de la commande de Type Membership Report (0x16) est modifié à partir de la table de service.
Il faudra prendre soin d'effectuer la même modification sur la requête de Type Leave Group (0x17) .
De même, pour que l'opération soit transparente pour la STB, les requêtes reçues depuis le réseau d'accès de type Membership Query (OxIl) seront envoyées avec le champ "Group Address" modifié vers la STB. La passerelle peut, ne pas transmettre la requête IGMP au réseau d'accès, et produire elle même un flux vidéo, représentant éventuellement une image fixe, qu'elle transmettra à la STB sous forme de paquets multicast .
Dans la suite, nous détaillons le cas dans lequel la requête IGMP est refusée et un fichier multimédia est diffusé.
La passerelle résidentielle, représentée sur la Figure 1, dispose dans sa table de configuration une URL (« uniform resource locator ») à laquelle on récupère par HTTP un fichier vidéo. Ce fichier vidéo, après mise en forme, est envoyé à la STB par la passerelle comme un flux multicast, en boucle. Ainsi, on n'utilise pas de bande passante ADSL pendant la diffusion en boucle.
Ce fichier contient des informations expliquant à l'utilisateur la raison de la non-diffusion de la chaîne demandée (par exemple : "L'abonnement ADSL dont vous disposez ne permet pas de visionner simultanément 2 flux Haute Définition . Pour augmenter la capacité de votre ligne rendez-vous sur hc tp : // www. ozange-ft . coin ") . Il pourrait aussi contenir des animations, car c'est un fichier vidéo, ainsi qu'un message vocal.
La récupération du « plan de service » permet au dispositif de communication de connaître les codées audio et vidéo utilisés pour chaque adresse multicast et ainsi d'envoyer un fichier multimédia préconfiguré encodé de la même manière . L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims

REVENDICATIONS
1. Dispositif de communication, relié d'une part à un réseau de communication et d'autre part à au moins un récepteur/décodeur, caractérisé en ce qu' il comprend des moyens de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance dudit récepteur/décodeur :
• transmettre audit réseau la requête sans modification ; ou
• modifier la requête pour demander un flux de qualité moindre ; ou
• refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré .
2. Dispositif de communication selon la revendication 1 caractérisé en ce qu' il comporte en outre des moyens d'exploitation d'un plan de service contenant toutes les adresses multicast et au moins une caractéristique des flux correspondants, par exemple le nom du programme, les codées utilisés ou la bande passante utilisée.
3. Dispositif de communication selon la revendication 1 ou 2 caractérisé en ce qu'il comporte en outre des moyens d'exploitation d'une table des flux en cours de réception sur chacun des récepteurs/décodeurs connectés audit dispositif de communication, ladite requête étant établie à partir de requêtes IGMP vues.
4. Dispositif de communication selon les revendication 2 et 3 caractérisé en ce qu'il comporte des moyens de calcul de la bande passante du réseau de communication utilisée et des moyens de calcul de la bande passante du réseau de communication requise par la réception d'un nouveau flux sur demande d'une nouvelle requête IGMP, à partir du plan de service et de la table des flux.
5. Dispositif de communication selon la revendication 1, 2, 3 ou 4 caractérisé en ce qu'il est compatible ADSL (« Asymmetric Digital Subscriber Line ») .
6. Dispositif de communication selon l'une quelconque des revendications précédentes caractérisé en ce qu'il possède dans une table de configuration une URL
(« uniform resource locator » ) et en ce qu' il comporte des moyens pour récupérer ledit fichier multimédia préconfiguré depuis ladite URL et des moyens de transmission dudit fichier multimédia au dit récepteur/décodeur en flux multicast et en boucle.
7. Dispositif de communication selon la revendication 6 caractérisé en ce que le fichier multimédia est récupéré depuis ladite URL au moyen du protocole HTTP (« Hypertext Transfer Protocol ») .
8. Dispositif de communication selon la revendication 6 ou 7 caractérisé en ce qu'il comporte des moyens de mise en forme dudit fichier multimédia.
9. Dispositif de communication selon l'une quelconque des revendications précédentes caractérisé en ce que ledit fichier multimédia comprend de la vidéo.
10. Dispositif de communication selon l'une quelconque des revendications précédentes caractérisé en ce que ledit fichier multimédia comprend des animations.
11. Dispositif de communication selon l'une quelconque des revendications précédentes caractérisé en ce que ledit fichier multimédia comprend un message vocal .
12. Dispositif de communication selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comporte des moyens de modulation et de démodulâtion .
13. Procédé de communication mettant en œuvre un dispositif de communication, relié d'une part à un réseau de communication et d'autre part à au moins un récepteur/décodeur, caractérisé en ce qu'il comprend une étape de sélection entre les différentes possibilités suivantes, en fonction de la bande passante disponible sur le réseau de communication, à réception d'une requête en provenance dudit récepteur/décodeur :
• transmettre audit réseau la requête sans modification ; ou
• modifier la requête pour demander un flux de qualité moindre ; ou
• refuser de transmettre la requête audit réseau et diffuser vers le récepteur/décodeur un fichier multimédia préconfiguré .
14. Procédé de communication selon la revendication 13 caractérisé en ce qu'il comporte en outre une étape d'exploitation d'un plan de service contenant toutes les adresses multicast et au moins une caractéristique des flux correspondants, par exemple le nom du programme, les codées utilisés ou la bande passante utilisée.
15. Procédé de communication selon la revendication 13 ou 14 caractérisé en ce qu'il comporte en outre une étape d'exploitation d'une table des flux en cours de réception sur chacun des récepteurs/décodeurs connectés audit dispositif de communication, ladite requête étant établie à partir de requêtes IGMP vues.
16. Procédé de communication selon les revendications 14 et 15 caractérisé en ce qu'il comporte en outre une étape de calcul de la bande passante du réseau de communication utilisée et une étape de calcul de la bande passante du réseau de communication requise par la réception d'un nouveau flux sur demande d'une nouvelle requête IGMP, à partir du plan de service et de la table des flux.
17. Procédé de communication selon l'une quelconque des revendications 13 à 16 caractérisé en ce que ledit dispositif de communication possède dans une table de configuration une URL (« uniforrn resource locator « ) et en ce qu'il comporte une étape de récupération ledit fichier multimédia préconfiguré depuis ladite URL et une étape de transmission dudit fichier multimédia au dit récepteur/décodeur en flux multicast et en boucle .
EP07823727A 2006-08-22 2007-08-17 Mecanisme pour la gestion de connexions de recepteurs / decodeurs Withdrawn EP2055042A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0653422 2006-08-22
FR0653822 2006-09-19
PCT/FR2007/051827 WO2008023130A2 (fr) 2006-08-22 2007-08-17 Mecanisme pour la gestion de connexions de recepteurs / decodeurs

Publications (1)

Publication Number Publication Date
EP2055042A2 true EP2055042A2 (fr) 2009-05-06

Family

ID=38995204

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07823727A Withdrawn EP2055042A2 (fr) 2006-08-22 2007-08-17 Mecanisme pour la gestion de connexions de recepteurs / decodeurs

Country Status (5)

Country Link
US (1) US20100002779A1 (fr)
EP (1) EP2055042A2 (fr)
JP (1) JP5122568B2 (fr)
KR (1) KR101375182B1 (fr)
WO (1) WO2008023130A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2323314A1 (fr) 2009-11-17 2011-05-18 Thomson Telecom Belgium Procédé d'accès de services et appareil correspondant
NO334029B1 (no) * 2011-09-30 2013-11-18 Cisco Tech Inc System og fremgangsmåte for etablering av videokonferansesesjon med justerbart filter for markering av tilstedeværelsesnivå i endepunkter
EP3968691A1 (fr) 2011-10-21 2022-03-16 FRAUNHOFER-GESELLSCHAFT zur Förderung der angewandten Forschung e.V. Concept de gestion des ressources

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6678740B1 (en) * 2000-01-14 2004-01-13 Terayon Communication Systems, Inc. Process carried out by a gateway in a home network to receive video-on-demand and other requested programs and services
US20020062258A1 (en) * 2000-05-18 2002-05-23 Bailey Steven C. Computer-implemented procurement of items using parametric searching
US20070053428A1 (en) * 2001-03-30 2007-03-08 Vixs Systems, Inc. Managed degradation of a video stream
JP3652670B2 (ja) * 2002-05-08 2005-05-25 株式会社エヌ・ティ・ティ・データ マルチキャスト映像配信システム及び同システムにおけるリクエスト受付処理プログラム
USRE44782E1 (en) * 2002-11-11 2014-02-25 Supracomm, Inc. Multicast videoconferencing
DE10257377A1 (de) * 2002-12-09 2004-07-08 Basf Coatings Ag Wässriger farb- und/oder effektgebender Beschichtungsstoff und seine Verwendung
JP2005236618A (ja) * 2004-02-19 2005-09-02 Nec Corp 通信帯域制御システム及びアクセスゲートウェイ並びにホームゲートウェイ
US7773581B2 (en) * 2004-03-19 2010-08-10 Ericsson Ab Method and apparatus for conferencing with bandwidth control
US7835276B2 (en) * 2004-12-30 2010-11-16 Cisco Technology, Inc. Admission control mechanism for multicast receivers
US8140666B2 (en) * 2007-03-29 2012-03-20 International Business Machines Corporation Method and apparatus for network distribution and provisioning of applications across multiple domains

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
KR101375182B1 (ko) 2014-03-17
JP2010502071A (ja) 2010-01-21
JP5122568B2 (ja) 2013-01-16
KR20090071540A (ko) 2009-07-01
US20100002779A1 (en) 2010-01-07
WO2008023130A2 (fr) 2008-02-28
WO2008023130A3 (fr) 2008-04-10

Similar Documents

Publication Publication Date Title
US11032344B2 (en) Content delivery
US9641578B2 (en) Minimizing unicast bandwidth in an adaptive bit rate system
EP1842337B1 (fr) Repartition multidiffusion d'un contenu multimedia a diffusion en flux
EP3053303B1 (fr) Procede d'abonnement a des flux en provenance de clients multicast
EP1908259B1 (fr) Appareil et procede d'estimation du taux de remplissage des tampons d'entree de clients d'une distribution de contenu temps reel
FR2880491A1 (fr) Methode de transmission d'un flux multipoint dans un reseau local et dispositif de connexion implementant la methode
EP2140651B1 (fr) Procede de gestion d'une pluralite de sessions audiovisuelles dans un reseau ip et systeme de commande associe
EP2332332A1 (fr) Procede et dispositif de redirection d'une requete de controle d'un flux de donnees
EP2050251B1 (fr) Procede de diffusion d'informations dans un reseau distribue
WO2008023130A2 (fr) Mecanisme pour la gestion de connexions de recepteurs / decodeurs
FR2933213A1 (fr) Methode d'affichage d'interface utilisateur et methode d'emission correspondante
EP1407595B1 (fr) Procede de diffusion d'un contenu vers des terminaux recepteurs et serveur de collecte
KR100502186B1 (ko) 고화질 인터넷 방송 서비스 시스템
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d'un flux de données selon un mode de transmission multipoint
WO2009095590A1 (fr) Procede de transmission de contenus vod
FR3054765B1 (fr) Procede pour la lecture sur un equipement d'un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
WO2011001102A1 (fr) Procede et systeme de distribution de contenus numeriques personnalises
EP2553900B1 (fr) Transmission de flux de données adaptable
Ahmed et al. IPTV Video Streaming in Content Distribution Network
Simpson Audio and Video over IP Networks and Internet Broadcasting

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: 20090206

AK Designated contracting states

Kind code of ref document: A2

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 MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090721

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

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

Owner name: THOMSON LICENSING

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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

Owner name: INTERDIGITAL CE PATENT HOLDINGS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/911 20130101ALI20201021BHEP

Ipc: H04L 12/18 20060101AFI20201021BHEP

Ipc: H04L 12/26 20060101ALN20201021BHEP

Ipc: H04L 12/927 20130101ALI20201021BHEP

Ipc: H04L 12/801 20130101ALI20201021BHEP

INTG Intention to grant announced

Effective date: 20201112

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: 20210323