Multicast caching method

Abstract

Described are improved methods of managing content delivery to a client device by a proxy in a hybrid unicast-multicast network. In such networks, multicast and unicast delivery are used, with a proxy inserted between a client and a content server. The proxy can join to a multicast channel, receive content segments over multicast, store these received segments in the cache, and provide these segments to the client when requested, packaged to look like unicast delivered segments. However, delivery of segments over multicast and managing the cache that stores received multicast segments need to be managed in a particular manner to optimise the use of the cache for satisfying unicast segment requests from the client. Described are various methods to optimise multicast delivery and associated cache management.

Description

[0001] MULTICAST CACHING METHOD

[0002] Field of the Invention

[0003] This invention relates to the field of managing content delivery in a network, in particular managing cached content in a network utilising a combination of unicast and multicast.

[0004] Background to the Invention

[0005] Video content is currently delivered to a range of client devices using unicast delivery, where a single stream of data is transmitted to each individual client device. Web (HTTP) technology is used for the content delivery, where the content is segmented into short segment files, typically around six to ten seconds in duration, enabling each segment file to be requested by and delivered to the client device using HTTP.

[0006] Each segment may also be encoded at a set of quality levels, each with a different bit rate and hence different file size. The client device monitors its buffer level and the network throughput achieved, and determines from these at which quality to request the next segment in order to achieve a good compromise between media quality and timely delivery. This is commonly referred to as adaptive bitrate (ABR) streaming.

[0007] However, HTTP is delivered over unicast (one to one) transport, so is inefficient for delivering the same content at the same time to many client devices. Multicast (one to many) transport would be far more efficient. Yet multicast is currently rarely used for any services other than network operators’ on-net linear video channels delivered to their own set-top boxes. The main reason for this is that multicast does not lend itself to open use on the Internet.

[0008] To bring the benefits of multicast scalability to HTTP-based Internet media streaming, a class of techniques known as Multicast-Adaptive Bitrate (m-ABR) is being investigated and standardised.

[0009] Multicast-Adaptive Bitrate (m-ABR) is a relatively new technology. It aims to allow more efficient delivery of ABR content over networks by enabling the use of multicast for content streams where many clients are requesting the same content at about the same time. One ambition of many m-ABR systems is to deploy multicast and enable m-ABR without any change to the client device and the client application that are already supporting HTTP (unicast) streaming. This can be achieved using a hybrid approach that uses a combination of both multicast and unicast delivery, where a proxy is inserted between the client device and the content server. The proxy can inspect content requests from the client device, and when appropriate, join to a multicast channel, receive multicast content, and provide this content to the client, packaged to look like unicast delivered content.

[0010] Examples of such hybrid solutions include: “IP Multicast Adaptive Bit Rate Architecture Technical Report” OC-TR-IP-MULTI-ARCH-C01 -161026, 26 / 10 / 2016, by Cable Labs; 3GPP specifications, 23.246 (MBMS Architecture and functional description), 26.346 (MBMS Protocols and codecs) and 26.347 (MBMS APIs); and DVB “Adaptive Media Streaming over IP Multicast” ETSI TS 103 769 V1 .1 .1 (2020-1 1 ).

[0011] In these hybrid solutions, the proxy typically joins a multicast channel, receives content segments by multicast on the multicast channel, and buffers the received content segments in a cache. The proxy responds to requests for content segments from the client device using cached data whenever possible, and otherwise by requesting and receiving the content segments from a unicast server.

[0012] The timing of requests for content segments by the client device may be different to the timing of the delivery of content segments on the multicast channel. Content segments may be delivered on the multicast channel as soon as they are produced by the content encoder, or very soon afterwards. However, while many client devices may request content segments soon after they have been transmitted on the multicast channel, some client devices may request them a little later. This may happen due to client design or user behaviour, for example by pausing playback for a short time, or “rewinding” to view a piece of content again.

[0013] If the proxy receives a request for a content segment from the client device a short while after the content segment was transmitted on the multicast channel, the proxy may be able to respond to the client device using data received on the multicast channel and stored in its cache. But the amount of storage on the proxy may be limited, and although the data requested by the client device may have been received on the multicast channel and stored in its cache, it may subsequently have been overwritten by data received on the multicast channel at a later time. In these solutions, the proxy may operate the cache in a first in first out manner, where, when the cache is full, a received content segment overwrites the oldest content segment in the cache, that is, it overwrites the content segment that was received the longest time ago.

[0014] If the client device is requesting content segments later than the capability of the cache, then the proxy will not be able to satisfy any of the requests from the client device using data delivered by multicast and stored in its cache. For example, if the cache can store five content segments, and the five content segments most recently received on the multicast channel have indices 1100, 1101 , 1102, 1103 and 1 104, then the cache will store these five content segments. But if the client device requests content segment 1099, because its requests are behind the delivery time on the multicast channel by just a little more than the capability of the cache, the proxy will not be able to respond to the client device using data that has been received on the multicast channel and stored in its cache. The proxy will have to satisfy the request from the client device by obtaining segment 1099 from the unicast server.

[0015] About one segment period later, the client device requests segment 1 100, but by this time segment 1105 has been received on the multicast channel and stored in the cache, overwriting segment 1 100 as the cache is operated in a first in first out manner. Again, the proxy will not be able to respond to the client device using data that has been received on the multicast channel and stored in its cache and will have to satisfy the request from the client device by obtaining the requested segment from the unicast server.

[0016] Thus, it can be seen that problems can arise under certain situations, where segment requests from a client device cannot be serviced by a proxy with cached segments received over multicast.

[0017] Summary of the Invention

[0018] It is the aim of examples of the present invention to provide improved methods of managing content segments received over multicast.

[0019] According to one example of the invention, there is provided a method as set out in claim 1. According to a further example of the invention, there is provided a network element as set out in claim 8.

[0020] Brief Description of the Drawings

[0021] For a better understanding of the present invention reference will now be made by way of example only to the accompanying drawings, in which:

[0022] Figure 1 system diagram showing the main components of an example of the present invention;

[0023] Figure 2 is a flow chart summarising the steps of an example of the invention;

