FR2888703A1 - Systeme et methode pour convertir des donnees de diffusion video numerique - Google Patents

Systeme et methode pour convertir des donnees de diffusion video numerique Download PDF

Info

Publication number
FR2888703A1
FR2888703A1 FR0507549A FR0507549A FR2888703A1 FR 2888703 A1 FR2888703 A1 FR 2888703A1 FR 0507549 A FR0507549 A FR 0507549A FR 0507549 A FR0507549 A FR 0507549A FR 2888703 A1 FR2888703 A1 FR 2888703A1
Authority
FR
France
Prior art keywords
data
mpeg
digital video
wired
video broadcast
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.)
Pending
Application number
FR0507549A
Other languages
English (en)
Inventor
Luc Ottavj
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.)
Udcast
Original Assignee
Udcast
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 Udcast filed Critical Udcast
Priority to FR0507549A priority Critical patent/FR2888703A1/fr
Priority to PCT/FR2006/001751 priority patent/WO2007010130A1/fr
Priority to EP06778876A priority patent/EP1905193A1/fr
Publication of FR2888703A1 publication Critical patent/FR2888703A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • 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/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4341—Demultiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4344—Remultiplexing of multiplex streams, e.g. by modifying time stamps or remapping the packet identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H04N21/43637—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wireless protocol, e.g. Bluetooth, RF or wireless LAN [IEEE 802.11]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64315—DVB-H
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • 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/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un système destiné à convertir des données de diffusion vidéo numérique en une forme adaptée à leur réception par un ou plusieurs récepteurs filaires ou radio comportant :un moyen pour recevoir des données de diffusion vidéo numérique composées de flux élémentaires et de données de signalisation ;un moyen pour identifier quels flux élémentaires sont requis par un ou plusieurs récepteurs filaires ou radio ;un moyen pour détecter et extraire les données de signalisation et n'importe lesquels des flux élémentaires requis des données de diffusion vidéo numérique reçues; etun moyen pour transmettre de façon dynamique les flux élémentaires extraits aux récepteurs filaires ou radio.

Description

