Content delivery - server push method and system

Abstract

Described are methods of delivering a sequence of content segments from a content server to a client device in a server push system, where content segments comprise a first (e.g. header) component and a second (e.g. content payload) component. Where possible, a multicast server is used to deliver at least some of these segments (the content payload components) over a multicast channel, which can be received by edge servers. A unicast root proxy receives the sequence of content segments pushed by the content server to a client device over unicast, and determines whether any given segment has been made available to the edge server over multicast. If not, then the unicast root proxy can transmit the entire content segment over unicast to the edge server, which transmits it onto the client device. If the edge server does have the content segment (the payload component), then the unicast root proxy can send only the header component to the edge server over unicast. The edge server can regenerate the sequence of content segments using the data received over unicast and data received over multicast, and send the regenerated sequence of content segments onto the client device over unicast.

Description

[0001] CONTENT DELIVERY - SERVER PUSH METHOD AND SYSTEM

[0002] Field of the Invention

[0003] This invention relates to the field of managing content delivery in a network, in particular managing content delivery using a combination of unicast and multicast. The invention applies to a system in which a set of clients receive adaptive bitrate streams, representing the same content, from one or more servers.

[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. The content is segmented into short segment files, typically around two to ten seconds in duration, with each segment being encoded at a set of quality levels, each with a different bit rate and hence different file size.

[0006] The buffer level at the client device and the network throughput achieved are monitored and used to determine from these at which quality the next segment is to be delivered, in order to achieve a good compromise between media quality and timely delivery. This is commonly referred to as adaptive bitrate (ABR) streaming.

[0007] Web (HTTP) technology is frequently used for such content delivery, where the client device monitors its buffer level and the network throughput and determines the quality at which to request each segment in turn by HTTP.

[0008] In some alternative systems, for which we use the term server push delivery, the content server performs the monitoring and makes the quality decisions and pushes segment files to the client device, typically over UDP, and typically making the delivery appear as a continuous stream of data.

[0009] However, both in approaches content data is delivered over unicast (one to one) transport, which 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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 ).

[0014] These solutions may integrate the multicast transmission capability directly with the content encoding process, with the content encoder sending encoded data to the multicast transmission capability, which then immediately transmits the data by multicast.

[0015] Alternatively, these solutions operate a replica client device at the multicast transmission capability, to obtain and parse the presentation manifest file, and then to request content segments from the content server, just as a client device would, and then transmit that data by multicast. However, this approach requires knowledge of the streaming format, the presentation manifest format and the content segment indexing scheme, as well as requiring content protection to not prevent the proxy from obtaining and parsing the presentation manifest file. The Applicant’s own International application W02020 / 173878 describes a hybrid approach termed MAUD (multicast assisted unicast delivery) that addresses some of these problems. Content is requested by client devices from a content server over unicast. The responses containing the requested content are separated into two components: a first component containing elements that are specific to individual client devices (for example session specific data), and a second component that is common to all client devices (typically this is the video content being requested). The first component can be delivered over unicast and the second component over multicast. The first and second components are recombined to form the original responses by suitably configured servers.

[0016] However, none of these hybrid approaches are easily adaptable to a server push delivery system.

[0017] Summary of the Invention

[0018] It is the aim of examples of the present invention to provide improved methods of managing content delivery.

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

[0020] The information may comprise a checksum determined from the segment.

[0021] Determining by the unicast root proxy whether the segment has been delivered on the multicast channel may further comprise determining that the edge proxy was joined to the multicast channel at the time the segment was delivered over the multicast channel.

[0022] Determining by the unicast root proxy whether the segment has been delivered on the multicast channel may further comprise determining that the time that has elapsed since the segment was delivered on the multicast channel is less than a predetermined threshold.

[0023] Determining by the unicast root proxy whether the segment has been delivered on the multicast channel further may comprise determining that the data delivered on the multicast channel since the segment was delivered on the multicast channel is less than a predetermined threshold.

[0024] Determining by the unicast root proxy whether the segment has been delivered on the multicast channel may further comprises receiving information from the edge proxy indicating that the segment has been received at the edge proxy on the multicast channel.

[0025] The received information may additionally indicates that the segment is stored at the edge proxy.

[0026] The information about segments delivered on the multicast channel may comprise one or more time values, each associated with one segment.

[0027] The information about the segments delivered on the multicast channel may comprise one or more data size values, each associated with one segment.

[0028] The content may comprise media content. The media content may comprises a video sequence.

[0029] Brief Description of the Drawings

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

[0031] Figure 1 is a system diagram showing the main components of an example of a typical unicast server push delivery system;

[0032] Figure 2 is a system diagram showing the main components of an example of the present invention;

[0033] Figure 3 is a diagram illustrating the content segments that the content server may push towards three clients in an example of the invention;

[0034] Figure 4 is a diagram illustrating the content payloads that the multicast root proxy may deliver by multicast, and the client specific headers and the content payloads that the unicast root proxy may deliver by unicast to the edge proxy in an example of the invention;

