WO2025201779A1

WO2025201779A1 - Multicast caching method

Info

Publication number: WO2025201779A1
Application number: PCT/EP2025/055132
Authority: WO
Inventors: Michael Nilsson; Stephen Appleby; Rory TURNBULL; Timothy Stevens
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2024-03-26
Filing date: 2025-02-26
Publication date: 2025-10-02
Anticipated expiration: 2026-09-26

Abstract

Described are improved methods of managing the cache at 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, the cache that stores received multicast segments needs 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 manage the cache by determining when to store a segments received over multicast and if necessary, which stored segment to delete from the cache, taking into account the relative timings of when segments are received over multicast and when unicast requests are received.

Description

MULTICAST CACHING METHOD

Field of the Invention

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.

Background to the Invention

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.

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.

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.

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.

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.

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

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.

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.

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.

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 four content segments, and the four content segments most recently received on the multicast channel have indices 1100, 1101 , 1102, and 1 103, then the cache will store these four 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.

About one segment period later, the client device requests segment 1 100, but by this time segment 1104 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.

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.

Summary of the Invention

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

According to one example of the invention, there is provided a method as set out in claim 1. It may be determined to delete a specific stored segment and it is determined to store the further segment when the specific stored segment was received over multicast before or at the same time as the most recent segment requested by the client device was received over multicast.

It may be determined not to delete a specific stored segment and it is determined not to store the further segment when the most recent segment requested by the client device was received over multicast before all the stored segments were received over multicast.

It may be determined to delete the specific stored segment that is the segment most recently received over multicast and it is determined to store the further segment when the most recent segment requested by the client device was received over multicast before all the stored segments were received over multicast.

The network element may be a proxy server.

According to a further example of the invention, there is provided a network element as set out in claim 6.

Brief Description of the Drawings

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

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

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

Figure 3 is a flow chart summarising further steps of an example of the invention; Figure 4 is a table showing an example of how a proxy manages the contents of its cache.

Description of Preferred Embodiments

The present invention is described herein with reference to particular examples. The invention is not, however, limited to such examples. Described are improved methods of managing the cache at a proxy in a hybrid unicastmulticast 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, the cache that stores received multicast segments needs 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 manage the cache by determining when to store a segments received over multicast and if necessary, which stored segment to delete from the cache, taking into account the relative timings of when segments are received over multicast and when unicast requests are received.

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.

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.

For simplicity, only one proxy 112 and one associated client device 1 14 has been shown in Figure 1 . In practice, there may be a plurality of the proxies connecting to the multicast transmitter 106 and the unicast server 1 10, with each of the plurality of proxies having an associated one or more client devices 1 14

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

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

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. This would allow the proxy 112 to deliver a content segment to the client device 1 14 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 1 14 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.

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

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.

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.

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

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 1 14 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.

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 1 14 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.

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 1 10 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 1 12. This technique allows the unicast server 1 10 and the proxy 112 to exist in different domains, which would often be the case.

Other mechanisms to insert the proxy 1 12 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).

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.

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.

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.

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

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.

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, SID_m, and the time that it starts to receive the content segment on the multicast channel, SegRxTime_m, being short for segment receive time.

If the cache is not full, the proxy 1 12 stores content segment SID_m in the cache.

If the cache is full, the proxy 112 determines whether to store the content segment SID_m in the cache, and if so, which content segment to delete to make space for it.

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 that was received and stored longest ago) from the cache, making space for the content segment SID_m that is being received. 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.

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 not be able to satisfy requests from the client device 1 14 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.

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.

In a first improved method, the proxy 1 12 always stores a content segment received on the multicast channel in its cache, and if the cache is full, determines which content segment to delete to make space for the content segment being received. If no request for a content segment has been received from the client device 114, the proxy 1 12 operates the cache in a first in first out manner, removing the content segment that has been in the cache the longest. If one or more requests for content segments have been received from the client device 114, the proxy 112 considers whether the most recent request was satisfied using data stored in the cache, or whether the data was not stored in the cache and had to be obtained from the unicast server 110 before forwarding to the client device 114.