[0024] Figure 3 is a flow chart summarising further steps of an example of the invention;

[0025] Figure 4 is a table showing an example of how a proxy manages the contents of its cache in response to receiving content segments proxy over a multicast channel and receiving requests for content segments from a client device;

[0026] Figure 5 is a diagram showing an example timing schedule of content segments on a multicast channel.

[0027] Description of Preferred Embodiments

[0028] The present invention is described herein with reference to particular examples. The invention is not, however, limited to such examples.

[0029] Described are improved methods of managing content delivery to a client device by a proxy in a hybrid unicast-multicast network. In such networks, multicast and unicast delivery are used, with a proxy inserted between a client and a content server. The proxy can join to a multicast channel, receive content segments over multicast, store these received segments in the cache, and provide these segments to the client when requested, packaged to look like unicast delivered segments. However, delivery of segments over multicast and managing the cache that stores received multicast segments need to be managed in a particular manner to optimise the use of the cache for satisfying unicast segment requests from the client. Described are various methods to optimise multicast delivery and associated cache management.

[0030] Figure 1 shows an adaptive bit rate (ABR) streaming system 100 comprising the main components of an example of the invention. The system 100 comprises a content source 102, a content encoder 104, a multicast transmitter 106, a unicast server 1 10, a proxy server 1 12 and a client device 114. The content source 102 provides content, such as a live sports or TV broadcast, in the form of video sequences to the content encoder 104. The proxy 1 12 may be located within a device such as a home gateway or router.

[0031] The client device 114 is assumed to be running a client application, which is the source of content requests. For simplicity, the term client device has been used to refer to a client device running a client application.

[0032] For simplicity, only one proxy 112 and one associated client device 1 14 has been shown in Figure 1 . However, there may be a plurality of the proxies connecting to the multicast transmitter 106, the unicast server 110, with each of the plurality of proxies having an associated one or more client devices 1 14 connected to it. Each of the plurality of proxies is connected and operable as described here with reference to proxy 112.

[0033] The proxy 1 12 may be located within a device such as a home gateway or router. The proxy 112 includes a cache for storing data.

[0034] The content encoder 104 receives the content from the content source 102 and encodes it using a suitable compression scheme, such as ITU-T Recommendation H.264 for video content, and segments the encoded content into a sequence of content segments, each content segment typically of duration 2 to 10 seconds. The content encoder 104 also encodes the content at one or more quality levels or bit rates, resulting in one or more (at each quality level) encoded content segments corresponding to each uncompressed content segment. Such an arrangement is typical of an adaptive bit rate streaming service.

[0035] The content encoder 104 passes the encoded content segment data, encoded at all of the required bit rates, to the unicast server 110 where the data is stored and made available for delivery by unicast. The unicast server 1 10 responds to unicast requests for content segments with unicast responses using the stored data.

[0036] The content segments encoded at one quality level, corresponding to one encoded bit rate, are passed to the multicast transmitter 106 for transmission by multicast to any devices that have subscribed to the respective multicast channel. However, the invention is not limited to this case, and also applies when content segments encoded at a plurality of quality settings, corresponding to a plurality of encoded bit rates, are passed to the multicast transmitter 106 for transmission by multicast on a plurality of multicast channels (one channel per quality setting).

[0037] The multicast transmitter 106 may start to transmit content segments before, at the same time, or after they have been made available on the unicast server 110. The multicast transmitter 106 may transmit content segments at a constant bit rate, approximately equal to their encoding rate, to fully utilise the multicast channel, or may transmit them at a faster rate, so that each content segment is delivered in less time that a segment period (where the segment period is the time period the client application takes to play out a segment of content). This would allow the proxy 112 to deliver a content segment to the client device 114 in less than a segment period when the client device 1 14 has requested the content segment soon after delivery of that content segment started on the multicast channel. Responding to a request from the client device 1 14 in less than a segment period may be needed to prevent the client device 114 interpreting a long time to deliver the content segment as a slow network connection and adapting to a lower encoded bit rate, which is not delivered on the multicast channel that the proxy 1 12 has joined.

[0038] The multicast transmitter 106 may be configured in one of various modes of operation.

[0039] In one mode of operation, the unicast server 110 monitors the requests for content segments made by a plurality of client devices. When the unicast server 110 determines that a sufficient number of client devices have requested the same content segment at about the same time, it instructs the multicast transmitter 106 to transmit the content segment on the multicast channel, in the expectation that it would subsequently be requested by additional client devices. The multicast transmitter 106 obtains the content segment from the unicast server 110 and converts the content segment data into a format suitable for multicast delivery, and then transmits it on the multicast channel to all devices that have subscribed to that multicast channel.

[0040] In another mode of operation, the multicast transmitter 106 is configured for specific content, such as a television channel, at a specific encoding quality level. Content segments encoded at the specific quality setting, corresponding to one encoded bit rate, are passed from the content encoder 104 to the multicast transmitter 106 for transmission by multicast to all the devices that have subscribed to the respective multicast source. However, the invention is not limited to these two configurations of the multicast transmitter 106.

[0041] Note, the most recent content segment transmitted by the multicast transmitter 106 is considered to represent the “live edge” of the video sequence.

[0042] The client device 114 can obtain a manifest file from the unicast server 110. Manifest files are used by client devices to identify where content segments are located (by a URL in the manifest). The client device 114 can then request these content segments in sequence using HTTP requests from the unicast server 110, and concatenate them to form a continuous stream of content segments for playback. As each content segment is available on the unicast server 110 at a plurality of encoded bit rates, the client device 110 determines for each content segment, the encoded bit rate (quality) at which to request it, taking into account such factors as the available network throughput and how much data is already received and buffered at the client device awaiting play-out.

[0043] Some HTTP requests made by the client device 114 for content will not make use of multicast delivery and are sent directly to the unicast server 110, which delivers the requested content by unicast. Other requests for content from the client device 114 that may benefit from multicast delivery are re-directed to, or simply intercepted by, the proxy 112, and can be handled in accordance with the examples described below.

