FR2864869A1 - Methode de transmission de services numeriques sur un reseau et appareil mettant en oeuvre la methode - Google Patents

Abstract

Dans le cadre de la diffusion de services DVB sur un réseau IP, la tendance est de séparer les informations de signalisation décrivant le réseau et les services offerts des services eux-mêmes. La signalisation est mise à disposition des terminaux via des fichiers XML disponible sur des serveurs HTTP. A la différence de cette approche, l'invention consiste en une méthode de découverte, par un récepteur connecté à un réseau bidirectionnel, de services numériques sur le réseau bidirectionnel qui comporte une étape où le récepteur se connecte à un premier flux, une étape où le récepteur extrait dudit flux des informations sur la localisation sur le réseau d'une part, de flux véhiculant le contenu de ces services et d'autre part de flux séparés, véhiculant des informations de description de ces services, une étape où le récepteur se connecte à au moins une partie des flux véhiculant les informations de description des services de façon à obtenir des informations sur ces services et une étape où le récepteur utilise ces informations pour construire une liste éventuellement unitaire des services disponibles sur le réseau.

Description

Méthode de transmission de services numériques sur un réseau et

appareil mettant en oeuvre la méthode La présente invention concerne la transmission de services numériques et plus particulièrement selon la norme DVB, diffusion vidéo numérique ( Digital Video Broadcasting en anglais). DVB définit un service comme une séquence de programmes sous le contrôle d'un opérateur pouvant être diffusée dans le cadre d'une programmation , sur un réseau généralement de type broadcast (terrestre, câble ou satellite), mais aussi depuis récemment sur un réseau de type IP, c'est à dire supportant le protocole IP, protocole Internet ( Internet Protocol en anglais). On peut trouver la spécification du protocole IP dans les RFC, requête pour commentaire ( request for comments en anglais), maintenu par l'IETF, groupe de travail d'ingénierie Internet ( Internet Engineering Task Force en anglais) sous le numéro 791.

La découverte des services numériques offerts par un réseau est normalisée par DVB dans le cadre d'un réseau de transmission par satellite, par câble ou numérique terrestre. Cette norme est décrite dans le document Digital Video Broadcasting (DVB) ; Specification for Service Information (SI) in DVB Systems publié par I'ETSI, l'Institut européen de standardisation des télécommunications ( European Telecomunication Standard Institute en anglais) sous le numéro ETSI EN 300 468. Ce document décrit un ensemble de tables contenant des informations sur le réseau, sur les fréquences auxquelles sont transmis les flux de données contenant les services, sur les services proposés etc. On peut également se référer au document MPEG-2 système ISO IEC 13818-1 pour la définition du format du flux de transport. Un flux de transport contient donc des données audio, des données vidéo, des données annexes comme des sous-titres, du teletexte ou des applications interactives sous la forme de flux élémentaires, ainsi que des tables de signalisation minimum obligatoires permettant d'organiser ce contenu comme la table d'information sur le réseau (NIT pour Network Information Table ) qui permet de retrouver les autres flux de transport sur le réseau, la table d'association des programmes (PAT pour Program Association Table en anglais) et la table d'organisation des programmes (PMT pour Program Map Table en anglais) entre autres. Ces tables sont multiplexées dans le flux de transport, le récepteur étant configuré avec les données nécessaires pour se connecter à un premier flux lui permettant de recevoir ces tables et de construire, d'après leur contenu, une base de donnée contenant la liste des services offerts par le réseau et les données de connexion nécessaires à leur réception.

Le développement de réseaux de transfert de données numériques bidirectionnels, en particulier du réseau Internet, et surtout la généralisation des accès à haut débit, offrent maintenant la possibilité technique de diffuser des services numériques de type audiovisuels sur ce type de réseaux. D'autre part, des réseaux privés de type IP à haut débit se développent, que ce soit au sein des entreprises ou dans le cadre du domicile. Dans ce cadre DVB travaille à la standardisation de la diffusion de services DVB sur les réseaux de type IP. Un groupe de travail appelé DVB-IPI, infrastructure sur protocole Internet ( Internet Protocol Infrastructure en anglais) est en train de finaliser une spécification concernant le transport des services numériques DVB sur un réseau de type IP, et plus particulièrement la découverte de ces services. La proposition telle qu'envisagée aujourd'hui est présentée dans le document DVB-IP Phase 1 Handbook sous la référence IP12003-227. La solution, telle qu'envisagée actuellement par le groupe de travail, s'oriente vers une séparation entre la diffusion des services sous la forme de flux de transport contenant un seul service DVB d'une part et les informations décrivant ces services, disponibles sous la forme de fichiers XML (eXtensible Markup Language) accessibles pour les terminaux sur requête par exemple. Le protocole HTTP (Hyper Text Transport Protocol) pouvant, par exemple, être utilisé pour retrouver ces fichiers. Cette solution semble naturelle car elle tire profit du caractère bidirectionnel de la connexion IP contrairement à la transmission par satellite par exemple. En effet les normes telles que DVB ont été conçues dans l'optique d'un réseau de transmission unidirectionnel imposant la transmission permanente de toutes les informations susceptibles d'être utiles à un récepteur. Le caractère bidirectionnel des réseaux envisagés permet de distinguer les informations utiles au décodage du service audiovisuels et les informations de description des services. Ces deux types d'informations traditionnellement présentes dans un flux DVB ne sont pas utilisées de manière synchronisée par le récepteur. Leur transmission sur le réseau va donc pouvoir être séparée, ce qui permet d'économiser la bande passante en ne transmettant les informations de signalisation qu'à la demande et non en permanence dans le canal audio et vidéo. De plus, la mise à disposition d'informations sur un réseau de type IP via des serveurs HTTP sous la forme de fichiers de données en XML est la solution dominante largement adoptée sur ce type de réseau.