If the most recent request from the client device 114 for a content segment was satisfied using data stored in the cache, the proxy 1 12 again operates the cache in a first in first out manner, removing the content segment that has been in the cache the longest, and storing the new content segment being received.

However, if the most recent request from the client device 114 for a content segment was not satisfied using data stored in the cache and instead the data had to be obtained from the unicast server 110, then the proxy 112 operates the cache in a last in first out manner. That is, the proxy 1 12 removes the content segment that has been in the cache for the shortest period of time, or in other words, the content segment that was most recently added to the cache, and stores the new content segment being received.

By acting in this way following a “cache miss”, the cache retains older content segments which are expected to be requested by the client device 114 in due course.

This first improved method can be illustrated with the following example. Assuming the cache can store four content segments, and the four content segments most recently received on the multicast channel have indices 1100, 1 101 , 1102, and 1103, then the cache will store these four content segments. Content segment 1103, being the most recently received of the four segments, can be considered as being at the “live edge” of the video sequence. The client device 114 makes a content segment request that lags behind the live edge (e.g. the client device has rewound playback in time to an older portion of the video sequence) by just over 4 segment periods, thus makes a request for content segment 1099. The proxy 1 12 will not be able to respond to this request with any of the segments stored in its cache, but instead has to obtain segment 1099 from the unicast server. About one segment period later, the client device requests the next segment, segment 1100. However, by this time segment 1104 has already been received on the multicast channel.

Using a conventional first in first out approach, receipt of segment 1104 would cause segment 1100 to be removed from the cache and segment 1104 stored in its place, which would result in requested segment 1 100 being obtained from the unicast server 110. Requests for subsequent segments (1101 , 1102 etc) would be satisfied in the same manner, as the cache would be still be updated in a first in first out manner, continuously removing older segments, and so none of the requests would be satisfied from data stored in the cache. However, using the first improved method, when the segment 1 104 is received on the multicast channel, because the previous request from the client device 114 for content segment 1099 could not be satisfied using data stored in the cache, the proxy 112 operates the cache in a last in first out manner, and thus removes segment 1 103 (the content segment that has been in the cache for the shortest period of time) and stores segment 1104. The cache now contains the content segments with indices 1100, 1 101 , 1 102, and 1 104. Thus, the request for segment 1100 can be satisfied with segment 1100 that is still stored in the cache. Indeed, by adopting the first improved method in this example of a 4 segment cache, 75% of the requests for content segments from the client device 114 can be satisfied using stored data (compared to no requests when a conventional first in first out method is used)

In a second improved method, the proxy 112 operates as in the first improved method, except when the most recent request from the client device 114 for a content segment was not satisfied using data stored in the cache and the data had to be obtained from the unicast server 110. Instead of storing the content segment being received on the multicast channel in place of the content segment that was most recently added to the cache (“last in first out”), the proxy does not store the content segment being received on the multicast channel at all.

By acting in this way following a “cache miss”, the entire capacity of the cache is used for storing older content segments, which are expected to be requested by the client device 1 14 in due course. With reference to the worked example above, all four of the stored content segments can be used to respond to subsequent requests for content segments from the client device 114, while every fifth request will result in a “cache miss”. This approach thus allows 80% of the requests for content segments from the client device 1 14 to be satisfied using stored data. Later in the description, the term “Discard Multicast Segment” mode is used to describe the second method of operating the cache.

However, there are certain circumstances in which the first and second improved methods have limitations. These include the case of the client device 1 14 changing the timing of its requests for content segments, so that it instead makes requests for content segments nearer to the time at which the content segments start to be received on the multicast channel. The client device 1 14 may make such a change to the timing of its requests for content segments, for example, in response to the user interacting with the video player application to move towards the live edge of the content stream from an older portion of the content stream.

When the client device 114 is making requests for content segments near to the time at which they start to be received on the multicast channel, it is possible to satisfy all these requests using stored data if the cache is operating in the conventional first in first out manner all the time.

When either of the first two improved methods are used, if at the time the client device changes the timing of its content segment requests (e.g. from an older to a newer segment) the cache contains the requested content segment and all the content segments that started to be received on the multicast channel after the requested content segment, the request and all subsequent content segment requests will be a “cache hit”. The proxy 1 12 will then operate the cache in a first in first out manner, and the next request will also be a “cache hit”, and again the proxy 1 12 will operate the cache in a first in first out manner, and so on. The proxy 112 will be able to satisfy all subsequent requests using stored data.

