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

Systeme et methode pour convertir des donnees de diffusion video numerique

Info

Publication number
EP1905193A1
EP1905193A1 EP06778876A EP06778876A EP1905193A1 EP 1905193 A1 EP1905193 A1 EP 1905193A1 EP 06778876 A EP06778876 A EP 06778876A EP 06778876 A EP06778876 A EP 06778876A EP 1905193 A1 EP1905193 A1 EP 1905193A1
Authority
EP
European Patent Office
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.)
Withdrawn
Application number
EP06778876A
Other languages
German (de)
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.)
Oneaccess
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
Publication of EP1905193A1 publication Critical patent/EP1905193A1/fr
Withdrawn 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

Definitions

  • the present invention provides a system and method for converting digital video broadcast data into a form adapted for reception by one or more wired or wireless receivers.
  • the present invention relates to a gateway for routing DVB-H streams to receivers that do not have a DVB-T or DVB-H radio interface, but having a wired (ethernet) or radio (WiFi / WiMAX) interface. ).
  • DVB-H is about to break into the consumer electronics market. While it is envisaged that a large number of people will buy DVB-H phones, a number of owners of laptops (or Laptops), personal digital assistants (PDAs), and cell phones with an assistant Personal digital devices (or smartphones), will also be interested in DVB-H content while not having the necessary hardware to receive a DVB-H signal. However, laptops, PDAs and smartphones typically already have a WiFi or Ethernet interface (and perhaps WiMAX).
  • Ethernet PCs are usually powered by industry.
  • SHEET BE fcEMPLACEmiT (KGLE 26) devices.
  • WiFi laptops are typically battery powered. Therefore, battery energy conservation is to be considered on such devices.
  • WiFi PDAs are predominantly battery powered, so battery power consumption is particularly problematic in such devices.
  • the present invention relates to a gateway providing an interface between the DVB-H and WiFi / WiMAX broadcast transport protocols, it is useful at this level to briefly review the principles of unicast (IP) or multicast (multicast) IP transmission. ) as well as DVB-H and WiFi protocols. Therefore, the context of the invention will be described with reference to the accompanying drawings, in which:
  • Fig. 1 is a block diagram of an unicast (IP unicast) network
  • Fig. 2 is a block diagram of an IP multicast network
  • Fig. 3 is a block diagram of an MPEG-2 multiplexer
  • Fig. 4 is a block diagram of a packet belonging to a Packetised Elementary Stream (PES);
  • PES Packetised Elementary Stream
  • FIG. 5 is a block diagram of the hardware and software components of a DVB-H receiving terminal.
  • a network comprises routers Ri, R2, R3 and R 4 are connected by transmission lines Li, L 2, L 3, L 4 and L 5 and devices (hosts) Di and D2.
  • the device D x is directly connected to the router Ri and the device D 2 is connected to the router R 4 .
  • Each device and router on the network has an IP address, which encodes its network number and host number. IPv4 addresses are four bytes long and IPv6 addresses are sixteen bytes long.
  • a user generates data for transmission over the network.
  • the data is sent to the transport layer, which adds a header (eg, a TCP header) and passes the resulting packet to the network layer.
  • the network layer adds its own header (including the addresses of the source and destination devices) to form a network layer packet (eg an IP packet).
  • the packet is then sent to the data link layer, which adds its own headers and checksum and passes the resulting frame to the physical layer, and the host (eg Di) then transmits the frame to the router on closer (eg Ri).
  • a router Upon receipt of a frame, a router (eg Ri) removes the header and link-layer termination from the frame and passes the packet located in the information part (payload) of the frame to the routing software.
  • the software uses the packet header to choose an output line of the current router to reroute the packet to nearest router (eg R 2 , R3). This process continues while routing the packet across the network until it reaches the required destination.
  • IP diagrams are normally communicated between a single sender and a single recipient. However, for some applications it is useful to be able to send data to a large number of recipients simultaneously. Multicasting allows a source to send a single copy of data using a unique broadcast address to a large group of recipients.
  • a multicast group is identified by a Class D IP address (224.0.0.0 to 239.255.255.255 in IPv4).
  • a source device sends data to a multicast group using the address of that multicast group as the destination address.
  • the multicast data is propagated only to those areas of the network where there are users interested in the relevant multicast groups (i.e. these groups).
  • the source device S sends data to the multicast group of which the devices Di, D 2 and D 3 are members along the routes SD 1 , SD 2 and SD 3 , respectively.
  • the route SDi comprises the routers Ri and R5.
  • the SD 2 route comprises the routers Ri, R2 and R3 and SD 3 route comprises the routers Ri, R2, R 3, R 4, R 7 and Re.
  • the devices D4 and D5 are not members of the multicast group. As a result, these devices do not receive the multicast data from the source device S.
  • a device In order to receive multicast data, a device (eg D 4 ) must join a multicast group by informing the router (s) (eg R 9 ) on its LAN of the multicast group address he wants to join. It is then the responsibility of a router on the LAN to join the multicast group.
  • IGMP Internet Group Management Protocol
  • MLD Multicast Listener Discovery
  • multicast ATM There are three main protocols used to communicate to a router an affiliation to a multicast group, namely Internet Group Management Protocol (IGMP) [used by IPv4 multicast groups], Multicast Listener Discovery (MLD) [used by IPv ⁇ multicast groups] and multicast ATM.
  • IGMP Internet Group Management Protocol
  • MLD Multicast Listener Discovery
  • IGMP provides three specific message structures (namely Query, Report and Leave Group) to allow communication between specialized devices, routers and routers known as "queriers".
  • Query ⁇ ail groups are used by queriers to find out which groups have at least one member on the LAN.
  • a Report message is sent in response to a query message by a receiver that is a member of the relevant multicast group.
  • Leave Group messages are sent by a receiver wishing to leave a given multicast group.
  • a device To join a multicast group, a device must send a Report or join message addressed to the group multicast.
  • a local router detects the Report or join message and uses a multicast routing protocol to join the multicast group.
  • a querier periodically broadcasts a Query message on the LAN and at least one device on the LAN interested in the group responds to the Query message by sending a Report message. If no device on the LAN claims to be affiliated with a group within a specified time interval, the router stops forwarding multicast traffic for that group on the LAN. When no LAN or downstream router directly attached to the router is interested in the multicast group, the router requests its upstream neighbor to stop forwarding multicast traffic to it for the multicast group.
  • a multicast router Once a multicast router knows the affiliations to a group of devices directly connected to it, it exchanges information with other routers to form a multicast tree, in which data sent to a multicast group is forwarded to all branches of the associated tree.
  • the mechanisms for building multicast trees can be broadly classified into membership mechanisms or non-membership mechanisms. Membership mechanisms (which include Protocol Independent Multicast Sparse Mode (PIM-SM)) are based on the assumption that most devices in a network will not want to receive multicast data. As a result, a router must specifically indicate whether it wishes to receive multicast data for a particular multicast group, otherwise the router is not connected to the multicast tree of that group.
  • PIM-SM Protocol Independent Multicast Sparse Mode
  • Non-adherence protocols include Protocol Independent Multicast Dense Mode (PIM-DM) and Distance Vector Multicast Routing Protocol (DVRMP).
  • PIM-DM Protocol Independent Multicast Dense Mode
  • DVRMP Distance Vector Multicast Routing Protocol
  • Digital Video Broadcasting (DVB) protocols are a group of standards developed to transmit digital television.
  • an MPEG-2 encoder 150 multiplexes a number of elementary streams.
  • transport stream 152 a single data stream, known as a "transport stream" 152.
  • the stream 152 data is transmitted to a modulator that delivers a radio signal.
  • a stream transport 152 comprises a succession of 188-byte packets called transport packets 160.
  • Each transport packet 160 has a 4-byte header 162 followed by an adaptation field 164 or an information part (payload) 166 (or both).
  • Header 162 has a number of fields including a byte of synchronization (which allows a decoder to detect the beginning of the transport packet 160) and a packet identifier (PID), the transport floors having the same PID form an elementary stream (Elementary Stream) 154.
  • PID packet identifier
  • a stream transport 152 includes time markers 156 (which allow the synchronization of elementary streams 154 which are decomposed into program specified information (PSI) and service information (SI) 158.
  • PSI program specified information
  • SI service information
  • PSI Program Map Table
  • PAT Program Association Table
  • NIT Network Information Table
  • a PMT provides details about a service and its elementary flows.
  • a PAT provides a list of all available services in a given transport stream. Each service listed in the PAT is accompanied by the PID values of the transport packets that contain its PMT.
  • NIT provides information about the network transporting the transport stream (eg channel frequencies, modulation characteristics, etc.).
  • DVB-SI DVB-SI
  • transport packets which contain, inter alia, technical information for integrated receiver / decoders (IRD) and electronic program guide (EPG) information (eg nature of a program, the timing and the channel on which it is available, etc.).
  • IRD integrated receiver / decoders
  • EPG electronic program guide
  • DVB-SIs include the following tables:
  • Event Information Table (EIT)
  • TDT Time and Date Table
  • An SDT provides user-oriented information about services in a transport stream (eg the name of the service and whether the service is running or not).
  • An EIT provides schedule information for a service and a TDT provides a time reference for the transport stream.
  • An INT signals the availability and location of IP streams in DVB networks. More specifically, an INT provides the mapping table between IP addresses (including IP multicast destination addresses) and items for locating the IP streams sent to these addresses in the DVB streams. These elements include the stream transport identifier, the program number, and the component component identifier ⁇ component tag ⁇ in this program. It should be noted that there may be one or more INTs covering all IP streams for a DVB network.
  • an MPEG-2 multiplexer 150 converts each received elementary stream 154 into a Packetized Elementary Stream (PES) packet stream each of variable length up to one maximum of 64 Kb.
  • PES Packetized Elementary Stream
  • a PES packet 168 includes a payload portion 170 and a header 172.
  • the header 172 contains a number of fields including:
  • stream_ID 176 (b) stream_ID 176 (which distinguishes between PES packets corresponding to different elementary streams);
  • indicator bits 178 which indicate the presence (or absence) of optional fields in the header
  • the MPEG-2 Digital Media Storage and Control provides a mechanism for broadcasting data (as opposed to audio / video signals) into sections of a standard MPEG-2 private table.
  • the Multi-Protocol Encapsulation allows a datagram of any communication protocol to be transmitted in a section of a DSMCC table within a transport stream. This procedure can be used for high-speed Internet data transmissions in which an Internet Protocol (IP) datagram carries information about the logical (IP) address of the source and destination devices as well as possibly the Media Access Control (MAC) address. ) of recipient device.
  • IP Internet Protocol
  • MAC Media Access Control
  • Digital Video Broadcasting Handhelds is specifically designed to facilitate the broadcast of IP to battery-powered handheld devices (eg mobile phones, PDAs, etc.).
  • the main applications of DVB-H will probably be the broadcasting of television to new generation mobile phones, which combine the functions of a TV receiver and a telephone (Nokia CF 7100) or a PDA (DVB-Smartphones). H).
  • a pocket television device has a significantly smaller antenna than a conventional television.
  • pocket television devices must be able to receive a television signal in virtually any location, the signal transmission system must be effective under varying reception conditions.
  • DVB-H the power consumption of the DVB-T is too high for the batteries of handheld television devices.
  • DVB-H One of the main developments in DVB-H is the division of time. The key to splitting time is the observation that, if the receiver could be off while a service is not being transmitted, the receiver's battery power could be saved. Therefore, as opposed to the continuous data transmission mechanism provided by the DVB-T, the time division mechanism allows data transmission (MPE / IP) in high bandwidth burst which can last from a few milliseconds to a few seconds.
  • the bursts of DVB-H data are transmitted at the speed of the radio channel (D) (ie 10 to 20 Mbs) and are repeated periodically (the period (P) being several seconds), the radio receiver being in sleep mode during burst intervals.
  • D the speed of the radio channel
  • P the period
  • a pocket receiver will receive data at an average rate of 10 Mbs * 0.1 / 2, or 500 Kbs.
  • the receiver can switch its radio circuitry to sleep mode for (2 - 0.1) / 2 or 95% of the time, resulting in savings of up to 90% of the battery power of the pocket receiver.
  • the time division technique can increase the time interval between recharging the receiver batteries by tens of minutes (with a reception continuous data at 500 Kbs) at several hours.
  • DVB-H Due to the screen size, resolution and storage requirements of a DVB-H receiver, it is enough to feed it with data streams at a rate of a few hundred kilobits per second. Moreover, since the DVB radio channels are transmitted at rates of 10 to 20 Mbps, the DVB-H data streams are typically transmitted in time slicing mode.
  • IP streams Before data can be transmitted using DVB-H, IP streams must be transformed into DVB-H through an IP Encapsulator (IPE).
  • IPE IP Encapsulator
  • a DVB-H IPE calculates a self-correcting code (Reed Solomon) at the MPE level which improves the quality of the reception of the signal by the single antenna of a pocket receiver and possibly encrypts content at the IP level which ensures a good level of confidentiality.
  • the hardware components of a DVB-H receiver 208 include an antenna 210 and three functional blocks, namely an RF block 212, a baseband block 214, and a physical connector at the terminal 216.
  • the central component of the DVB-H receiver software 217 is an Electronic Service Guide Server (ESG-S) 218.
  • the receiver software 217 also includes players 220 (eg Mediaplayer (trademark) and Realplayer (trademark )) and a cache system 222.
  • ESG-S Electronic Service Guide Server
  • the receiver software 217 also includes players 220 (eg Mediaplayer (trademark) and Realplayer (trademark )) and a cache system 222.
  • the DVB-PSI / SI tables provide the necessary information to retrieve and receive each available IP data broadcast service (identifiable by its IP address).
  • the information provided by the DVB-PSI / SI includes the transport ID stream and the associated frequency and modulation, program number, component identifier (component tag) and PID.
  • the user can select a specific service using I 1 ESG server 218, in which case the DVB-H receiver tunes the RF block 212 to the relevant frequency and processes the corresponding MPEG-2 frames. the required PIDs.
  • WiFi is a common name for IEEE 802.11 standards for wireless LANs.
  • An 802.11 LAN is based on a Base Service Station (BSS) cellular architecture in which a BBS includes at least two computers communicating with each other, in which each of the computers contains a Networking Interface (NIC) card.
  • BBS Base Service Station
  • NIC Networking Interface
  • 802.11 LANs can be classified as "ad-hoc" or "infrastructure".
  • the stations communicate directly with each other in a peer-to-peer manner without involving a central access point. Since there is no relay function in the network, all stations must be within range of one another. Therefore, an ad hoc network typically has a small number of devices close to each other.
  • the stations communicate with each other through an access point (AP) in which the The access point acts as an arbiter for the network, determining if, and when, each station can transmit.
  • AP access point
  • the 802.11 protocol addresses two distinct layers of the wireless network model, namely the Media Access Layer (MAC) and the physical layer.
  • the MAC defines two access methods, namely the Distributed Co-ordination Function (DCF) and the Point Co-ordination Function (PCF) and a number of functions including scanning, association, fragmentation and economy. of energy to collectively manage the communication between stations.
  • DCF Distributed Co-ordination Function
  • PCF Point Co-ordination Function
  • PCF Distributed Co-ordination Function
  • DCF does not employ a central control mechanism and is essentially a Carrier Sensé Multiple Access with Collision Avoidance (CSMA / CA) mechanism.
  • CSMA Carrier Sensé Multiple Access with Collision Avoidance
  • CA Carrier Sensé Multiple Access with Collision Avoidance
  • the CSMA is a contention-based protocol, which ensures that all stations "listening" to the radio channel before transmitting transmit only when the radio channel is free and thus do not transmit messages at the same time.
  • the DCF defines a virtual carrier sensing mechanism, in which a station wanting to transmit data first transmits a control packet known as the "Request To Send" (RTS) packet.
  • RTS Request To Send
  • the destination station responds with a control packet known as the "Clear To Send” (CTS) packet.
  • CTS Call To Send
  • All stations (other than the source and destination) receiving either the CTS packet or the RTS packet set an internal counter known as “Network Allocation Vector” (NAV) over the duration of the transmission and cease transmitting on the until the transmission to the destination is complete.
  • NAV Network Allocation Vector
  • PCF Point Co-ordination Function
  • the PCF performs data delivery according to a schedule in which an access point grants the station access to the radio channel by polling the station during the contention free period. Since the transmission permission is completely controlled by the Access Point, there is never a collision.
  • Scanning refers to the process by which the NIC searches for an Access Point.
  • the scanning is based on the detection of a signal (or beacon frame) broadcast periodically by an access point.
  • the tag frames contain the following information:
  • beacon interval ie the amount of time between beacon transmissions
  • time marker
  • SSID Service Set Identifier
  • Traffic Indication Map (d) Traffic Indication Map (TIM) (identifies which stations operating in power-saving mode have unicast data waiting for them in the Access Point buffer and if there is broadcast and multicast traffic that wait too).
  • a station waits to receive a beacon frame from an Access Point.
  • a station locates an Access Point by transmitting a survey request (hair) frame and waits for a survey response from all access points within its reach. .
  • the station receives beacon / survey responses, the data contained within each beacon / survey response allows the station to order the detected Access Points using attributes present in the beacon, such as the signal strength received.
  • a station Once a station has identified a Preferred Access Point, its NIC must associate (or establish a logical connection) with the Access Point. The association allows the access point to allocate resources for a NIC, and to synchronize on it. In use, the station sends an association request frame to the preferred access point.
  • the association request frame carries information about the NIC and the SSID of the network to which it wishes to associate.
  • the Preferred Access Point Upon receipt of the association request frame, the Preferred Access Point will consider whether to associate with the NIC and, if it accepts the association request, the Preferred Access Point reserves the memory space and assigns an Association ID (AID) to the station's NIC.
  • AID Association ID
  • the station's NIC is able to send data frames to the access point.
  • the NIC continues to scan for other beacons from the access point to detect if the signal from the access point has become too weak to maintain communications.
  • the NIC also uses the time tag of tag frames to update its local clock and thereby maintain synchronization on the access point and other stations.
  • the 802.11 standard includes a mechanism for fragmentation and re-assembly, which allows frames to be fragmented into larger pieces. each having his own checksum. Once a channel has been acquired, multiple fragments are sent consecutively in a sequence known as a "burst of fragments".
  • the 802.11 standard power saving feature allows a NIC to conserve battery power by switching from operational mode to sleep mode when there is no need to send or receive data.
  • the NIC wakes up periodically to receive beacon transmissions from an Access Point.
  • the TIM parameter informs the NIC of the presence of pending data concerning it in the Access Point and whether there are broadcast or multicast frames in waiting.
  • the NIC learns if unicast traffic is waiting for it by looking at the entry corresponding to its AID in the Traffic Indicator Map. In this case, the card sends a polling message (a PS-POLL frame) to the access point to retrieve messages queued, the NIC remains awake until the messages are transferred to it and then returns sleep mode.
  • a polling message (a PS-POLL frame)
  • the access point When at least one associated receiver is in power saving mode the access point also stores multicast and broadcast frames until the next DTIM beacon frame. At the next DTIM beacon, the access point announces that it is storing multicast and broadcast traffic using the first bit of the TIM MAP (AID 0).
  • the access point transmits the multicast and broadcast traffic.
  • a receiver may know that there is pending multicast traffic, without knowing if this traffic is for a multicast group of interest.
  • the transmission of multicast traffic is not secured by a PSPOLL / ACK mechanism.
  • the present invention provides a system and method for converting digital video broadcast data into a form adapted for reception by one or more wired or wireless receivers.
  • the present invention relates to a gateway for dynamically routing DVB-H streams of interest to receivers having no DVB-T nor DVB-H radio interfaces, but having an interface wired (Ethernet) or radio (WiFi / WiMAX).
  • the present invention uses the DVB-H time division function and the 802.11 standard energy saving function to route the DVB-H streams to the receiver of a receiver. way that minimizes its battery power consumption while ensuring reliable data transfer.
  • the present invention is directed to the system and method as defined in the independent claims to provide a DVB-H / Ethernet or WiFi / WiMAX gateway. Additional embodiments of the invention are provided in the dependent claims in the annex.
  • Figure 6 is a block diagram of the hardware architecture of the system of the present invention, in use, the system not being connected to a client
  • Fig. 7 is a block diagram of the data streams in the system of the present invention when operating in a DVB-H to WiFi / WiMAX gateway mode or
  • the system for converting digital video broadcast data to a form suitable for reception by one or more wired or wireless receivers will be known from now on as a gateway.
  • the gateway 300 includes an antenna 302, a processor 304, a random access memory 306, a LAN interface 308, a flash memory or CF 310 and / or a disk 312.
  • the gateway 300 has a number of operational modes including: (a) DVB-H gateway mode to WiFi / WiMAX or basic Ethernet;
  • gateway mode for relaying multiple MPEG-2 elementary streams.
  • DVB-H gateway mode to WiFi / WiMAX or Ethernet
  • the gateway 300 receives subscription requests to a multicast group (i.e., IGMP / MLD messages) 314 through the LAN interface 308 from one or more devices LAN clients 316. Having established the affiliation with a multicast group of LAN client devices 316, the gateway 300 scans the RF spectrum for any available DVB-H channels (or tunes to a pre-selected DVB-H channel).
  • a multicast group i.e., IGMP / MLD messages
  • the gateway 300 When detecting and tuning to a DVB-H channel, the gateway 300 identifies the signaling tables PSI / SI (NIT, INT, PAT, PMT, etc.) in the DVB-H stream of the channel. The gateway 300 uses the information contained in the PSI / SI signaling tables to determine whether the received DVB-H channel contains a transmission relating to one of the multicast groups identified by the LAN client devices 316.
  • PSI / SI NIT, INT, PAT, PMT, etc.
  • the gateway 300 uses the PSI / SI signaling tables from the channel to allow the extraction of specific IP datagrams from MPE sections of the channel MPEG-2 transport stream. Therefore, gateway 300 behaves like a traditional dynamic multicast router. However, instead of determining the affiliation and structure of a multicast tree through conventional PIM-DM or DVRMP mechanisms, the gateway 300 employs standard DVB-H signaling and data extraction mechanisms to decode the data. PSI / SI tables from a received DVB-H transmission and thereby route the IP datagrams contained therein to members of appropriate multicast groups.
  • 802.11 LANs can be classified as “ad hoc" or "infrastructure".
  • the gateway 300 routes IP datagrams extracted from a DVB-H stream to an ad hoc 802.11 LAN, the IP datagrams are routed according to the 802.11 protocol.
  • the gateway 300 may behave either as a client of an access point or as an access point.
  • the gateway 300 accomplishes the normal functionality of an 802.11 access point and, in particular, implements the 802.11 energy saving beacon frame transmission operations.
  • the multicast stream transmission to 802.11 LANs in infrastructure mode is particularly inefficient to both maintain the quality of the data transfers and the conservation of the battery energy of the receiving devices.
  • the presence of multicast traffic is announced globally at each DTIM interval by the AIDO of the TIM. Due to burst transmission, the multicast traffic for a given group is present only at all N DTIM intervals. Under these conditions, a receiver interested in only one multicast group will be woken up at each DTIM interval and will have to decode the traffic of all the P multicast groups while only one is interested to discover only once on N that there is interesting traffic for him.
  • association ID 802.11
  • NIC Network Controller
  • AID Association ID 802.11
  • the extension of the 802.11 Association ID (AID) to a multicast group also allows the transmission of data on one channel to all members of relevant multicast groups on the LAN, upon receipt of a PS_POLL request from one of the LAN client devices 316 (eg the LAN client device 316 that transmitted the IGMP Report message for the multicast group).
  • This process allows the battery power consumption of individual LAN client devices 316 during data transmission in multiple multicast groups to be significantly reduced, since a LAN client device 316 will have the ability to tune to a multicast channel only at times where there is multicast traffic that interests him. Similarly, the quality of data transfer can be improved since the transfers will be made reliable by one of the receivers who will be responsible for claiming each multicast frame and confirming that it has been well received.
  • the above mechanism for multicast traffic transmission and signaling can also be applied to traditional access points that do not have a DVB-H relaying function.
  • the gateway 300 can also perform the traditional functions of an IGMP / MLD querier, namely the continuous verification of multicast group affiliation of its wired or wireless LAN client devices 316.
  • the gateway 300 extracts the IP datagrams from the DVB-H streams and transmits them to the receivers whether the IP streams are encrypted or not. However, when these streams are encrypted at IP (IPSEC) level or for any other technique, such as OMA DRM,. the gateway 300 has a user-selectable option enabling it to acquire the information for decrypting the streams to transmit them in clear to the appropriate LAN client devices concerned.
  • IP IP
  • OMA DRM OMA DRM
  • a gateway when operating in the DVB-H mode to WiFi / WiMAX or Basic Ethernet, a gateway receives DVB-H data and extracts IP datagrams corresponding to the multicast streams requested by the receivers.
  • the gateway 300 dynamically routes these datagrams on the ethernet or WiFi / WiMAX LANs.
  • the gateway 300 also has an MPEG-2 relay mode in which it selectively and dynamically relays the MPE.G-2 elementary streams contained in a received DVB-H signal.
  • the main purpose of this procedure is to provide LAN client devices with access to, and use of, all the information transported by the transport MPEG-2 streams (and in particular the signaling information contained therein), while at the same time avoiding the occupation of LAN bandwidth by elementary streams present in the transport stream and not required on the LANs.
  • DVB network_id (original network ID), transport_stream_id r packet identifier (PID).
  • MPEG-2 packets that make up an elementary stream are transported to LAN clients in one of the following ways:
  • UDP User Datagram Protocol
  • All MPEG-2 packets from a given MPEG-2 elementary stream are transported to a common multicast MAC address. However, these MPEG-2 packets are also transported to a common IP multicast address when they are transmitted:
  • the correspondence between the elementary stream identifier and the multicast IP address is obtained either by calculation (eg in IPv ⁇ datagrams on calculation may consist in concatenating to a multicast prefix the values of the DVB variables identifying the elementary stream).
  • the address space comprises 32 bits of which 28 bits are available to distinguish between different multicast addresses (class D traffic).
  • An example of implementation correspondence between an elementary stream identifier and the IPv4 multicast address used to carry it could be: 2 bits (DN) to identify the DVB network, 13 bits (TS) to identify the transport stream and 13 bits (PID) to identify the packet identifier.
  • the DN bits could be obtained from the last two bits of I 1 DVB network ID.
  • the TS bit could be obtained from the last 13 bits (among the 16 possible bits) of I 1 DVB transport stream ID.
  • the PID could be obtained from the 13-bit packet identifier.
  • ESG Electronic Service Guide
  • SAP Session Announcement Protocol
  • the gateway 300 associates an IP address with each MPEG-2 elementary stream.
  • the gateway 300 takes into account the IGMP or MLD activity on a LAN to decide whether it transmits MPEG-2 transport streams or prevents the transmission of MPEG-2 transport streams on the LAN. This ensures that only the elementary streams actually required on the LAN are relayed and that the LAN bandwidth is not wasted by transporting MPEG-2 elementary streams that would not be used by the LAN client devices.
  • a port number is used which is either a well-known fixed number or is derived from the PID parameter from the DVB-H stream (eg by adding a constant to the PLD which constant is known to the receivers and gateway 300).
  • a multicast IP address is always associated with each elementary stream of each transport stream.
  • the multicast address (MIPES) is used to indicate an interest for a given elementary stream using the IGMP / MLD protocol.
  • the multicast address is also used to encapsulate the elementary flow data in the case of encapsulation c, d, e and f.
  • the elementary stream data is transported using a destination MAC address derived from the MIPES as described in RFC1469 for IPv4 and in RFC2464 for IPv6.
  • MPEG-2 relay mode can be implemented for all MPEG-2 elementary streams, including those containing MPE sections, or those carrying only signaling tables.
  • the gateway 300 has a single DVB-T / S interface and can decode only a single radio channel. Therefore, a gateway 300 can decode a single transport stream MPEG-2 unique at a given moment (ie all of the elementary streams included in this MPEG-2 transport stream). In order to satisfy LAN requests for data from different MPEG-2 transport streams, it is possible to install multiple gateways on the LAN.
  • the IP multicast protocol A allows a gateway to periodically advertise on the LAN its own identifier and its own unicast IP address, as well as the identifier of the MPEG-2 transport stream that the gateway is decoding. Each gateway will therefore be aware of the MPEG-2 transport streams being processed by the other gateways and a given gateway will decode a given MPEG-2 stream transport only if no other gateway already does. In the case of a request from a LAN client device for data contained in an MPEG-2 stream transport that has not yet been decoded by a gateway, an unoccupied gateway will advertise on the LAN (through a message in protocol A) that it will decode the relevant MPEG-2 stream transport.
  • the gateway with the smallest IP address will decode the MPEG-2 stream transport. .
  • the relevant gateway continues to announce that it is decoding the MPEG-2 stream transport and routes the streams of the MPEG-2 stream transport to the appropriate LAN client multicast group members.
  • the gateway announces on the LAN that it will stop decoding the transport stream. The gateway then becomes available to decode other transport MPEG-2 streams when needed.
  • DVB-H The mechanism described here for DVB-H is also applicable to DVB-T, DVB-S or DVB-C, which differs only in their physical interface.

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; et un moyen pour transmettre de façon dynamique les flux élémentaires extraits aux récepteurs filaires ou radio.

