WO2009095081A1

WO2009095081A1 - Method and apparatus for obtaining media over a communications network

Info

Publication number: WO2009095081A1
Application number: PCT/EP2008/051187
Authority: WO
Inventors: Andreas Ljunggren; Robert Skog
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2008-01-31
Filing date: 2008-01-31
Publication date: 2009-08-06
Anticipated expiration: 2010-07-31

Abstract

A node and a method for use in an IPTV communications network. The node comprises a user analyzer function for analyzing information relating to a user' s IPTV channel switching behaviour, and for predicting the user' s IPTV channel switching behaviour. By predicting the user s IPTV channel switching behaviour the node can, for example, populate a database for profiling the user s behaviour, and pre-fetch fragments for an IPTV channel which a user may be about to switch to, thereby allowing the node to render the IPTV channel more quickly when the user does switch to that channel.

Description

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, and in particular IPTV media.

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 user changes channel and the user's 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 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. A fragment may contain both metadata about the media stream, and payload data from the media stream itself.

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 analyzer function for analyzing information relating to a user's IPTV channel switching behaviour, and for predicting the user's IPTV channel switching behaviour. By predicting the user's IPTV channel switching behaviour the node can, for example, populate a database for profiling the user's behaviour, and pre-fetch fragments for an IPTV channel which a user may be about to switch to, thereby allowing the node to render the IPTV channel more quickly when the user does switch to that channel.

Where the node is provided with functionality to pre-fetch fragments for an IPTV channel that the user is not currently viewing, the node is optionally provided with a transmitter for, as a result of the prediction, 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. If the user subsequently switches to the further IPTV channel then the fragments in the memory can be used to quickly render the further IPTV channel. Optionally, 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. For the case where the user is "zapping" between channels, the user analyzer 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.

The node optionally comprises a database for storing information relating to the user's channel switching behaviour. The database can be used to build up a historical picture of the user's channel switching behaviour, which can be used to more accurately predict the user's channel switching behaviour.

As an option, the node is arranged to, at start-up, select a default IPTV channel on the basis of the user's predicted behaviour. In this way, if the user habitually watches a certain channel at a certain time, the node can default to that channel if the user switches on the node shortly before that time.

The node is optionally selected from one of a Set Top Box and a proxy node arranged to act on behalf of a Set Top Box.

The node is optionally adapted to operate in a Peer to Peer IPTV communications network, in which case it is provided with P2P functionality. However, it should be noted that the invention may equally apply to a client/server type of network.

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 analyzing information relating to a user's IPTV channel switching behaviour and, as a result of the analysis, predicting the user's IPTV channel switching behaviour.

Optionally, the method further comprises requesting from a remote node fragments for a further IPTV channel that is not currently being viewed by the user, receiving from the remote node the requested fragments, and storing the received fragments in a memory at the node. In this way, the prediction can be used to pre-fetch fragments from a channel that the user is not currently watching but is likely to switch to. When the user does switch to that channel, fragments stored in the buffer can be used to begin rendering that channel.

The method optionally comprises storing 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.

In the event that fragments for a further channel are being stored because the user is

"zapping" between channels, the method optionally comprises stopping 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, once the user has settled on a particular channel, no fragments will be pre-fetched fro a channel that is not being viewed.

The method optionally comprises obtaining the information for analysis from a user behaviour database. A database of user behaviour can make the prediction of the user's IPTV channel switching behaviour more accurate.

The method optionally comprises selecting a default IPTV channel on the basis of the user's predicted behaviour when the node is switched on.

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; and

Figure 8 illustrates schematically a signalling sequence 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 all peers in the P2P network to send each other "keep alive" messages, as illustrated in Figure 7, 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 peer in the network, 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.

Referring to Figure 8, there is illustrated a signalling sequence according to an embodiment of the invention. Figure 8 shows an STB, 12 which is provided with a video decoder 9 for rendering media, P2P logic 13 for handling P2P signalling, and an end-user analyzer module 14 for analyzing channel viewing behaviour of an end-user. The following steps correspond to the numbering shown in Figure 8:

51. The end-user selects a new channel and signals this to the STB 12. Information relating to the required new channel is sent to the P2P Iogic13 in the STB 12. The P2P logic 13 then handles signalling for obtaining media fragments for the new channel

52. Information relating to the required new channel is sent to the end-user analyzer module 14.