However, if at the time the client device changes the timing of its content segment requests (e.g. from an older to a newer segment) the cache does not contain the requested content segment or if the cache does not contain all the content segments that started to be received on the multicast channel after the requested content segment, then the proxy 112 will not be able to satisfy all subsequent requests using stored data. This is because when the client device 1 14 requests a content segment that is not stored in the cache, the proxy 1 12 will operate the cache in a last in first out manner and delete a content segment that the client device 114 will request later. And when the client device 1 14 does request this deleted content segment, the same will happen again.

Consider the case above of the cache containing the content segments with indices 1 100, 1 101 , 1 102, and 1 104, and the client device 114, instead of requesting content segment 1 100 next, jumps a little towards the “live edge” and requests content segment 1102. This is stored in the cache, and so the request can be serviced using stored data. The proxy 1 12 then receives content segment 1105 on the multicast channel. As the previous request from the client device 1 14 was satisfied using stored data, the proxy 112 operates the cache in a first in first out way, removing content segment 1 100 and storing content segment 1 105. The cache now contains content segments 1 101 , 1 102, 1104 and 1 105. The client device 1 14 then requests the next content segment, with index 1103. But this is not stored in the cache and so must be obtained from the unicast server 110. When the proxy 112 then receives content segment 1106 on the multicast channel, it either operates the cache in a last in first out way, removing content segment 1105, or, if operating in “Discard Multicast Segment” mode, does not store content segment 1106 that is being received on the multicast channel. Consequently, later, when the client device 114 requests content segment 1 105 (or 1106 if the proxy 1 12 is operating in “Discard Multicast Segment” mode), the proxy 1 12 will not be able to satisfy the request using stored data and so must obtain it from the unicast server 1 10. And this pattern of periodic “cache misses” will continue.

Hence, a third improved method is presented. In this method the proxy 1 12, when starting to receive a content segment on the multicast channel, determines whether any of the content segments stored in the cache started to be received on the multicast channel earlier than or at the same time as the time that the previous content segment requested by the client device 114 started to be received on the multicast channel. If there is such a content segment, the proxy 112 deletes that content segment from the cache, or if there is more than one such content segment, the proxy 112 deletes any one of those content segments from the cache. In the latter case, it may, for example, always delete the one of those content segments that was received first on the multicast channel.

When operating in this way, in the example above, when the proxy 112 receives content segment 1 106 on the multicast channel, the cache contains content segments 1 101 , 1102, 1 104 and 1 105, and the client device 1 14 has most recently requested content segment 1 103. The proxy 1 12 determines that content segments 1 101 and 1102 were received on the multicast channel before content segment 1 103, and hence determines to remove one of these two content segments from the cache. For example, it removes content segment 1 101 and stores content segment 1106 that is being received on the multicast channel. The cache then contains content segments 1102, 1104, 1 105 and 1106. Subsequent requests for content segments from the client device 114 can be satisfied using data stored in the cache, and the cache continues by operating in a first in first out way.

Note that to do this, the proxy 1 12 needs to store the time at which content segments started to be received on the multicast channel, including for content segments that it has deleted from the cache. However, there is no need to retain this data for content segments that are older than any content segment still stored in the cache, that is, there is no need to retain this data for content segments that were received on the multicast channel before all the content segments still stored in the cache were received on the multicast channel.

In the case that the client device 114 requests a content segment that was transmitted on the multicast channel before all the content segments in the cache were transmitted on the multicast channel, the proxy 1 12 may not have a record of the time that the requested content segment was transmitted on the multicast channel. Hence the proxy 1 12 cannot determine explicitly whether any of the content segments stored in the cache started to be received on the multicast channel earlier than or at the same time as the time that the previous content segment requested by the client device 1 14 started to be received on the multicast channel. However, the proxy 1 12 could determine this implicitly from knowing that it does not know the transmission time of the requested segment, and hence that time is earlier then the transmission time of the content segments stored in the cache. Therefore, in this case the proxy 1 12 determines implicitly that there is no such stored content segment, and consequently operates the cache in the last in first out manner.

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.

