WO2009095079A1

WO2009095079A1 - Method and apparatus for distributing media over a communications network

Info

Publication number: WO2009095079A1
Application number: PCT/EP2008/051181
Authority: WO
Inventors: Robert Skog; Andreas Ljunggren
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2008-01-31
Filing date: 2008-01-31
Publication date: 2009-08-06
Also published as: GB2469949A; GB201012160D0

Abstract

A method and apparatus for distributing media over a P2P IPTV network is described. Media frames of a subscribed media channel are received at a peer node in the network. Meta data is sent from selected other peer nodes in the network to the peer node. The meta data includes media channel subscription information of the selected other peer nodes. When user instructions are received to change the subscribed media channel to a new channel, the meta data is used to determine whether any of the selected other peer nodes are subscribed to the new channel. If one of the selected other peer nodes is subscribed to the new channel, frames of the new channel are requested from that peer node.

Description

Method and Apparatus for Distributing Media over a Communications Network

TECHNICAL FIELD

The invention relates to the field of distributing media over a communications network, and in particular to distribution of IPTV using a Peer to Peer communications network.

BACKGROUND

TV services broadcast over an IP network are referred to as IPTV. IPTV is typically broadcast using a broadband access network, in which channels are transmitted over a broadband network from a super head-end down to an end-user's set top box (STB).

Linear content delivery, in which all channels in a subscription are simultaneously delivered to a user's set top box (STB), is not suitable for IPTV, as IPTV has limited bandwidth available over a broadband connection. A typical ADSL broadband connection provides a capacity of between 3 and 8 Mbps, and ADSL2 promises to deliver up to 25 Mbps downstream, whereas VDSL can provide a capacity of greater than 30 Mbps. Standard quality MPEG 2 IPTV content requires 2 Mbps per channel, and HDTV will require around 8-10 Mbps per channel. The MPEG 4 standard will approximately halve the bandwidth required to deliver IPTV content with the same quality. Nevertheless, the available bandwidth is a scarce resource, and IPTV solutions must limit the number of channels that can be delivered simultaneously.

Figure 1 illustrates a known way of distributing media in which an IPTV media stream originates in a service provider network 1 , is passed to a core network 2, is further passed into a metro network 3, and finally is sent via access networks 4 to each home network 5 that contains an STB that wishes to receive the media stream. Networks can quickly become saturated due to heavy traffic loads. In order to mitigate this problem, content can be multicast to reduce bandwidth demands for broadcast TV distribution. Furthermore, Video on Demand (VoD) services can be handled by VoD cache servers located close to the end-user. However, such caches require additional investment, and many routers would need to be replaced, as existing routers may not support IPTV multicasts. It is known to distribute an IPTV service using a Peer to Peer (P2P) network, as illustrated in Figure 2. Each STB is a peer in the network. An IPTV media stream can be delivered to a STB from another STB, from a media injector from which the stream originates, or from any other peer in the network.

The IPTV P2P requires a media injector in order to introduce the IPTV media stream into the network, although the media injector is not a true peer in the network in the sense that it only sends data but does not receive data from the peers. This is illustrated in Figure 3, which is a schematic representation of a simple IPTV P2P network 1. The network 1 includes an IPTV back-end 6 and two STBs STB1 and STB2. Each STB includes a P2P network interface 12, 13 to which is connected a video decoder 9, 11. In this example, STB1 receives the IPTV media stream from both STB2 and the IPTV back-end 6, which injects either streaming content or content from a database 7 using a P2P media injector 8. Note that other network nodes (in addition to nodes in STBs) may be peers in the network.

Note that the term "IPTV media stream" is used herein to refer to any kind of data having real time requirements, and includes Video on Demand, user generated TV content, interactive TV, interactive or co-operative games, or audio media. The media stream is to be delivered to the user such that the user can observe the media content at a constant rate without interruptions or delays. There is some latency in the P2P network, caused by buffers in each STB and the time it takes to establish communication between peers.

Compressed video media generally consists of a series of frames containing the information to be displayed on a user's screen. Each frame can be considered as a "picture" displayed on the screen. In most video compression formats, such as in ITU- T VCEG or ISO/IEC MPEG video standards, only the differences between successive pictures are usually encoded. For example, in a scene in which a person walks past a stationary background, only the moving portions of the picture are represented in each frame (either using motion compensation or as image data or as a combination of the two, depending on which representation requires fewer bits to adequately represent the picture). The parts of the scene that are not changing do not need to be sent repeatedly. However, it is still necessary for compressed media data to include some frames containing "complete" pictures, i.e. pictures encoded without reference to any pictures except themselves. These are included periodically in the media stream. Such frames are known as "l-frames" ("intra-frames")or "key frames".

