Multicast join method

Abstract

Described are methods of managing content delivery to a client device, where a proxy server services unicast requests for content segments by joining a multicast channel carrying those content segments. An alternative content segment is provided to the proxy server in advance of the proxy server joining the multicast channel. Then, should a requested content segment not have been received over multicast and stored at the proxy server, for example when first joining a multicast channel, the proxy server can respond to the request with the stored alternative content segment. The alternative content segment can carry, for example, a simple video clip or static image such as a broadcaster logo or programme details, associated with the multicast channel. Thus, there is no need for the proxy server to make a unicast request for any content segment it has yet to receive over the appropriate multicast channel.

Description

[0001] MULTICAST JOIN METHOD

[0002] Field of the Invention

[0003] This invention relates to the field of content delivery in a hybrid network utilising a combination of unicast and multicast, in particular a method of managing content delivery when joining a multicast channel in such a network.

[0004] Background to the Invention

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

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

[0007] However, ABR relies on the use of HTTP which is a unicast (one to one) delivery technology. Therefore, for live streams where audiences are large, ABR is inefficient as a result of the significant amount of duplication in the content being delivered. Multicast (one to many) transport would be more efficient. However, multicast is currently rarely used for any services other than network operators’ on-net linear video channels delivered to their own set-top boxes. The main reason for this is that multicast does not lend itself to open use on the Internet.

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

[0009] 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 a multicast channel, receive multicast content, and provide this content to the client, packaged to look like unicast delivered content.

[0010] Examples of such hybrid solutions are described in: “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-11 ).

[0011] The Applicant’s own International application W02020 / 173878 describes an alternative hybrid unicast / multicast content delivery method. 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 components are recombined before being sent to the client device over unicast. The separation and recombination are handled by suitably configured proxy servers.

[0012] These m-ABR systems generally place a proxy at the root of the multicast network that sources the content segments and pushes them into the network over multicast. Proxies at the edge of the multicast network (typically in the broadband home gateway), after joining the appropriate multicast channel, receive the content segments and cache them locally awaiting requests for those content segments from a client. A proxy normally joins a multicast channel when it is made aware that there is a client consuming a particular media stream, for example when an initial request for a manifest file or content segment has been made by the client.

[0013] The segment being delivered over multicast at the time the proxy joins, may be the same or different to the segment being requested by the client. The client will also likely join part way through the delivery of a media segment. Therefore, there is a high probability that there will be a mismatch between the segment the client has requested and the first complete segment received over multicast. To resolve this mismatch, the proxy requests one or more segments over unicast when the stream is first started to service the corresponding requests from the client, giving the proxy time to join the multicast channel and also receive and cache the required content segments to bring the cached content and the client requests into line.

[0014] However, the need for the proxy to make unicast requests when a client first starts streaming a popular live event (such as a football match) negates many of the benefits of m-ABR. Large unicast traffic peaks are exactly what m-ABR was designed to avoid, and even if they are brief, they still require sufficient network capacity.

[0015] Summary of the Invention

[0016] It is the aim of examples of the present invention to address one or more of the above problems.

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

[0018] Advantageously, examples of the invention remove the need for any unicast requests for content segments to be made to the content server when a client first starts streaming. This removes the large unicast traffic spike as the audience grows for a particular stream.

[0019] According to second example of the invention, there is provided a network element as claimed in claim 7.

[0020] 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:

[0021] Figure 1 is a diagram of an exemplary m-ABR network;

[0022] Figure 2 is a flow chart summarising the steps of a prior art method;

[0023] Figure 3 is a flow chart summarising the steps of a method in an example of the invention.

[0024] Description of Preferred Embodiments

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

[0026] Examples of the invention provide a method of managing content delivery to a client device, where a proxy server services unicast requests for content segments by joining a multicast channel carrying those content segments. An alternative content segment is provided to the proxy server in advance of the proxy server joining the multicast channel. Then, should a requested content segment not have been received over multicast and stored at the proxy server, for example when first joining a multicast channel, the proxy server can respond to the request with the stored alternative content segment, where the alternative content segment is not part of the sequence of content segments being requested by the client device. The alternative content segment can carry, for example, a simple video clip or static image such as a broadcaster logo or programme details, associated with the multicast channel. Thus, there is no need for the proxy server to make a unicast request for any content segment it has yet to receive over the appropriate multicast channel.