Starting at step 200, the proxy 1 12 receives a request for a content segment from the client device 114. The proxy 112 determines the segment identifier, SID_r, for this requested content segment from the URL of the request from the client device 1 14.

In step 202, the proxy 112 determines whether the content segment with segment identifier SIDr has previously been received on the multicast channel, and if so, determines the time at which it was received. It stores this time in the variable LastReqSegRxTime, setting it the corresponding SegRxTime_m, if the content segment has previously been received on the multicast channel, or setting it to indicate it does not have a valid value if the content segment has not been received on the multicast channel.

In step 204, the proxy 112 determines whether the content segment with segment identifier SID_r is currently stored in its cache. If so, flow passes to step 206, and otherwise flow passes to step 210. 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.

In step 208, the proxy 112 sets the variable ServedFromCache to TRUE to indicate that the most recent request for a content segment from the client device 114 has been satisfied using data stored in the cache at the proxy 1 12. Flow then passes back to step 200 to process the next content segment request.

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.

In step 212, the proxy 112 responds to the request for the content segment from the client device 114 with the data that has been received from the unicast server 1 10. The response is sent by unicast.

In step 214, the proxy 112 sets the variable ServedFromCache to FALSE to indicate that the most recent request for a content segment from the client device 1 14 has not been satisfied using data stored in the cache at the proxy 112, but instead was satisfied with data received from the unicast server 110. Flow then passes back to step 200 to process the next content segment request.

Turning 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 1 12 receives a content segment on the multicast channel from the multicast transmitter 106, 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.

Starting at step 300, the proxy 1 12 joins a multicast channel and starts to receive a content segment on the multicast channel. The proxy 1 12 determines the segment identifier, SID_m, for this content segment from data received on the multicast channel with the content segment. Flow then passes to step 302. In step 302, the proxy 112 stores the time that it starts to receive the content segment on the multicast channel in the variable, SegRxTirne_m, being short for segment receive time, and associates it with the segment identifier, SID_m. Flow then passes to step 304.

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.

In step 306, the proxy 112 determines whether the variable Served From Cache is TRUE, and if so, flow passes to step 308, and otherwise flow passes to step 310.

In step 308, the proxy 112 identifies the content segment stored in its cache that has the earliest value of segment receive time. This content segment with index e (in consideration of “earliest”) has segment identifier SID_e, and an associated segment receive time SegRxTime_e. When the variable Served From Cache is TRUE, the most recent content segment requested by the client device 114 was stored in the cache, and hence it is appropriate to operate the cache in the conventional first in first out manner. Flow then passes to step 318.

In step 310, the proxy 112 determines whether there is a content segment with index k that has segment receive time, stored in SegRxTime_k, earlier than or the same as LastReqSegRxTime. If so, flow passes to step 312, and otherwise flow passes to step 314. By doing this, the proxy 112 is determining whether any of the content segments stored in the cache were received on the multicast channel earlier or at the same time as the content segment most recently requested by the client device 114. Such a content segment is unlikely to be requested by the client device 114 as it is either the one that it has most recently been requested or it represents an earlier piece of content than the content segment that it has most recently been requested. The content segment with index and Segment Identifier SID_k is in this case a good candidate to be removed from the cache at the proxy 112 to make space for the content segment that is being received on the multicast channel.

In step 312, the proxy 112 deletes the content segment with the segment identifier SID_k from its cache. Flow then passes to step 318. In step 314, the proxy 112 considers the mode in which it is operating, and if it is operating in the “Discard Multicast Segment” mode, flow passes back to step 300 (to process the next segment received over multicast), and the content segment being received on the multicast channel is not stored in the cache of the proxy 112 and instead is simply discarded. Otherwise flow passes to step 316.

When the variable ServedFromCache is FALSE, the most recent content segment requested by the client device 114 was not stored in the cache, and hence it is not appropriate to operate the cache in the conventional first in first out manner. Instead, it is better to keep the content segments currently cached in the expectation that in due course they will be requested by the client device 1 14. In “Discard Multicast Segment” mode the content segment being received on the multicast channel is discarded, whereas otherwise the cache operates in a last in first out manner in step 316.