Mais cette solution impose le développement d'un ensemble d'outils permettant de générer et de gérer les serveurs offrant ces informations de signalisation au format XML. Or à l'heure actuelle, les diffuseurs de contenu disposent d'une infrastructure maîtrisée pour la diffusion de services MPEG- 2 DVB via le satellite ou le câble. L'adoption de ce nouveau schéma de signalisation imposant le développement, en parallèle du système existant, de nouveaux outils implique un investissement et une prise de risque pour les opérateurs. De plus, les terminaux n'intègrent pas aujourd'hui les outils nécessaires à l'analyse de ces informations, comme par exemple, un analyseur XML. L'intégration de tels outils dans un récepteur à faible coût peut s'avérer délicate voire impossible en fonction des ressources matérielles disponibles comme la puissance du processeur ou la mémoire.

L'invention permet d'offrir une méthode de transmission de services numérique sur un réseau de transmission de données bidirectionnel et plus particulièrement la découverte des services offerts sur le réseau par un récepteur. Cette méthode, utilisée dans le cadre de DVB, permet la réutilisation en grande partie de la chaîne de production actuellement déployée de services DVB pour le satellite ou le câble. Cette méthode doit également permettre de limiter la bande passante utilisée pour la diffusion des informations permettant la découverte des services.

L'invention concerne une méthode de découverte, par un récepteur connecté à un réseau bidirectionnel, de services numériques sur le réseau bidirectionnel qui comporte une étape où le récepteur se connecte à un premier flux, une étape où le récepteur extrait dudit flux des informations sur la localisation sur le réseau d'une part de flux véhiculant le contenu de ces services et d'autre part de flux séparés, véhiculant des informations de description de ces services, une étape où le récepteur se connecte à au moins une partie des flux véhiculant les informations de description des services de façon à obtenir des informations sur ces services et une étape où le récepteur utilise ces informations pour construire une liste éventuellement unitaire des services disponibles sur le réseau.

Selon un mode particulier de l'invention toutes les tables de signalisations relatives à un service sont contenues dans au moins un flux différent du flux véhiculant le contenu dudit service.

Selon un mode particulier de l'invention la méthode comporte une étape de test de correspondance entre un identificateur et un filtre contenu dans le descripteur d'un flux permettant de déterminer si une table possédant cet identificateur est disponible dans ledit flux.

Selon un mode particulier de l'invention la première adresse IP de diffusion et le premier numéro de port sont entrés par l'utilisateur.

Selon un mode particulier de l'invention la première adresse IP et le premier numéro de port sont obtenus du réseau par le récepteur.

Selon un mode particulier de l'invention les flux ne contiennent qu'un seul service DVB.

Selon un mode particulier de l'invention la liste des services est incluse dans la NIT contenue dans le flux disponible à la première adresse IP de diffusion sur le premier port.

L'invention concerne également un appareil possédant des moyens de se connecter à une adresse IP de diffusion via des moyens de connexion à un réseau IP et des moyens de décodage de flux DVB diffusé à cette adresse IP de diffusion, caractérisé en ce que les moyens de décodage de flux DVB ont la capacité d'analyser une NIT, extraite du flux, contenant des descripteurs de réseau adaptés au réseau IP et de se connecter à chaque adresse IP de diffusion décrite dans ladite NIT pour y lire un flux DVB et en extraire les informations sur les services offerts sur le réseau préférentiellement selon l'une quelconque des méthodes selon les revendications précédentes.

L'invention concerne également un descripteur d'un service de diffusion d'un flux DVB destiné à être inclus dans une NIT caractérisé en ce qu'il contient l'adresse IP de diffusion d'un serveur de flux et un numéro de port sur lequel ledit serveur diffuse un flux DVB véhiculant le contenu d'un service sur un réseau de type IP et au moins un descripteur contenant l'adresse IP de diffusion d'un serveur de flux et un numéro de port sur lequel ledit serveur diffuse un flux DVB véhiculant des informations de signalisation relatives audit service.

Selon un mode particulier de l'invention les au moins un descripteur contenant l'adresse IP de diffusion d'un serveur de flux et un numéro de port sur lequel ledit serveur diffuse un flux DVB véhiculant des informations de signalisation relatives audit service contiennent également le moyen de tester la correspondance d'un identificateur avec un filtre.

L'invention sera mieux comprise, et d'autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels: La figure 1 représente un schéma de la chaîne de production de services DVB dans le cadre d'une diffusion satellite classique.

La figure 2 représente un exemple d'architecture de flux de données DVB dans le cadre d'un exemple de réalisation de l'invention.

La figure 3 représente un exemple d'architecture de flux de données DVB dans le cadre d'un autre exemple de réalisation de l'invention.

La figure 4 représente le fonctionnement d'un récepteur dans le cadre d'un exemple de réalisation de l'invention.

La figure 5 représente un schéma de la chaîne de production de services DVB dans le cadre d'un exemple de réalisation de l'invention.

La figure 6 représente la structure d'une NIT (Network Information Table) selon la norme DVB.

La figure 7 représente la structure d'un décodeur numérique standard, par exemple dans le cas d'une réception terrestre.

La figure 8 représente la structure d'un décodeur numérique adapté à la réception sur IP.

La figure 9 représente un organigramme de la phase de découverte des services.

La figure 10 représente un organigramme de la phase de lecture des informations sur les services.