[0044] The proxy 112 can be inserted in the HTTP path using any of a number of well-known techniques, such as using an HTTP redirection from the unicast server 110. In this case, the unicast server 110 would be configured such that requests for potentially popular content are not served directly but instead redirected to a suitable proxy. For example, instead of supplying a normal response, the unicast server 110 could respond with an HTTP status code 307 which indicates a temporary redirect. This invites the client device 114 to make a new request to the new URL supplied by the unicast server 110 in its response, thus enabling requests to be made to the proxy 112. This technique allows the unicast server 110 and the proxy 112 to exist in different domains, which would often be the case.

[0045] Other mechanisms to insert the proxy 112 in the HTTP path include: proxy configured as a transparent proxy (though all requests are intercepted by it, and only works with unencrypted traffic); proxy configured as a forward proxy (where the client device 114 sends its requests directly to the proxy by virtue of being explicitly configured to do so); DNS hijacking (where a DNS server is configured to supply the IP address of the proxy for domains of interest); and manifest manipulation (where the manifest file is re-written so that requests are made directly to the proxy).

[0046] The client device 114 could request and receive content segments from the unicast server 110 from the start to the end of a streaming session. However, in some cases the proxy 112 determines that multicast delivery could be used to receive some content segments.

[0047] The proxy 112 monitors unicast content requests from the client device 1 14 and is aware of when content requested by the client device 114 could be received by multicast.

[0048] The proxy 112 determines whether it should join a multicast channel to satisfy the client device’s requests for content using data that is delivered by multicast, and if so, joins the relevant multicast channel at an appropriate time. The proxy 112 receives content segments by multicast on the multicast channel and stores the received content segments in a cache. The proxy 1 12 responds to requests for content segments from the client device 1 14 using cached data, packaged as unicast content responses, whenever possible, and otherwise by requesting and receiving the content segments from the unicast server 110.

[0049] The client device 114 does not need to be aware of the proxy 112 and does not need to be aware of whether content is being delivered by unicast from the unicast server 1 10 via the proxy 1 12, or is delivered by multicast to the proxy 112 which then delivers the content to the client device 1 14 in a unicast format.

[0050] Described now are examples of how the proxy 1 12, when its cache of content segments is full and it starts to receive a content segment on the multicast channel, can determine whether to store the content segment it is starting to receive on the multicast channel in its cache, and if so, which content segment that is already stored in its cache should be overwritten with the new content segment data that is being received on the multicast channel.

[0051] Each content segment created by the content encoder 104 and stored at the unicast server 110 has an associated URL that the client device 1 14 can use to request the content segment. Each such content segment also has an associated segment identifier, SID (short for Segment Identifier). This may be created in any of many different ways, including but not limited to being part of the URL and being calculated from all or part of the URL, for example using a hash function. If the multicast transmitter 106 transmits the content segment on the multicast channel, it also transmits the SID associated with the content segment. This enables the proxy 112 to associate the URL of a request for a content segment from the client device 114 with the content segment data transmitted on the multicast channel and stored in its cache.

[0052] The multicast channel may be configured to have a higher bit rate, that is to say the multicast channel may be configured to transmit data at a higher bit rate, than the encoded bit rate of the content to be delivered on the multicast channel, so that each content segment is delivered in less time than a segment period. This allows the proxy 1 12 to deliver a content segment to the client device 114 in less than a segment period when the client device 114 has requested the content segment soon after delivery of that content segment started on the multicast channel. Responding to a request from the client device 114 in less than a segment period may be needed to prevent the client device 114 interpreting a long time to deliver the content segment as a slow network connection and adapting to a lower encoded bit rate, which may not be available on any multicast channel.

[0053] The multicast transmitter 106 may be configured to deliver older content segment data on the multicast channel in the gaps between new content segments that are currently being delivered. For example, if the multicast channel is configured to have a bit rate that is 1 .5 times the encoded bit rate of the content to be delivered on the multicast channel, each new content segment is delivered in two thirds of a segment period. The multicast transmitter 106 could deliver half of an older content segment during the remaining one third of a segment period that is not being used for transmissions on the multicast channel, and could deliver the second half of that older content segment during the remaining one third of the next segment period.

[0054] This is illustrated in Figure 5 which shows content segment data transmitted on the multicast channel, where the segment period is 6s, and the bit rate of the multicast channel is such that each content segment can be transmitted on the multicast channel in 4s. Content segments are numbered using sequential integers, and where the transmission of partial content segments is shown by appending the letter A to the content segment number to indicate the first half of a content segment, and the letter B is appended to the content segment number to indicate the second half of a content segment. The numbers below the content segments indicate the time in seconds, showing that content segments are transmitted in 4s and half content segments in 2s.

[0055] At time Os, transmission of the content segment labelled 7 starts. This completes at time 4s, at which retransmission of the content segment 3 starts. By time 6s, half of content segment 3 has been transmitted, with this half of content segment 3 labelled as 3A. Transmission of the content segment labelled 8 then starts, and this finishes at time 10s, at which time, retransmission of content segment s resumes, labelled as 3B. Transmission of 3Bcompletes at time 12s. This sequence repeats, firstly with content segments labelled 9 and 10 being transmitted for the first time, starting at time 12s and 18s respectively, and content segment 5 being retransmitted in two halves, labelled 5A(starting at 16s) and 5B(starting at 22s), and then with content segments labelled 11 and 12 being transmitted for the first time, starting at time 24s and 30s respectively, and content segment 7 being retransmitted in two halves, labelled 7A(starting at 28s) and 7B(starting at 34s).

[0056] The multicast transmitter 106 is configured to indicate for each content segment transmitted on the multicast channel the time that the content segment was first transmitted on the multicast channel, whether the content segment will be transmitted on the multicast channel again, and if so, the time of the next transmission of the content segment on the multicast channel. The multicast transmitter 106 may, for example, indicate this information by transmitting it on the multicast channel together with the content segment. Alternatively, as another example, it may indicate this information by publishing it on a web server.

[0057] When the proxy 112 starts to receive a content segment on the multicast channel, it determines the SID for the content segment, from data transmitted with the content segment on the multicast channel. Using the index m for this multicast content segment, the proxy 1 12 keeps a record of the segment identifier, SIDm. The proxy 112 also keeps a record of the time that the content segment was first transmitted on the multicast channel in the variable, SegFirstTxTimem, and stores the time of the next transmission of the content segment on the multicast channel in the variable, SegNextTxTimem, setting this to indicate it does not contain a valid value if the content segment will not be transmitted on the multicast channel again.