In step 316, the proxy 1 12 identifies the content segment stored in its cache that has the latest value of segment receive time, and deletes this content segment from its cache. This content segment with index / (in consideration of “latest”) has segment identifier SIDi, and segment receive time SegRxTimei. Flow then passes to step 318.

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

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 1 12 over the multicast channel, the segments stored in the cache at the proxy 1 12 at that time, and various parameters used in the methods described above.

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 SID_m of the received content segment. Column 406 shows the content segments that are stored in the cache after the corresponding content segment has been received over multicast. For example, at time 2s, content segment 1100 is being received over multicast, and after processing, the cache stores segment 1100. Column 408, shows the time at which a request for a content segment is received from a client device, with the content segment identifier of the requested content segment shown in column 410. Column 412 shows the time at which the same content segment (requested in column 410) was previously received on the multicast channel (if at all), which is represented by the variable LastReqSegRxTime. Column 414 shows the status of the variable ServedFromCache, which is used to indicate if the most recent request for a content segment from the client device 114 was satisfied using data stored in the cache at the proxy 112.

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

In this example, the content segments have segment period equal to 6s, the cache at the proxy 1 12 can store four content segments (with play-out duration of 24s), and the client device 1 14 initially makes requests for content segments 27s after the content segments start to be transmitted on the multicast channel. The client device 1 14 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.

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 27s 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.

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 not have to request them from the unicast server 110.

In this example, the proxy 112 is not operating in “Discard Multicast Segment” mode. Thus, the proxy 1 12 stores in its cache every content segment that is received on the multicast channel, and when the cache is full, determines, in accordance with the behaviours described above, which content segment to delete from the cache to make space for the content segment that is being received on the multicast channel.

Initially, the proxy 1 12 joins the multicast channel and no content segments are stored in its cache. At time 2s, the content segment with SID_m equal to 1100 starts to be received by the proxy 112 on the multicast channel (step 300). The proxy 112 stores the time that this content segment started to be received (2s) in the variable SeqRxTime_m and associates it with SID_m (step 302). As the cache is not full (step 304), the proxy 112 stores this content segment 1 100 in its cache (step 318).

At time 5s, the proxy 1 12 receives a request from the client device 114 for the content segment with SID_r equal to 1096 (step 200). As this content segment has not been received on the multicast channel, the proxy 1 12 cannot determine the time at which it was transmitted on the multicast channel, and hence sets the variable LastReqSegRxTime to indicate it does not have a valid value, shown in Figure 4 as a blank entry in column 412.

Additionally, as this content segment 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 114 (step 212) over unicast. The proxy 1 12 sets the flag ServedFromCache to FALSE (step 214).

The next three rows of Figure 4 show similar behaviour from the proxy 112, as content segments are received on the multicast channel, and stored in the cache which is not yet full as it can store four content segments. The client device 1 14 continues to request content segments that are not cached, the proxy 112 obtains them from the unicast server 110 and forwards them to the client device 114 over unicast. LastReqSegRxTime continues to indicate it does not have a valid value.

At time 26s, the content segment with SID_m equal to 1 104 starts to be received by the proxy 112 on the multicast channel (step 300). The proxy 112 stores the time that this content segment started to be received (26s) in the variable SeqRxTime_m and associates it with SID_m (step 302). This time as the cache is full (step 304), the proxy 112 determines whether there is a content segment with index k that has segment receive time, stored in SegRxTimek, earlier than or the same as LastReqSegRxTime (step 306). But as LastReqSegRxTime does not have a valid value, the conclusion of the determination is no.

The proxy 112 then considers the flag Served From Cache and observes that it is set to FALSE (step 310).

As the proxy 112 is not operating in “Discard Multicast Segment” mode (step 314), the proxy 112 operates the cache in a last in first out manner. The proxy 112 identifies the content segment with the segment identifier, SIDi equal to 1103 as the content segment stored in its cache that has the latest (most recent) value of SegRxTimei and deletes this content segment from its cache (step 316).

The proxy 112 stores the content segment being received on the multicast channel in its cache (step 318), with segment 1104 effectively taking the place in the cache of segment 1103. Thus, the cache operates in a last in first out manner.