L'exemple de réalisation de l'invention concerne la transmission de services DVB sur un réseau IP mais peut s'appliquer à tout autre système de transmission de services numérique sur un réseau de transmission de données bidirectionnel.

La connexion à un serveur sur un réseau de type IP peut se faire selon un protocole de diffusion multipoint ( IP multicast en anglais). Un exemple d'un tel protocole est le protocole IGMP (Internet Gateway Management Protocol) défini dans la RFC 2236. Dans ce protocole, à un serveur de diffusion multipoint est associé une adresse de diffusion multipoint. Cette adresse a le format d'une adresse IP, dans un domaine réservé à cet usage, mais ne correspond pas à l'adresse IP d'une machine accessible sur le réseau. Un récepteur désirant se connecter à ce serveur va envoyer une requête sur le réseau contenant cette adresse IP de diffusion multipoint. Cette requête va être relayée dans tout le réseau jusqu'à atteindre le serveur en charge de cette diffusion qui va donc inscrire le récepteur comme client de la diffusion. Les routeurs sur le chemin entre le serveur et le récepteur vont ensuite être en mesure de relayer les paquets IP constituant le flux vers les terminaux abonnés à la diffusion. Une optimisation de ce protocole permet, par la connaissance de l'adresse IP de la machine serveur en sus de l'adresse IP de diffusion multipoint, d'optimiser la route de la requête d'abonnement en l'acheminant directement vers le serveur destinataire au lieu de la diffuser dans tout le réseau. Cette optimisation est connue sous le nom de SSM (Source Specific Multicast). C'est donc un système par abonnement à une diffusion de données numériques. Un serveur diffuse des données numériques, sous forme de paquets, sur le réseau. Tant qu'aucun récepteur ne s'abonne à cette diffusion, aucun paquet n'est réellement transmis. Quand un récepteur s'abonne, les paquets lui sont transmis par un acheminement à travers le réseau suivant une route entre le serveur et le client. Le protocole assure que les paquets ne vont emprunter que les routes du réseau menant à des récepteurs effectivement abonnés à la diffusion. Lorsqu'un récepteur se désabonne, la transmission effective des paquets vers ce récepteur cesse.

Le protocole assure également que les paquets ne sont pas dupliqués sur une portion de route du réseau menant à plusieurs récepteurs abonnés à la diffusion.

La transmission des données constituant le service peut également se faire selon un protocole de diffusion unipoint ( IP unicast en anglais) . Un exemple d'un tel protocole est le protocole de transfert de flux en temps réel RTSP ( Real Time Streaming Protocol en anglais) défini dans la RFC 2326. Ce protocole servant à contrôler la diffusion du flux sur IP, il est prévu pour fonctionner conjointement avec un protocole de diffusion proprement dit comme RTP. La principale différence avec la diffusion multipoint étant qu'à chaque client désirant se connecter sur le flux, le serveur va initier une diffusion point à point entre lui-même et le client. II est évident que cette solution est plus dispendieuse en bande passante que la solution basée sur la diffusion multipoint. En effet, dans cette solution les paquets de données transitant sur une portion de route du réseau menant à plusieurs récepteurs abonnés sont dupliqués autant de fois qu'il y a de récepteurs abonnés. Cette solution est envisageable dans le cadre d'un réseau restreint où seul un petit nombre de terminaux sont susceptibles de se connecter à un flux.

De façon à limiter la bande passante utilisée à la diffusion des services DVB sur un réseau IP tout en limitant les modifications à apporter à la chaîne de production de services utilisée chez les opérateurs qui offrent déjà des services de ce type sur d'autres supports de transmission comme le satellite ou le câble, nous allons adopter une organisation des données constituant les services comme suit. D'une part un flux, dit d'installation, va contenir une table d'information sur le réseau fortement dérivée de la NIT de DVB et seulement cette table que nous appelons NIT modifiée dans le sens où elle reprend la syntaxe de la NIT DVB mais contient des descripteurs spécifiques, adaptés à la diffusion de services DVB sur IP. D'autre part les services vont être séparés en un flux de contenu qui va rassembler les flux élémentaires du service, audio, vidéo, sous-titres, etc, ainsi que la signalisation minimum permettant d'organiser ces flux élémentaires comme la PAT et la PMT et en flux de description ne contenant que des informations de description sur les services. Seuls les flux de contenu vont conserver le format de flux de transport tel qu'il est définit par MPEG-2. Les flux d'installation et de description sont directement constitués des tables telles que la NIT pour le flux d'installation et les SDT ou autres pour les flux de description. Ces tables suivent la syntaxe des sections MPEG-2. En effet, l'accès aux informations de description des services est un besoin ponctuel non corrélé au besoin de décoder le contenu audio et vidéo. Les bandes passantes actuelles sur IP et le besoin de limiter la bande passante sur le réseau rendent probable la création d'un flux par service mais le multiplexage de plusieurs services sur un flux est possible dans le cadre de l'invention.

