LIBAULT, DAVID (43 rue Lacepede, Paris, Paris, F-75005, FR)
THOMSON GRASS VALLEY FRANCE S.A. (1 rue de l'Hautil, Zone des Boutries, Conflans Sainte Honorine, F-78700, FR)
LEPRINCE, PATRICK (10 allée des poiriers, Chantepie, F-35135, FR)
LIBAULT, DAVID (43 rue Lacepede, Paris, Paris, F-75005, FR)
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 . |
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.