At time 29s, the proxy 112 receives a request from the client device 114 for the content segment with SID_r equal to 1100 (step 200). As this content segment was received on the multicast channel at time 2s, the proxy 112 sets the variable LastReqSegRxTime to the value 2s (step 202).

Further, this requested content segment 1100 is stored in the cache (step 204), so the proxy 112 responds to the client device 114 with the stored data (step 206). The proxy 112 sets the flag ServedFromCache to TRUE (step 208).

At time 32s, the content segment with SID_m equal to 1105 starts to be received by the proxy 112 on the multicast channel (step 300). The proxy 112 stores the time that this content segment started to be received (32s) in the variable SeqRxTirne_m and associates it with SID_m (step 302). The cache is now again full (step 304). The proxy 112 considers the flag ServedFromCache and observing that it is set to TRUE (step 306) proceeds to step 308 where the proxy 112 deletes the segment 1100 from its cache.

Hypothetically, if this comparison in step 306 had not been done, and flow had arrived at step 310, the proxy 112 would have considered whether there was a content segment with index k that had segment receive time, stored in SegRxTimek, earlier than or the same as LastReqSegRxTime (step 310). As LastReqSegRxTime had the value 2s, the same as the value of segment receive time for segment 1100, the conclusion of the determination would have been yes, and the proxy 1 12 would have deleted the segment 1 100 from its cache (step 308).

In both these cases the proxy 1 12 is operating the cache in a first in first out manner.

The proxy 112 stores the content segment being received on the multicast channel in its cache (step 318), with segment 1 105 effectively taking the place in the cache of segment 1 100.

These recent results are repeated twice with the client device 1 14 requesting content segments 1101 and 1 102, the proxy 112 finding these stored in its cache and forwarding them to the client device 114; and content segments 1106 and 1107 being received on the multicast channel and being stored in the cache, which the proxy 1 12 operates in a first in first out manner, replacing the earliest received content segments 1101 and 1102.

Then at time 47s, the proxy 1 12 receives a request from the client device 1 14 for the content segment with SID_r equal to 1 103 (step 200). As this content segment was received on the multicast channel at time 20s, the proxy 112 sets the variable LastReqSegRxTime to the value 20s (step 202).

As this content segment is not stored in the cache (step 204), the proxy 112 requests it from the unicast server 110 (step 210) and forwards the response to the client device 114 (step 212). The proxy 112 sets the flag Served From Cache to FALSE (step 214). This content segment had been received on the multicast channel, starting at time 20s, but had been overwritten by content segment 1104 at time 26s when the cache was being operated in a last in first out manner.

However, this is the desired behaviour, as it is not possible to satisfy all requests for content segments from the client device 114 using data stored in the cache, as the cache is not large enough considering the timing of the requests from the client device 114. Being able to satisfy three out of four requests from the client device 1 14 using data stored in the cache is much better than being able to satisfy none of the four requests using data stored in the cache when always operating the cache in the conventional first time first out manner. As before, the absence of a requested segment in the cache causes the proxy 1 12 to operate the cache in a last in first out manner when the next content segment starts to be received on the multicast channel, with the new content segment 1108 overwriting the most recently received content segment 1107. This again allows the other content segments stored in the cache to be retained for one content segment period longer than if the cache were always operated in a first in first out manner, allowing the subsequent requests from the client device 1 14 to be satisfied with data that has been received by multicast and stored in the cache.

This continues until time 77s when the proxy 1 12 receives a request from the client device 114 for the content segment with SID_r equal to 11 10 (step 200). The client application has moved closer to the live edge by not requesting the content segments 1108 and 1 109. This may be due, for example, to the user instructing the player application to move closer to the live edge.

As this requested content segment, 11 10, was received on the multicast channel at time 62s, the proxy 112 sets the variable LastReqSegRxTime to the value 62s (step 202). And as this content segment is stored in the cache (step 204), the proxy 1 12 responds to the client device 1 14 with the stored data (step 206) and sets the flag ServedFromCache to TRUE (step 208).

