WO2009103343A1

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

Info

Publication number: WO2009103343A1
Application number: PCT/EP2008/052183
Authority: WO
Inventors: Andreas Ljunggren; Robert Skog
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2008-02-22
Filing date: 2008-02-22
Publication date: 2009-08-27
Also published as: WO2009103351A1

Abstract

Method and Apparatus for Distributing Media over a Communications Network A method and apparatus for distributing media over a P2P IPTV network is described. The media is encoded into data fragments An internal time relative to an epoch time reference point is determined at a media injector. Each data fragment is tagged with a fragment counter and a timestamp corresponding to the internal time at the moment the data is encoded. The data fragments are transmitted into the network, and received at a peer node, which stores the data fragments in a buffer. At the node, an insertion rate at which the fragments have been inserted into the network is calculated from the timestamps and fragment counters of at least two data fragments. Fragments are then requested from another node in the network (which may be the media injector) at a fragment request rate determined from the calculated insertion rate.

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, STB2 receives the IPTV media stream from both STB1 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. For example, MPEG media streams contain different frames, such as l-frames ("intra" frames), P-frames ("predicted" frames) and B-frames ("bi-predictive" or "bi-directional" 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.

In order to obtain data, a P2P node (e.g. STB2) sends requests for media fragments to nearby peers and/or media injectors. The fragments do not need to be requested individually; typically, of the order of ten fragments are sent in response to each request. However, requests to nearby peers for fragments should not be made more often than necessary. If such requests are too frequent, both the P2P node(s) from which fragments are requested, and the P2P system itself, may be flooded.

The speed at which fragments are inserted into the P2P network depends on the coding rate. For example, fragments containing HDTV content are inserted at a much higher rate than those generated by a low resolution webcam. Returning to Figure 3, suppose the media injector 8 inserts fragments containing webcam data into the network. If the P2P network interface 13 of STB2 requests frames at a rate suitable for HDTV, the "webcam" media injector 8 will overloaded.

Furthermore, since the STB2 is requesting frames at a much higher rate than can be supplied by the media injector 8, its own resources will also be wasted.

There is thus a need for a P2P client to be able to determine the "quality" of media inserted in the P2P network, to avoid making requests to other peers too frequently.

SUMMARY

The invention generally involves the calculation of the rate at which fragments are inserted in the P2P network by looking at tagged time stamps. This information is used to adjust the sending of requests for fragments.

In accordance with a first aspect of the present invention, there is provided a node for use in a non-linear network delivering streaming media. The node comprises a receiver arranged to receive data fragments from the network, where each data fragment is tagged with a fragment counter and a timestamp providing a time interval relative to an epoch time reference point. A buffer is arranged to store the received data fragments. A processor is arranged to calculate, from the timestamps and fragment counters of at least two data fragments, an insertion rate at which fragments have been inserted into the network. A transmitter is arranged to request fragments from another node in the network at a fragment request rate determined from the calculated insertion rate.

Preferably, the insertion rate is calculated as follows. The fragment counter of a second fragment is subtracted from the fragment counter of a first fragment to generate a fragment number difference between the first and second fragments. The timestamp of the second fragment is subtracted from the timestamp of the first fragment to generate an insertion time difference between the first and second fragments. The insertion rate is obtained by dividing the fragment number difference by the insertion time difference.

The fragment request rate may be the same as the calculated insertion rate. Alternatively, an algorithm may be used to ensure that the fragment request rate is not constantly changing. The insertion rate may be calculated periodically, and the fragment request rate adapted over time so that it approaches the calculated insertion rate asymptotically. This should ensure that a suitable average is obtained. The initial fragment request rate should preferably be high.

It is likely that more than one fragment will be required for each frame of media content. The timestamp on any particular fragment is preferably the internal time at which the frame, of which all or a part is encoded into that fragment, was received by a media injector which inserted the fragments into the network. The timestamp and fragment counter may preferably be included in a metadata portion of each fragment.

The receiver may be arranged to receive data fragments from more than one source (e.g. a media injector and another peer node). In this case, it will still be the initial insertion rate by the media injector which is calculated by the node.

The network is preferably a P2P network and more preferably a P2P IPTV network, but it will be appreciated that the technique may also be used in other situations such as top down and store and forward networks.

According to a second aspect of the present invention, there is provided a method of controlling delivery of streaming media in a non-linear network, preferably a Peer-to- Peer IP Television network. The media is encoded into data fragments, each data fragment containing all or part of a media frame. An internal time relative to an epoch time reference point is determined at a media injector connected to the network. Each data fragment is tagged with a fragment counter and a timestamp corresponding to the internal time at the moment the data is encoded. The data fragments are transmitted from the media injector into the network, received at a node connected to the network, and stored in a buffer of the node. At the node, an insertion rate at which fragments have been inserted into the network is calculated from the timestamps and fragment counters of at least two data fragments. Fragments are then requested from another node in the network (which may be the media injector) at a fragment request rate determined from the calculated insertion rate.

According to a third aspect of the present invention there is provided a method of controlling delivery of streaming media in a non-linear network preferably a P2P IPTV network. Data fragments are received at a node in the network, each data fragment tagged with a fragment counter and a timestamp providing a time interval relative to an epoch time reference point. The fragments are stored in a buffer of the node. An insertion rate at which fragments have been inserted into the network is calculated from the timestamps and fragment counters of at least two data fragments. Fragments are then requested from another node in the network at a fragment request rate determined from the calculated insertion rate.

According to a fourth aspect of the present invention, there is provided apparatus for use in a network, the apparatus comprising means for performing a method according to the second or third aspect of the present invention.

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 fourth aspect of the present invention.

According to a sixth aspect of the present invention there is provided a program which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the 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 an seventh aspect of the present invention, there is provided an apparatus programmed by a program according to the fifth or sixth aspect of the present invention.

According to a eighth aspect of the present invention, there is provided a storage medium containing a program according to the fifth or sixth 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 is a schematic illustration of a buffer of a STB in a P2P IPTV network; Figure 8 is a schematic block diagram of a STB;

Figure 9 is a flow diagram illustrating the tagging and transmission of data fragments by a media injector; and

Figure 10 is a flow diagram illustrating the receiving and re-ordering of data fragments by a STB.

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 the 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.

It is preferred that all peers in the P2P network 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.

When data is inserted into the network, each fragment is tagged with a timestamp and a counter. This can be understood by returning to Figure 3, in which the IPTV Backend 6 includes a video encoder or database 7 and media injector 8. Media frames are passed from the video encoder 7 to the media injector 8 for encoding into fragments and transmission into the network. The media injector 8 runs an internal clock, and tags the metadata of each fragment with a timestamp taken from this internal clock. The time can be relative to any arbitrary chosen time (e.g. midnight on 28 January 2006, or the time of receipt of the first frame) but is consistent for the media injector. The time used is the time (relative to the arbitrary chosen time) that the frame is received by the media injector. If the arbitrary chosen time is the time the first frame is received by the media injector, it can be seen that frames could be sent to the media injector at, for example, T=O, 2, 4, 7, 8, 12 and 13 ms.

It will be appreciated that there need not be a direct correlation between a single media frame and a single data fragment. It is frequently the case that one frame is encoded into many fragments. In this case, each fragment corresponding to a particular frame will be tagged with the same timestamp - i.e. the time that the particular frame was received by the media injector 8. The fragments are also tagged with a counter to indicate the order in which they are encoded by the media injector.

The data fragments are then sent through the network and received by the network interface 13 of the STB2. The transmission through the network may introduce jitter, bursting and packet drops, and the data fragments may take different times to arrive. They do not necessarily arrive at the STB2 at a homogeneous rate corresponding exactly to the rate at which they were transmitted by the media injector 8.

The STB2 saves all of the fragments into a buffer 70, e.g. a sliding window buffer or a ring buffer, as shown in Figure 7. Figure 7 illustrates the buffer 70 at a snapshot in time when it contains fragments having counters 15-41. At the time snapshot shown in Figure 7, fragment 17 is currently being exported to the video decoder 1 1 of STB2 for decoding, and fragment 40 (the last requested fragment) is being written in to the buffer, having been received from the media injector 8. The metadata of fragment 17 contains both the counter value (Fragment ID_P|_ay out) 17, and a timestamp (relative to the arbitrary epoch time) having value t_Pι_ay out- The metadata of fragment 40 contains the counter value (Fragment I D_Last requested fragment) 40 and a timestamp t_Last requested fragment-

Once the STB2 has been receiving fragments for a predetermined time (x seconds), it calculates the rate at which fragments are being inserted into the network via: Fragment ID Fragment ID

Last requested fragment - Play Out

Last requested fragment ^™ Play Out Once the rate of fragment insertion into the network has been determined, this rate is used as a benchmark for the rate at which the STB2 requests subsequent fragments, whether from the media injector 8, or from other peers such asSTBL

It will be noted that this calculation uses the timestamp on the fragments, rather than the time at which they are received by the STB2. This ensures that the calculation determines the rate at which they were inserted into the network, rather than the rate at which they are received by the STB2 (which might be very different). It will also be noted that there is no absolute synchronisation between the clock of the STB2 and the clock of the media injector 8: the fragments are labelled with a time reference from the media injector's clock, and the calculation performed by the STB2 simply determines the time difference between fragments.

It will further be noted that the calculation above is determined on the basis of a comparison between the fragment currently being exported to the video decoder and the most recently requested fragment. It will be appreciated that any pair of fragments may be used to perform the calculation, although the more widely spaced the fragments, the better the averaging in determining the correct rate. Furthermore, the calculation can be repeated every few seconds to ensure that the rate has not changed in the meantime.

The initial fragment request rate should be high, to ensure that the all fragments are received to begin with, whatever the media type. For example, if a client STB requests fragments but does not know what type of media to expect, it must request fragments at a sufficiently high rate that it will receive all of them even if a media injector is inserting many fragments (e.g. HDTV media). If the media source turns out to be a low resolution webcam, the fragment request rate can quickly be adjusted to take account of the low insertion rate. The insertion rate should then be re-calculated at periodic intervals to ensure that it remains correct.

Figure 8 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 70 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 70, for communicating with media injectors and the other set-top boxes in the network. The set-top box 31 also comprises a control unit for controlling the functions of the transmitter unit 35, the receiver unit 37 and the buffer 70. In particular, the control unit is able to identify time stamps and counters on data fragments stored in the buffer, and determine the rate of insertion of fragments into the network by using the timestamps and counters of fragments in the buffer. Requests for further fragments can then be sent at an appropriate rate. 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 9 is a flow chart illustrating the actions carried out by the media injector 8 in the IPTV server 6 shown in Figure 7.

S1 : Media frames are received from the video encoder or database 7.

S2: The frames are encoded into data fragments.

S3: Each data fragment is tagged with a counter.

S4: Each data fragment is tagged with a timestamp, the timestamp reflecting the time, relative to a reference epoch time, that a frame, of which at least a part is encoded into that fragment, was received by the media injector.

S5: The tagged data fragments are transmitted into the network.

Figure 10 is a flow chart illustrating the actions carried out by the P2P network interface 13 in the STB2.

S6: Data fragments are received from the network.

S7: The fragments are saved in the buffer.

S8: The rate at which fragments were inserted into the network is calculated from the timestamp and counters of two fragments.

S9: The rate at which fragments are requested from other peers in the network is modified to match the calculated rate of insertion. 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 node for use in a non-linear network delivering streaming media, comprising: a receiver arranged to receive data fragments from the network, each data fragment tagged with a fragment counter and a timestamp providing a time interval relative to an epoch time reference point; a buffer arranged to store the received data fragments; a processor arranged to calculate, from the timestamps and fragment counters of at least two data fragments, an insertion rate at which the fragments have been inserted into the network; and a transmitter arranged to request fragments from another node in the network at a fragment request rate determined from the calculated insertion rate.

2. The node of claim 1 , wherein the processor is arranged to calculate the insertion rate by: calculating a fragment number difference between a first and a second fragment by subtracting the fragment counter of the second fragment from the fragment counter of the first fragment; calculating an insertion time difference between the first and the second fragment by subtracting the timestamp of the second fragment from the timestamp of the first fragment; and obtaining the insertion rate by dividing the fragment number difference by the insertion time difference.

3. The node of claim 1 or 2, wherein the fragment request rate is the same as the calculated insertion rate.

4. The node of claim 1 or 2, wherein the insertion rate is calculated periodically and the fragment request rate is adapted over time on the basis of the periodically calculated insertion rate.

5. The node of any preceding claim, wherein an initial fragment request rate is high.

6. The node of any preceding claim, wherein the receiver is arranged to receive data fragments from more than one source.

7. The node of any preceding claim, wherein the fragment counter and timestamp are included in a metadata portion of each data fragment.

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

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

10. A method of controlling delivery of streaming media in a non-linear network, comprising: encoding the media into data fragments, each data fragment containing all or part of a media frame; at a media injector connected to the network, determining an internal time relative to an epoch time reference point; at the media injector, tagging each data fragment with a fragment counter and a timestamp corresponding to the internal time at the moment the data is encoded; transmitting the data fragments from the media injector into the network; receiving the data fragments at a node connected to the network; storing the data fragments in a buffer of the node; at the node, calculating, from the timestamps and fragment counters of at least two data fragments, an insertion rate at which fragments have been inserted into the network; and at the node, requesting fragments from another node in the network at a fragment request rate determined from the calculated insertion rate.

1 1. The method of claim 10, wherein the fragment counters and timestamps are included in metadata portions of the data fragments.

12. The method of claim 10 or 1 1 , wherein the node requests the fragments from the media injector.

13. The method of claim 10, 11 or 12, wherein the network is a Peer-to-Peer IP Television network.

14. The method of claim 10, 1 1 or 12, wherein the network is a top down or store and forward network.

15. A method of controlling delivery of streaming media in a non-linear network, comprising: receiving data fragments at a node connected to the network, each data fragment tagged with a fragment counter and a timestamp providing a time interval relative to an epoch time reference point; storing the data fragments in a buffer of the node; calculating, from the timestamps and fragment counters of at least two data fragments, an insertion rate at which the fragments have been inserted into the network; and requesting fragments from another node in the network at a fragment request rate determined from the calculated insertion rate.

16. A program for controlling an apparatus to perform a method as claimed in any one of claims 10 to 15.

17. A program as claimed in claim 16, carried on a carrier medium.

18. A program as claimed in claim 17, wherein the carrier medium is a storage medium.

19. A program as claimed in claim 17, wherein the carrier medium is a transmission medium.

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

21. A storage medium containing a program as claimed in any one of claims 16 to 18.