[0027] Figure 1 shows an example m-ABR streaming network 100. The network 100 comprises a content source 102, a content encoder 103, a multicast server 104, a multicast network 106, a unicast server 108, a unicast network 110, a proxy server 1 12, a provisioning server 114, and a client device 116.

[0028] The content source 102 provides content, such as a live sports or TV broadcast, in the form of video sequences to the content encoder 103.

[0029] The proxy server 1 12 comprises a cache for storing data. The proxy server 1 12 may be located within a device such as a home gateway or router for example. The proxy server 112 has several functions, including acting as a multicast gateway, as will be described in more detail below.

[0030] The client device 116 is 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.

[0031] The content encoder 103 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 103 may encode 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.

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

[0033] The content segments, encoded at one or more quality levels (each corresponding to an encoded bit rate), are also passed from the content encoder 103 to the multicast server 104 for transmission by multicast to any devices that have joined the corresponding multicast channel or channels. Alternatively, the multicast server 104 can request encoded content segments from the unicast server 108 and process them ready for transmission over multicast. The operation of the multicast server 104 is controlled by the provisioning server 1 14.

[0034] Whilst the system 100 described here comprises a single client device 116, it should be noted that more than one client device may be connected to the proxy server 112. Similarly, the system may comprise more than one proxy server 112, each with one or more client devices 116 connected to it.

[0035] The multicast server 104 may be configured in one of various modes of operation. In one mode of operation, the provisioning server 1 14 monitors the requests for content segments made by a plurality of client devices to the unicast server 108 via one or more proxies. When the provisioning server 114 determines that a sufficient number of client devices have requested the same content segment at about the same time, it may instruct the multicast server 104 to transmit the content segment and subsequent content segments in the sequence on an associated multicast channel, in the expectation that the sequence would be requested by multiple client devices. Any devices, such as the proxy server 1 12, that have joined the multicast channel will be able to receive the transmitted segments.

[0036] In another mode of operation, the multicast server 104 is configured for specific content, such as a particular television channel. That specific content passed from the content encoder 103 to the multicast server 104 is transmitted over a suitable multicast channel.

[0037] A skilled person will appreciate that other modes of operation of the multicast server 104 are possible.

[0038] The proxy server 112 can also be configured by the provisioning server 1 14 or via a suitable multicast control channel. The configuration can give information about the multicast streams that are available over the multicast network 104, and further assist with controlling when the proxy server 112 should join a multicast channel.

[0039] To request content segments, the client device 116 can first obtain a manifest file from the unicast server 108, or provided some other way, such as from the proxy server 1 12 which obtains it during configuration with the provisioning server 114. Manifest files are used by client devices to identify where content segments are located (by a URL in the manifest). The client device 1 16 can then request these content segments in sequence using HTTP requests from the unicast server 108 (path not shown in Figure 1 ), and concatenate them to form a continuous stream of content segments for playback. As each content segment is available on the unicast server 108 at a plurality of encoded bit rates, the client device 116 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 116 for content segments will not make use of multicast delivery and are sent directly to the unicast server 108, which delivers the requested content segments by unicast. Other requests for content segments from the client device 1 16 that may benefit from multicast delivery are re-directed to, or simply intercepted by, the proxy server 112, and can be handled in accordance with the examples described later.

[0040] The client device 116 could request and receive content segments from the unicast server 108 from the start to the end of a streaming session. However, in some cases the proxy server 1 12 determines that multicast delivery could be used to receive some content segments.

[0041] The proxy server 1 12 monitors unicast content requests from the client device 116 and is aware of when content segments requested by the client device 116 could be received by multicast by joining a suitable multicast channel.

[0042] The proxy server 1 12 determines whether it should join a multicast channel to satisfy the client device’s requests, and if so, joins the relevant multicast channel at an appropriate time, and, after receiving data by multicast, replies to the client device’s requests with content segments received by multicast, but packaged as unicast content responses.