Description

Système et méthode pour convertir des données de diffusion vidéo numérique
Domaine de 1 ' 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 (WiFi/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 DVB-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
FEUILLE BE fcEMPLACEmiT (KGLE 26) 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 matériels et logiciels d'un terminal récepteur DVB-H.
1. MECANISMES DE TRANSMISSION IP (a) Monodiffusion IP junicast)
En se référant à la figure 1, un réseau comporte des routeurs Ri, R2, R3 et R4 connectés par des lignes de transmission Li, L2, L3, L4 et L5 et des dispositifs (hôtes) Di et D2. Le dispositif Dx 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. Di) transmet alors la trame au routeur le plus proche (par ex. Ri) .
A réception d'une trame, un routeur (par ex. Ri) enlève 1 ' 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-tête 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 Di, D2 et D3 le long des routes SDi, SD2 et SD3, respectivement. La route SDi comporte les routeurs Ri et R5. La route SD2 comporte les routeurs Ri, R2 et R3 et la route SD3 comporte les routeurs Ri, R2, R3, R4, R7 et Re. 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 groupe multicast. Il existe trois principaux protocoles utilisés pour communiquer à un routeur une affiliation à un groupe multicast, à savoir Internet Group Management Protocol (IGMP) [utilisé par les groupes multicast IPv4], Multicast Listener Discovery (MLD) [utilisé par les groupes multicast IPvβ] 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 join adressé au groupe multicast. Un routeur local détecte le message Report ou join 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 (DVRMP) .
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 certain 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 transport stream 152 sont transmises à un modulateur qui délivre un signal radio.
Un transport stream 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 spécifie information (PSI) et service information (SI) 158. Les tables Program Spécifie
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 suivantes :
une Service Description Table (SDT) ;
une Event Information Table (EIT) ;
une Time and Date Table (TDT) ; et
- une IP/MAC 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. Il 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 en-tê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 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 Storage 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 10 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 consommation d'énergie globale d'un récepteur, la technique de découpage du temps peut augmenter 1 ' 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-H 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 DVB-SI 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 DVB- PSI/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 I1ESG- server 218, dans ce cas le récepteur DVB-H syntonise le bloc-RF 212 sur la fréquence pertinente et traite les 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 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-ordînation 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 Co-ordination Function (PCF)
La DCF n'emploie pas de mécanisme de contrôle central et est essentiellement un mécanisme de Carrier Sensé 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 (poil) 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 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, le point 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 1 ' 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 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 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é) .
Lors de la détection et de la syntonisation à un canal DVB- H, 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 canal 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 1' 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 MPE.G-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_idr 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 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 IPvβ ayant un numéro de protocole de transport identifiant MPEG-2 ;
(e) dans un datagramme User Datagram Protocol (UDP) transporté dans un datagramme IPv4 ; ou
(f) dans un datagramme UDP transporté dans un datagramme 2
I Pvβ .
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 de transport identifiant MPEG-2 ;
(b) dans un datagramme IPvβ 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 IPvβ.
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 IPvβ 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 IPv4 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 I1ID 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 I1ID 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 par 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 PlD, 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