[0058] If the cache is not full, the proxy 1 12 stores content segment SIDmin the cache. If the cache is full, the proxy 112 determines whether to store the content segment SIDmin the cache, and if so, which content segment to delete to make space for it.

[0059] In a conventional implementation, when the cache is full the proxy 1 12 operates the cache in a first in first out manner, deleting the oldest content segment (the one with the oldest value of SegFirstTxTimek) from the cache, making space for the content segment SIDmthat is being received.

[0060] This method of managing the content of the cache works well when the client device 114 requests content segments soon after they have started to be delivered on the multicast channel, as they will be stored, or at least partially stored, in the cache at the time that they are requested, and hence these requests can be satisfied using data that is stored in the cache.

[0061] However, if the client device 1 14 requests content segments a longer time after they have started to be delivered on the multicast channel, further content segments will have been received on the multicast channel and stored in the cache, taking the place of content segments received on the multicast channel earlier, replacing them in a first in first out manner. So, when using this conventional method to manage the contents of the cache, the proxy 112 will be able to satisfy no requests from the client device 114 for content segments if these requests are made after the requested content segments have been removed from the cache. This scenario is discussed above in the background section.

[0062] There now follows a description of improved methods of managing the cache at the proxy 112, so that some requests for content segments can be satisfied using data stored in the cache, regardless of how long content segments are requested after the time they are received on the multicast channel, while continuing to be able to satisfy all requests for content segments using data stored in the cache when those requests are received soon after the time they are received on the multicast channel.

[0063] When the proxy 112 starts to receive a content segment on the multicast channel, it determines whether there is at least one reason not to store the content segment in its cache.

[0064] Firstly, proxy 1 12 determines not to store the content segment in the cache if the content segment is already stored in the cache. Secondly, proxy 112 determines not to store the content segment in the cache if the content segment represents content that is at least as old as content already requested by the client device 114. It may determine this by associating the age of content, that is, how long ago it was generated at the content source 102 and encoded by the content encoder 104, with the time that the content segment was first transmitted on the multicast channel. The proxy 112 may therefore compare the value of the variable SegFirstTxTimem, which stores the time that the content segment being received on the multicast channel was first transmitted on the multicast channel, with the corresponding value for the content segment most recently requested by the client device 114. If the client device 1 14 has not previously requested a content segment, or if the corresponding value is unknown, then the proxy 1 12 cannot make this second determination.

[0065] Thirdly, proxy 112 determines not to store the content segment in the cache if the content segment is indicated to be transmitted again before the client device 114 is expected to request it. The proxy 112 may determine when the client device 1 14 is expected to request the content segment using information collected for previous requests for content segments from the client device 1 14.

[0066] The proxy 112 may calculate the difference between the time that the client device 1 14 requested a specific content segment and the time that the specific content segment was first transmitted on the multicast channel. The variable RequestLag is used for this difference between the first transmission of a content segment on the multicast channel and the request for that content segment by the client device 1 14. The proxy 1 12 may calculate RequestLag for just one content segment, such as the most recently requested content segment, or may calculate it for more than one content segment, and determine an overall representative or average value of RequestLag from the plurality of calculated values of RequestLag, where the representative value may be calculated by any of various different methods, such as the mean, the mediam, a weighted average, including weighting the values for more recently requested content segments higher, and by using an infinite impulse response filter.

[0067] The proxy 112 may determine when the client device 1 14 is expected to request the content segment currently being received on the multicast channel as the sum of the first time that this content segment was transmitted on the multicast channel and the single value of RequestLag or the overall representative value of RequestLag. If the client device 1 14 has not previously requested a content segment, or if the proxy 1 12 is unable to determine at least one value of RequestLag, then the proxy 112 cannot make this third determination.

[0068] If the result of at least one of these three determinations is not to store the content segment currently being received on the multicast channel, the proxy does not store the content segment. Otherwise, the proxy 112 takes the following actions to determine whether to remove a content segment from the cache, and if so which one. If the proxy 112 determines to remove a content segment from the cache, it removes that content segment and stores the content segment currently being received on the multicast channel. Otherwise, the proxy does not store the content segment currently being received on the multicast channel.

[0069] The proxy 1 12 determines whether to remove the oldest content segment from the cache, that is, the content segment that was generated at the content source 102 and encoded by the content encoder 104 the longest time ago. It may determine the age of a content segment by associating the age with the time that the content segment was first transmitted on the multicast channel.

[0070] The proxy 1 12 determines to remove the oldest content segment from the cache if no request has yet been received from the client device 1 14 for a content segment.

[0071] The proxy 1 12 also determines to remove the oldest content segment from the cache if any of the content segments stored in the cache were first transmitted on the multicast channel at the same time as or before the content segment most recently requested by the client device 1 14 was first transmitted on the multicast channel. If the client device 114 requests content segments in the order they were was generated at the content source 102 and encoded by the content encoder 104, then the client device 1 14 will not request the same content segment that is most recently requested, and will not request any content segment generated and encoded before that content segment. So, any content segment meeting one or other of these conditions will not be requested by the client device 114 in the future, and hence can be removed from the cache without fear of causing a future “cache miss”. If the result of at least one of these two determinations is to remove the oldest content segment from the cache, the proxy 112 removes that content segment from the cache and stores the content segment currently being received on the multicast channel. Otherwise, the proxy 112 takes the following actions.

[0072] The proxy 112 determines whether to remove the newest content segment from the cache, that is, the content segment that was most recently generated at the content source 102 and encoded by the content encoder 104. Again, it may determine the age of a content segment by associating the age with the time that the content segment was first transmitted on the multicast channel.