[0035] Figure 5 is a flow chart summarising the steps of a first example method of that could be used to determine which content segment payloads to transmit on the multicast channel and how that data could be obtained; Figure 6 is a flow chart summarising the steps of a second example method that could be used to determine which content segment payloads to transmit on the multicast channel and how that data could be obtained;

[0036] Figure 7 is a flow chart summarising the steps of an example method that could be used to determine whether to forward an entire content segment received from the unicast root proxy to the edge proxy, or whether to forward just an identifier for the payload of the content segment and the header of the content segment;

[0037] Figure 8 is a flow chart summarising the steps of an example method that could be used to determine whether an edge proxy should join a multicast channel, and after determining to do so, how it obtains or creates content segments to forward to the client device;

[0038] Figure 9 is a flow chart summarising the main steps of an example method for delivering a content segment from a content server to a client device.

[0039] Description of Preferred Embodiments

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

[0041] Described are improved methods of delivering a sequence of content segments from a content server to a client device in a server push system, where content segments comprise a first (e.g. header) component and a second (e.g. content payload) component. Where possible, a multicast server is used to deliver at least some of these segments (the content payload components) over a multicast channel, which can be received by edge servers. A unicast root proxy receives the sequence of content segments pushed by the content server to a client device over unicast, and determines whether any given segment has been made available to the edge server over multicast. If not, then the unicast root proxy can transmit the entire content segment over unicast to the edge server, which transmits it onto the client device. If the edge server does have the content segment (the payload component), then the unicast root proxy can send only the header component to the edge server over unicast. The edge server can regenerate the sequence of content segments using the data received over unicast and data received over multicast, and send the regenerated sequence of content segments onto the client device over unicast. Where necessary, the edge proxy may need to combine header components with payload components to regenerate a complete content segment. Therefore, advantageously, the methods help avoid the situation in a hybrid system applied to a server push model, where there might be some duplication on what is pushed over unicast with what is also available over multicast.

[0042] Figure 1 shows an example adaptive bit rate (ABR) streaming system 100 implemented with server push delivery that is already known.

[0043] The system 100 comprises a content source 102, a content encoder 104, a content server 106 and a plurality of client devices 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.

[0044] 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 segments corresponding to each uncompressed content segment. Such an arrangement is typical of an adaptive bit rate streaming service.

[0045] The content server 106 receives content from the content encoder 104. For each of the plurality of client devices 1 14, the content server 106 determines, using information that may include the state of the buffer at the client device 1 14 and the recent network throughput to the client device 114, the encoded bit rate (quality) at which to deliver each content segment to the client device 114. The content server 106 creates a content segment comprising a header containing client specific data and the appropriate content payload, that is, the payload at the selected encoded bit rate (quality) and transmits the entire content segment to the client device 1 14 by unicast.

[0046] The content server 106 may determine the state of the client buffer in various ways. For example, the content server 106 could receive explicit information about the rate at which the client device is receiving data and how much is buffered, or could be less explicit and buffer fill could be deduced by the content server using how much time has elapsed and TCP throughput to estimate how much data had been delivered. The client device 1 14 receives the content segment and buffers it until it is ready for playout.

[0047] Note, each client device 1 14 is assumed to be running a client application, which is the receiver of content segments. For simplicity, the term client device has been used to refer to a client device running a client application.

[0048] Figure 2 shows an adaptive bit rate (ABR) streaming system 200 of an example of the invention implemented with server push delivery. Compared to system 100 shown in Figure 1 , the system 200 has two client devices 114-A and 114-B, and additionally comprises a multicast root proxy 108, a plurality of unicast root proxies 110-A and 1 10-B, and a plurality of edge proxies 112-A and 1 12-B.

[0049] The edge proxy 112 may be located within a device such as a home gateway or router.

[0050] The system 200 includes a plurality of client devices 114-A and 1 14-B. Each client device 114 is logically associated with a corresponding unicast root proxy 110 and a corresponding edge proxy 1 12, although in practice a single pair of (unicast and edge) proxies could serve content to more than one client device, or a single unicast root proxy could serve a plurality of client devices.

[0051] The content server 106, operating in exactly the same way as in system 100 shown in Figure 1 and described above, receives content from the content encoder 104. For each of the plurality of client devices 1 14, the content server 106 determines, using information that may include the state of the buffer at the client device 114 and the recent network throughput to the client device 114, the encoded bit rate (quality) at which to deliver each content segment to the client device 114. The content server 106 creates a content segment comprising a header containing client specific data and the appropriate content payload, that is, the payload at the selected encoded bit rate (quality) and transmits the entire content segment towards the client device 1 14 by unicast.

[0052] Whilst only two client devices 1 14, each having a corresponding unicast root proxy and edge proxy are shown in Figure 2 for simplicity, in practice there may be many hundreds or even thousands of client devices connected to the content server 106 in such a manner, each via its own corresponding edge proxy and unicast root proxy. Additionally, the methods described are also applicable to more than one client device connected to an edge proxy.

[0053] Whilst the unicast root proxies are described as separate entities and logically separate from each other, in practice they may be co-located in the same physical server.