Pour adapter la NIT à une utilisation sur un réseau IP, il est nécessaire de définir des descripteurs adaptés à la localisation de flux sur un réseau IP. Un tel descripteur adapté à la diffusion multipoint est donné ci- dessous: Syntaxe No de bits identifieur Ip stream descriptor () { Descriptor_tag 8 uimsbf Descriptor_length 8 uimsbf Content multicast address 32 bslbf Content multicast port number 16 bslbf Content multicast protocol mapping 8 bslbf Content source address 32 bslbf For (i=0; i < N; i++) { Descriptor() Le champ Descriptor tag est un identifiant correspondant à ce 30 nouveau type de descripteur.

Le champ Descriptor_length donne la taille du descripteur.

Le champ Content multicast address est l'adresse IP de diffusion multipoint du serveur sur lequel est disponible le flux de contenu.

Le champ Content multicast_port_number est le numéro de port sur le serveur où l'on doit se connecter pour recevoir le flux de contenu.

Le champ Content multicast protocol_mapping est un champ identifiant le protocole de codage du, ou des, service diffusé à cette adresse. Ce protocole peut être MPEG-2, MPEG-4, MHP ou autres. Ce champ, optionnel, peut permettre de filtrer sur le type de contenu pour ne retenir que les services que le récepteur est à même de décoder.

Le champ Content source_address est l'adresse IP réelle du serveur ce qui permet un routage efficace de la requête de connexion à un serveur de diffusion multipoint selon le protocole SSM.

La boucle sur les descripteurs permet de gérer les descripteurs de 10 localisation du, ou des, flux de description relatifs au service dont le contenu est diffusé à l'adresse précédemment définie.

Nous donnons ci-dessous la définition d'un autre exemple d'un tel descripteur adapté à la diffusion unipoint: Ip_stream_descriptor () { Descriptor tag 8 uimsbf Descriptor length 8 uimsbf Content_unicast_address 32 bslbf Content _ unicast_ port_number 16 bslbf Content_ unicast_protocol_mapping 8 bslbf } 25} Le champ descriptor_tag est un identifiant correspondant à ce nouveau type de descripteur.

Le champ descriptor length donne la taille du descripteur.

Le champ Content_unicast_address est l'adresse IP de diffusion unipoint du serveur sur lequel est disponible le flux véhiculant le contenu.

Le champ Content unicast port_number est le numéro de port sur le serveur où l'on doit se connecter pour recevoir le flux véhiculant le contenu.

For (i=0; i < N; i++) { Descriptor() Le champ Content unicast protocol_mapping est un champ identifiant le protocole de codage du, ou des, service diffusé à cette adresse. Ce protocole peut être MPEG-2, MPEG4, MHP ou autres. Ce champ, optionnel, peut permettre de filtrer sur le type de contenu pour ne retenir que les services que le récepteur est à même de décoder.

La boucle sur les descripteurs permet de gérer les descripteurs de localisation du, ou des, flux de description relatifs au service dont le contenu est diffusé à l'adresse précédemment définie.

Nous voyons dans la structure de la NIT de DVB, et donc de la NIT modifiée qu'il existe une boucle sur les flux de transport, ce qui veut dire que tous les flux de transport constituant le réseau complet d'un opérateur peuvent être décrits dans cette boucle. De cette façon, le récepteur peut construire une liste avec les adresses IP de diffusion multipoint ou unipoint de tous les flux de transport d'un réseau de diffusion de télévision large bande sur IP. Une liste de descripteurs de services peut être optionnellement incluse dans la NIT modifiée de façon à accélérer la phase d'installation du récepteur.

On peut également envisager que des serveurs de flux multipoint et unipoint soient présents dans le même réseau.

Dans une autre implémentation plus sophistiquée, les descripteurs de localisation des flux de description des informations relatives au service 25 diffusé peuvent par exemple prendre la forme suivante: Ip_stream_multicast_locator_descriptor () { Descriptor tag 8 uimsbf Descriptor_length 8 uimsbf Filter length 8 uimsbf Filter descriptor() multicast address 32 bslbf multicast port number 16 bslbf multicast_protocol_mapping 8 bslbf source address 32 bslbf} Nous retrouvons ici les champs classiques d'un descripteur permettant la localisation d'un flux diffusé sur IP en multipoint. Seuls les champs Filter length et Filter descriptor méritent une explication. En fait, dans le cadre de l'exemple de réalisation de l'invention, les informations de description du service sont séparées des informations de contenu, elles sont véhiculées dans un seul flux différent. Mais il est également possible de véhiculer ces informations de signalisation, ces tables, dans une pluralité de flux différents. C'est précisément pour prendre cette possibilité en compte que le descripteur Ip_stream_descriptor contient une boucle. Mais quand on parcourt ce descripteur, on ne sait pas à priori quel flux dans la boucle de descripteurs va contenir une table donnée que l'on recherche pour le service concerné par le descripteur. Le fait d'introduire les champs Filter length et Filter descriptor dans le descripteur permettent d'implémenter un moyen de stocker dans le descripteur des informations permettant de savoir quelles sont les tables contenues dans chaque flux de la boucle. Une façon de coder cette information peut, par exemple, être de mettre dans ce champ Filter descriptor les chaînes de bits qui permettent par exemple de programmer un démultiplexeur pour filtrer lesdites tables. Chaque type de table possédant un identificateur donné, on peut mettre dans le filtre la chaîne binaire représentant l'identificateur de la table contenue dans le flux. Dans le cas où l'on veut pouvoir avoir plusieurs tables dans le flux, on peut adopter la méthode utilisée pour programmer le filtre du démux. Une première chaîne binaire indique un identificateur que l'on veut filtrer et une deuxième chaîne de la même longueur indique pour chaque bit de la première si cette valeur est définie ou non. Un identificateur donné va donc correspondre au filtre si pour chaque bit de cet identificateur pour lequel le bit correspondant de la deuxième chaîne binaire est à un, le bit correspondant de la première chaîne a la même valeur. Par exemple, si on prend des chaînes sur trois bit, une première chaîne binaire d'une valeur de Ob101, une deuxième chaîne d'une valeur de Ob110, les identificateurs correspondant à ce filtre auront les valeurs Ob101 et Ob100. Cette méthode permet de définir les tables contenues dans le flux de la même façon que l'on programmerait un démultiplexeur pour les retrouver.

Dans une autre implémentation plus simple, les descripteurs de localisation des flux de description des informations relatives au service diffusé peuvent par exemple prendre la forme suivante: Descriptor tag 8 uimsbf Descriptor length 8 uimsbf NbOfTableIDs 8 uimsbf TablelDList() 32 bslbf multicast_address multicast port number 16 bslbf multicast protocol mapping 8 bslbf source_address 32 bslbf Nous retrouvons ici les champs classiques d'un descripteur permettant la localisation d'un flux diffusé sur IP en multipoint. Seuls les champs NbOfTablelDs et TablelDList méritent une explication.

Le champ tablelDList correspond à une liste des identificateurs de tables qui sont inclus dans le flux correspondant, et le champ NbOfTablelDs représente le nombre d'identificateurs de tables listées.

Ainsi, un flux contenant a la fois des informations concernant les informations de signalisation sur les événements actuels et suivant du flux courant dont l'identificateur de table est Ox4E et les informations de signalisation sur les événements actuels et suivant des autres flux dont l'identificateur de table est Ox4F, aura un descripteur avec la valeur 2 pour le champ nbOfTablelds et les valeurs Ox4E et Ox4F dans le champ tablelDList .

Une autre possibilité d'implémentation de la diffusion des flux contenant les informations de signalisation peut être de choisir un simple 35 protocole de transfert de fichiers entre le serveur et le récepteur au lieu de la Ip_stream_multicast_locator_descriptor_table_ids () { 15 diffusion multipoint. Un tel protocole peut, par exemple, être le protocole HTTP ( HyperText Transfert Protocol ). Ce protocole est simple à implémenter, surtout si l'on se limite à implémenter la capacité de faire un GET permettant d'obtenir un fichier sur un serveur. Ce protocole est bien moins lourd à gérer que le traitement des fichiers XML évoqué dans l'introduction. Dans ce cas, il est nécessaire d'avoir un autre descripteur comme par exemple le descripteur suivant qui permet d'associer à une table d'identificateur donné, l'URL ( Universal Resource Locator ) du fichier la contenant: Ip stream HTTP locator descriptor () { Descriptor tag 8 uimsbf Descriptor length 8 uimsbf

Table id 8 bslbf

For (i=0; i<N; i++) { 8 bslbf Char } } Mais, cette façon de faire n'est pas le mode préféré de réalisation de l'invention, car la diffusion par HTTP, comme d'ailleurs la diffusion unipoint des ces tables de signalisation implique une duplication du flux de données sur le réseau pour chaque récepteur voulant s'installer. Mais c'est tout de même un mode de réalisation envisageable sur des réseaux ne contenant pas un grand nombre de récepteurs, comme des réseaux domestiques.

La figure 1 décrit l'architecture générale d'une chaîne de production de services MPEG-2 DVB dans le cadre d'une diffusion satellite. Au départ de la chaîne, nous avons du contenu audio et vidéo 1.1 qu'il s'agit de diffuser. Ce contenu est encodé selon la norme MPEG2 dans un codeur 1.2 pour générer un flux élémentaire audio/vidéo 1.5. Parallèlement au codage de l'audio et de la vidéo, les informations de signalisation 1.3 sont générées, elles proviennent généralement d'une base de données contenant les informations descriptives sur le service que l'on veut diffuser. Ces informations sont générées sous la forme d'un flux de signalisation 1.6. Un autre module 1.4 prend en charge la génération d'un flux de soustitres 1.7. II est également possible d'inclure un flux d'applications interactives 1.8, dont la chaîne de production n'est pas détaillée ici. Tous ces flux élémentaires, avec éventuellement d'autres flux véhiculant d'autres contenus audio et vidéo, la signalisation s'y rapportant ou autre, sont ensuite multiplexés dans un multiplexeur 1.9 pour générer le flux de transport MPEG-2 qui va être ensuite modulé et converti sur une fréquence choisie par le modulateur convertisseur 1.10. Un ensemble de flux de ce type peuvent être mélangés par un mélangeur 1.11 pour un envoi sur un satellite 1.13 via une station d'émission 1.12. Dans ce cas une synchronisation des informations de signalisation est nécessaire entre lesdifférents flux de façon à inclure des informations sur les autres flux dans les tables descriptives de chaque flux. Ces programmes peuvent ensuite être reçus au domicile de l'utilisateur via sa parabole 1.14 pour être décodés par un décodeur et affichés sur un téléviseur. Cette chaîne est maintenant bien maîtrisée par les opérateurs.

La figure 2 représente un exemple d'architecture de flux suivant un exemple de réalisation de l'invention. Dans cet exemple, un premier flux 2.1, appelé flux d'installation est montré. Ce flux d'installation ne contient pas de contenu audio ou vidéo, mais seulement la NIT modifiée 2. 4 contenant les informations sur le réseau. Ce flux d'installation peut directement utiliser la syntaxe d'une section MPEG-2 et peut ne pas posséder l'encapsulation sous la forme d'un flux de transport du fait que les données sont directement transmises sur le réseau IP.

Cette NIT modifiée décrit plusieurs flux contant des services. La structure standard d'une NIT telle que définie par DVB est donnée figure 6. Bien qu'un flux, quel que soit le moyen de transmission, puisse contenir plusieurs services DVB, il est probable que seuls des flux ne contenant qu'un service DVB soient utilisés dans un premier temps dans le cadre de la diffusion sur IP et ceci pour des raisons de bande passante. L'exemple décrit sur la figure 2 se place donc dans ce cas. Mais il est évident que l'invention ne se limite pas à l'utilisation de flux ne contenant qu'un service DVB dans le flux. Nous avons donc dans la NIT modifiée 2.4 la description de trois services 2.5, 2.6 et 2.7. La description d'un service va contenir des descripteurs 2.8 et 2.9 permettant de localiser le flux de contenu 2.2 ainsi que le flux contenant la description relative au service 2.3. Le flux de contenu 2.2 va contenir une PAT ( Program Association Table ) pointant sur les contenus relatifs à un service 2.11 constitué d'une PMT ( Program Map Table ). Le flux de description 2.3 est donc un flux séparé du précédent. Ce flux ne possède pas le format des flux de transport MPEG-2 mais directement des tables ayant la syntaxe d'une section MPEG-2. Cette séparation permet à un client de ne se connecter sur ce flux que lorsqu'il doit accéder aux informations de description et évite donc d'utiliser de la bande passante pour une diffusion permanente de ces informations. Ainsi l'utilisation de cette bande passante est améliorée. Rappelons que dans la diffusion sur IP, lorsqu'un récepteur se désabonne d'une diffusion, la transmission effective des paquets sur le réseau à destination de ce récepteur cesse. Dans l'exemple, le flux de description contient les informations sur les événements 2.14, comme l'information sur l'événement courant, le suivant, ainsi que éventuellement le calendrier complet des événements permettant la construction d'un guide électronique de programme. Il contient également, les informations sur le service 2.13, comme la SDT ( Service Description Table ).

La figure 3 est un autre exemple d'architecture de flux suivant un exemple de réalisation de l'invention. Cet exemple ressemble beaucoup au précédent tel que représenté sur la figure 2. La différence vient du fait que, ici, les informations de description relatives aux événements et celles relatives au service sont portées par deux flux différents. Nous avons donc ici pour le service 1 3.5, trois descripteurs de flux 3.8, 3.9 et 3.10 au lieu des deux précédents pointant sur le flux des contenus 3.2, celui des informations sur le service 3.3 et celui sur les événements 3. 15. Il est donc possible de répartir les différentes tables constituant les informations de signalisation sur différents flux en fonction des tables disponibles et de l'utilisation qui en sera faite de façon à gérer la bande passante du réseau. On peut aussi prendre en compte les contraintes de gestion du service en regroupant les tables ayant la même fréquence de mise à jour.

La figure 4 représente un schéma d'acteurs décrivant la phase de découverte des services présents sur le réseau. Les entités représentent d'une part l'utilisateur du système qui est devant son récepteur, le récepteur ainsi que les flux d'installation, de contenu d'un service et de description de ce même service. D'autres flux relatifs à d'autres services peuvent être présents dans le réseau mais ne sont pas représentés sur la figure. Dans un premier temps l'utilisateur met son récepteur sous tension. Le récepteur se connecte alors au flux d'installation. Le récepteur possède des paramètres lui permettant une première connexion à une adresse IP de diffusion multipoint ou unipoint. La solution la plus simple est de considérer que cette adresse IP de diffusion est entrée manuellement dans un menu de configuration. Cette adresse IP de diffusion peut également être attribuée au récepteur lors de la phase de connexion via des protocoles comme DHCP (Dynamic Host Control Protocol) ou PPP (Point to Point Protocol). Mais toute autre méthode de détermination de cette première adresse IP est possible. Cette adresse consiste en une adresse IP de diffusion multipoint ou unipoint et un numéro de port correspondant. Le flux d'installation est diffusé à cette adresse.

Une fois que le récepteur est connecté au flux d'installation, il est donc en mesure de décoder la NIT modifiée et de lire les informations qu'elle contient. Le récepteur est donc à même de créer une liste des services disponibles sur le réseau. Le parcours de cette liste lui donne accès aux adresses de diffusion des flux de contenu et des flux de description diffusés sur le réseau. Le récepteur est donc en mesure de se connecter successivement à ces flux de façon à collecter les informations sur les services, dont le nom de chaque service. II est donc possible ensuite, pour le récepteur, de présenter à l'utilisateur la liste des services. L'utilisateur choisit ensuite le service qu'il désire regarder, le récepteur utilise le descripteur du flux de contenu trouvé dans la NIT modifiée pour le service choisi et se connecte au flux de contenu du service choisi. Le décodage et l'affichage du service choisi peut alors commencer. Si ensuite, l'utilisateur désire accéder aux informations sur l'événement courant et sur l'événement suivant, il envoie une requête dans ce sens, le récepteur va utiliser, encore une fois le descripteur contenu dans la NIT modifiée pour y trouver la localisation sur le réseau du flux de description contenant les informations sur les événements.

Ces informations peuvent être contenues dans le même flux que les informations de description du service ou dans un flux séparé comme décrit sur les figures 2 et 3. Le récepteur se connecte alors à ce flux et récupère les informations sur les événements de façon à être en mesure de les afficher à l'utilisateur.

La connexion du récepteur à un flux peut se faire par exemple via le protocole IGMP. Généralement ce flux de transport est du type MPEG-2 encapsulé sur IP en utilisant les couches de protocole IP/UDP/RTP (User Datagram Protocol, Real Time Protocol), mais ce peut être également un flux de type MPEG-4, MHP ou autre.

La figure 5 représente la chaîne de production des flux selon l'invention. D'une part le contenu audio et vidéo brut 5.1 est encodé par l'encodeur 5.4 pour donner les flux élémentaires audio et vidéo 5.7. Une base de données 5.2 contient toute la description des services ainsi que les informations sur les événements. Un module 5.5 permet de construire les tables de signalisation 5.8 avec ces informations. Les informations de signalisation 5.8, les flux de contenu audio et vidéo 5.7, ainsi que d'autres informations optionnelles telles que des applications interactives ou autre 5.6 sont multiplexées 5.9 pour construire un flux de contenu 5.10. Un premier module de formatage 5.11 utilise les tables de signalisation construites 5.8, éventuellement des informations contenues dans la base 5.2 et des informations additionnelles sur d'autres services 5.3 pour construire le flux de description 5.12. Un second module de formatage 5.13 utilise les informations additionnelles sur les services du réseau 5.3 pour construire le flux d'installation 5. 14 qui va contenir la description de tous les flux disponibles sur le réseau avec les adresses permettant d'y accéder. Les principaux modules qui n'existent pas dans la chaîne de production classique de services DVB sont ces modules de formatages 5.11 et 5.13. Mais ces modules sont simples à construire car ils se contentent de construire des flux contenant des tables de signalisation telles que celles qui sont déjà construites par le module de signalisation 5.5. L'originalité venant de l'utilisation des descripteurs adaptés à la localisation d'un flux sur un réseau IP, que ce flux soit diffusé en multipoint, unipoint ou encore disponible via un protocole de transfert de fichier tel que HTTP. Ces flux, 5.10, 5.12 et 5.14, une fois construits peuvent donc être diffusés sur les serveurs du réseau IP.

La figure 7 décrit l'architecture d'un décodeur traditionnel, comme par exemple un décodeur numérique terrestre. Le décodeur 7.1 dispose d'un écran 7.3. L'utilisateur 7.2 interagit grâce à une application de navigation 7.4 qui s'affiche sur l'écran 7.3. L'ensemble des fonctions du décodeur est piloté par une application de gestion traditionnellement appelé middleware 7.5. Cette application de gestion pilote les modules matériels qui sont le tuner 7.8, le demux 7.7 et le décodeur 7.6. Le tuner est responsable de la récupération du flux DVB reçu par l'antenne 7.9. Ce flux est démultiplexé par le demux, c'est à dire que le demux est capable de reconstituer les différents flux élémentaires constituants le flux de transport DVB, tel que l'audio, la vidéo et les données auxiliaires (comme les sous-titres, le télétexte ou une application interactive) ou telle ou telle table de signalisation. Dans le flux DVB, chaque flux élémentaire est identifié par un identificateur et l'on peut programmer le demux pour filtrer les flux élémentaires qui nous intéressent dans le flux complet qui est reçu. Au moins les flux audio et vidéo sont encodés de façon à compresser et/ou crypter les informations qu'ils contiennent, le décodeur est donc là pour décompresser et/ou décrypter ces flux de manière à restituer le contenu audio et vidéo à l'utilisateur.

La figure 8 quant à elle décrit un décodeur IP, adapté à la réception des flux DVB sur un réseau IP. On retrouve exactement la même architecture que dans le cas du décodeur traditionnel à la différence que le tuner est remplacé par une interface réseau 8.10 branchée sur un réseau IP 8.11.

La figure 9 détaille les étapes de la découverte des services sur le réseau. La première étape consiste à obtenir le flux d'installation 9.1. Ce flux est disponible sur le réseau. Il existe de multiples façons de mettre ce flux à disposition, on peut en citer au moins trois, ce flux peut être diffusé en multipoint, il peut également être diffusé en unipoint ou être disponible via un protocole de transfert de fichier tel que, par exemple HTTP. Quel que soit la manière de diffuser ce flux d'installation sur le réseau, le décodeur doit être en mesure de le retrouver, il doit donc en connaître l'adresse ainsi que les paramètres de connexion permettant de se connecter à ce flux. Cette première adresse peut soit être présente dans la mémoire morte de l'appareil soit lui être communiquée par l'utilisateur ou encore être communiquée à l'appareil par un serveur lors de sa connexion au réseau via un protocole de connexion permettant l'acquisition de paramètres tel que DHCP ( Dynamic Host Configuration Protocol ) ou PPP ( Point to Point Protocol ). Le récepteur se connecte au flux d'installation 9.2, puis il y cherche une NIT modifiée 9.3. Lorsque cette NIT modifiée est trouvée, il y lit la description d'un premier flux de transport caractérisé par son identificateur de flux de transport ( TSID ) et son identificateur de réseau d'origine ( ONID ) 9.4. Ensuite, un flux de transport pouvant contenir plusieurs services, on commence à lire la description des services contenus dans le flux de transport. Pour chaque service on commence par lire l'identificateur du service et les données permettant de localiser le flux de contenu 9.5. Pour chaque service, des informations sur ce service peuvent être contenues dans une pluralité de flux de description de service. La localisation de cette pluralité de flux de description est précisée dans une suite de descripteurs que l'on lit maintenant 9.6 et 9.7. Ensuite on stocke pour chaque service, l'identificateur de flux de transport, l'identificateur de réseau d'origine, l'identificateur de service, le descripteur de localisation du flux véhiculant le contenu du service (CSL pour Content Stream Locator ) ainsi que le tableau des descripteurs de localisation des flux de description du service (SDSL pour Service Description Stream locator ) 9.8. On réitère ces opérations pour chaque service contenu dans le flux de transport ainsi que pour chaque flux de transport 9.9 et 9.10. De cette manière on obtient la liste de tous les services disponibles sur le réseau et les descripteurs des flux les diffusant tant pour le contenu que pour les informations de description de ces contenus.

La figure 10 détaille un exemple de la façon dont on peut récupérer les informations sur les services une fois que l'on a construit la liste des services par le parcours de la NIT modifiée comme expliqué sur la figure 9. Pour récupérer les informations sur les différents services offerts sur le réseau, le récepteur doit trouver les tables de description de service (SDT pour Service Description Table ) pour chaque service. Pour ce faire, il commence par lire le descripteur du premier service 10. 1. Puis il lit le premier descripteur de localisation des flux de description du service (SDSL). Là, si ce SDSL ne contient pas les champs Filter length et Filter descriptor permettant de savoir si le flux désigné contient la SDT, il doit se connecter au flux 10.9, en lire les sections à la recherche d'une SDT dont l'identificateur de table est 0x42, 10.10, 10.11 et 10.12. Dans le cas où les champs Filter length et Filter descriptor existent, il va utiliser ces informations pour vérifier la présence de la SDT dans le flux 10.3. Si elle n'est pas présente, il teste le descripteur suivant 10.13, 10.14 et finit par supprimer de la liste un service dont il ne pourrait pas trouver la SDT 10.15. Quand il a trouvé le flux contenant la SDT, il lit cette table 10. 5, y trouve le nom du service et du fournisseur de service qu'il stocke en mémoire 10.6.

Cette opération est faite pour tous les services 10.7, 10.8 et ceci jusqu'à la fin de la liste des services 10.16.

L'invention permet aux opérateurs de réutiliser la majeure partie de leur chaîne existante de production, en particulier les multiplexeurs. Le seul développement nécessaire est celui de modules de formatage permettant de construire des flux ne contenant que les tables de signalisation, toutes ou parties et d'éventuellement ne pas les encapsuler dans un flux de transport. Ce développement est minime. L'invention permet aussi de limiter les modifications à apporter aux logiciels exécutés sur les décodeurs. En effet, principalement la partie gérant l'interface IP, en lieu et place de l'interface de réception satellite ou câble, est a ajouter, tandis que doit être légèrement modifiée la partie de l'application gérant l'installation. Tout le reste du fonctionnement de l'appareil est le même que pour un décodeur standard.

De même le contrôle d'accès peut être repris à l'identique. L'invention permet donc l'adoption de la diffusion de services DVB sur un réseau IP large bande en minimisant les investissements et les risques pour les opérateurs ainsi que l'utilisation de la bande passante disponible sur le réseau.

Claims (10)

REVENDICATIONS

1. Méthode de découverte, par un récepteur connecté à un réseau bidirectionnel, de services numériques sur le réseau bidirectionnel, caractérisée en ce qu'elle comporte au moins les étapes suivantes: - le récepteur se connecte à un premier flux; - le récepteur extrait dudit flux des informations sur la localisation sur le réseau d'une part de flux véhiculant le contenu de ces services et d'autre part de flux séparés, véhiculant des

informations de description de ces services;

- le récepteur se connecte à au moins une partie des flux véhiculant les informations de description des services de façon à obtenir des informations sur ces services; le récepteur utilise ces informations pour construire une liste éventuellement unitaire des services disponibles sur le réseau.

2. Méthode selon la revendication 1 où toutes les tables de signalisations relatives à un service sont contenues dans au moins un flux différent du flux véhiculant le contenu dudit service.

3. Méthode selon la revendication 2 contenant une étape de test de correspondance entre un identificateur et un filtre contenu dans le descripteur d'un flux permettant de déterminer si une table possédant cet identificateur est disponible dans ledit flux.

4. Méthode selon l'une des revendications 1 à 3 où la première adresse IP de diffusion et le premier numéro de port sont entrés par l'utilisateur.

5. Méthode selon l'une des revendications 1 à 3 où la première adresse IP et le premier numéro de port sont obtenus du réseau par le récepteur.

6. Méthode selon l'une des revendications 1 à 5 où les flux ne contiennent qu'un seul service DVB.

7. Méthode selon l'une des revendications 1 à 6 où la liste des services est incluse dans la NIT contenue dans le flux disponible à la première adresse IP de diffusion sur le premier port.

8. Appareil possédant des moyens de se connecter à une adresse IP de diffusion via des moyens de connexion à un réseau IP et des moyens de décodage de flux DVB diffusé à cette adresse IP de diffusion, caractérisé en ce que les moyens de décodage de flux DVB ont la capacité d'analyser une NIT, extraite du flux, contenant des descripteurs de réseau adaptés au réseau IP et de se connecter à chaque adresse IP de diffusion décrite dans ladite NIT pour y lire un flux DVB et en extraire les informations sur les services offerts sur le réseau préférentiellement selon l'une quelconque des méthodes selon les revendications précédentes.

9. Descripteur d'un service de diffusion d'un flux DVB destiné à être inclus dans une NIT caractérisé en ce qu'il contient l'adresse IP de diffusion d'un serveur de flux et un numéro de port sur lequel ledit serveur diffuse un flux DVB véhiculant le contenu d'un service sur un réseau de type IP et au moins un descripteur contenant l'adresse IP de diffusion d'un serveur de flux et un numéro de port sur lequel ledit serveur diffuse un flux DVB véhiculant des informations de signalisation relatives audit service.

10. Descripteur selon la revendication 9 où les au moins un descripteur contenant l'adresse IP de diffusion d'un serveur de flux et un numéro de port sur lequel ledit serveur diffuse un flux DVB véhiculant des informations de signalisation relatives audit service contiennent également le moyen de tester la correspondance d'un identificateur avec un filtre.