[0073] The proxy 112 determines to remove the newest content segment from the cache if the content segment currently being received on the multicast channel is older than at least one of the content segments stored in the cache. The proxy 112 has already determined that the content segment currently being received on the multicast channel is newer than the content segment most recently requested by the client device 1 14, as are all of the content segments currently stored in the cache. So, all of the stored content segments and the one currently being received on the multicast channel are expected to be requested by the client device 1 14 in the future. By removing the newest content segment from the cache and replacing it with the older content segment currently being received on the multicast channel, the proxy 1 12 aims to make use of the newly cached content segment sooner than the one that is being replaced, and hence free up a space in the cache sooner, and thus make more efficient use of the cache.

[0074] The proxy 112 may determine that the content segment currently being received on the multicast channel is older than at least one of the content segments stored in the cache by comparing the value of the variable SegFirstTxTimem, which stores the time that the content segment being received on the multicast channel was first transmitted on the multicast channel, with the corresponding values for each content segment stored in the cache.

[0075] If the proxy 1 12 determines to remove the newest content segment from the cache, the proxy 1 12 removes that content segment from the cache and stores the content segment currently being received on the multicast channel. Otherwise, the proxy 112 does not store the content segment currently being received on the multicast channel. Turning now to the flow chart of Figure 2. The flow chart of Figure 2 summarises the steps of an example of the present invention in which the proxy 1 12 receives a request for a content segment from the client device 1 14, processes that request, and returns the requested data to the client device 114.

[0076] Starting at step 200, the proxy 1 12 receives a request for a content segment from the client device 114. The proxy 1 12 determines the segment identifier for this requested content segment from the URL of the request from the client device 114. The proxy 112 stores the segment identifier in the variable ClientReqIDr, the time that it received this request in the variable ClientReqTimer.

[0077] In step 202, the proxy 112 determines whether the content segment with segment identifier ClientReqIDr was received on the multicast channel, and if so, determines the time at which the content segment was first transmitted on the multicast channel. It stores this time in the variable LastReqFirstTxTime, setting it to indicate it does not have a valid value if the content segment has not been received on the multicast channel.

[0078] In step 204, the proxy 112 determines whether the content segment with segment identifier ClientReqIDr is currently stored in its cache. If so, flow passes to step 206, and otherwise flow passes to step 210.

[0079] In step 206, the proxy 112 responds to the request for the content segment from the client device 114 with the data that has been delivered by multicast and stored in its cache. The response is sent by unicast. Flow then passes back to step 200 to process the next content segment request.

[0080] In step 210, the proxy 112 makes a request to the unicast server 110 for the content segment requested by the client device 1 14 and receives the requested data.

[0081] In step 212, the proxy 112 responds to the request for the content segment from the client device 1 14 with the data that has been received from the unicast server 110 from step 210. The response is sent by unicast. Flow then passes back to step 200 to process the next content segment request.

[0082] T urning now to the flow chart of Figure 3. The flow chart of Figure 3 summarises the steps of an example of the present invention in which the proxy 112 has joined a multicast channel and receives a content segment on the multicast channel from the multicast transmitter 106. The proxy 112 then determines whether to store the content segment in its cache, and if so and the cache is already full, determines which content segment stored in the cache should be overwritten by the content segment that is being received.

[0083] Starting at step 300, the proxy 112 starts to receive a content segment on the multicast channel. The proxy 112 determines the segment identifier, SIDm, for this content segment from data received on the multicast channel with the content segment. This data received on the multicast channel also indicates the time that the content segment was first transmitted on the multicast channel, whether the content segment will be transmitted on the multicast channel again, and if so, the time of the next transmission of the content segment on the multicast channel.

[0084] In step 302, the proxy 1 12 stores the time that the content segment was first transmitted on the multicast channel in the variable, SegFirstTxTimem, and stores the time of the next transmission of the content segment on the multicast channel in the variable, SegNextTxTimem, setting this to indicate it does not contain a valid value if the content segment will not be transmitted on the multicast channel again. The proxy 112 associates these variables with the segment identifier, SIDm.

[0085] In step 304, the proxy 112 determines whether its cache is full, that is whether there is insufficient space remaining to store the content segment being received on the multicast channel without first having to remove one of the content segments that have already been received and stored. If the cache is full, flow passes to step 306, and otherwise flow passes to step 318, where the received content segment is stored.

[0086] In step 306, the proxy 112 determines whether there is at least one reason not to store the content segment in its cache as described earlier, and sets the parameter DoNotStoreSegment accordingly. In summary, DoNotSto reSegment is set to TRUE if one of more of the following are true, and is set to FALSE otherwise: the content segment, SIDm, being received on the multicast channel has SegFirstTxTimem less than or equal to LastReqFirstTxTime; the content segment, SIDm, being received on the multicast channel is already stored in the cache; the content segment, SIDm, being received on the multicast channel is indicated to be transmitted again before the client device 1 14 is expected to request it. This last test can be expressed as, if SegNextTxTimem < SegFirstTxTimem + Requesting then the content segment will be transmitted again before the client device is expected to receive it.

[0087] If DoNotStoreSegment s true, the content segment, SIDm, being received on the multicast channel is not stored in the cache and flow passes back to step 300 to process the next content segment received over multicast. Otherwise flow passes to step 308.

[0088] Note that flow passing to step 308 does not imply that the content segment, SIDm, being received on the multicast channel will be stored in the cache, as that decision is made by the proxy 1 12 later.

[0089] In step 308, the proxy 1 12 determines whether to remove the oldest content segment from as described earlier, and sets the parameter RemoveOldestSegment accordingly. In summary, RemoveOldestSegment is set to TRUE if one of more of the following are true and is set to FALSE otherwise: no request has yet been received from the client device 114 for a content segment; any of the content segments, SID,, stored in the cache have SegFirstTxTimei less than or equal to LastReqFirstTxTime.

[0090] If RemoveOldestSegment is TRUE, flow passes step 310. Otherwise flow passes to step 312.

[0091] In step 310, the proxy 112 identifies the content segment SIDestored in its cache with the earliest (smallest) value of SegFirstTxTimeeand deletes that content segment from its cache, where the index e is used in consideration of the word “earliest”. Flow passes to step 318.