[0054] Figure 3 provides an example of the content segments that the content server 106 may transmit to three client devices, 114-A, 114-B and 1 14-C (note the third client 114-C has been omitted from Figure 2 for simplicity). For example, the content segments 302 transmitted to client device 1 14-A include the headers containing client specific data, HAI , HA2, HAS, HA4, HAS, and include content payloads at the encoded bit rate (quality) selected by the content server 106, Pi,L5, P2,L3, PS,L4, P4,LS, PS.LS, and where the number in the subscript following the letter L indicates the selected encoded bit rate (quality level).

[0055] Similarly, the content segments 304 transmitted to client device 1 14-B include the headers containing client specific data, HBI , HB2, HB3, HB4, HB5, and include content payloads at the encoded bit rate (quality level) selected by the content server 106, PI .LS, P2,LS, PS.LS, P4.L4, PS.LS, and the content segments 306 transmitted to client device 114-C include the headers containing client specific data, HCi, HC2, HC3, HC4, HCs, and include content payloads at the encoded bit rate (quality level) selected by the content server 106, PI .LS, P2,LS, PS , P4.L4, Ps,L5-

[0056] It can be seen that while some of the payloads transmitted to the client devices are the same, with content payloads PI .LS and PS.LS being transmitted to all three client devices, some client devices receive some content payloads at different encoded bit rate (quality level), due to decisions made at the content server 106 that may depend on the state of the buffer at the client device 114 and the recent network throughput to the client device 114.

[0057] For simplicity, the following examples are described is with reference to one of the plurality of client devices 1 14 (and associated edge proxy and unicast root proxy), but is applicable to any of the client devices.

[0058] In the system 200, a content segment transmitted by the content server 106 towards the client device 114 is first received by the unicast root proxy 1 10. This, as described below, separates the content segment into a header containing client specific data and the content payload. The unicast root proxy 1 10 forwards the header containing client specific data to the respective edge proxy 1 12. In consideration of whether the edge proxy 1 12 has joined the multicast channel, and in consideration of whether and when the content payload has been or will be transmitted on the multicast channel, unicast root proxy 110 determines whether to forward the content payload to the edge proxy 1 12, and if so, delivers the content payload to the edge proxy 1 12 by unicast, for example as a combined content segment.

[0059] Thus, the edge proxy 112 could receive entire content segments from the unicast root proxy 1 10 from the start to the end of a streaming session. However, in some cases the edge proxy 112 determines that multicast delivery could be used to receive some content segment payloads.

[0060] The edge proxy 112 may initially not be joined to the multicast channel. In this case, the unicast root proxy 110 forwards entire content segments, each comprising a header containing client specific data and the content payload, to the edge proxy 112, which then in turn forwards entire content segments to the client device 114.

[0061] The edge proxy 1 12 monitors the unicast content segments it receives from the unicast root proxy 110 and forwards them to the client device 114 over unicast. The edge proxy 112 is aware of when content being delivered to the client device 1 14 could be received by multicast (such as by monitoring the available multicast channels directly, or my getting multicast session information from a suitable web server). The edge proxy 112 determines when it is possible to receive, on a multicast channel, content payload data that is to be forwarded to the client device 1 14, joins the relevant multicast channel at an appropriate time and receives multicast data from the multicast root proxy 108. The edge proxy 112 may join the multicast channel for example by issuing an IGMP Join request.

[0062] There are many ways in which the edge proxy 112 may determine it is possible to receive, on the multicast channel from the multicast root proxy 108, content payload data that is to be forwarded to the client device 1 14.

[0063] For example, the edge proxy 112 may determine this to be possible if the content server 106 has delivered a plurality of consecutive content segments at the same encoded bit rate (quality) towards the client device 1 14, that bit rate (quality) is available by multicast delivery, and each of these content segments has been delivered in less time than the segment period.

[0064] In another example, the edge proxy 112 may ignore the fact that some content segments have taken more time than a segment period to be delivered, provided that many segments are delivered in much less than a segment period. The edge proxy 1 12 may also ignore some variations in the bit rate (quality) at which segments are delivered, if for much or all of the time there is easily sufficient network throughput to deliver content segments at the bit rate (quality) available by multicast.

[0065] After joining the multicast channel, the edge proxy 1 12 receives content segment payload data by multicast and stores it in a cache. The edge proxy 1 12 may, from time to time, including after receiving content segment payload data by multicast, and including after removing content segment payload data that was received some time ago from its cache, inform the unicast root proxy 1 10 of the content segment payload data received by multicast, and / or the content segment payloads stored in its cache, by for example sending one or more identifiers corresponding to the relevant content segment payloads to the unicast root proxy 1 10.

[0066] The edge proxy 1 12 continues to receive data from the unicast root proxy 1 10, this data being at times an entire content segment, and at other times being an identifier of a content segment payload and a content segment header containing client specific data. In the former case, the edge proxy 112 forwards the entire content segment to the client device 114 by unicast.

[0067] In the latter case, the edge proxy 112 uses the identifier to locate the corresponding content segment payload that has been received by multicast and stored in the cache. The edge proxy 112 combines the header containing client specific data that has been received by unicast from the unicast root proxy 1 10 with content payload data received by multicast from the multicast root proxy 108 to create an entire content segment. The edge proxy 1 12 then forwards the created content segment to the client device 1 14 by unicast.