For example, MPEG media streams contain different frames, such as l-frames, P- frames and B-frames. l-frames do not depend on data contained in the preceding or following frames, as they contain a complete picture. P-frames provide more compression than l-frames because they utilize data contained in the previous l-frame or P-frame. When generating a P-frame, the preceding frame is reconstructed and altered according to incremental extrapolation information. B-frames are similar to P- frames, except that B-frames interpolate data contained in the following frame as well as the preceding frame. As a result, B-frames usually provide more compression than P-frames. In some systems, every 15th frame or so is an l-frame. P-frames and B- frames might follow an l-frame as follows: IBBPBBPBBPBB(I). The order and number of frames in the sequence can be varied.

The media stream includes payload data and metadata. The payload data is the media data itself, and is decoded and shown by the receiver. Payload data typically comprises frames as described above. The metadata includes all other data in the media stream. This may be, for example, data describing the payload data, or information establishing signalling between two peers. In order to facilitate handling of the media stream, the media stream is sent in "fragments". Fragments are discrete portions of the media stream containing both the payload data and the metadata. It will be appreciated that a frame and a fragment do not necessarily correspond to each other directly: a single frame may be encoded into many fragments or (in some cases) a single fragment may contain more than one frame.

When an end user of a linear broadcast system wishes to change channel (e.g. from channel X to channel Y), his STB will generally transmit a request to an STB manager in the IPTV back-end. The STB manager knows which other peers (other STBs) are currently subscribed to the new channel (channel Y) and returns a list of suitable peers from which the STB can obtain fragments containing channel Y frames. The suitable peers should be those near to the requesting STB. The STB then sends a request to one or more of these nearby peers to obtain channel Y. When changing channel, it is desirable for this to be carried out as quickly as possible. However, the signalling between the STB and the STB manager takes time, and this introduces a delay to the channel change viewed by the user.

There is thus a need for a system enabling a faster change of channel for a user.

SUMMARY

In accordance with a first aspect of the present invention there is provided a peer node for use in a P2P network, preferably an IPTV P2P network. The peer node comprises a receiver arranged to receive media frames of a subscribed media channel and to receive meta data from selected other peer nodes in the network. The meta data includes media channel subscription information from the selected other peer nodes. A storage medium is operatively connected to the receiver and arranged to store the meta data. A controller is operatively connected to the receiver and storage medium and arranged to receive user instructions to change the subscribed media channel to a new channel and, in response, to interrogate the meta data and determine whether any of the selected other peer nodes are subscribed to the new channel. A transmitter is operatively connected to the controller and arranged so that, if one of the selected other peer nodes is subscribed to the new channel, the transmitter requests frames of the new channel from said one of the selected other peer nodes subscribed to the new channel.

In other words, the peer node can subscribe to meta data from other peer nodes in the network. This meta data includes channel subscription information for the other peer nodes. When the user wishes to change channel, the peer node can determine, from this meta data, which of the other nodes is subscribed to the new channel, and receive media frames from that node. This means that there is no requirement to obtain a peer list from an STB manager before changing channel, thus speeding up the channel changing process.

Preferably, updates to the meta data from the selected other peer nodes are automatically received periodically. This ensures that the peer node always has an accurate snapshot of the channels subscribed to by other peer nodes. The other peer nodes may be neighbours of the peer node (e.g. other nodes in the same building or street). Preferably, the peer node itself sends information confirming its own channel subscription to other nodes in the network.

In accordance with a second aspect of the present invention there is provided a peer node for use in a Peer-to-Peer network. The node comprises a receiver arranged to receive media frames of a subscribed media channel. A controller is operatively connected to the receiver and arranged to generate meta data identifying that the peer node is subscribed to the media channel. A transmitter operatively connected to the controller and arranged to transmit the meta data to other peer nodes in the network.

In accordance with a third aspect of the present invention there is provided a method for receiving media at a first peer node in a P2P network. The method comprises receiving media frames of a subscribed media channel. Meta data is periodically received from selected other peer nodes in the network, the meta data including media channel subscription information of the selected other peer nodes. When user instructions are received at the first peer node to change the subscribed media channel to a new channel, it is determined from the meta data whether any of the selected other peer nodes are subscribed to the new channel. If one of the selected other peer nodes is subscribed to the new channel, frames of the new channel are requested from said one of the selected other peer nodes subscribed to the new channel.