REVENDICATIONS
1. Un système destiné à convertir des données de diffusion vidéo numérique en une forme adaptée a 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. 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 les flux élémentaires extraits aux récepteurs filaires ou radio comporte un moyen pour transmettre les datagrammes IP extraits.
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. 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. 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 notification IP/MAC.
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 multîcast des récepteurs filaires ou radio.
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 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. 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. Un système tel que revendiqué dans la revendication 8, dans lequel les données MPEG-2 comportent des paramètres de signalisation MPEG-2.
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. 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. 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. 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 IPvβ ayant un numéro de protocole de transport identifiant MPEG-2.
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 IPv4.
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 IPvβ.
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. 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. 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. 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. 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. 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. 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. 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 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. 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) réception le signal de diffusion vidéo 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. 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. 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. 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 :
(d3) 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. Une méthode telle que revendiquée selon l'une quelconque des revendications 24 à 27, dans laquelle la méthode comporte de plus l'étape (el) de transmission des données MPEG-2 aux récepteurs filaires ou radio.
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. 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. 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. Une méthode telle que revendiquée dans la revendication 28, dans laquelle les données MPEG-2 sont transmises dans un datagramme IPvβ ayant un numéro de protocole de transport identifiant MPEG-2.
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. 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 IPvβ.
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. 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. 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. Une méthode telle que revendiquée selon l'une quelconque des revendications 28 à 37, dans laquelle la méthode comporte 1 ' é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. 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. 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. 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 .
EP06778876A 2005-07-18 2006-07-18 Systeme et methode pour convertir des donnees de diffusion video numerique Withdrawn EP1905193A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP1905193A1 true EP1905193A1 (fr) 2008-04-02