[0068] The client device 1 14 does not need to be aware of the multicast root proxy 108, the unicast root proxy 110 or the edge proxy 112 and does not need to be aware of whether content payload data is received at the edge proxy 112 by unicast or by multicast, as the content segment data delivered to the client device 1 14 is the same in both cases. The multicast root 108

[0069] The multicast root proxy 108 receives content segment payloads. These may be received from the content server 106 as entire content segments, or may be received from one of the plurality of unicast root proxies as either entire content segments or content segment payloads. In the case of receiving entire content segments the multicast root proxy 108 separates the content segment into a header containing client specific data and the content payload. The multicast root proxy 108 transmits content segment payloads on the multicast channel.

[0070] There are many ways in which the multicast root proxy 108 may determine which content segment payloads to transmit on the multicast channel, and many ways in which it may obtain that data.

[0071] For example, the multicast root proxy 108 may include functionality similar to a client device 114, and receive, from the content server 106, a sequence of content segments in the same way that any other client device 1 14 would receive a sequence of content segments. The multicast root proxy 108 would separate the headers from the payloads of these content segments, discard the headers and transmit the payloads on the multicast channel.

[0072] In another example, the multicast root proxy 108 may receive information from one or more of the plurality of unicast root proxies 110 about the content segments being delivered to their respective client devices 114. The multicast root proxy 108 may use this information to determine which content segment to deliver on the content segment payload of on the multicast channel.

[0073] There are many forms of information that could be provided by the unicast root proxies 110 to the multicast root proxy 108, and many ways in which this information could be used. In a simple example, each of the unicast root proxies 1 10 could provide an identifier for the content segment, and the multicast root proxy 108 could select the content segment that has been delivered the most times, or chose to only transmit on the multicast channel after the number of deliveries of a specific content segment has reached a threshold. After determining which content segment to deliver the payload of on the multicast channel, the multicast root proxy 108 may get content segment data from one of unicast root proxies 110 that has received the determined content segment. This received content segment data may be the entire content segment, in which case the multicast root proxy 108 separates the header from the payload, discards the header and transmits the payload on the multicast channel, or it may be just the content segment payload, as the separation and discarding has been done by the unicast root proxy 1 10, and the multicast root proxy 108 simply transmits the payload on the multicast channel.

[0074] After the multicast root proxy 108 has determined which content segment payload data to transmit next on the multicast channel, it informs each of the plurality of unicast root proxies 110 of its decision. It may do this using information in the header of the content segment if such information exists, where such information could include a segment index or sequence number and an indication of the encoded bit rate (quality). Alternatively, the multicast root proxy 108 could create an identifier for the selected content payload data, for example, by calculating the size in bytes of the content payload data, or by calculating a check sum over the content payload data, or by doing both.

[0075] After the multicast root proxy 108 has obtained the content payload data, it transmits this data on a suitably configured multicast channel to all devices that have subscribed to that multicast channel. The multicast root proxy 108 may also transmit information on the multicast channel, to allow the edge proxy 1 12 to associate a header received from the unicast root proxy 1 10 with a payload received on the multicast channel. This information is the information obtained from the header of the content segment or the identifier created from the content payload data. For the latter, in some cases the information (identifier) is not transmitted on the multicast channel and instead is calculated at the edge proxy 1 12 from the received content segment payload data.

[0076] The unicast root proxy 110

[0077] As stated above, a content segment transmitted by the content server 106 towards the client device 114 is first received by the unicast root proxy 1 10. This determines whether the corresponding edge proxy 1 12 has joined the appropriate multicast channel. If the edge proxy 112 has not done so, then the unicast root proxy 110 forwards the entire content segment to the edge proxy 1 12. Otherwise, that is, the corresponding edge proxy 112 has joined the appropriate multicast channel, the unicast root proxy 110 determines, using information from the multicast root proxy 108, whether the content segment payload of the content segment has been or will be transmitted on the multicast channel. If not, then the unicast root proxy 1 10 forwards the entire content segment to the edge proxy 112. Otherwise, the unicast root proxy 110 separates the content segment into a header containing client specific data and the content payload, and forwards just the header containing client specific data to the edge proxy 112.

[0078] If the information from the multicast root proxy 108 had been obtained from the header of the content segment, the unicast root proxy 1 10 obtains equivalent data from the content segment received from the content server 106, and by comparison of these determines whether the content segment has been or will be transmitted on the multicast channel. For example, it may draw this conclusion if both sets of information are the same.

[0079] If the information from the multicast root proxy 108 is an identifier created from the content payload data, the unicast root proxy 110 creates an identifier from the payload of the content segment received from the content server 106 using the same processing, and by comparison of these identifiers determines whether the content segment has been or will be transmitted on the multicast channel. For example, it may draw this conclusion if both identifiers are the same.

[0080] The unicast root proxy 110 may take additional information into account before determining to forward just the header containing client specific data to the edge proxy 1 12.

