LJUNGGREN, Andreas (Ångermannagatan 119, S- Vällingby, SE-162 64, SE)
SKOG, Robert (Gullvivegränd 7, S- Hässelby, SE-165 76, SE)
LJUNGGREN, Andreas (Ångermannagatan 119, S- Vällingby, SE-162 64, SE)
CLAIMS:
1. A node for use in an IPTV communications network, the node comprising: a user prediction function for determining that a user is likely to switch between IPTV channels; a transmitter for, as a result of the determination, requesting from a remote node fragments for a further IPTV channel that is not currently being viewed by the user; a receiver for receiving from the remote node the requested fragments; and a memory for storing the received fragments.
2. The node according to claim 1 , wherein the node is selected from one of a Set Top Box and a proxy node arranged to act on behalf of a Set Top Box.
3. The node according to claim 1 or 2, wherein the node is adapted to operate in a Peer to Peer IPTV communications network.
4. The node according to any one of claims 1 , 2 or 3, further comprising a database of channels, wherein the further IPTV channel is selected from the database.
5. The node according to any one of claims 1 to 4, wherein the user prediction function is arranged to instruct the transmitter to stop requesting fragments for the further IPTV channel after it is determined that the user has not switched between IPTV channels for a predetermined amount of time.
6. The node according to any one of claims 1 to 5, wherein the memory is arranged to store fragments for both the further IPTV channel that is not currently being viewed by the user, and a channel that is currently being viewed by the user.
7. A method of operating a node in an IPTV communications network, the method comprising: determining that a user is likely to switch between IPTV channels; as a result of the determination, requesting from a remote node fragments for a further IPTV channel; receiving from the remote node the requested fragments; and storing the received fragments.
8. The method according to claim 7, further comprising selecting the at least one further channel from a database.
9. The method according to claim 7 or 8, comprising: determining that the user has not switched between IPTV channels for a predetermined amount of time; and stopping requesting from the remote node fragments for the further IPTV channel.
10. The method according to claim 7, 8 or 9, further comprising: determining that the user wishes to view the further IPTV channel; and sending the stored fragments for the further IPTV channel to a media renderer.
1 1. An apparatus for use in receiving media over a communications network, the apparatus comprising means for performing the method as claimed in any one of claims 7 to 10.
12. A program for controlling an apparatus to perform a method as claimed in any one of claims 7 to 10.
13. A program which, when loaded into an apparatus, causes the apparatus to become an apparatus as claimed in claim 11.
14. A program as claimed in claim 12 or 13, carried on a carrier medium.
15. A program as claimed in claim 14, wherein the carrier medium is a storage medium.
16. A storage medium containing a program as claimed in any one of claims 12 to 16. |
Method and Apparatus for Obtaining Media over a Communications Network
TECHNICAL FIELD
The invention relates to the field of obtaining media over a 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.
An IPTV media stream is typically compressed in order to save bandwidth. An example of a compressed media format is MPEG. 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. Typically, 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.
Since B and P frames depend on adjacent frames it is necessary that when the STB receives a new channel, it receives a full l-frame before the new channel can be shown. The average time for switching between channels therefore depends on the length of time between l-frames. Typically, for MPEG-2 IPTV content, the length of time is around 0.5 seconds. For MPEG-4 part 10 IPTV content, the length of time between l-frames can be several seconds.
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.
In order to show a channel quickly when a STB connects to a peer, it would be beneficial if the peer sends the latest l-frame (or other format of complete image frame) and all related frames in order to allow the STB to decode the media stream as quickly as possibly. Unfortunately this is not practical, as the media stream is sent in fragments. A buffer containing fragments is illustrated in Figure 3. A fragment may
contain both metadata about the media stream, and payload data from the media stream itself.
The P2P network interface (in, for example, a STB) requests fragments from other P2P peers. In Figure 3 the P2P logic is writing fragment number 21 into the buffer and fragment number 17 is sent to the video decoder.
In some circumstances, a user will switch between channels (referred to as "zapping") frequently. In this case, the user joins and leaves P2P networks for specific channels often. When a user leaves a channel the buffer in their STB will no longer build up fragments for that channel, and if a user returns to that channel it will take a significant amount of time to render the media for that channel, as the user's STB will have to build up buffer data once more for the channel.
SUMMARY
The inventors have realised the problems associated with the prior art and devised an apparatus and method to mitigate the problems and reduce the time it takes for a peer to receive the latest key frame from another peer in the network.
According to a first aspect of the invention, there is provided a node for use in an IPTV communications network. The node comprises a user prediction function for determining that a user is likely to switch between IPTV channels, and a transmitter for, as a result of the determination, requesting from a remote node fragments for a further IPTV channel that is not currently being viewed by the user. The node is also provided with a receiver for receiving from the remote node the requested fragments; and a memory for storing the received fragments. The node is optionally either a Set Top Box or a proxy node arranged to act on behalf of a Set Top Box. By determining when a user is likely to switch channels, for example by determining that the user is "zapping" between channels or the user habitually changes to Channel 3 after watching Channel 4 for thirty minutes, the node can pre-fetch fragments for the channel that the user is likely to switch to. In the event that the user then switches to the further channel, the fragments are already stored in the channel, and the channel can be rendered more quickly than if the node started to fetch fragments for the further channel after the viewer requested to switch to the further channel.
The node is optionally adapted to operate in a Peer to Peer IPTV communications network.
Optionally, the node comprises a database of channels, wherein the further IPTV channel is selected from the database. The database may be, for example, a list of the user's "favourite" channels.
The user prediction function is optionally arranged to instruct the transmitter to stop requesting fragments for the further IPTV channel after it is determined that the user has not switched between IPTV channels for a predetermined amount of time. In this way, if fragments for the further channel are pre-fetched because the node has determined that the user is zapping between channels, then the node can determine that there is no need to pre-fetch fragments once the user has stopped zapping between channels and has settled on one channel.
The memory is optionally arranged to store fragments for both the further IPTV channel that is not currently being viewed by the user, and a channel that is currently being viewed by the user.
According to a second aspect of the invention, there is provided a method of operating a node in an IPTV communications network. The method comprises determining when a user is likely to switch between IPTV channels. As a result of the determination, fragments for a further IPTV channel are requested from a remote node. The method further comprises receiving from the remote node the requested fragments, and storing the received fragments. The method allows a node to pre-fetch fragments for a channel that a user is not currently watching if it is determined that a user is likely to switch channels, for example when zapping between channels or from habitual user behaviour. In this way, when a user switches to a further channel, the channel can be rendered more quickly, as fragments for that channel have already been received.
The method optionally comprises selecting the at least one further channel from a database. An example of such a database is a list of user "favourites", or a database of the user's historical channel switching behaviour.
The method optionally comprises determining that the user has not switched between IPTV channels for a predetermined amount of time, and stopping requesting from the remote node fragments for the further IPTV channel.
Optionally, the method further comprises determining that the user wishes to view the further IPTV channel, and sending the stored fragments for the further IPTV channel to a media renderer.
According to a third aspect of the invention, there is provided apparatus for use in receiving media over a communications network, the apparatus comprising means for performing the method described above in the second aspect of the invention.
According to a fourth aspect of the invention, there is provided a program for controlling an apparatus to perform the method described above in the second aspect of the invention.
According to a fifth aspect of the invention, there is provided a program which, when loaded into an apparatus, causes the apparatus to become an apparatus as described above in the third aspect of the invention.
According to a sixth aspect of the invention, there is provided a program described above in either of the fourth or fifth aspects of the invention, carried on a carrier medium. The carrier medium is optionally a storage medium.
According to a seventh aspect of the invention, there is provided a storage medium containing a program as described above in either of the fourth or fifth aspects of the 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 buffer in a STB containing data fragments;
Figure 4 illustrates schematically in a block diagram a media injector and two Set Top Boxes;
Figure 5 illustrates schematically in a block diagram the signalling required to initiate an IPTV broadcast with a first Set Top Box;
Figure 6 illustrates schematically in a block diagram the signalling required to initiate an IPTV broadcast with a further Set Top Box;
Figure 7 illustrates schematically in a block diagram keep alive messages sent by a Set Top Box;
Figure 8 illustrates schematically the contents of a buffer where a user is viewing a single channel;
Figure 9 illustrates schematically the contents of a buffer where a user is switching between channels according to an embodiment of the invention;
Figure 10 is a flow diagram illustrating the steps according to an embodiment of the invention; and
Figure 11 illustrates schematically in a block diagram a peer node according to an embodiment of the invention.
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.
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 sends media data but does not receive media data from the peers. This is illustrated in Figure 4, which is a schematic representation of a simple IPTV P2P network 1. The network 1 includes an IPTV server 6 and two STBs STB1 and STB2. Each STB includes a P2P network interface 2, 3 to which is connected a video decoder 9, 1 1. In this example, STB1 receives the IPTV media stream from both STB2 and the IPTV Server 6, which injects either streaming content 4 or content from a database 7 using a P2P media injector 8. Note that other network nodes (in addition to STBs) may be peers in the network.
Figure 5 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 2 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 P2P function 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 termed STBO. The P2P function 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), and sends a peer list and an IPTV media stream comprising fragments of frames to the P2P network interface of STB1. The P2P network interface of STB1 sends the frames to the video decoder 9 in STB1 , which can then show the IPTV media stream to the user.
Figure 6 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 a P2P network interface in STB2. The P2P network interface 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 P2P function 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 P2P network
interface in STB2, which passes the frames of the IPTV media stream to the video decoder.
It is advantageous for neighbouring or active peers in the P2P network to 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.
Note that the term "IPTV media stream" is used herein to refer to any kind of media data having real time requirements, and includes Video on Demand, user defined 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. The term "media stream" need not necessarily refer to the media data injected into the network by a media injector, but can also be used to refer to media data received from other peers in a P2P network.
A STB is provided with a set of "favourite" channels that the user often views. Prediction logic is also provided to predict user behaviour and flag up to the STB when a user begins to switch between channels. For example, if a user changes from channel 5 to channel 4 and back again to channel 5, it may be likely that the user will return once more to channel 4. These channels are both on the "favourite" list.
The STB therefore keeps "favourite" channels active for a period of time during whilst the user is switching channels. The STB fetches fragments for the favourite channels for a certain amount of time, the time being determined by the prediction logic. For example, the prediction logic may predict that if a user stays with a certain channel for a predetermined amount of time, the user is unlikely to switch to another channel at any time soon, and will therefore stop obtaining fragments for channels that the user is not currently viewing.
The STB is therefore keeping favourite channels active for a certain time even when they are not being viewed by the user. If the user subsequently switches to one of the favourite channels, the buffer will already contain fragments for that channel and the STB can immediately start rendering the media. This greatly reduces the amount of
time that a user has to wait before seeing the media when switching between favourite channels.
The STB re-arranges the memory for the buffer to ensure that fragments relating to more than one channel at a time can be stored. It will be appreciated that for a given memory size, the more channels a STB obtains fragments for, the fewer fragments will be stored for each channel at the STB. This places a limit on the amount of time that a channel can be viewed for before the STB must start to fetch fragments for that channel to enable a viewer to watch it. However, if a user quickly switches between channels then this will not be a problem, as the buffer may not run out of fragments for the user to view before the viewer switches to another channel.
By way of example, and referring to Figure 8, a buffer containing fragments for Channel X is illustrated. All of the fragments contain media data and metadata for rendering Channel X. Turning now to Figure 9, the end user starts "zapping" between Channel Y and Channel Z. The prediction logic in the STB determines that the user is zapping between Channel Y and Channel Z, and rearranges the buffer memory such that fragments containing frames and metadata for both Channel Y and Channel Z are obtained. If the user is currently watching Channel Z, and the STB prediction logic determines that the user is likely to switch back to Channel Y, then the STB will continue to retrieve fragments fro Channel Y and store them in the buffer. If the user continues to watch Channel Z for a sufficient amount of time that the prediction logic no longer expects the user to switch to another channel, then the prediction logic will instruct the STB to only fetch fragments relating to Channel Z. Note that the same amount of buffer space might be available whether the STB is obtaining fragments relating to Channel X only, or if the STB is obtaining fragments for Channel X and Channel Y.
Note that in the above example, the user is switching between two channels, but it will be appreciated that the user may be switching between more channels.
Note also that whilst the above description refers to the functions of the STB, the same functions can be applied to any peer node in the P2P network. In particular, this may be useful for a proxy node acting on behalf of one or more STBs. The proxy node would predict a user's behaviour when the user starts to zap, and pre-fetch and store channels in a buffer such that the channel can be rendered on the user's STB almost
immediately if the user switches to that channel. An example of a node that could be used as a proxy node in such a way is a Digital Subscriber Line Access Multiplexer (DSLAM).
Referring now to Figure 10, a flow diagram is shown illustrating the basic steps of an embodiment of the invention. The following numbering refers to the numbering in the flow diagram:
51. The STB's prediction logic determines that the user is switching between channels. In this example, the user is currently viewing channel Y;
52. The STB requests fragments for channel Z from remote nodes. Note that the end user is not viewing channel Z, but channel Z is in a user's "favourites" list and the user often switches between channel Y and channel Z;
53. The STB receives fragments for channel Z;
54. The STB stores the received channel Z fragments in a buffer, along with fragments for the channel that the user is currently viewing;
55. The user subsequently switches to channel Z, and so the fragments stored in the buffer are sent to a media renderer to allow the user to view channel Z straight away.
Of course, the STB may receive fragments for many channels that the user is not currently viewing but might reasonably be expected to switch to within a predetermined time period.
Referring now to Figure 1 1 , a peer node such as a STB is illustrated. The peer node 12 is provided with a user prediction function 13 that is used for determining when the end-user starts to switch between channels. A transmitter 14 is also provided fro requesting remote fragments from other peer nodes relating to other IPTV channels than the one the user is currently viewing. A receiver 15 receives the requested fragments, which are then stored in a memory 16. If the user switches to a channel for which fragments are already stored on the memory 16, those fragments are passed to a media renderer 14 to allow the user to view the channel. The peer node 12 may also
be provided with a database 17 of "favourite" channels from which the requested channels are selected.
The invention provides a pre-fetch function in a peer node such as a STB for use in an IPTV P2P network that is activated if a user begins to switch channels. The pre-fetch function re-arranges the buffer in the STB so that fragments for more than one channel can be handled. Even if fragments for a channel are not sent to the STB video decoder for rendering, the STB will still fetch frames belonging to that channel as long as it is likely that the user will switch to that channel.
It will be appreciated by the person of skill in the art that various modifications may be made to the embodiments described above without departing from the scope of the present invention. For example, the above description assumes that the node that prefetches fragments for channels that are not currently being viewed is the viewer's STB. However, it will be appreciated that the invention applies to any peer in the network. Furthermore, the above description assumes that the STB is disposed in a P2P network, although the invention could equally apply to a client-server type of network.