[0092] In step 312, the proxy 112 determines whether to remove the newest content segment from the cache as described earlier, and sets the parameter RemoveNewestSegment accordingly. In summary, it is set to TRUE if the content segment, SIDm, being received on the multicast channel has SegFirstTxTirnemless than the value of SegFirstTxTimei for one or more content segments, SID,, stored in the cache; and is set to FALSE otherwise.

[0093] If RemoveNewestSegment is not true, the content segment, SIDm, being received on the multicast channel is not stored in the cache and flow passes back to step 300. Otherwise flow passes to step 314. In step 314, the proxy 112 identifies the content segment SIDi stored in its cache with the most recent (largest) value of SegFirstTxTimei and deletes that content segment from its cache, where the index / is used in consideration of the word “latest”.

[0094] In step 318, the proxy 1 12 stores the content segment with segment identifier SIDm, being received on the multicast channel, in its cache. Flow then passes back to step 300 to process the next content segment received over multicast.

[0095] An illustrated example of the behaviour of the proxy 112 will now be described with reference to Figure 4. Figure 4 is a table showing the content segments that are delivered to the proxy 112 over the multicast channel, the content segments that are stored in the cache at the proxy 1 12 at that time, the content segment that is being requested by the client device 1 14 at a particular time, and whether the content segment requested by the client device 114 was stored in the cache at the proxy 1 12 at the time of the request. Additionally, the relevant parameters and variables used in the methods described above are also shown.

[0096] Specifically, column 402 shows the time that the proxy 1 12 starts to receive a content segment on the multicast channel SegRxTime with column 404 showing the corresponding segment identifier SIDmof the received content segment. Column 406 shows the time that the content segment SIDmwas first transmitted on the multicast channel in the variable, SegFirstTxTimem. Column 408 shows the time of the next transmission of the content segment SIDmon the multicast channel in the variable, SegNextTxTimem. Column 410 shows the content segments that are stored in the cache after the corresponding content segment SIDmhas been received over multicast. For example, at time 4s, content segment 1097 is being received over multicast, and after processing, the cache stores segment 1097 (after deleting segment 1094).

[0097] Column 412, shows the time ClientReqTimerat which a request for a content segment is received from a client device 1 14, with the content segment identifier, ClientReqlDr, of the requested content segment shown in column 414. Column 416 shows the time at which the content segment was first transmitted on the multicast channel, LastReqFirstTxTime. Column 418 shows the status of the variable Served From Cache, which is used to indicate if the current request for a content segment from the client device 114 is satisfied using data stored in the cache at the proxy 112. In this example, the content segments have segment period equal to 6s, the cache at the proxy can store five content segments (giving a total play-out duration of 30s), and the client device 114 initially makes requests for content segments 26s after the content segments start to be transmitted on the multicast channel. The value of RequestLag is therefore 26s at this time.

[0098] The client device 114 may be making requests for content segments with this timing because, for example, the user paused the playing of content in the player application for a while or jumped back on the content timeline to watch some content again.

[0099] As the cache at the proxy 112 can only store 24s of content and the client device 1 14 is making requests for content segments 26s after the content segments start to be transmitted on the multicast channel, if the proxy 112 operated the cache in a conventional first in first out manner all of the time it would not be able to satisfy any of the requests for content segments from the client device 114 using data stored in its cache and would have to request all the data from the unicast server 110.

[0100] However, by using the methods described above, the proxy 1 12 can satisfy many of the requests for content segments from the client device 114 using data stored in its cache, and consequently reduces the requests required to the unicast server 110.

[0101] As shown in Figure 5, each content segment is transmitted on the multicast channel in 4s, and the remaining 2s of each segment period is used to retransmit other content segment data. In this example, every second content segment is retransmitted, with retransmission starting 22s (three segment periods and 4s) after the first transmission started, with half of the content segment being retransmitted in one 2s “gap” and the second half being retransmitted in the next 2s “gap”.

[0102] The example of Figure 4 will now be described with reference to the steps of the flowcharts shown in Figure 2 and Figure 3.

[0103] The proxy 112 has been receiving content segments on the multicast channel, determining, for each of these segments whether to store it, and receiving requests for segments from the client device 114, and responding to these using stored data whenever possible. The first row of Figure 4 shows that at a particular time the cache stores the five content segments with SID equal to 1098, 1096, 1094, 1095 and 1093. It also shows that at time -4s the proxy 1 12 receives a request from the client device 114 for the content segment with ClientReqlDrequal to 1095. As this content segment was first received on the multicast channel at time -30s (as the client device 114 is making requests for content segments 26s after they start to be received on the multicast channel), the proxy 1 12 sets the variable LastReqFirstTxTime to the value -30s (step 202). The proxy can determine a value of RequestLag (26s) as the difference between the time of this request (-4s) and the time that the requested segment was first delivered on the multicast channel (-30s).

[0104] At time 0s, the content segment with SID equal to 1100 starts to be received on the multicast channel. The cache is full (step 304). In step 306, the proxy 112 determines that DoNotStoreSegment is FALSE, because of each of the following three conditions: the content segment starting to be received on the multicast channel has SegFirstTxTime equal to 0s, which is not less than or equal to LastReqFirstTxTime which is -30s; the content segment starting to be received on the multicast channel is not already stored in the cache; and the content segment starting to be received on the multicast channel is not to be transmitted again.

[0105] In step 308, the proxy 112 determines the value of RemoveOldestSegment, which is TRUE if the client device 1 14 has not made any requests for content segments before this time, or if any of the content segments, SIDk, stored in the cache have SegFirstTxTimekless than or equal to LastReqFirstTxTime.

[0106] While the former condition is not true as the client device 114 has been making requests for content segments, the latter is true as three of the stored segments (with SIDkequal to 1093, 1094 and 1095) have SegFirstTxTimek(-42s, -36s and -30s) less than or equal to LastReqFirstTxTime, which is -30s. Consequently, the proxy 112 determines that RemoveOldestSegment is set to TRUE.

[0107] The proxy 1 12 identifies the content segment with SID equal to 1093 as the content segment stored in its cache with the earliest value of SegFirstTxTime and deletes that content segment from its cache (step 310). The proxy 1 12 stores the content segment with SID equal to 1100 in its cache (step 318).