In accordance with a fourth aspect of the present invention there is provided a method for distributing media in a P2P network. The method comprises, at a first peer node in the network, receiving media frames of a subscribed media channel. Meta data is periodically sent from selected other peer nodes in the network to the first peer node, the meta data including media channel subscription information of the selected other peer nodes. When user instructions are received at the first peer node to change the subscribed media channel to a new channel, it is determined from the meta data whether any of the selected other peer nodes are subscribed to the new channel. If one of the selected other peer nodes is subscribed to the new channel, frames of the new channel are requested from said one of the selected other peer nodes subscribed to the new channel. According to a fifth aspect of the present invention, there is provided a program for controlling an apparatus to perform a method according to the third or fourth aspect of the present invention.

The program may be carried on a carrier medium, which may be a storage medium or a transmission medium.

According to a sixth aspect of the present invention, there is provided an apparatus programmed by a program according to the fifth aspect of the present invention.

According to an seventh aspect of the present invention, there is provided a storage medium containing a program according to the fifth aspect of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates schematically in a block diagram an architecture for the distribution of IPTV; Figure 2 illustrates schematically in a block diagram an architecture for the distribution of IPTV in a peer to peer network;

Figure 3 illustrates schematically in a block diagram a media injector and two Set Top

Boxes;

Figure 4 illustrates schematically in a block diagram the signalling required to initiate an IPTV broadcast with a first Set Top Box;

Figure 5 illustrates schematically in a block diagram the signalling required to initiate an

IPTV broadcast with a further Set Top Box;

Figure 6 illustrates schematically in a block diagram keep alive messages sent by a Set

Top Box; Figure 7 illustrates schematically some components of an IPTV network showing the delivery of meta data containing channel subscription information to a STB;

Figure 8 illustrates the components of Figure 7 following a channel change request from a user;

Figure 9 is a schematic block diagram of a STB; and Figure 10 is a flow diagram illustrating the actions taken by a STB following a channel switch. DETAILED DESCRIPTION

The following description sets forth specific details, such as particular embodiments, procedures, techniques, etc. for purposes of explanation and not limitation. In some instances, detailed descriptions of well known methods, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail.

Moreover, individual blocks are shown in some of the drawings. It will be appreciated that the functions of those blocks may be implemented using individual hardware circuits, using software programs and data, in conjunction with a suitably programmed digital microprocessor or general purpose computer, using application specific integrated circuitry, and/or using one or more digital signal processors.

Figure 4 illustrates typical signalling required to initiate an IPTV broadcast with a first STB STB1. The video decoder 9 in STB1 receives an instruction from a user to start channel X. This is relayed to the P2P network interface 12 in STB1 , which sends a request to a STB manager 10 in the IPTV back-end to join channel X. The STB Manager 10 returns a peer list to the network interface 12 in STB1 , but no IPTV media stream. The peer list includes the P2P media injector 8. Since the media injector can be considered as a peer in the network it is hereinafter referred to as STBO. The network interface 12 in STB1 then sends a request to join channel X to STBO. STBO receives an IPTV media stream from an IPTV media stream source (for example from the database 7 shown in Figure 3), and sends a peer list and an IPTV media stream comprising fragments of frames to the network interface 12 of STB1. The network interface 12 sends the frames to the video decoder 9 in STB1 , which can then show the IPTV media stream to the user.

Figure 5 illustrates typical signalling required to initiate an IPTV broadcast with a further STB STB2. It is assumed that STB1 is already receiving an IPTV media stream from STBO. When the user of STB2 wishes to receive channel X, she sends an instruction to logic within STB2, which is relayed to the network interface 13 in STB2. The network interface 13 in STB2 sends a request join channel X to the STB manager 10. The STB manager 10 returns a peer list but no payload to STB2. The peer list includes STBO and STB1 , as these are both possible sources for the IPTV media stream. The network interface 13 in STB2 then sends a request to each of STBO and STB1 to join channel X. STBO and STB1 each send a peer list and IPTV data stream to the network interface 13 in STB2, which passes the frames of the IPTV media stream to the video decoder.

All peers in the P2P network may send each other "keep alive" messages, as illustrated in Figure 6, to ensure that each STB is included in the list of peers and can both send and receive IPTV media streams.