[0081] For example, the unicast root proxy 110 may consider when the corresponding edge proxy 1 12 joined the appropriate multicast channel, and in particular, whether it was joined to the multicast channel at the time that the multicast root proxy 108 transmitted the content segment payload on the multicast channel, and if not, forward the entire content segment to the edge proxy 112.

[0082] In another example, the unicast root proxy 110 may consider the time that has elapsed since the multicast root proxy 108 transmitted the content segment payload on the multicast channel, and if this is more than a threshold, forward the entire content segment to the edge proxy 112. The unicast root proxy 110 would take this course of action due to limited buffering at the edge proxy 1 12, and the content segment payload, having been received at the edge proxy 112 and cached some time ago, not still being in its cache at the current time.

[0083] In another example, the unicast root proxy 1 10 may consider the amount of data that has been transmitted on the multicast channel since the multicast root proxy 108 transmitted the content segment payload on the multicast channel, and if this is more than a threshold, forward the entire content segment to the edge proxy 112. The unicast root proxy 110 would take this course of action due to limited buffering at the edge proxy 1 12, and with much data having been received on the multicast channel at the edge proxy 112 since the content segment payload was received, the content segment payload no longer being in its cache at the current time.

[0084] In yet another example, the unicast root proxy 110 may receive information from the edge proxy 112 indicating content segment payload data that it has received on the multicast channel and / or the content segment payloads currently stored in cache. If this information indicates that the content segment payload has been received by the edge proxy 112 and / or the content segment payload is currently stored in cache, the unicast root proxy 1 10 forwards the content segment header to the edge proxy 1 12, and not the content segment payload.

[0085] In the case that the unicast root proxy 110 forwards the content segment header to the edge proxy 1 12, and not the content segment payload, the unicast root proxy 1 10 also forwards information to the edge proxy 1 12 to allow it to associate the header received from the unicast root proxy 110 with the payload received on the multicast channel from the multicast root proxy 108 and stored in the cache. This information is the information obtained from the header of the content segment or the identifier created from the content payload data

[0086] Figure 4, for the scenario shown in Figure 3, provides an example of the content segment headers and the content segment payloads 402 sent by unicast from unicast root proxy 1 10-A to edge proxy 112-A, both of which are associated with client device 1 14-A; the content payloads 404 transmitted over multicast by the multicast root proxy 108 to ; and the content segment headers and the content segment payloads 406 sent by unicast from unicast root proxy 1 10-C to edge proxy 1 12-C, both of which are associated with client device 114-C. In this example shown in Figure 4, the multicast root proxy 108 includes functionality similar to a client device 114. It receives the sequence of content segments shown in Figure 3 as delivered to client device 114-B. The multicast root proxy 108 separates the headers from the payloads of these content segments, discards the headers and transmits the payloads 404 on the multicast channel. Thus content payloads Pi ,LS, P2J.5, PS.LS, P4.L4, PS.LS, are transmitted on the multicast channel. Note that four of these encoded bit rate (quality) values are equal to L5 and the other is equal to L4: all the content payloads on the multicast channel are not at the same encoded bit rate (quality) in this case, but in some cases they would be. These payloads transmitted on the multicast channel are available for reception by any entities (such as the edge servers 112) that have subscribed to the multicast channel.

[0087] The multicast root proxy 108 informs the two unicast root proxies 110-A and 110-C of the content segment payloads that are transmitted on the multicast channel.

[0088] Unicast root proxy 110-A therefore knows when it receives the content segment comprising header HAI and payload PI .LS from the content server 106 that the payload is available on the multicast channel. Unicast root proxy 1 10-A therefore only sends the header HAI to the edge proxy 112-A. However, for the following three content segments the unicast root proxy 1 10-A has not been informed that the payloads are available on the multicast channel, and therefore sends the entire content segments to the edge proxy 1 12-A. And finally when it receives the fifth content segment, comprising header HAS and payload PS.LS, it knows that the payload PS.LS, is available on the multicast channel and therefore only sends the header HAS to the edge proxy 1 12-A.

[0089] Similarly unicast root proxy 1 10-C sends only the headers of four segments, HCi, HC2, HC4, and Hcs to the edge proxy 1 12-C, as it knows that the corresponding payloads required have been made available on the multicast channel, but sends the whole of the other content segment comprising header HC3 and payload P3,L4 to the edge proxy 1 12-C, as payload P3,L4 is not available on the multicast channel.

[0090] Figure 5 is a flow chart illustrating the steps of a first example method that the multicast root proxy 108 may use to determine which content segment payloads to transmit on the multicast channel and how it may obtain that data. In this example, the multicast root proxy 108 includes functionality similar to a client device 1 14, and receives, from the content server 106, a sequence of content segments in the same way that any other client device 114 would receive a sequence of content segments. The multicast root proxy 108 separates the headers from the payloads of these content segments, discards the headers and transmits the payloads on the multicast channel.

[0091] Processing with step 500, where the multicast root proxy 108 requests a stream of content from the content server 106.

[0092] In step 502, the multicast root proxy 108 receives a content segment from the content server 106.

[0093] In step 504, the multicast root proxy 108 separates the header from the payload of the content segment received from the content server 106.