[0108] At time 2s, the proxy 1 12 receives a request from the client device 114 for the content segment with ClientReqlDr equal to 1096 (step 200). As this content segment was received on the multicast channel at time -24s (as the client device 114 is making requests for content segments 26s after they start to be received on the multicast channel), the proxy 1 12 sets the variable LastReqFirstTxTime to the value -24s (step 202). The proxy can again determine a value of RequestLag (26s) as the difference between the time of this request (2s) and the time that the requested segment was first delivered on the multicast channel (-24s). While in this example this calculated value of RequestLag is the same as the previously calculated value, in practice the calculated values will often be different, and the proxy 1 12 will need to calculate a representative value of RequestLag from the individual calculated values, as described earlier.

[0109] As this requested content segment, 1096, is stored in the cache (step 204), the proxy 1 12 responds to the client device 1 14 with the stored data (step 206).

[0110] At time 4s, the content segment with SID equal to 1097 starts to be received on the multicast channel. This is indicated to be a retransmitted content segment that was first started to be transmitted on the multicast channel at time -18s. As before, the cache is full (step 304), the proxy 112 determines that DoNotStoreSegment is FALSE (step 306) and that that RemoveOldestSegment is TRUE (step 308). The proxy 112 deletes the oldest content segment, which has SID equal to 1094 (step 310) and stores the content segment with SID equal to 1097 in its cache (step 318).

[0111] At time 6s, the content segment with SID equal to 1 101 starts to be received on the multicast channel. This is indicated to be a content segment that will be retransmitted at time 28s. As before, the cache is full (step 304). But this time the proxy 112 determines that DoNotStoreSegment is TRUE (step 306) on the grounds that this content segment will be retransmitted on the multicast channel before it is expected to be requested by the client device 1 14. The proxy 112 determines this expected time at which this segment will be requested by the client device 114 by adding RequestLag (26s) to time at which this segment was first transmitted on the multicast channel SegFirstTxTime (6s) and getting the expected request time of 32s, which is after the next transmission time, SegNextTxTime, which is 28s.

[0112] At time 8s, the proxy 1 12 receives a request from the client device 114 for the content segment with SID equal to 1097 (step 200). The proxy 1 12 sets the variable LastReqFirstTxTime to the value -18s (step 202), and, as this requested content segment, 1096, is stored in the cache (step 204), the proxy 112 responds to the client device 114 with the stored data (step 206).

[0113] The client device 1 14 then stops requesting content segments until time 32s, at which time it requests the next content segment, with SID equal to 1098, which was first transmitted on the multicast channel at time -12s. The client device 114 may have stopped and then resumed requesting content segments in this way as a result of the user pressing pause, and later play, on the player application.

[0114] In the meantime, as shown in Figure 4, the proxy 1 12 continues to operate as before, receiving content segments on the multicast channel, and determining, according to the steps of Figure 3, whether to store them in the cache. The content segments with SID equal to 1 102 and 1104 are stored in the cache as this is the only time they will be received; the retransmitted content segments with SID equal to 1099 and 1101 are stored; and the content segments with SID equal to 1 103 and 1 105, which will be retransmitted, are not stored.

[0115] The only one of these content segments received on the multicast channel that is processed differently to those described earlier is the retransmitted content segment with SID equal to 1 101 . As before, the cache is full (step 304), and the proxy 112 determines that DoNotStoreSegment is FALSE (step 306). But this time the proxy 112 determines that RemoveOldestSegment is FALSE (step 308) because there is no content segment, SID,, stored in the cache that has SegFirstTxTime, less than or equal to LastReqFirstTxTime. In fact, the content segments stored in the cache at this time have SID, equal to {1098, 1099, 1 104, 1 102, 1100} and SegFirstTxTime, equal to {-12s, -6s, 24s, 12s, 0s}, while LastReqFirstTxTime is equal to -18.

[0116] The proxy 1 12 has effectively determined that all of the content segments stored in the cache would be requested by the client device 114 if it continues to request content segments in the order that they were first transmitted on the multicast channel, and hence there is no reason to delete the oldest of them.

[0117] In step 312, the proxy 112 determines that RemoveNewestSegment is TRUE, as the content segment, SIDm, being received on the multicast channel has SegFirstTxTimem(equal to 6s) less than the value of SegFirstTxTimei for one or more content segments, SID,, stored in the cache. In fact, as stated above, the content segments with SID, equal to {1 104, 1102} have SegFirstTxTimei equal to {24s, 12s}. The proxy 1 12 then deletes the content segment with SID equal to 1104 as this has the most recent (latest) SegFirstTxTimei (step 314) and stores the content segment with SID equal to 1 101 being received on the multicast channel in the cache (step 318).

[0118] The proxy 1 12 is effectively retaining content segments in the cache that the client device 114 is likely to request soon in preference to those the client device 114 is likely to request later. This choice allows a cached content segment to be used sooner, and hence will create space in the cache sooner, and hence make more efficient use of the cache.

[0119] The client device 114 resumes making requests for content segments at time 32s when it requests the content segment with SID equal to 1098, which was first transmitted on the multicast channel at time -12s. After the pause in making requests, the client device 114 is making requests for content segments 44s after they were first transmitted on the multicast channel. But despite this, due to keeping older content segments in the cache, and storing the retransmitted content segments in the cache, the proxy is able to satisfy this and some subsequent requests from the client device 114 for content segments using data stored in the cache.

[0120] The system continues to operate in this way, with the proxy 112 storing all segments received on the multicast channel except those that will be retransmitted, and satisfying all requests for content segments from the client device 1 14 using stored data, until time 68s when the client device 1 14 requests the content segment with SID equal to 1104. This is the content segment that the proxy deleted from the cache at time 28s to make space for the retransmitted content segment with SID equal to 1101. However, that decision was correct as the client device 114 requested the content segment with SID equal to 1101 at time 50s, the proxy 1 12 satisfied the request using stored data, and then made this space in the cache available for storing another content segment, which it did by storing the content segment with SID equal to 1 105 at time 52s.

[0121] As this content segment with SID equal to 1104 is not stored in the cache (step 204), the proxy 112 requests it from the unicast server 1 10 (step 210) and forwards the response to the client device 1 14 (step 212).