DESCRIPTION Domaine de l'invention
La présente invention porte sur un système et une méthode destinés à convertir des données de diffusion vidéo numérique en une forme adaptée à leur réception par un ou plusieurs récepteurs filaires ou radio. En particulier, la présente invention porte sur une passerelle pour router des flux DVB-H à des récepteurs n'ayant pas d'interface radio DVB-T ou DVB-H, mais ayant une interface filaire (ethernet) ou radio (WiF:_/WiMAX).
Contexte de l'invention Les prédictions relatives à la technologie actuelle suggèrent que le DVB-H est sur le point de percer sur le marché de l'électronique grand public. Tandis qu'on envisage qu'un grand nombre de personnes achèteront des téléphones DVE-H, un certain nombre de possesseurs d'ordinateurs portables (ou Laptops), d'assistants numériques personnels (ou PDA), et de téléphones cellulaires intégrant un assistant numérique personnel (ou Smartphones), seront également intéressés par un contenu DVB-H tout en ne possédant pas le matériel nécessaire pour recevoir un signal DVB-H. Cependant, les laptops, les PDA et les Smartphones possèdent déjà typiquement une interface WiFi ou ethernet (et peut-être WiMAX).
Les PC ethernet sont généralement alimentés par secteur. Par conséquent, la question de la consommation d'énergie de batterie ne constitue pas un problème particulier pour ces dispositifs. Toutefois, les laptops WiFi sont typiquement alimentés par batterie. De ce fait, la conservation d'énergie de batterie est à prendre en considération sur de tels dispositifs. Les PDA WiFi sont, de façon prédominante, alimentés par batterie, si bien que la consommation d'énergie de batterie est particulièrement problématique dans de tels dispositifs.
Puisque la présente invention porte sur une passerelle fournissant une interface entre les protocoles de transport de diffusion DVB-H et WiFi/WiMAX, il est utile à ce niveau de revoir brièvement les principes de transmission IP en monodiffusion (unicast) ou en multidiffusion (multicast) ainsi que les protocoles DVB-H et WiFi. Par conséquent, le contexte de l'invention sera décrit en référence aux dessins qui l'accompagnent, sur lesquels: la figure 1 est un schéma fonctionnel d'un réseau monodiffusion (unicast) IP; la figure 2 est un schéma fonctionnel d'un réseau multidiffusion (multicast) IP; la figure 3 est un schéma fonctionnel d'un multiplexeur MPEG-2; la figure 4 est un schéma fonctionnel d'un paquet appartenant à un Packetised Elementary Stream (PES) ; la figure 5 est un schéma fonctionnel des composants 30 matériels et logiciels d'un terminal récepteur DVB-H.
1. MECANISMES DE TRANSMISSION IP 3 (a) Monodiffusion IP (unicast) En se référant à la figure 1, un réseau comporte des routeurs R1, R2, R3 et R4 connectés par des lignes de transmission L1i L2, L3, L4 et L5 et des dispositifs (hôtes) D1 et D2. Le dispositif Dl est directement connecté au routeur RI et le dispositif D2 est connecté au routeur R4. Chaque dispositif et chaque routeur sur le réseau a une adresse IP, laquelle encode son numéro de réseau et son numéro d'hôte. Les adresses IPv4 font quatre octets de long et les adresses IPv6 font seize octets de long.
Dans un scénario typique, un utilisateur génère des données destinées à être transmises sur le réseau. Les données sont envoyées à la couche transport, laquelle ajoute un en-tête (par ex., un en-tête TCP) et passe le paquet résultant à la couche réseau. La couche réseau ajoute son propre en-tête (comprenant les adresses des dispositifs source et destination) pour former un paquet de couche réseau (par ex. un paquet IP) . Le paquet est ensuite envoyé à la couche liaison de données, laquelle ajoute ses propres en-têtes et somme de contrôle et passe la trame résultante à la couche physique, et l'hôte (par ex. D1) transmet alors la trame au routeur le plus proche (par ex. R1).
A réception d'une trame, un routeur (par ex. R1) enlève l'en-tête et la terminaison de couche liaison de la trame et passe le paquet situé dans la partie information (payload) de la trame au logiciel de routage. Le logiciel utilise l'en-tete de paquet pour choisir une ligne de sortie du routeur actuel pour réacheminer le paquet au routeur le plus proche (par ex. R2, R3). Ce processus se poursuit pendant l'acheminement du paquet à travers le réseau jusqu'à ce qu'il atteigne la destination requise.
(b) Multidiffusion IP (multicasting) Les diagrammes, IP sont normalement communiqués entre un expéditeur unique et un destinataire unique. Cependant, pour certaines applications il est utile de pouvoir envoyer des données à un nombre important de destinataires simultanément. La multidiffusion (multicasting) permet à une source d'envoyer une copie unique de données en utilisant une adresse unique de diffusion à un groupe important de destinataires.
Un groupe multicast est identifié par une adresse IP de classe D (224.0.0. 0 à 239.255.255.255 en IPv4). Lors de l'utilisation, un dispositif source envoie des données à un groupe multicast en utilisant l'adresse de ce groupe multicast comme adresse de destination. Lorsque des protocoles de routage multicast dynamiques sont utilisés sur le réseau, les données multicast sont propagées seulement dans les zones du réseau où il existe des utilisateurs intéressés par les groupes multicast pertinents (c.-à-d. dans lesquelles des utilisateurs sont membres de ces groupes).
Par exemple, en se référant à la figure 2, le dispositif source S envoie des données au groupe multicast dont sont membres les dispositifs D1, D2 et D3 le long des routes SD1, SD2 et SD3, respectivement. La route SD1 comporte les routeurs R1 et R5. La route SD2 comporte les routeurs R1, R2 et R3 et la route SD3 comporte les routeurs R1, R2, R3, R4, R7 et R8. Les dispositifs D4 et D5 ne sont pas membres du groupe multicast. Par conséquent, ces dispositifs ne reçoivent pas les données multicast provenant du dispositif source S. Afin de recevoir des données multicast, un dispositif (par ex. D4) doit se joindre à un groupe multicast en informant le(s) routeur(s) (par ex. R9) sur son LAN de l'adresse du groupe multicast auquel il souhaite se joindre. C'est ensuite la responsabilité d'un routeur sur le LAN de se joindre au grcupe multicast. Il existe trois principaux protocoles utilisés pour communiquer à un routeur une affiliation à un groupe multicast, à savoir Internet Group Management Prctocol (IGMP) [utilisé par les groupes multicast IPv4], Multicast Listener Discovery (MLD) [utilisé par les groupes multicast IPv6] et ATM multicast.
IGMP fournit trois structures de message spécifiques (à savoir Query, Report et Leave Group) afin de permettre la communication entre des dispositifs, des routeurs et des routeurs spécialisés connus sous le nom de "queriers". Des messages Query (ail groups) sont utilisés par des queriers afin de découvrir quels groupes ont au moins un membre sur le LAN. Un message Report est envoyé en réponse à un message query;par un récepteur qui est membre du groupe multicast pertinent. Des messages Leave Group sont envoyés par un récepteur souhaitant quitter un groupe multicast donné.
Pour se joindre à un groupe multicast, un dispositif doit envoyer un message Report ou _loin adressé au groupe multicast. Un routeur local détecte le message Report ou foin et utilise un protocole de routage multicast pour se joindre au groupe multicast. Un querier diffuse de façon périodique un message Query sur le LAN et au moins un dispositif sur le LAN intéressé par le groupe répond au message Query en envoyant un message Report. Si aucun dispositif sur le LAN ne revendique l'affiliation à un groupe à l'intérieur d'un intervalle de temps spécifié, le routeur cesse de réacheminer du trafic multicast pour ce groupe sur le LAN. Quand aucun LAN ni routeur en aval directement attaché au routeur n'est intéressé par le groupe multicast, le routeur demande son voisin en amont d'arrêter de lui réacheminer du trafic multicast pour le groupe multicast.
Une fois qu'un routeur multicast connaît les affiliations à un groupe des dispositifs directement connectés à lui, il échange des informations avec d'autres routeurs pour former un arbre multicast, dans lequel des données envoyées à un groupe multicast sont réacheminées à toutes les branches de l'arbre associé. Les mécanismes pour construire des arbres multicast peuvent être globalement classifiés en mécanismes d'adhésion ou mécanismes de non-adhésion. Les mécanismes d'adhésion (lesquels comprennent le Protocol Independent Multicast Sparse Mode (PIM-SM)) sont basés sur le postulat que la plupart des dispositifs dans un réseau ne voudront pas recevoir de données multicast. En conséquence, un routeur doit indiquer de façon spécifique s'il désire recevoir des données multicast pour un groupe multicast particulier, faute de quoi le routeur n'est pas connecté à l'arbre multicast de ce groupe.
Par opposition, les mécanismes de non-adhésion ou d'inondation flood) et d'élagage (prune) supposent, qu'à priori, chaque routeur sur un réseau désire recevoir des données multicast. En conséquence, les données sont envoyées à tous les routeurs. Les routeurs désirant se retirer d'un arbre multicast doivent envoyer un message Prune à un routeur en amont sur l'arbre. Les protocoles de non-adhésion comprennent le Protocol Independent Multicast Dense Mode (PIM-DM) et le Distance Vector Multicast Routing Protocol (DVRN:P).
2. STANDARDS DE DIGITAL VIDEO BROADCASTING (a) Composants d'un système de transmission DVB Les protocoles Digital Video Broadcasting (DVB) sont un groupe de standards développés pour transmettre de la télévision numérique. Si l'on se réfère à la figure 3, durant une transmission DVB, un encodeur MPEG-2 150 multiplexe un:ertain nombre de flux élémentaires 154 (c.-à-d. des flux de données numériques individuels mais pouvant être apparentés) pour former un flux de données unique, connu sous le nom de "transport stream" 152. Les données du t:ra.lsport stream 152 sont transmises à un modulateur qui délivre un signal radio.
Un transport sc.ream 152 comporte une succession de paquets de 188 octets appelés paquets de transport 160. Chaque paquet de transport 160 comporte un en-tête de 4 octets 162 suivi d'un champ d'adaptation 164 ou d'une partie information (payload) 166 (ou des deux). L'en-tête 162 comporte un certain nombre de champs comprenant un octet de synchronisation (lequel permet à un décodeur de détecter le début du paquet de transport 160) et un packet identifier (PID), les parquets de transport ayant le même PID forment un flux élémentaire (Elementary Stream) 154.
En plus des flux élémentaires 154, un transport stream 152 comprend des marqueurs temporels 156 (qui permettent la synchronisation de flux élémentaires 154 qui se décomposent en program specific information (PSI) et service information (El) 158. Les tables Program Specific Information (PSI), font la relation entre un service ( ex audio, vidéo d'une chaîne TV) et les valeurs PID de ses flux élémentaires 154. Les principales tables PSI sont: la Program Map Table (PMT), une Program Association Table (PAT) et une Network Information Table (NIT). Une PMT fournit des détails sur un service et ses flux élémentaires. Une PAT fournit une liste de tous les services disponibles dans un transport stream donné. Chaque service listé dans la PAT est accompagné par les valeurs PID des paquets de transport qui contiennent sa PMT. Une NIT fournit des informations sur le réseau transportant le transport stream (par ex. fréquences des canaux, caractéristiques de modulation, etc.).
Les normes DVB prescrivent l'inclusion de tables supplémentaires connues sous le nom de "DVB-SI" dans un transport stream MPEG-2. Les DVB-SI sont incorporées dans le transport stream en tant que paquets de transport qui contiennent, entre autres, des informations techniques pour des récepteur/décodeurs intégrés (IRD) et des informations d'electronic program guide (EPG) (par ex. la nature d'un programme, le timing et le canal sur lequel il est disponible, etc.). En particulier, les DVB-SI comprennent les tables su_Lvantes:
- une Service Description Table (SDT) ;
- une Evenf: Information Table (EIT) - une Time and Date Table (TDT) ; et 10 - une IP/Mz,C Notification Table (INT) Une SDT fournit des informations orientées utilisateur sur des services dans un transport stream (par ex. le nom du service et si le service fonctionne ou non). Une EIT fournit des informations de calendrier pour un service et un TDT fournit une référence de temps pour le transport stream. Une INT signale la disponibilité et l'emplacement de flux IP dans des réseaux DVB. Plus particulièrement, une INT fournit la table de correspondance entre des adresses IP (y compris des adresses destination multicast IP) et les éléments permettant de localiser les flux IP envoyés à ces adresses dans Les flux DVB. Ces éléments comprennent l'identifiant de transport stream, le numéro de programme et l'identifiant de composant (component tag) du flux dans ce programme. Cl convient de noter qu'il peut y avoir une ou plusieurs INT couvrant tous les flux IP pour un réseau DVB.
Afin de produire le transport stream 152, un multiplexeur MPEG-2 150 convertit chaque flux élémentaire reçu 154 en un flux de paquets Packetised Elementary Stream (PES) pouvant chacun être d'une longueur variable allant jusqu'à un maximum de 64 Kb. En se référant à la figure 4, un paquet PES 168 comporte une partie information (payload) 170 et un entête 172. L'en-tête 172 contient un certain nombre de champs comprenant: (a) un code de début 174; (b) un stream ID 176 (lequel établit une distinction entre des paquets PES correspondant à des flux élémentaires 10 différents) ; c) des bits indicateurs 178 qui indiquent la présence (ou l'absence) de champs optionnels dans l'en-tête; (d) des marqueurs temporels 180; et (e) des données de longueur d'en-tête PES 182.
Le Digital Stcrage Media Command and Control (DSMCC) MPEG-2 fournit un mécanisme destiné à diffuser des données (par opposition à des signaux audio/vidéo) dans les sections d'une table privée MPEG-2 standard. En particulier, la Multi-Protocol Encapsulation (MPE) permet à un datagramme de n'importe quel protocole de communication d'être transmis dans une section d'une table DSMCC à l'intérieur d'un transport stream. Cette procédure peut être utilisée pour des transmissions de données Internet haute vitesse dans lesquelles un datagramme Internet Protocol IP) transporte des informations concernant l'adresse logique (IP) des dispositifs source et destinataire ainsi qu'éventuellement l'adresse Media Access Control (MAC) du dispositif destinataire. (b) DVB-H Le Digital Video Broadcasting Handhelds (DVB-H) est spécifiquement conçu pour faciliter la diffusion d'IP à des dispositifs de poche alimentés par batterie (par ex. des téléphones mobiles, des PDA, etc.). Les principales applications du DVB-H seront probablement la diffusion de la télévision à des téléphones mobiles de nouvelle génération, lesquels combinent les fonctions d'un récepteur TV et d'un téléphone (Nokia CF 7100) ou d'un PDA (Smartphones DVB-H).
Comparée avec la transmission à des téléviseurs traditionnel, la transmission à des dispositifs de télévision de poche présente un certain nombre de défis techniques. Par exemple, un dispositif de télévision de poche a une antenne significativement plus petite qu'un téléviseur traditionnelle. De même, puisque les dispositifs de télévision de poche doivent être capables de recevoir un signal de télévision dans virtuellement n'importe quel endroit, le système de transmission de signal doit être efficace dans des conditions de réception variables.
Enfin, l'une des principales préoccupations pour tout dispositif de poche est son autonomie de batterie. En particulier, la consommation d'énergie du DVB-T est trop élevée pour les batteries de dispositifs de télévision de poche. L'un des principaux développements en DVB-H est le découpage du temps. La clé du découpage du temps est l'observation selon laquelle, si le récepteur pouvait être éteint pendant. qu'un service n'est pas en cours de transmission, l'énergie de batterie du récepteur pourrait être économisée. En conséquence, par opposition avec le mécanisme de transmission de données continue fourni par le DVB-T, le mécanisme de découpage du temps permet la transmission des données (MPE/IP) en rafales à bande passante élevée et qui peuvent durer de quelques millisecondes à quelques secondes.
Les rafales de données DVB-H sont transmises à la vitesse du canal radio (D) (c.-à-d. 10 à 20 Mbs) et sont répétées de façon périodique (la période (P) étant de plusieurs secondes), le récepteur radio étant en mode veille pendant les intervalles entre les rafales. Si la vitesse d'un canal radio est de 10 Mbs, la durée de rafale de 100 ms et la période de rép=_tition de rafale de 2 s, un récepteur de poche recevra des données à un débit moyen de Mbs* 0.1/2, ou 500 Kbs. Par conséquent, le récepteur peut commuter sa circuiterie radio en mode sommeil pendant (2 - 0,1) /2 ou 95 % du temps, menant à une économie pouvant atteindre 90 % de l'énergie de batterie du récepteur de poche.
En tenant compte de la contribution de la circuiterie radio à la consommat_Lon d'énergie globale d'un récepteur, la technique de découpage du temps peut augmenter l'intervalle de temps entre le rechargement des batteries du récepteur de dizaines de minutes (avec une réception de données continue à 500 Kbs) à plusieurs heures.
En raison des contraintes de taille d'écran, de résolution et de capacité de stockage d'un récepteur DVB-H, il est suffisant de l'alimenter avec des flux de données à un débit de quelques centaines de kilo bits par seconde. De plus, puisque les canaux radio DVB sont transmis à des débits de 10 20 Mbs, les flux de données DVB-H sont typiquement transmis en mode découpage du temps (time - slicing).
Avant que des données puissent être transmises en utilisant le DVB-H, les flux IP doivent être transformés en flux DVB- H par un Encapsulateur IP (IPE) (IP Encapsulator (IPE)). Outre la production des sections MPE et de leur transmission en rafales, un IPE DVB-H calcule un code autocorrecteur (Reed Solomon) au niveau MPE qui améliore la qualité de la réception du signal par l'antenne unique d'un récepteur de poche et éventuellement crypte le contenu au niveau IP qui assure un bon niveau de confidentialité.
En se référant à la figure 5, les composants matériels d'un récepteur DVB:i 208 comportent une antenne 210 et trois blocs fonctionnels, à savoir un bloc RF 212, un bloc de bande de base 214 et un connecteur physique au terminal 216. Le composant central du logiciel de récepteur DVB-H 217 est un Electronic Service Guide Server (ESG-S) 218. Le logiciel de récepteur 217 comprend également des players 220 (par ex. Mediaplayer (marque de commerce) et Realplayer (marque de commerce)) et un système cache 222. Lorsqu'un récepteur est allumé pour la première fois, il stocke des DVBSI provenant du transport stream MPEG-2 démodulé dans le bloc de bande de base 214.
Comme vu précédement, les tables DVB-PSI/SI fournissent les informations nécessaires pour récupérer et recevoir chaque service de diffusion de données IP disponible (identifiable par son adresse IP). Les informations fournies par les DVBPSI/SI comprennent l'ID de transport Stream et la fréquence et la modulation associées, le numéro de programme, l'identifiant de composant (component tag) et le PID. A réception de ces informations, l'utilisateur peut sélectionner un service spécifique, en utilisant l'ESG- server 218, dans ce cas le récepteur DVB-H syntonise le bloc-RF 212 sur la fréquence pertinente et traite les 10 trames MPEG-2 correspondant aux PID requis.
3. STANDARD IEEE 802.11 (WiFi) WiFi est un nom commun pour les standards IEEE 802.11 pour 15 les LAN sans fil. Un LAN 802.11 est basé sur une architecture cellulaire de Base Service Stations (BSS) dans laquelle une BBS comporte au moins deux ordinateurs en communication l'un avec l'autre, dans laquelle chacun des ordinateurs contient une carte de Networking Interface (NIC).
Les LAN 802.11 peuvent être classifiés en ad-hoc ou en infrastructure . Dans un LAN ad hoc, les stations communiquent directement les unes avec les autres d'une manière poste-à-poste sans impliquer un point d'accés central. Puisqu'il n'y a pas de fonction relais dans le réseau, il est nécessaire que toutes les stations soient à portée les unes des autres. Par conséquent, un réseau ad-hoc comporte typiquement un petit nombre de dispositifs à proches les uns des autres. Par opposition, dans un LAN à infrastructure les stations communiquent les unes avec les autres par le biais d'un Point d'accés (AP) dans lequel le Point d'accés fait office d'arbitre pour le réseau, déterminant si, et quand, chaque station peut transmettre.
(a) Media Access Layer Le protocole 802.11 adresse deux couches distinctes du modèle de réseau sans fil, à savoir la Media Access Layer (MAC) et la couche physique. La MAC définit deux méthodes d'accès, à savoir la Distributed Co-ordination Function (DCF) et la Point Co- ordination Function (PCF) et un certain nombre de fonctions comprenant le balayage, l'association, la fragmentation et l'économie d'énergie pour gérer collectivement la communication entre stations.
(i) Méthodes d'accès MAC Distributed Cc-ordination Function (DCF) La DCF n'emploie pas de mécanisme de contrôle central et est essentiellement un mécanisme de Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). Le CSMA est un protocole basé sur la contention, lequel fait en sorte que toutes les stations écoutant le canal radio avant de transmettre ne transmettent que lorsque le canal radio est libre et, ainsi, ne transmettent pas des messages en même temps. Afin de réduire le risque que des signaux provenant de deux stations entrent en collision parce que les stations ne peuvent pas s'entendre l'une l'autre, la DCF définit un mécanisme de captage de porteuse virtuelle, dans lequel une station voulant transmettre des données transmet d'abord un paquet de contrôle connu sous le nom de paquet "Request To Send" (RTS). Le paquet RTS indique les adresses source, la destination et la durée de la transmission proposée. La station de destination répond avec un paquet de contrôle connu sous le nom de paquet "Clear To Send" (CTS). Toutes les stations (autres que la source et la destination) recevant soit le paquet CTS soit le paquet RTS règlent un compteur interne connu sous le nom de "Network Allocation Vector" (NAV) sur la durée de la transmission et cessent de transmettre sur le support jusqu'à ce que la transmission à la destination soit achevée.
Point Co-ordination Function (PCF) La PCF réalise une livraison de données conformément à un calendrier dans laquelle un Point d'accés accorde à la station l'accès au canal radio en interrogeant la station durant la période sans contention. Puisque l'autorisation de transmission est complètement contrôlé par le Point d'accés, il ne se produit jamais de collision.
(ii) Fonctions MAC Balayage Le balayage fait référence au processus selon lequel la NIC cherche un Point d'accés. Le balayage est basé sur la détection d'un signal (ou trame balise) diffusé de façon périodique par un Point d'accés. Les trames balises contiennent les informations suivantes: (a) intervalle balise (c.-à-d. la quantité de temps entre les transmissions balises) ; (b) marqueur temporel; (c) Service Set Identifier (SSID) (identifie des LAN sans fil spécifiques de sorte qu'une station puisse s'associer avec un LAN avant la transmission de données) ; et (d) Traffic Indication Map (TIM) (identifie quelles stations fonctionnant en mode d'économie d'énergie ont des données unicast qui les attendent dans le tampon du Point d'accés et s'il y a du trafic de diffusion et multicast qui attend aussi).
Il y a deux formes de balayage, à savoir passive et active.
Durant un balayage passif, une station attend de recevoir une trame balise provenant d'un Point d'accés. Par opposition, durant un balayage actif, une station localise un Point d'accés en transmettant une trame de requête d'enquête (poli) et attend une réponse d'enquête de la part de tous les Points d'accés qui sont à sa portée. Lorsque la station reçoit des réponses de balise/enquête, les données contenues à l'intérieur de chaque réponse balise/enquête permettent à la station d'ordonner les Points d'accés détectés en utilisant des attributs présents dans la balise, tels que l'intensité de signal reçu.
Association/Synchronisation Une fois qu'une station a identifié un Point d'accés préféré, sa NIC doit s'associer (ou établir une connexion logique) avec le Point d'accés. L'association permet au Point d'accés d'allouer des ressources pour une NIC, et de 2888703 18 se synchroniser sur celle- ci. Lors de l'utilisation, la station envoie une trame requête d'association au Point d'accés préféré. La trame requête d'association transporte des informations concernant la NIC et le SSID du réseau auquel elle souhaite s'associer. A réception de la trame requête d'association, le Point d'accés préféré se demande s'il doit s'associer avec la NIC et, s'il accepte la requête d'association, le Point d'accés préféré réserve de l'espace mémoire et affecte un Association ID (AID) à la NIC de la station.
Une fois le processus d'association achevé, la NIC de la station est à même d'envoyer des trames de données au Point d'accés. Toutefois, la NIC continue à balayer à la recherche d'autres trames balises provenant du Point d'accés afin de détecter si le signal provenant du Point d'accés est devenu trop faible pour maintenir les communications. La NIC utilise aussi le marqueur temporel des trames balises pour mettre à jour son horloge locale et, de ce fait, maintenir la synchronisation sur le Point d'accés et d'autres stations.
Fragmentation Les protocoles LAN classiques utilisent des paquets de plusieurs centaines d'octets de long. Toutefois, les réseaux sans fil sont typiquement moins fiables que les réseaux câblés. Puisque la probabilité qu'une trame soit correctement transmise sur un réseau sans fil diminue avec la longueur de la trame, le standard 802.11 comprend un mécanisme de fragmentation et de ré-assemblage, lequel permet à des trames d'être fragmentées en morceaux plus petits ayant chacun sa propre somme de contrôle. Une fois qu'un canal a été acquis, des fragments multiples sont envoyés de façon consécutive dans une séquence connue sous le nom de "rafale de fragments".
Économie d'énergie La fonction économie d'énergie du standard 802.11 permet à une NIC de conserver l'énergie de batterie en commutant du mode opérationnel en mode sommeil lorsqu'il n'y a pas besoin d'envoyer ni de recevoir des données. Lorsqu'elle est en mode sommeil, la NIC se réveille de façon périodique pour recevoir des transmissions de balises provenant d'un Point d'accès. Le paramètre TIM informe la NIC de la présence de données en attente la concernant dans le Point d'accés et s'il y a des trames de diffusion ou multicast en attente. La NIC apprend si du trafic unicast l'attend en regardant l'entrée correspondant à son AID dans la Traffic Indicator Map. Dans ce cas, la carte envoie un message d'interrogation (une trame PS-POLL) au Point d'accés afin de récupérer les messages mis en attente, la NIC reste éveillée jusqu'à ce que les messages lui soient transférés et ensuite retourne en mode veille.
Lorsqu'au moins un récepteur associé est en mode d'économie d'énergie le point d'accés stocke également des trames de diffusion et multicast jusqu'à la prochaine trame balise DTIM. A la prochaine balise DTIM, lepoint d'accés annonce qu'il stocke du trafic multicast et de diffusion en utilisant le premier bit de la TIM MAP (AID 0). Immédiatement après, le point d'accés transmet le trafic multicast et de diffusion.
De ce fait, un récepteur peut savoir qu'il y a du trafic multicast en attente, sans savoir si ce trafic est pour un groupe multicast qui l'intéresse. De plus, la transmission de trafic multicast n'est pas sécurisée par un mécanisme PSPOLL/ACK.
Résumé de l'invention La présente invention porte sur un système et une méthode destinés à convertir des données de diffusion vidéo numérique en une forme adaptée à leur réception par un ou plusieurs récepteurs filaires ou radio. En particulier, la présente invention porte sur une passerelle permettant d'acheminer de façon dynamique des flux DVB-H d'intérêt jusqu'à des récepteurs n'ayant pas d'interface radio DVB-T ni DVB-H, mais ayant une interface filaire (Ethernet) ou radio (WiFi/WiMAX).
Lorsqu'un récepteur possède une interface radio (WiFi/WiMAX), la présente invention utilise la fonction découpage du temps de DVB-H et la fonction économie d'énergie du standard 802.11 pour acheminer les flux DVB-H sur le récepteur d'une manière qui minimise sa consommation d'énergie de batterie tout en assurant la fiabilité de transfert de données.
La présente invention s'adresse au système et à la méthode tels que définis dans les revendications indépendantes pour fournir une passerelle DVB-H/Ethernet ou WiFi/WiMAX. Des modes de réalisation supplémentaires de l'invention sont fournis dans les revendications dépendantes en annexe. Description et dessins Un mode de réalisation de l'invention va maintenant être décrit, à titre d'exemple uniquement, en référence aux figures qui l'accompagnent, sur lesquelles: la figure 6 est un schéma fonctionnel de l'architecture matérielle du système de la présente invention, lors de l'utilisation, le système n'étant connecté à un client LAN; et la figure 7 est un schéma fonctionnel des flots de données dans le système de la présente invention lorsqu'elle fonctionne dans un mode passerelle DVB-H à WiFi/WiMAX ou Ethernet basique; et dans un mode relayage MPEG-2.
Description détaillée
Par souci de brièveté, le système destiné à convertir des données de diffusion vidéo numérique en une forme adaptée à leur réception par un ou plusieurs récepteurs filaires ou radio sera connu à partir de maintenant sous le nom de passerelle.
En se référant à la figure 7, la passerelle 300 comporte une antenne 302, un processeur 304, une mémoire vive 306, une interface LAN 308, une mémoire flash ou CF 310 et/ou un disque 312.
La passerelle 300 a un certain nombre de modes opérationnels comprenant: (a) mode passerelle DVB-H à WiFi/WiMAX ou Ethernet basique; (b) mode économie d'énergie de LAN sans fil 802.11 en mode infrastructure; (c) mode querier IGMP; (d) mode décodage d'IP crypté ; (e) mode relais MPEG-2; et (f) mode passerelle pour relayer des flux élémentaires 15 MPEG-2 multiples.
Ces modes opérationnels seront examinées plus en détail ci-dessous.
Mode passerelle DVB-H à WiFi/WiMAX ou Ethernet Lors de l'utilisation, la passerelle 300 reçoit des requêtes d'abonnement à un groupe multicast (c.à-d. des messages IGMP/MLD) 314 par le biais de l'interface LAN 308 25 provenant d'un ou plusieurs dispositifs clients LAN 316.
Ayant établi l'affiliation à un groupe multicast des dispositifs clients LAN 316, la passerelle 300 balaie le spectre RF à la recherche de tous canaux DVB-H disponibles (ou se syntonise sur un canal DVB-H présélectionné). 30 Lors de la détection et de la syntonisation à un canal DVBH, la passerelle 300 identifie les tables de signalisation PSI/SI (NIT, INT, PAT, PMT, etc.) dans le flux DVB-H du canal. La passerelle 300 utilise les informations contenues dans les tables de signalisation PSI/SI afin de déterminer si le cana]. DVB-H reçu contient une transmission relative àun des groupes multicast identifiés par les dispositifs clients LAN 316.
Dans l'éventualité où le canal DVB-H reçu contient effectivement des données relatives à l'un des groupes multicast requis, la passerelle 300 utilise les tables de signalisation PSI/SI provenant du canal afin de permettre l'extraction de datagrammes IP spécifiques des sections MPE du transport stream MPEG-2 du canal.
Par conséquent, la passerelle 300 se comporte comme un routeur multicast dynamique traditionnel. Cependant, au lieu de déterminer l'affiliation et la structure d'un arbre multicast par le biais de mécanismes PIM-DM ou DVRMP classiques, la passerelle 300 emploie des mécanismes standards de signalisation DVB-H et d'extraction de données pour décoder les tables PSI/SI provenant d'une transmission DVB-H reçue et route de ce fait les datagrammes IP contenus dans celles-ci jusqu'aux membres de groupes multicast appropriés.
2. Mode économie d'énergie de LAN à infrastructure 802.11 On a vu que les LAN 802.11 peuvent être classifiés en ad hoc ou en infrastructure . Lorsque la passerelle 300 route des datagrammes IP extraits d'un flux DVB-H jusqu'à un LAN 802.11 ad hoc, les datagrammes IP sont routés conformément au protocole 802.11. Cependant, lorsque la passerelle 300 route des trames jusqu'à un LAN 802.11 à interface, la passerelle 300 peut se comporter soit comme un client d'un Point d'accés, soit comme un Point d'accés. Lorsque la passerelle 300 se comporte comme un Point d'accés, la. passerelle 300 accomplit la fonctionnalité normale d'un Point d'accés 802.11 et, en particulier, met en uvre les opérations de transmission de trame balise économie d'énergie 802.11.
Puisque le trafic de diffusion et multicast est envoyé en utilisant AIDO et que le trafic pour un groupe multicast donné n'est pas identifié de façon spécifique, la transmission de flux multicast à des LAN 802.11 en mode infrastructure est particulièrement inefficace pour à la fois maintenir la qualité des transferts de données et la conservation de l'énergie de batterie des dispositifs récepteurs. En effet, dans le cas ou plusieurs groupes (P) multicast d'origine DVB-H (c'est à dire transmis en rafale) sont routés par la passerelle, la présence de trafic multicast est annoncée globalement à chaque intervalle DTIM par l'AIDO de la TIM. Du fait de la transmission en rafales, le trafic multicast pour un groupe donné n'est présent que tous les N intervalles DTIM. Dans ces conditions, un récepteur intéressé par uniquement un groupe multicast sera réveillé à chaque intervalle DTIM et devra décoder le trafic de tous les P groupes multicast alors qu'un seul l'intéresse pour découvrir seulement une fois sur N qu'il y a du trafic intéressant pour lui.
Cependant, cette situation peut être considérablement améliorée en utilisant une adaptation au protocole 802.11 qui étend la notion de l'Association ID (AID) 802.11 mentionnée précédemment à un groupe multicast, plutôt qu'à des NIC de stations individuelles. Cela permet l'identification (à partir de la Traffic Information Map (TIM) d'une balise) de canaux ayant du trafic à transmettre à des groupes multicast individuels. L'extension de l'Association ID (AID) 802.11 à un groupe multicast permet également la transmission des données sur un canal à tous les membres de groupes multicast pertinents sur le LAN, à réception d'une requête PS POLL provenant de l'un des dispositifs clients LAN 316 (par ex. le dispositif client LAN 316 qui a transmis le message Report IGMP pour le groupe multicast).
Ce processus permet que la consommation d'énergie de batterie de dispositifs clients LAN individuels 316 durant la transmission de données dans plusieurs groupes multicast soit considérablement réduite, puisqu'un dispositif client LAN 316 aura la possibilité de se syntoniser sur un canal multicast uniquement aux moments où il y a du trafic multicast qui l'intéresse. De façon similaire, la qualité de transfert de données pourra être améliorée puisque les transferts seront fiabilisés par un des récepteurs qui se chargera de réclamer chaque trame multicast et de confirmer qu'elle a été bien reçue.
Le mécanisme ci-dessus de transmission et de signalisation de trafic multicast peut être également appliqué à des Point d'accès traditionnels n'ayant pas de fonction de relayage DVB-H.
3. Mode querier IGMP La passerelle 300 peut également accomplir les fonctions traditionnelles d'un querier IGMP/MLD, à savoir la vérification continue de l'affiliation à un groupe multicast de ses dispositifs clients LAN filaires ou radio 316.
4. Mode décodage d'IP crypté La passerelle 300 extrait les datagrammes IP des flux DVB-H et les transmet aux récepteurs, que les flux IP soient cryptés ou non. Cependant, lorsque ces flux sont cryptés au niveau IP (IPSEC) ou pour toute autre technique, telle que OMA DRM, la passerelle 300 a une option, sélectionnable par l'utilisateur, lui permettant d'acquérir les informations permettant de décrypter les flux pour les transmettre en clair aux dispositifs clients LAN appropriés intéressés.
5. Mode relais MPEG-2 En se référant à la figure 7, lorsqu'elle fonctionne dans le mode DVB--H à WiFi/WiMAX ou Ethernet basique, une passerelle reçoit des données DVB-H et en extrait les datagrammes IP correspondant aux flux multicast demandés par les récepteurs. La passerelle 300 achemine de façon dynamique ces datagrammes sur les LAN ethernet ou WiFi/WiMAX.
La passerelle 300 a également un mode relais MPEG-2 dans lequel elle relaie d'une manière sélective et dynamique les flux élémentaires MPEG-2 contenus dans un signal DVB-H reçu. Le principal but de cette procédure est de fournir à des dispositifs clients LAN un accès à, et une utilisation de, toutes les informations transportées par les transport streams MPEG-2 (et en particulier les informations de signalisation contenues dans ceux-ci), tout en évitant en même temps l'occupation de largeur de bande LAN par des flux élémentaires présents dans les transports stream et non requis sur les LAN.
Les paramètres suivants sont utilisés pour identifier un flux élémentaire MPEG-2 donné à l'intérieur d'un transport stream DVB: DVB network id, (original network ID), transport stream id, packet identifier (PID).
Les paquets MPEG-2 composant un flux élémentaire sont transportés à destination des clients LAN de l'une des façons suivantes.
(a) dans une trame Ethernet ayant un ethertype identifiant MPEG-2; (b) dans une trame Logical Link Control (LLC) ayant une 20 Destination Service d'Access Point (DSAP) identifiant MPEG-2; (c) dans un datagramme IPv4 ayant un numéro de protocole de transport identifiant MPEG-2; (d) dans un datagramme IPv6 ayant un numéro de protocole de transport identifiant MPEG-2; (e) dans un datagramme User Datagram Protocol (UDP) 30 transporté dans un datagramme IPv4; ou (f) dans un datagramme UDP transporté dans un datagramme IPv6.
Tous les paquets MPEG-2 provenant d'un flux élémentaire MPEG-2 donné sont transportés à une adresse multicast MAC commune. Cependant, ces paquets MPEG-2 sont également transportés à une adresse multicast IP commune lorsqu'ils sont transmis.
(a) dans un datagramme IPv4 ayant un numéro de protocole 10 de transport identifiant MPEG-2; (b) dans un datagramme IPv6 ayant un numéro de protocole de transport identifiant MPEG-2; (c) dans un datagramme UDP transporté dans un datagramme IPv4; ou (d) dans un datagramme UDP transporté dans un datagramme IPv6.
Lors de la transmission d'un datagramme provenant du transport stream MPEG-2 à une adresse multicast IP, la correspondance entre l'identificateur de flux élémentaire et l'adresse IP multicast est obtenue soit par calcul (par ex. dans les datagrammes IPv6 le calcul peut consister à concaténer à un préfixe multicast les valeurs des variables DVB identifiant le flux élémentaire).
Pour IPv4, il est rappelé que l'espace d'adressage comporte 32 bits parmi lesquels 28 bits sont disponibles pour établir une distinction entre différentes adresses multicast (trafic de classe D). Un exemple de mise en correspondance entre un identifiant de flux élémentaires et l'adresse I:Pv4 multicast utilisée pour le transporter pourrait être: 2 bits (DN) pour identifier le réseau DVB, 13 bits (TS) pour identifier le transport stream et 13 bits (PID) pour identifier le packet identifier. Dans ce cas, les bits DN pourraient être obtenus à partir des deux derniers bits de l'ID de réseau DVB. De façon similaire, les bits TS pourraient être obtenus à partir des 13 derniers bits (parmi les 16 bits possibles) de l'ID de transport stream DVB. Finalement, le PID pourrait être obtenu à partir des 13 bits du packet identifier.
Une autre façon de fournir la table de correspondance entre les identificateurs de flux élémentaire et une adresse multicast IP est de créer et de diffuser un service Electronic Service Guide (ESG) en IP UDP et Session Announcement Protocol (SAP). Un ESG fournit la table de correspondance entre les variables identifiant un flux élémentaire (ID de réseau DVB, ID de transport stream, PID) et une adresse multicast IP associée.
Quel que soit le mécanisme utilisé par la passerelle 300 pour transporter des informations extraites d'un ensemble de transport stream jusqu'à un dispositif client LAN, la passerelle 300 associe une adresse IP avec chaque flux élémentaire MPEG-2.
La passerelle 300 prend en compte l'activité IGMP ou MLD sur un LAN pour décider si elle transmet les transport streams MPEG-2 ou empêche la transmission des transport streams MPEG-2 sur le LAN. Cela garantit que seuls les flux élémentaires réellement requis sur le LAN sont relayés et que la largeur de bande du LAN n'est pas gaspillée par le transport de flux élémentaires MPEG-2 qui ne seraient pas utilisés pair les dispositifs clients LAN. Dans le cas d'une encapsulation IP/UDP, on utilise un numéro de port qui soit est un numéro fixe bien connu, soit est établi à partir du paramètre PID provenant du flux DVB-H (par ex. en ajoutant une constante au PID, laquelle constante est connue des récepteurs et de la passerelle 300).
En résumé, une adresse IP multicast (MIPES) est toujours associée avec chaque flux élémentaire de chaque transport stream. L'adresse multicast (MIPES) est utilisée pour indiquer un intérêt pour un flux élémentaire donné en utilisant le protocole IGMP/MLD. L'adresse multicast est également utilisée pour encapsuler les données de flux élémentaires dans les cas d'encapsulation c, d, e et f. Dans tous les cas d'encapsulation (a à f) les données de flux élémentaire sont transportées en utilisant une adresse MAC destination MMACES dérivée de la MIPES tel que décrit dans le RFC1469 pour IPv4 et dans le RFC2464 pour IPv6.
Le mode relayage MPEG-2 peut être implémenté pour tous les flux élémentaires MPEG-2, y compris ceux contenant des sections MPE, ou ceux transportant seulement des tables de signalisation.
6. Mode passerelle pour transport streams MPEG-2 multiples La passerelle 300 a une seule interface DVB-T/S et peut décoder seulement un canal radio unique. Par conséquent, une passerelle 300 peut décoder un seul transport stream MPEG-2 unique à un instant donné (c.-à-d. l'ensemble de tous les flux élémentaires compris dans ce transport stream MPEG-2). Afin de satisfaire les requêtes LAN concernant des données provenant de différents transports streams MPEG-2, il est possible d'installer plusieurs passerelles sur le LAN.
Le protocole IP multicast A permet à une passerelle d'annoncer de façon périodique sur le LAN son propre identificateur et sa propre adresse IP unicast, ainsi que l'identificateur du transport stream MPEG-2 que la passerelle est en train de décoder. Chaque passerelle sera de ce fait au courant des transport streams MPEG-2 en cours de traitement par les autres passerelles et une passerelle donnée ne décodera un transport stream MPEG-2 donné que si aucune autre passerelle ne le fait pas déjà.
Dans le cas d'une requête provenant d'un dispositif client LAN pour des données contenues dans un transport stream MPEG-2 qui n'a pas encore été décodé par une passerelle, une passerelle inoccupée annoncera sur le LAN (par le biais d'un message dans le protocole A) qu'elle décodera le transport stream MPEG-2 pertinent. Dans l'éventualité d'une collision dans laquelle deux passerelles ou plus annoncent qu'elles sont sur le point de décoder le même transport stream MPEG-2, la passerelle dont l'adresse IP est la plus petite décodera le transport stream MPEG-2. Dans ce cas, la passerelle pertinente continue d'annoncer qu'elle est en train de décoder le transport stream MPEG-2 et route les flux dudit transport stream MPEG-2 jusqu'aux membres de groupes multicast clients LAN appropriés.
Si, après une certaine période de temps (fixée par défaut à trois fois la période de querier IGMP/MLD), aucun dispositif client LAN ne réclame des données provenant du transport stream MPEG-2 décodé par une passerelle, la passerelle annonce sur le LAN qu'elle va arrêter de décoder le transport stream. La passerelle devient ensuite disponible pour décoder d'autres transport streams MPEG-2 lorsque nécessaire.
Le mécanisme décrit ici pour le DVB-H est également applicable au DVB-T, au DVB-S ou au DVB-C, qui ne différent que par leur interface physique.
On peut modifier ou changer ce qui précède sans sortir de la portée de l'invention.