Referring back to Figure 5, when STB2 is started up and wishes to subscribe to channel X, it obtains a peer list from the STB manager 10, providing a list of peers from which channel X can be obtained. If the STB2 now wishes to change channel (e.g. to channel Z), it may request a peer list from the STB manager 10 in the same way. The STB manager provides a list of those peers currently subscribed to channel Z, and STB2 can therefore obtain channel Z from any of these peers. However, a delay is introduced by the signalling between STB2 and the STB manager 10 before STB2 can start receiving the new channel.

Figure 7 illustrates elements of a P2P network which enable a quicker channel handover. It will be appreciated that further components, not shown, will also be included in the network. The figure illustrates STB2, together with nearby peers STB3, STB4, STB5 having network interfaces 71 , 72 73 and video decoders 74, 75, 76 respectively. The nearby peers may, for example, be other peers in the same apartment, same house, same street etc., or simply other peers nearby on the network. As shown in Figure 7, STB2 is currently subscribed to channel X. Fragments containing channel X frames (hereinafter referred to channel X media) are received from other peers in the network such as STBO and STB1 (not shown in Figure 7). The fragments are received by the STB2 network interface 13 and passed to the video decoder 11.

Nearby peers STB3, STB4, STB5 are all currently subscribed to different channels. In this example, STB3 is subscribed to channel Y, so channel Y media is received by the network interface 71 from other peers in the network (not shown) and passed to the video decoder 74. Similarly, STB4 is subscribed to channel Z and STB5 is subscribed to channel U.

STB2 subscribes to meta data from these nearby peers, which includes information as to the channel to which they are currently subscribed. It will be appreciated that the meta data including the channel subscription information is different to the metadata described above which is included in the fragments which carry the media frames. The meta data currently described is distributed separately, and includes no video data, although it may contain other information such as media synchronisation information, a peer neighbourhood list, and network topology.

The subscription by STB2 to the meta data may use any appropriate subscription system, and the details will not be reproduced here. One example includes regular broadcasts by each STB of the channel to which it is subscribed. Alternatively, the meta data could be included with the "keep alive" messages discussed with reference to Figure 6.

Figure 8 illustrates the network components of Figure 7, when the user 81 of STB2 requests a channel change. Since STB2 has been receiving meta data from the nearby peers STB3, STB4, STB5, it knows that STB4 is currently subscribed to channel Z. The network interface 13 therefore immediately sends a request to STB4 to join channel Z. This process is similar to that shown in Figure 5, except that there is no need to contact the STB manager 10 first. As in Figure 5, STB4 sends a peer list and IPTV data stream to the network interface 13 in STB2, which passes the frames of the IPTV media stream to the video decoder 1 1.

The STB2 will still need to contact the STB manager 10 to inform it that it is now subscribed to channel Z. However, the channel switch of STB2 can take place immediately, without the need to receive a list of peers from the STB manager 10.

Figure 9 illustrates a set-top box 31 , which may be any of the STBs shown in the other figures. In addition to the functions normally found in a set-top box known in the art, the set-top box 31 comprises a buffer 33 for storing fragments received from media injectors and/or other set-top boxes or other peers, as discussed above. The set-top box 31 also comprises a transmitter unit 35 and a receiver unit 37, connected to the buffer 33, for communicating with the other set-top boxes in the network. The set-top box 31 also comprises a store unit 38 for storing meta data received from other set-top boxes, and a control unit 39 for controlling the functions of the transmitter unit 35, the receiver unit 37, the buffer 33 and the store unit 38. In particular, when a channel request is made, the control unit 39 interrogates the meta data held in the store unit to identify whether any nearby peers are currently subscribed to the new channel and, if so, instructs the transmitter 35 to request media of the new channel from the nearby peer subscribed to that channel, and the receiver 37 to receive the new channel.

The receiver may be implemented as a software module in a television set, which will then be able to receive IPTV from the network and display it to the user. Alternatively, the set-top box is implemented as a software module, for example in a personal computer or other terminal having data processing capabilities. The stream can then be forwarded from the set-top box to any display unit, including a television set, or the computer's own display for display to the user.

Figure 10 is a flow diagram illustrating a sequence of actions taken by STB2 in changing subscription from channel X to channel Z.

S1 : STB2 receives instructions from viewer to switch to channel Z.

S2: The stored meta data is checked to see whether any near by peers are currently subscribed to channel Z.

S3: If a nearby peer (e.g. STB4) is subscribed to channel Z, then channel Z frames are requested from that nearby peer.

S4: If no nearby peer is subscribed to channel Z, then a request is sent to the STB manager for a list of peers from which channel Z media can be received.

S5: A suitable peer or peers from the list is chosen.