[0094] In step 506, the multicast root proxy 108 determines an identifier for the content segment. In this example, the multicast root proxy 108 calculates a check sum over the content segment payload and uses the calculated check sum as the identifier. As described earlier, other methods of determining an identifier for the content segment could be used.

[0095] In step 508, the multicast root proxy 108 informs the plurality of unicast root proxies 110 of the determined identifier. The multicast root proxy 108 may indicate when this content segment will be transmitted on the multicast channel or may indicate it is to be transmitted immediately. It may also indicate the size of the payload of the content segment in terms of the playout time it contains and / or its size in bytes. It may also send information about content segments the payloads of which have previously been transmitted on the multicast channel.

[0096] The multicast root proxy 108 may choose to only inform those unicast root proxies 1 10 that are associated with edge proxies 1 12 that have joined the multicast channel for delivery of content segment payloads. The multicast root proxy 108 may inform the unicast root proxies 1 10 by using unicast delivery to each unicast root proxy 1 10, or by multicast using a multicast channel that the plurality of unicast root proxies 1 10 have joined. In the latter case, only those unicast root proxies 1 10 that are associated with edge proxies 112 that have joined the multicast channel for delivery of content segment payloads need to join the multicast channel used to distribute identifier values. In step 512, the multicast root proxy 108 discards the header of the content segment received from the content server 106 in step 502.

[0097] In step 514, the multicast root proxy 108 transmits on the multicast channel the identifier determined in step 506 and the payload of the content segment received from the content server 106 in step 502. Flow then passes back to step 502.

[0098] Alternatively, the multicast root proxy 108 doesn’t transmit the identifier determined in step 506 on the multicast channel, and instead the edge proxy 112 calculates the identifier from the content segment payload received on the multicast channel using the same method as used by the multicast root proxy 108 in step 506. However, this approach suffers from many edge proxies 1 12 having to perform this calculation rather than a single multicast root proxy 108, and may be intolerant of transmission errors or losses on the multicast channel.

[0099] Figure 6 is a flow chart illustrating the steps of a second example method that the multicast root proxy 108 may use to determine which content segment payloads to transmit on the multicast channel and how it may obtain that data.

[0100] In this example, the multicast root proxy 108 receives information, being an identifier, from one or more of the plurality of unicast root proxies 1 10 indicating the content segments being delivered to their respective client devices 114. The multicast root proxy 108 counts the occurrences for each value of identifier, and determines to deliver the payload of a content segment on the multicast channel when the count associated with the identifier for that content segment reaches a threshold.

[0101] Processing starts with step 600, where the multicast root proxy 108 receives an identifier from a unicast root proxy 110 for the content segment being delivered towards the respective client device 114 of the unicast root proxy 1 10.

[0102] In step 602, the multicast root proxy 108 increments a counter associated with the identifier. In the case that there is no counter, as the identifier has not previously been sent to the multicast root proxy 108, the multicast root proxy 108 creates a counter associated with the identifier and sets the value of the counter to one. In step 604, the multicast root proxy 108 compares the value of the counter associated with the identifier received from the unicast root proxy 1 10 with a predetermined threshold. For example, the threshold may be one, two, 15 or any other value. If the counter is greater than or equal to the threshold, flow passes to step 606, and otherwise flow passes back to step 600.

[0103] In step 606, the multicast root proxy 108 obtains the content segment from a unicast root proxy 110 by unicast. This can be any unicast root proxy 1 10 that has reported the identifier and would often be the unicast root proxy 110 that most recently reported the identifier and caused the associated counter to reach the threshold.

[0104] In step 608, the multicast root proxy 108 informs the plurality of unicast root proxies 110 of the determined identifier. The amount or type of information that the multicast root proxy 108 sends, the method that the multicast root proxy 108 uses to do this, and the unicast root proxies 1 10 that it determines to inform are the same as described in step 508 of Figure 5.

[0105] In step 610, the multicast root proxy 108 separates the header from the payload of the content segment received from the identifier 1 10 in step 606.

[0106] In step 612, the multicast root proxy 108 discards the header of the content segment received from the unicast root proxy 1 10.

[0107] In step 614, the multicast root proxy 108 transmits on the multicast channel the determined identifier and the payload of the content segment received from the unicast root proxy 110 step 606. Flow then passes back to step 600.

[0108] Alternatively, as noted in step 514 of Figure 3, the multicast root proxy 108 may choose not to transmit the determined identifier on the multicast channel in step 614.

[0109] And alternatively, the unicast root proxy 1 10 may perform the separation of the content segment into a header and payload as in step 610, and only deliver the content segment payload to the multicast root proxy 108. In this case, step 610 is skipped as the separation is already done, and step 612 is skipped as the header has not been received at the multicast root proxy 108. Figure 7 is a flow chart illustrating the steps of an example method the unicast root proxy 1 10 may use to determine whether to forward an entire content segment received from the unicast root proxy 110 to the edge proxy 1 12, or whether to forward just an identifier for the payload of the content segment and the header of the content segment.

[0110] Processing starts with step 700, where the unicast root proxy 1 10 receives a request for a stream of content from the client device 1 14 via the edge proxy 112. The unicast root proxy 110 requests this stream of content from the content server 106.