Claims (41)

  1. 33 REVENDICATIONS
    1. Un système destiné à convertir des données de diffusion vidéo numérique en une forme adaptée à leur réception par un ou plusieurs récepteurs filaires ou radio comportant: un moyen pour recevoir des données de diffusion vidéo numérique composées de flux élémentaires et de données de signalisation; un moyen pour identifier quels flux élémentaires sont requis par un ou plusieurs récepteurs filaires ou radio; un moyen pour détecter et extraire les données de signalisation et n'importe lesquels des flux élémentaires requis des données de diffusion vidéo numérique reçues; et un moyen pour transmettre de façon dynamique les flux élémentaires extraits aux récepteurs filaires ou radio.
  2. 2. Un système tel que revendiqué dans la revendication 1, dans lequel: les flux élémentaires comportent des datagrammes IP; le moyen pour identifier quels flux élémentaires sont requis par un ou plusieurs récepteurs filaires ou radio comporte un moyen pour utiliser les données de signalisation afin d'identifier des datagrammes IP dans les flux élémentaires et déterminer si les datagrammes IP sont requis par le ou les récepteurs filaires ou radio; le moyen pour détecter et extraire n'importe lesquels des flux élémentaires requis des données de diffusion vidéo numérique reçues comporte un moyen pour extraire des datagrammes IP des flux élémentaires; et le moyen pour transmettre de façon dynamique 15 les flux élémentaires extraits aux récepteurs filaires ou radio comporte un moyen pour transmettre les datagrammes IP extraits.
  3. 3. Un système tel que revendiqué selon l'une quelconque des revendications précédentes, dans lequel le moyen pour identifier des récepteurs filaires ou radio comporte un moyen pour identifier un groupe multicast des données de diffusion vidéo numérique et un moyen de déterminer s'il y a des récepteurs filaires ou radio qui sont membres du groupe multicast.
  4. 4. Un système tel que revendiqué selon l'une quelconque des revendications précédentes, dans lequel les données de signalisation comportent une table PSI/SI.
  5. 5. Un système tel que revendiqué selon l'une
    quelconque des revendications précédentes, dans
    lequel les données de signalisation comportent une Network Information Table et une table de 5 notification IP/MAC.
  6. 6. Un système tel que revendiqué selon l'une quelconque des revendications précédentes, dans lequel le système comporte un moyen pour vérifier de façon périodique une affiliation à un groupe multicast des récepteurs filaires ou radio.
  7. 7. Un système tel que revendiqué selon l'une quelconque des revendications précédentes, dans lequel le système comporte: un moyen pour obtenir une clé de cryptage pour des données de diffusion vidéo numérique 20 cryptées; et un moyen pour employer la clé de cryptage afin de décrypter les données de diffusion vidéo numérique avant qu'elles soient transmises aux récepteurs filaires ou radio.
  8. 8. Un système tel que revendiqué selon l'une quelconque des revendications précédentes, comportant un moyen pour transmettre des données MPEG-2 provenant des données de diffusion vidéo numérique reçues aux récepteurs filaires ou radio.
  9. 9. Un système tel que revendiqué dans la revendication 8, dans lequel les données MPEG-2 comportent des paramètres de signalisation 5 MPEG-2.
  10. 10. Un système tel que revendiqué dans la revendication 8 ou la revendication 9, dans lequel les données MPEG-2 sont transmises dans une trame ayant un ethertype identifiant MPEG-2.
  11. 11. Un système tel que revendiqué dans la revendication 8 ou la revendication 9, dans lequel les données MPEG-2 sont transmises dans une trame LLC ayant un DSAP identifiant MPEG-2.
  12. 12. Un système tel que revendiqué dans la revendication 8 ou la revendication 9, dans lequel les données MPEG-2 sont transmises dans un datagramme IPv4 ayant un numéro de protocole de transport identifiant MPEG-2.
  13. 13. Un système tel que revendiqué dans la revendication 8 ou la revendication 9, dans lequel les données MPEG-2 sont transmises dans un datagramme IPv6 ayant un numéro de protocole de transport identifiant MPEG-2.
  14. 14. Un système tel que revendiqué dans la revendication 8 ou la revendication 9, dans lequel les données MPEG-2 sont transmises dans un datagramme UDP transporté dans un datagramme I1?v4.
  15. 15. Un système tel que revendiqué dans la revendication 8 ou la revendication 9, dans lequel les données MPEG-2 sont transmises dans un datagramme UDP transporté dans un datagramme IPv6.
  16. 16. Un système tel que revendiqué selon l'une quelconque des revendications 8 à 15, dans lequel le système comporte un moyen pour transmettre les données MPEG-2 à une adresse MAC commune.
  17. 17. Un système tel que revendiqué selon l'une quelconque des revendications 12 à 15, dans lequel le système comporte un moyen pour transmettre les données MPEG-2 à une adresse multicast IP.
  18. 18. Un système tel que revendiqué dans la revendication 17, dans lequel le système comporte un moyen pour créer une diffusion de type ESG en IP ou SAP afin de former une correspondance entre chaque flux élémentaire transporté dans un réseau DVB MPEG-2 et l'adresse multicast IP associée utilisée pour le transporter dans un réseau IP.
  19. 19. Un système tel que revendiqué selon l'une quelconque des revendications 8 à 18, dans lequel le système comporte un moyen pour détecter une activité IGMP ou MLD et déterminer de ce fait s'il faut transmettre ou mettre fin à la transmission de données MPEG-2 ou de données IP extraites des données MPEG-2 aux récepteurs filaires ou radio.
  20. 20. Un système tel que revendiqué selon l'une quelconque des revendications précédentes, dans lequel les récepteurs radio comportent des interfaces WiFi ou WiMAX et les récepteurs filaires comportent des interfaces Ethernet.
  21. 21. Un système tel que revendiqué selon l'une quelconque des revendications précédentes, dans lequel les données de diffusion vidéo numérique sont DVB-H.
  22. 22 Un appareil destiné à convertir plusieurs signaux de diffusion vidéo numérique donnés en une forme adaptée à leur réception par un ou plusieurs récepteurs filaires ou radio dans lequel l'appareil comporte plusieurs des systèmes revendiqués dans n'importe lesquelles des revendications précédentes, dans lequel chacun des systèmes convertit l'un des signaux de diffusion vidéo numérique.
  23. 23. Un appareil tel que revendiqué dans la revendication 22, dans lequel l'appareil comporte un moyen de garantir que le système dont l'adresse IP unicast est la plus petite 2888703 39 convertit un signal de diffusion vidéo numérique donné dans l'éventualité où deux systèmes ou plus tenteraient de décoder le même signal.
  24. 24. Une méthode pour convertir des données de diffusion vidéo numérique en une forme adaptée à leur réception par un ou plusieurs récepteurs filaires ou radio comportant les étapes de: (a) syntonisation à un signal de diffusion vidéo numérique; (b) reception le signal de diffusion vidéo 15 numérique; (c) détection et extraire des données de signalisation du signal de diffusion vidéo numérique; (d) utilisation les données de signalisation afin d'identifier des récepteurs filaires ou radio appropriés; (e) extraction des datagrammes IP du signal de diffusion vidéo numérique; (f) transmission les datagrammes IP aux récepteurs filaires ou radio appropriés.
  25. 25. Une méthode telle que revendiquée dans la revendication 24, dans laquelle l'étape (d) d'identification des récepteurs filaires ou radio appropriés comporte les étapes de: (dl) identification d'un groupe multicast pour les données de diffusion vidéo numérique; et (d2) détermination de la présence d'un ou plusieurs récepteurs filaires ou radio qui sont membres du groupe multicast.
  26. 26. Une méthode telle que revendiquée dans la revendication 24 ou la revendication 25, dans laquelle la méthode comporte l'étape supplémentaire (g) de vérifier de façon périodique une affiliation à un groupe multicast des récepteurs filaires ou radio.
  27. 27. Une méthode telle que revendiquée selon l'une quelconquedes revendications 24 à 26, dans laquelle la méthode comporte les étapes supplémentaires de: (d:3) obtention une clé de cryptage pour des données de diffusion vidéo numérique cryptées; et (d4) décryptage les données de diffusion vidéo numérique avec la clé de cryptage.
  28. 28. Une méthode telle que revendiquée selon l'une quelconque des revendications 24 à 27, dans 10 laquelle la méthode comporte de plus l'étape (el) de transmission des données MPEG-2 aux récepteurs filaires ou radio.
  29. 29. Une méthode telle que revendiquée dans la revendication 28, dans laquelle les données MPEG-2 sont transmises dans une trame ayant un ethertype identifiant MPEG-2.
  30. 30. Une méthode telle que revendiquée dans la revendication 28, dans laquelle les données MPEG-2 sont transmises dans une trame LLC ayant un DSAP identifiant MPEG-2.
  31. 31. Une méthode telle que revendiquée dans la revendication 28, dans laquelle les données MPEG-2 sont transmises dans un datagramme IPv4 ayant un numéro de protocole de transport identifiant MPEG-2.
  32. 32. Une méthode telle que revendiquée dans la revendication 28, dans laquelle les données MPEG-2 sont transmises dans un datagramme IPv6 ayant un numéro de protocole de transport identifiant MPEG-2.
  33. 33. Une méthode telle que revendiquée dans la revendication 28, dans laquelle les données MPEG-2 sont transmises dans un datagramme UDP transporté dans un datagramme IPv4.
  34. 34. Une méthode telle que revendiquée dans la revendication 28, dans laquelle les données MPEG-2 sont transmises dans un datagramme UDP transporté dans un datagramme IPv6.
  35. 35. Une méthode telle que revendiquée selon l'une
    quelconque des revendications 28 à 34, dans
    laquelle les données MPEG-2 sont transmises à une adresse MAC commune.
  36. 36. Une méthode telle que revendiquée selon l'une quelconque des revendications 31 à 34, dans laquelle les données MPEG-2 sont transmises à une adresse multicast IP.
  37. 37. Une méthode telle que revendiquée dans la revendication 36, dans laquelle la méthode comporte l'étape supplémentaire (e2) de former une correspondance entre un flux élémentaire des données MPEG-2 et l'adresse multicast IP en créant et diffusant ESG en IP et SAP.
  38. 38. Une méthode telle que revendiquée selon l'une quelconque des revendications 28 à 37, dans laquelle la méthode comporte l'étape supplémentaire (e3) de détecter une activité IGMP ou MLD et de déterminer de ce fait s'il faut transmettre des données MPEG-2 aux récepteurs filaires ou radio.
  39. 39. Une méthode telle que revendiquée selon l'une quelconque des revendications 24 à 38, dans laquelle les récepteurs radio comportent des interfaces WiFi ou WiMAX et les récepteurs filaires comportent des interfaces Ethernet.
  40. 40. Une méthode telle que revendiquée selon l'une quelconque des revendications 24 à 39 dans laquelle les données de diffusion vidéo numérique sont DVB-H.
  41. 41. Une méthode pour convertir plusieurs signaux de diffusion vidéo numérique comportant la méthode revendiquée dans n'importe laquelle des revendications 24 à 40, implémentée sur différents signaux de diffusion vidéo numérique.