(S6): Once the suitable peer or peers have been identified, channel Z frames are requested from that peer in the same way as in step S3.

The description above has focussed chiefly on an arrangement in which a STB receives meta data from nearby peers containing details of the channel to which they are subscribed. It will be appreciated that further data in the meta data may still enable a STB to identify a peer from which channel media can be requested without having to contact the STB manager. For example, referring back to Figure 7, the meta data from STB3 may also contain information about the channels to which other peers, near to STB3 but less near to STB2, may be subscribed. If STB2 wishes to subscribe to channel W, none of the nearby peers is subscribed to this channel. However, if one of channel Y's peers is subscribed to channel W then this information may still be included in the meta data, enabling STB2 to contact this peer without the need to contact the STB manager.

It will be appreciated that variations from the above described embodiments may still fall within the scope of the claims. For example, the set top boxes have all been described as including "video decoders" but it will be appreciated that decoding for any form of media may be envisaged.

It will also be appreciated that the above described embodiments have been described with reference to P2P IPTV networks, but the invention may also be used in other nonlinear environments, for example top down networks and store and forward networks.

Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above description should be read as implying that any particular element, step, or function is essential such that it must be included in the claims' scope. The scope of protection is defined by the claims.

Claims

CLAIMS:

1. A peer node for use in a Peer-to-Peer network, comprising: a receiver arranged to receive media frames of a subscribed media channel and to receive meta data from selected other peer nodes in the network, the meta data including media channel subscription information from the selected other peer nodes; a storage medium operatively connected to the receiver and arranged to store the meta data; a controller operatively connected to the receiver and storage medium and arranged to receive user instructions to change the subscribed media channel to a new channel and, in response, to interrogate the meta data and determine whether any of the selected other peer nodes are subscribed to the new channel; and a transmitter operatively connected to the controller and arranged so that, if one of the selected other peer nodes is subscribed to the new channel, the transmitter requests frames of the new channel from said one of the selected other peer nodes subscribed to the new channel.

2. The node of claim 1 , arranged so that updates to the meta data from the selected other peer nodes are automatically received periodically.

3. The node of claim 1 , wherein the selected other peer nodes are neighbours of the node.

4. The node of claim 1 or 2, arranged to send information confirming that the node is subscribed to the subscribed media channel to additional peer nodes in the network.

5. A peer node for use in a Peer-to-Peer network, comprising: a receiver arranged to receive media frames of a subscribed media channel; a controller operatively connected to the receiver and arranged to generate meta data identifying that the peer node is subscribed to the media channel; and a transmitter operatively connected to the controller and arranged to transmit the meta data to other peer nodes in the network.

6. The node of any preceding claim, wherein the network is an IP Television Peer-to-Peer network.

7. A method for receiving media at a first peer node in a Peer-to-Peer network, comprising: receiving media frames of a subscribed media channel; periodically receiving meta data from selected other peer nodes in the network, the meta data including media channel subscription information of the selected other peer nodes; receiving user instructions to change the subscribed media channel to a new channel; determining from the meta data whether any of the selected other peer nodes are subscribed to the new channel; and if one of the selected other peer nodes is subscribed to the new channel, requesting frames of the new channel from said one of the selected other peer nodes subscribed to the new channel.

8. A method for distributing media in a Peer-to-Peer network, comprising: at a first peer node in the network, receiving media frames of a subscribed media channel; periodically sending meta data from selected other peer nodes in the network to the first peer node, the meta data including media channel subscription information of the selected other peer nodes; at the first peer node, receiving user instructions to change the subscribed media channel to a new channel; determining from the meta data whether any of the selected other peer nodes are subscribed to the new channel; and if one of the selected other peer nodes is subscribed to the new channel, requesting frames of the new channel from said one of the selected other peer nodes subscribed to the new channel.

9. The method of claim 7 or 8, wherein the selected other peer nodes are neighbours of the peer node.

10. The method of claim 7, 8 or 9, wherein the network is an IP Television Peer-to- Peer network.

1 1. The method of any of claims 7 to 10, wherein the network is a top down network or a store and forward network.

12. A program for controlling an apparatus to perform a method as claimed in any one of claims 7 to 11.

13. A program as claimed in claim 12, carried on a carrier medium.

14. A program as claimed in claim 13, wherein the carrier medium is a storage medium.

15. A program as claimed in claim 13, wherein the carrier medium is a transmission medium.

16. An apparatus programmed by a program as claimed in any one of claims 12 to 15.

17. A storage medium containing a program as claimed in any one of claims 12 to 14.