[0111] In step 702, the unicast root proxy 1 10 receives a content segment from the content server 106.

[0112] In step 704, the unicast root proxy 1 10 separates the header from the payload of the content segment received from the content server 106.

[0113] In step 706, the unicast root proxy 1 10 determines an identifier for the content segment by calculating a check sum over the content segment payload and uses the calculated check sum as the identifier. As described earlier, other methods of determining an identifier for the content segment could be used.

[0114] In step 708, the unicast root proxy 110 sends the determined identifier to the multicast root proxy 108. This is the determined identifier that the multicast root proxy 108 receives in step 600 of Figure 6.

[0115] In step 710, the unicast root proxy 110 receives information from the multicast root proxy 108 about content segments transmitted on the multicast channel. This is the information transmitted by the multicast root proxy 108 in step 508 of Figure 5 and step 608 of Figure 6. The unicast root proxy 110 stores this received information. The receipt of this information is generally asynchronous to the other steps in this flowchart but may often happen between the times that steps 708 and 712 happen.

[0116] In step 712, the unicast root proxy 1 10 considers whether the edge proxy 1 12 has joined the multicast channel (see step 808 in Figure 8 below). If not, flow passes to step 730. Otherwise flow passes to step 714. In step 714, the unicast root proxy 110 compares the determined identifier with identifiers that it received in step 710, and previous instances of step 710. If the determined identifier is not the same as any of the received identifiers, the unicast root proxy 110 concludes that the content segment has not been transmitted on the multicast channel, and flow passes to step 730. Otherwise flow passes to step 716.

[0117] In step 716, the unicast root proxy 110, having determined that the content segment has been, or soon will be, transmitted on the multicast channel in step 714 determines whether the edge proxy 1 12 was joined to the multicast channel at the time that the payload of the content segment was transmitted on the multicast channel. If so, flow passes to step 718, and otherwise passes to step 730. The determination in step 716 is done using the information received from the multicast root proxy 108 in step 710, and previous instances of step 710, and using knowledge of when the edge proxy 1 12 joined the multicast channel (see step 808 in Figure 8).

[0118] In step 718, the unicast root proxy 1 10 determines the amount of time that has elapsed since the payload of the content segment was transmitted on the multicast channel, by using the information received from the multicast root proxy 108 in step 710, previous instances of step 710, and the current time. If the determined amount of time is more than a threshold, the unicast root proxy 110 concludes that the entire payload of the content segment may no longer be in the cache of the edge proxy 1 12 and flow passes to step 730. Otherwise flow passes to step 720.

[0119] In step 720, the unicast root proxy 1 10 determines the amount of data that has been transmitted on the multicast channel since the payload of the content segment started to be transmitted on the multicast channel, by using the information received from the multicast root proxy 108 in step 710, and previous instances of step 710. If the determined amount of data is more than a threshold, the unicast root proxy 110 concludes that the entire payload of the content segment may no longer be in the cache of the edge proxy 112 and flow passes to step 730. Otherwise flow passes to step 722.

[0120] In step 722, the unicast root proxy 1 10 separates the header from the payload of the content segment received from the content server 106.

[0121] In step 724, the unicast root proxy 110 discards the payload of the content segment received from the content server 106. In step 726, the unicast root proxy 1 10 sends the identifier determined in step 706 and the header of the content segment received from the content server 106 to the edge proxy 1 12 by unicast. Flow passes back to step 702.

[0122] In step 730, the unicast root proxy 1 10 sends the entire content segment received from the content server 106 to the edge proxy 1 12 by unicast. Flow passes back to step 702.

[0123] Figure 8 is a flow chart illustrating the steps of an example method that the edge proxy 1 12 may use to determine whether to join a multicast channel, and after determining to do so, how it obtains or creates content segments to forward to the client device 1 14.

[0124] Processing starts with step 800, where the edge proxy 112 receives a request for a stream of content from the client device 114. The edge proxy 112 requests this stream of content from the content server 106 via the unicast root proxy 1 10.

[0125] In step 802, the edge proxy 112 receives a content segment from the content server 106 via the unicast root proxy 110.

[0126] In step 804, the edge proxy 112 forwards the entire content segment to the client device 114.

[0127] In step 806, the edge proxy 112 determines whether to join the multicast channel. As described earlier, there are many ways the edge proxy 1 12 could make this determination. In this case the edge proxy 112 determines to join the multicast if the content server 106 has delivered towards the client device 114 a number of consecutive content segments at an encoding bit rate (quality) that is available by multicast delivery greater than or equal to a threshold. If it decides to join, flow passes to step 808, otherwise flow passes back to step 802.

[0128] In step 808, the edge proxy 1 12 joins the multicast channel. This may be done for example by issuing an IGMP Join request. The edge proxy 1 12 informs the corresponding unicast root proxy 1 10 that it has joined the multicast channel.

[0129] In step 810, the edge proxy 1 12 receives data by multicast from the multicast root proxy