FR0507549A 2005-07-18 2005-07-18 Systeme et methode pour convertir des donnees de diffusion video numerique Pending FR2888703A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0507549A FR2888703A1 (fr) 2005-07-18 2005-07-18 Systeme et methode pour convertir des donnees de diffusion video numerique
PCT/FR2006/001751 WO2007010130A1 (fr) 2005-07-18 2006-07-18 Systeme et methode pour convertir des donnees de diffusion video numerique
EP06778876A EP1905193A1 (fr) 2005-07-18 2006-07-18 Systeme et methode pour convertir des donnees de diffusion video numerique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0507549A FR2888703A1 (fr) 2005-07-18 2005-07-18 Systeme et methode pour convertir des donnees de diffusion video numerique

Publications (1)

Publication Number Publication Date
FR2888703A1 true FR2888703A1 (fr) 2007-01-19

Family

ID=36498704

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0507549A Pending FR2888703A1 (fr) 2005-07-18 2005-07-18 Systeme et methode pour convertir des donnees de diffusion video numerique

Country Status (3)

Country Link
EP (1) EP1905193A1 (fr)
FR (1) FR2888703A1 (fr)
WO (1) WO2007010130A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2056564A1 (fr) * 2007-10-12 2009-05-06 Thomson Licensing Procédé pour la signalisation d'un identifiant de programme en DVB IP
EP2186218A1 (fr) * 2007-08-21 2010-05-19 Packetvideo Corp. Routeur multimédia mobile, et son procédé d'utilisation
WO2010070349A1 (fr) * 2008-12-17 2010-06-24 Paul Jason Rogers Procédé, système et appareil pour traiter un signal de télévision de diffusion
ITBO20090072A1 (it) * 2009-02-13 2010-08-14 Davide Paselli Registratore/riproduttore di transport streams digitali
EP2408201A4 (fr) * 2009-03-25 2013-06-19 Zte Corp Système et procédé pour partager un programme de diffusion multimédia

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001061988A2 (fr) * 2000-02-15 2001-08-23 Viacast Networks, Inc. Recepteur de donnees multiprotocole conçu pour une connexion entre un satellite et un reseau local
DE10029643A1 (de) * 2000-06-16 2001-12-20 Deutsche Telekom Ag Verfahren zur abhörsicheren Übertragung von IP-Diensten über ein Rundfunkmedium
US20030069930A1 (en) * 2001-10-09 2003-04-10 Engelbertus Van Willigen Service information multicasting method and system
US20050120378A1 (en) * 2001-11-28 2005-06-02 Esa Jalonen Event driven filter monitoring for IP multicast services

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001061988A2 (fr) * 2000-02-15 2001-08-23 Viacast Networks, Inc. Recepteur de donnees multiprotocole conçu pour une connexion entre un satellite et un reseau local
DE10029643A1 (de) * 2000-06-16 2001-12-20 Deutsche Telekom Ag Verfahren zur abhörsicheren Übertragung von IP-Diensten über ein Rundfunkmedium
US20030069930A1 (en) * 2001-10-09 2003-04-10 Engelbertus Van Willigen Service information multicasting method and system
US20050120378A1 (en) * 2001-11-28 2005-06-02 Esa Jalonen Event driven filter monitoring for IP multicast services

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2186218A1 (fr) * 2007-08-21 2010-05-19 Packetvideo Corp. Routeur multimédia mobile, et son procédé d'utilisation
EP2186218A4 (fr) * 2007-08-21 2012-07-11 Packetvideo Corp Routeur multimédia mobile, et son procédé d'utilisation
EP2056564A1 (fr) * 2007-10-12 2009-05-06 Thomson Licensing Procédé pour la signalisation d'un identifiant de programme en DVB IP
WO2010070349A1 (fr) * 2008-12-17 2010-06-24 Paul Jason Rogers Procédé, système et appareil pour traiter un signal de télévision de diffusion
ITBO20090072A1 (it) * 2009-02-13 2010-08-14 Davide Paselli Registratore/riproduttore di transport streams digitali
EP2408201A4 (fr) * 2009-03-25 2013-06-19 Zte Corp Système et procédé pour partager un programme de diffusion multimédia