[0043] After joining a multicast channel, the proxy server 1 12 may decide to leave the multicast channel. If the proxy server 112 leaves the multicast channel, it can return to satisfying the client device’s requests for unicast content segments by requesting the content segments from the unicast server 108 and delivering it to the client device 116 as unicast responses.

[0044] The client device 1 16 does not need to be aware of the proxy server 1 12, and does not need to be aware of whether content segments are being delivered by unicast from the unicast server 108 via the proxy server 112, or are delivered by multicast to the proxy server 1 12 that then delivers the content segments to the client device 1 16 in a unicast format.

[0045] With reference to Figure 2, there now follows a description of the operation of the proxy server 112 in an example where the invention has not been applied. In step 200, the proxy server 1 12 receives a unicast request for a content segment from the client device 116. Then in step 202, the proxy server 112 checks its configuration to determine if the stream from which the content segment has been requested is available on an associated multicast channel. If it is not, then processing passes to step 203, and the proxy server 112 makes a unicast request for the content segment from the unicast server 108 over the unicast network 1 10 and receives the requested content segment over unicast. The proxy server 112 then forwards this received content segment to the client device 116 in step 210 over unicast. Processing can then return to step 200 to process the next client request.

[0046] Alternatively, in step 202, if the stream is available over an associated multicast channel, then processing passes to step 204, where the proxy server 112 determines whether the proxy server 112 has joined the associated multicast channel. If it has, then processing passes to step 208. If it has not, then in step 206 the proxy server 1 12 joins the associated multicast channel and starts receiving content segments over the multicast network 106, which it caches locally, and then processing passes to step 208.

[0047] In step 208, the proxy server 112 checks to see if the requested content segment is stored in the local cache (having been previously received over multicast). If it is not in the cache, then processing passes to step 203, where the proxy server 112 makes a unicast request for the content segment from the unicast server 108 over the unicast network 1 10, and forwards the content segment received in response to the client device 116 in step 210. If the content segment is stored in the cache, then processing passes to step 210, where the proxy server 1 12 forwards the stored content segment to the client device 1 16 over unicast. Processing can then return to step 200 to process the next client request.

[0048] The method of Figure 2 shows how under certain conditions, the proxy server 1 12 will need to make unicast requests for content segments that it is trying to receive over multicast. The reason why this happens is that in typical m-ABR systems, the content segments streamed over a multicast channel are configured to be slightly ahead of the content segments available over unicast from the unicast server. This is so that when requests are received, the matching content, or at least the initial portion of it, is generally available in the local cache at the proxy server. However, when first joining a multicast channel, the join request can still be made part way through the transmission of a content segment by the multicast server 104, and so the segment will not be available in the cache. Thus, the proxy server 1 12 has to make unicast requests as per step 203 to obtain the requested segment.

[0049] There now follows a description of examples of the invention with reference to Figure 3, where an alternative segment of “holding” content is made available to and cached locally by the proxy server 112 in advance. This alternative segment can then be used to respond to client requests for content segments that haven’t been cached at the proxy server 112 without the need to make unicast requests to the unicast server 108.

[0050] The alternative segment can be any encoded segment that can be played out by the client device 1 16, such as a segment of encoded video. The alternative segment can be provided to the proxy server 112 by the provisioning server 1 14 during its configuration prior to any multicast channels being joined, or can be provided in advance of it being used by some other mechanism such as over the multicast network 106 or the unicast network 1 10 from a suitable source. Advantageously, the alternative segment can be a low bit rate piece of encoded video or the resulting file being small in size, so that it can be delivered to the proxy server 112 quickly and is not onerous to cache. Examples of the type of content the alternative segment could hold include a static image or logo (such as the broadcaster’s logo), or a short animation / video (such as an advert). The alternative content segment is different from the content that the client device 116 is requesting a segment from in step 200 and described generally with reference to a content segment herein. Thus, the alternative content segment is not part of the sequence of content segments being requested by the client device 116. Or put another way, the alternative content segment is a segment from alternative content.

[0051] Figure 3 illustrates an example of the operation of the proxy server 1 12 in an example of the invention.