Family

ID=36498704

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06778876A Withdrawn EP1905193A1 (fr) 2005-07-18 2006-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)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009025747A1 (fr) * 2007-08-21 2009-02-26 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
GB2466259A (en) * 2008-12-17 2010-06-23 Paul Jason Rogers System for use in the home to convert a digital TV signal into IP data packets for transmission to IP devices or a home IP network
IT1399303B1 (it) * 2009-02-13 2013-04-16 Paselli Registratore/riproduttore di transport streams digitali
CN101848201B (zh) * 2009-03-25 2014-06-11 中兴通讯股份有限公司 一种共享多媒体广播节目的系统及方法

Family Cites Families (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
WO2003032576A1 (fr) * 2001-10-09 2003-04-17 Koninklijke Philips Electronics N.V. Procede et systeme relatifs une multi-diffusion d'informations de services
US7512084B2 (en) * 2001-11-28 2009-03-31 Nokia Corporation Event driven filter monitoring for IP multicast services

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007010130A1 *

Also Published As

Publication number Publication date
FR2888703A1 (fr) 2007-01-19
WO2007010130A1 (fr) 2007-01-25

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
US8787366B2 (en) Community driven program access system and method
EP1516456B1 (fr) Filtrage de recherche d'identificateur de paquets
CA2442622A1 (fr) Procede et dispositif de transport de donnees dans un systeme de communication sans fil
KR20040012435A (ko) 무선 도시권 통신망 시스템 및 방법
JP2007503155A5 (fr)
TW200818777A (en) Standby time improvements using sub-networks
CN1822545A (zh) 控制前端系统与多个客户系统之间的通信的方法
WO2008130772A1 (fr) Procédé et appareil d'identification de service dans un système de communication sans fil
TW200810420A (en) System and method for acquisition and delivery of services to devices in a wireless multicast communication system
EP1905193A1 (fr) Systeme et methode pour convertir des donnees de diffusion video numerique
US20100085922A1 (en) System and method for improving bandwidth of wireless local area network
US7653019B2 (en) Method of distributing identical data to mobile units
CN101668027B (zh) 多媒体内容的提供方法、系统和客户端
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
EP1905265A2 (fr) Methode et dispositif pour la transmission de trafic par rafales
EP4408036A1 (fr) Procédé de communication de messages entre une pluralité d'équipements d'utilisateur
US20070168549A1 (en) Enhanced digital video broadcast idle mode in wireless communication networks
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

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20071205

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ONEACCESS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20131125

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140408