Also Published As

Publication number Publication date
WO2007010130A1 (fr) 2007-01-25
EP1905193A1 (fr) 2008-04-02

Similar Documents

Publication Publication Date Title
KR100753026B1 (ko) 무선 네트워크에서의 방송 핸드오버
US20070286121A1 (en) Systems and techniques for selective point-to-multipoint retransmission of multicast frames in a wireless network
US8204055B2 (en) Multicast over unicast in a network
US7944922B2 (en) Media distribution in a wireless network
US9264248B2 (en) System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
US20040022222A1 (en) Wireless metropolitan area network system and method
CA2442622A1 (fr) Procede et dispositif de transport de donnees dans un systeme de communication sans fil
JP2007503155A5 (fr)
FR2888703A1 (fr) Systeme et methode pour convertir des donnees de diffusion video numerique
CN101668027B (zh) 多媒体内容的提供方法、系统和客户端
US8655264B2 (en) Communication system, base station device, mobile station device, and communication method
FR2922710A1 (fr) Procede optimise de transmission, vers des terminaux mobiles et via une infrastructure radio a methode d'acces de type tdm/tdma/ofdma, de contenus en couches, et dipositif de traitement associe
FR3039740A1 (fr) Procede de decouverte d'un noeud d'un reseau ad hoc, procede d'echange de donnees, systeme associe
EP1905265A2 (fr) Methode et dispositif pour la transmission de trafic par rafales
KR20050105901A (ko) 무선 통신 시스템에서 방송 서비스 방법 및 시스템
JP2011139500A (ja) 分散制御によるオーバーヘッドメッセージの更新
US10819802B2 (en) Enabling transmission of streaming content using point to multipoint delivery
US20070168549A1 (en) Enhanced digital video broadcast idle mode in wireless communication networks
EP4408036A1 (fr) Procédé de communication de messages entre une pluralité d'équipements d'utilisateur
EP4407908A1 (fr) Procédé de communication de messages entre une pluralité d'équipements d'utilisateur
FR3109852A1 (fr) Procede et dispositif de relai d’un message recu d’un premier dispositif par un deuxieme dispositif nœud vers un troisieme dispositif noeud
EP2208310A1 (fr) Procede, station de base et serveur mbs pour la fourniture dynamique de flux de service a des terminaux connectes a une zone mbs