[0122] At time 72s, the content segment with SID equal to 1112 starts to be received on the multicast channel. This is indicated to be a content segment that will not be retransmitted. The cache is full (step 304). The proxy 112 determines that DoNotStoreSegment is FALSE (step 306) because the content segment being received on the multicast channel is not older than the most recent content segment requested by the client device 1 14, the content segment is not already stored in the cache, and the content segment will not be retransmitted on the multicast channel. The proxy 112 determines that RemoveOldestSegment is FALSE because no content segment stored in the cache is older than the most recent content segment requested by the client device 114 (step 308). The proxy 112 determines that RemoveNewestSegment is FALSE because the content segment being received on the multicast channel is not older than any content segment stored in the cache (step 312). Hence the proxy 112 determines not to store the content segment that is being received on the multicast channel despite the fact it will not be retransmitted, because all of the segments stored in the cache are expected to be requested by the client device 114 before the content segment that is being received on the multicast channel is expected to be requested by the client device 114.

[0123] This will lead to a “cache miss” at time 1 16s if the client device 1 14 continues to request consecutive content segments at intervals of the segment period. But storing the content segment with SID equal to 11 12 in the cache in place of one of the content segments stored in the cache would be worse, as a request for the replaced content segment would cause a “cache miss”, and that “cache miss” would happen sooner.

[0124] It is not possible to satisfy all requests for content segments from the client device 1 14 using data stored in the cache as the cache is not large enough considering the timing of the requests from the client device 114, even with some of the content segments being retransmitted. In this example, the proxy 1 12 operates the cache so that it stores two retransmitted content segments and three content segments that will not be retransmitted, but as just described, determines not to store every fourth content segment that will not be retransmitted. All retransmitted content segments result in “cache hits”, and three of every four requests for content segments that will not be retransmitted result in “cache hits”, so that the proxy 112 can satisfy seven out of every eight requests from the client device 1 14 for content segments using stored data, and only has to request one out of every eight from the unicast server 110. By operating in this way, the proxy 1 12 makes good use of the content segments delivered on the multicast channel, considering the cache can store 30s of content segment data and the client device 1 14 is making requests for content segments 44s after they are first transmitted on the multicast channel. Examples of the invention are realised, at least in part, by executable computer program code which may be embodied in an application program data. When such computer program code is loaded into the memory of a processor in the proxy 112, it provides a computer program code structure which is capable of performing at least part of the methods in accordance with the above-described examples.

[0125] A person skilled in the art will appreciate that the computer program structure referred to can correspond to the flow chart shown in Figure 2 and Figure 3, where each step of the flow chart can correspond to at least one line of computer program code and that such, in combination with the processor in the proxy 1 12, provides apparatus for effecting the described process.

[0126] In general, it is noted herein that while the above describes examples of the invention, there are several variations and modifications which may be made to the described examples without departing from the scope of the present invention as defined in the appended claims. One skilled in the art will recognise modifications to the described examples.

Claims

CLAIMS1. A method of managing content delivery to a client device (1 14) by a network element (112), said content comprising a sequence of segments, said network element comprising a store, and said method comprising: i) receiving (300) a plurality of segments over multicast, wherein some segments are received over multicast once and some segments are received over multicast more than once, and storing (302) one or more of the plurality of segments in a store; ii) receiving (200) a unicast request for a segment from the client device; iii) determining (204) whether the requested segment has been received over multicast and stored in the store, and if so, then obtaining (206) the requested segment from the store, otherwise obtaining (210) the requested segment by requesting and receiving the requested segment from a unicast content source; iv) transmitting (212) the obtained segment to the client device by unicast; v) receiving a further segment over multicast (300), wherein said further segment is associated with a first time value indicating when that segment was first transmitted over multicast and a second time value indicating when that segment will be transmitted over multicast again; vi) determining (306), in dependence on one or more of the time values, whether to replace a stored segment with the further segment received over multicast and replacing the stored segment with the further segment.

2. A method according to claim 1 , wherein it is determined not to replace a stored segment when the second time value of the further segment received over multicast is earlier than the time at which the further segment received over multicast is expected to be requested by the client device.

3. A method according to claim 2, wherein a lag is determined as the difference between the time at which the client device requested a previous segment and the first time value of said previous segment, and wherein the expected time is determined as the sum of the lag and the first time value of the further segment received over multicast.

4. A method according to claim 2, wherein a plurality of values of lag are determined for a plurality of segments previously requested by the client device, wherein each of the plurality of values of lag are determined in dependence as the difference between the time at which the client device requested one of the plurality of previous segments and the firsttime value of that segment, wherein a representative value of lag is determined in dependence on the plurality of values of lag, and wherein the expected time is determined as the sum of the representative value of lag and the first time value of the further segment received over multicast.

5. A method according to claim 4, wherein the representative value of lag is calculated as an average of the plurality of values of lag.

6. A method according to claim 1 , wherein it is determined not to replace a stored segment when the first time value of the further segment received over multicast is earlier than or equal to the first time value of the segment requested by the client device.

7. A method according to claim 1 , wherein it is determined to replace a specific stored segment when the first time value of the segment received over multicast is earlier than the first time value of the specific stored segment.

8. A network element (112) for managing content delivery to a client device (1 14), said content comprising a sequence of segments, said network element comprising a store and further adapted in operation to: receive (300) a plurality of segments over multicast, wherein some segments are received over multicast once and some segments are received over multicast more than once, and storing (302) one or more of the plurality of segments in a store; receive (200) a unicast request for a segment from the client device; determine (204) whether the requested segment has been received over multicast and stored in the store, and if so, then obtain (206) the requested segment from the store, otherwise obtain (210) the requested segment by requesting and receiving the requested segment from a unicast content source; transmit (212) the obtained segment to the client device by unicast; receive a further segment over multicast (300), wherein said further segment is associated with a first time value indicating when that segment was first transmitted over multicast and a second time value indicating when that segment will be transmitted over multicast again; determine (306), in dependence on one or more of the time values, whether to replace a stored segment with the further segment received over multicast and replacing the stored segment with the further segment.

Images