[0052] Steps 300, 302, 303, 304, 306 and 310 operate in the same manner as steps 200, 202, 203, 204, 206 and 210. However, in step 308, the proxy server 1 12 checks to see if the requested content segment is stored in the local cache (having been previously received over multicast). This check can be done repeatedly over a predetermined period of time, to allow time for segments to be received and cached. If it is not in the cache, then processing passes to step 309, where instead of the proxy server 1 12 fetching the content segment over unicast (as per steps 203 / 303), the proxy server 1 12 retrieves the alternative segment from the cache and 1 12 then transmits the alternative segment to the client device 116 over unicast in response to the content request from the client device 1 16.

[0053] In this situation where the client device 116 receives the alternative segment in response to its content segment request, the client device 116 will play out this alternative segment as if it had received the requested segment. The client device 116 would then make a request for the next content segment (details of which it can obtain from the manifest) and processing starts again at step 300. The next content segment may be received over the multicast channel and cached at the proxy server 112 by the time processing reaches step 308. If the requested next content segment hasn’t been cached (or sufficiently cached), then the alternative segment can be used again by processing to step 309.

[0054] However, if in step 308, the content segment is stored in the cache, then processing passes to step 310, where the proxy server 1 12 forwards the stored requested content segment to the client device 116 over unicast. The client device 116 can then play out the requested content segment. Processing can then return to step 300 to process the next client request.

[0055] Note, in step 308, even if the requested content segment is not cached at the proxy server 112 in its entirety, as long as at least a predetermined first portion has been cached, then processing may pass to step 310 to begin forwarding that segment to the client device 116 in the knowledge that the rest of the segment will be received over multicast ready forwarding by the time that portion of the segment is needed.

[0056] Hence, the alternative content segment is effectively substituted for the requested content segment when the requested content segment is not at least partially stored in the cache. Using the alternative segment prevents the proxy server 112 from making unicast requests when first joining a multicast channel. This is especially useful when the audience numbers rise quickly and is likely to be large, as is typical at the start of a major sporting event, which would otherwise trigger numerous unicast requests for segments when client devices initially start streaming.

[0057] The alternative content segment could be associated with the content for which it is used in the place of. For example, if used to respond to requests for a segment from a live football stream, the alternative segment could be a static image showing details of the teams involved in the football match. In general, it is noted herein that while the above describes examples of the invention, there are several variations and modifications which may be made to the described examples without departing from the scope of the present invention as defined in the appended claims. One skilled in the art will recognise modifications to the described examples.

Claims

CLAIMS1 . A method of managing content delivery over a network to a client device by a network element, said content comprising a sequence of content segments, said method comprising: i) receiving from the client device a request for a content segment from the sequence of content segments; ii) joining a multicast channel associated with the sequence of content segments, and storing any content segments from the multicast channel in a cache; iii) determining whether the requested content segment is stored in the cache at the network element; and if the requested content segment is stored, then transmitting to the client device over unicast the requested content segment from the cache, otherwise transmitting to the client device over unicast an alternative content segment stored at the network element, wherein the alternative content segment is not part of the sequence of content segments.

2. The method as claimed in claim 1 , wherein the content is video, and the content segments are encoded segments of video.

3. The method as claimed in claim 1 or claim 2, wherein the alternative content segment is one of a static image, a logo, a short animation, or short video .

4. The method as claimed in any preceding claim, wherein the alternative content segment is associated with the sequence of content segments.

5. The method as claimed in any preceding claim, wherein the alternative content segment is stored at the network element in advance of the network element joining the multicast channel.

6. The method as claimed in any preceding claim, wherein the alternative content segment is received by the network element as part of a configuration process of the network element.

7. A network element for managing content delivery over a network to a client device, said content comprising a sequence of content segments, said network element arranged in operation to:receive from the client device a request for a content segment from the sequence of content segments; join a multicast channel associated with the sequence of content segments, and storing any content segments from the multicast channel in a cache; determine whether the requested content segment is stored in the cache at the network element; and if the requested content segment is stored, then transmit to the client device over unicast the requested content segment from the cache, otherwise transmit to the client device over unicast an alternative content segment stored at the network element, wherein the alternative content segment is not part of the sequence of content segments.

Images