At time 80s, the content segment with segment identifier equal to 1113 starts to be received by the proxy 1 12 on the multicast channel (step 300). The proxy 112 determines that the flag ServedFromCache is set to TRUE (step 306), deletes the segment 1 108 from its cache (step 308), and stores segment 11 13 in the cache (step 318).

At time 83s, the proxy 112 receives a request from the client device 1 14 for the content segment with segment identifier equal to 11 11 (step 200). As this content segment is not stored in the cache (step 204), the proxy 1 12 requests it from the unicast server 1 10 (step 210) and forwards the response to the client device 114 (step 212). The proxy 112 sets the flag ServedFromCache to FALSE (step 214).

Now that the client device 1 14 is making requests for content segments closer to the live edge, and within the capacity of the cache at the proxy 112 to store all content segments received on the multicast channel until they are requested by the client device 114, the proxy 1 12 should operate the cache in a first in first out manner all the time. If the proxy 1 12 did not consider whether there is a content segment in its cache with a value of segment receive time earlier than or the same as LastReqSegRxTime (step 310), and only considered the value of ServedFromCache (step 306), the proxy 112 would operate the cache in a last in first out manner (step 316) when the next content segment, 1 114, is received on the multicast channel, and delete segment 1 113, which will later be requested by the client device 1 14 at time 95s.

Instead, by determining that there is at least one content segment (1109 and 11 10) in its cache with a value of segment receive time earlier than or the same as LastReqSegRxTime (step 310), and by deleting, for example, content segment 1 109, and then continuing to operate the cache in a first in first out manner, either by determining that there is a content segment in its cache with a value of segment receive time earlier than or the same as LastReqSegRxTime (step 310), or by determining that ServedFromCache is TRUE (step 306), the proxy 1 12 can satisfy all subsequent requests for content segments from the client device 114 using data received on the multicast channel and stored in its cache.

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.

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.

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

1. A method of managing content delivery to a client device (114) by a network element (112), said content comprising a sequence of segments, said network element comprising a store, and said method comprising: i) joining (300) a multicast channel, receiving (300) one or more segments over multicast, and storing (302) the one or more segments in a store; ii) receiving (200) a unicast request for a segment from a client device; iii) determining (204) whether the requested segment is 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 (206, 212) the obtained segment to the client device by unicast; v) receiving (300) a further segment over multicast; vi) determining whether to delete one of the stored segments and deleting the determined stored segment; vii) determining whether to store the further segment and storing the further segment in the store; viii) repeating steps ii) to vii) at least once; wherein determining whether to delete a specific stored segment and determining whether to store the further segment are determined (310) in dependence on the time the requested segment was received on the multicast channel and the time each stored segment was received on the multicast channel.

2. A method according to claim 1 , wherein it is determined to delete a specific stored segment and it is determined to store the further segment when the specific stored segment was received over multicast before or at the same time as the most recent segment requested by the client device was received over multicast.

3. A method according to claim 1 , wherein it is determined (314) not to delete a specific stored segment and it is determined not to store the further segment when the most recent segment requested by the client device was received over multicast before all the stored segments were received over multicast.

4. A method according to claim 1 , wherein it is determined to delete (316) the specific stored segment that is the segment most recently received over multicast and it is determined to store the further segment when the most recent segment requested by the client device was received over multicast before all the stored segments were received over multicast.

5. A method as claimed in any preceding claim, wherein the network element is a proxy server.

6. A network element (1 12) for managing content delivery to a client device (114), said content comprising a sequence of segments, said network element comprising a store, and further adapted in operation to: i) join (300) a multicast channel, receive (300) one or more segments over multicast, and store (302) the one or more segments in a store; ii) receive (200) a unicast request for a segment from a client device; iii) determine (204) whether the requested segment is 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; iv) transmit (206, 212) the obtained segment to the client device by unicast; v) receive (300) a further segment over multicast; vi) determine whether to delete one of the stored segments and delete the determined stored segment; vii) determine whether to store the further segment and storing the further segment in the store; viii) repeating steps ii) to vii) at least once; wherein determining whether to delete a specific stored segment and determining whether to store the further segment are determined (310) in dependence on the time the requested segment was received on the multicast channel and the time each stored segment was received on the multicast channel.