S3. The analyzer 14 records the identity of the new channel and the time and date at which the channel was selected and stores the information in a database 15. Stored information includes, for example, the fact that the end-user regularly watches Channel X at 7pm on a Friday. Similarly, stored information may include the fact that if the end- user is watching Channel Y, then he is most likely to switch next to Channel Z. The analyzer 14 uses the stored information and prediction algorithms to predict the next "likely" channel that the end-user is likely to switch to next. It may also be used if, for example, the user turns on the STB 12 at 6.59pm on a Friday. The STB 12 normally defaults to Channel A, when it is turned on, but the analyzer can be used to predict that the user will want to watch Channel X at 7pm, and so the STB 12 defaults to Channel X; 54. The next "likely" channel determined by the analyzer 14 channel is sent to the P2P logic 13;

55. P2P logic 13 starts to pre-fetch fragments for the likely channel and stores the frames in a buffer 16, even if the user is not currently viewing that channel.

Assuming that the end-user behaves as predicted, and subsequently selects the "likely" channel when he next switches channel, the pre-fetched fragments stored in the buffer 16 are used to allow the video decoder 9 of the STB 12 to begin rendering the channel as soon as the user switches to that channel. This greatly reduces the time between a user selecting a new channel and the video decoder 9 rendering the channel for the end-user to view.

Whilst the above description assumes that the user is watching one channel, the analyzer 14 predicts a single channel to which the user will switch to next. However, it will be apparent that the analyser 14 may predict that the user may switch to one of a plurality of channels next, in which case the P2P logic 13 can pre-fetch fragments relating to a plurality of channels that are not currently being watched by the user.

Note that whilst the above description refers to a P2P scenario, it can equally apply in other types of scenario, such as a multicast in a client/server type of network.

The database 15 of user behaviour is used to predict which channels the user will wish to view, and to pre-fetch fragments for those channels in order for a channel to be rendered more quickly when the user switches to that channel. However, there are other uses for the database, for example user profiling. When combined with program information, the database can be used to customize an Electronic Program Guide (EPG) for the user, allowing the EPG to give better targeted information that might be relevant to the user. Furthermore, the database 15 can be mined to extract information that can be used for selecting advertisements to insert in the channel currently being watched by the user.

It will be apparent that the more an end-user uses the STB, the more the analyzer 14 using a database 15 can learn about the end-user's behaviour. This means that the analyzer 14 will, over time, become more accurate at predicting the end-user's behaviour. As a consequence, traffic bursts and set-up times when an end-user switches channel will decrease, and the end-user will see a faster response from TV services when the end-user changes channel. However, it is also possible for an analyzer 14 to be provided that does not access a database 15. In this case, analysis is done "on the fly" when a user is zapping between channels. For example, the analyzer may predict that if Channel Y is showing advertisements and the user switches to Channel Z, it is likely that the user will switch back to Channel Y to resume viewing Channel Y once the advertisements are over. This type of analysis does not require an analysis of a user's historic channel-switching behaviour.

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. This could include a proxy node acting on behalf of one or more STBs, such as a Digital Subscriber Line Access Multiplexer (DSLAM). 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.

Claims

CLAIMS:

1. A node for use in an IPTV communications network, the node comprising: a user analyzer function for analyzing information relating to a user's IPTV channel switching behaviour, and for predicting the user's IPTV channel switching behaviour.

2. The node according to claim 1 , further comprising: a transmitter for, as a result of the prediction, 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.

3. The node according to claim 2, 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.

4. The node according to claim 2 or 3, wherein the user analyzer 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.

5. The node according to any one of claims 1 to 4, further comprising: a database for storing information relating to the user's channel switching behaviour.

6. The node according to any one of claims 1 to 5, wherein the node is arranged to, at start-up, select a default IPTV channel on the basis of the user's predicted behaviour.

7. The node according to any one of claims 1 to 6, 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.

8. The node according to any one of claims 1 to 7, wherein the node is adapted to operate in a Peer to Peer IPTV communications network.

9. A method of operating a node in an IPTV communications network, the method comprising: analyzing information relating to a user's IPTV channel switching behaviour; and as a result of the analysis, predicting the user's IPTV channel switching behaviour.

10. The method according to claim 9, further comprising: requesting from a remote node fragments for a further IPTV channel that is not currently being viewed by the user; receiving from the remote node the requested fragments; and storing the received fragments In a memory at the node.

11. The method according to claim 10, comprising storing 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.

12. The method according to claim 10 or 11, comprising stopping 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.

13. The method according to any one of claims 9 to 12_S further comprising obtaining the information for analysis from a user behaviour database.

14. The method according to any one of claims 9 to 13, further comprising: when the node is switched on, selecting a default IPTV channel on the basis of the user's predicted behaviour.

15. 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 9 to 14.

16, A program for controlling an apparatus to perform a method as claimed in any one of claims 9 to 14.

17. A program which, when loaded into an apparatus, causes the apparatus to become an apparatus as claimed in claim 15.

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

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

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