[0130] 110 and stores it in the cache. If the cache is full, the edge proxy 112 removes older data to create space for the newer data. The receipt of data by multicast is generally asynchronous to the other steps in this flowchart but often one content segment payload is received by multicast for every content segment header received from the unicast root proxy 110.

[0131] In step 812, the edge proxy 1 12 receives data by unicast from the unicast root proxy 110.

[0132] In step 814, the edge proxy 1 12 determines whether this received data is an identifier and a header or an entire content segment. If it is an entire content segment flow passes to step 820, and otherwise flow passes to step 816.

[0133] In step 816, the edge proxy 1 12 having received an identifier and a header from the unicast root proxy 1 10 uses the identifier to find the corresponding content segment payload in the cache.

[0134] In step 818, the edge proxy 1 12 combines the header received from the unicast root proxy 1 10 with the content segment payload from the cache to make an entire segment.

[0135] In step 820, the edge proxy 112 forwards the entire content segment to the client device 1 14. Flow passes back to step 810.

[0136] Figure 9 is a flow chart summarises the general method covered in more detail by the specific approaches above, whereby content is delivered from the content server 106 to a client device 1 14. It is worth noting again that the method applies to a server push system, where the client device only makes a single initial request for content, after which the content (in the form of content segments) is pushed by the content server to the client device using the approaches described earlier and summarised here.

[0137] In this example, it is assumed that the edge server 1 12 has already joined the multicast channel and has already started receiving content segment payloads over the multicast channel.

[0138] Processing starts at step 900, where the client device 1 14 makes a request for content from the content server 106. In step 902, the content server 106 transmits a content segment, which comprises a first component (a header portion) containing client specific data and a second component containing the content payload, to the unicast root proxy 110.

[0139] In step 904, the unicast root proxy 110 receives information about data delivered on the multicast channel by the multicast root proxy 108.

[0140] In this example, we are assuming that the edge proxy 112 has joined the multicast channel and has been receiving and caching content payload data. Therefore, in step 906, the unicast root proxy 908 determines that the second component (of the content segment received from the content server 902) is available at the edge proxy 112.

[0141] In step 908, the unicast root proxy 1 10 separates out the content segment into the first component (the client specific header) and second components (the content payload), and sends only the first component over unicast to the edge proxy 112.

[0142] In step 910, the edge proxy 1 12 regenerates the content segment by combining the first component received over unicast with the second component received over multicast.

[0143] In step 912, the edge proxy 1 12 transmits the regenerated content segment to the client device 114 over unicast. The client device 1 14 buffers the content segment ready for playout.

[0144] Processing then returns to step 902, where the content server pushes another content segment out to the client device and processing repeats.

[0145] 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 delivering content from a content server (106) to a client device (1 14- A) in a network (200) comprising a plurality of client devices (1 14-A, 1 14-B, 114-C), said method comprising: i) receiving (702) from the content server (106) at a unicast root proxy (110-A) a content stream comprising a sequence of segments of content; ii) delivering (514) by a multicast root proxy (108) one or more of the segments of content over a multicast channel; ill) receiving (710) from the multicast root proxy (108) at the unicast root proxy (110- A) information about segments delivered on the multicast channel; iv) for each segment, determining (712) by the unicast root proxy (110-A) using said information whether said segment has been delivered on the multicast channel, and if said segment has not been delivered on the multicast channel, then sending said segment from the unicast root proxy to the edge proxy; v) receiving (812) at the edge proxy (1 12-A) segments from the unicast root proxy (110-A) and the multicast channel; vi) regenerating (818) by the edge proxy (1 12-A) the sequence of segments using the segments received from the unicast root proxy and the multicast channel; and vii) sending (820) by the edge proxy (1 12-A) the regenerated sequence of segments to the client device (1 14-A).

2. The method according to claim 1 , wherein the information comprises a checksum determined from the segment.

3. The method according to claim 1 or 2, wherein determining by the unicast root proxy whether the segment has been delivered on the multicast channel further comprises determining that the edge proxy was joined to the multicast channel at the time the segment was delivered over the multicast channel.

4. The method according to any preceding claim, wherein determining by the unicast root proxy whether the segment has been delivered on the multicast channel further comprises determining that the time that has elapsed since the segment was delivered on the multicast channel is less than a predetermined threshold.

5. The method according to any preceding claim, wherein determining by the unicast root proxy whether the segment has been delivered on the multicast channel further comprises determining that the data delivered on the multicast channel since the segment was delivered on the multicast channel is less than a predetermined threshold.

6. The method according to any preceding claim, wherein determining by the unicast root proxy whether the segment has been delivered on the multicast channel further comprises receiving information from the edge proxy indicating that the segment has been received at the edge proxy on the multicast channel.

7. The method according to claim 6, wherein the received information additionally indicates that the segment is stored at the edge proxy.

8. The method according to any preceding claim, wherein the information about segments delivered on the multicast channel comprises one or more time values, each associated with one segment.

9. The method according to any preceding claim, wherein the information about the segments delivered on the multicast channel comprises one or more data size values, each associated with one segment.

10. The method according to any preceding claim, wherein the content comprises media content.

11. A method according to claim 10, wherein the media content comprises a video sequence.

Images