Method for joining a multicast group

Abstract

A method of managing content delivery to client devices is described in which a proxy server serves unicast requests for content segments by joining the multicast channel carrying those content segments. Before the proxy server joins the multicast channel, an alternative content segment is provided to the proxy server in advance. The proxy server can then respond to a request with the stored alternative content segment if the requested content segment is not received over multicast and stored at the proxy server, for example when first joining the multicast channel. The alternative content segment can carry, for example, a simple video clip or static image associated with the multicast channel, such as a broadcaster logo or programme details. Thus, the proxy server does not need to make unicast requests for any content segments that it has not already received on the appropriate multicast channel.

Description

Technical Field

[0001] This invention relates to the field of content delivery in hybrid networks utilizing a combination of unicast and multicast, and more particularly, to a method for managing content delivery when multicast channels are added to such networks. Background Technology

[0002] Currently, unicast delivery is used to deliver video content to a range of client devices, where a single data stream is sent to just one individual client device. Web (HTTP) technology is used for content delivery, where the content is segmented into short file segments, typically lasting about two to ten seconds, allowing each segment to be requested and delivered to the client device via HTTP.

[0003] Alternatively, segments can be encoded at a set of quality levels, each with a different bitrate and therefore a different file size. Client devices monitor their buffer levels and achieved network throughput, determining the quality at which to request the next segment, thus striking a good trade-off between media quality and timely delivery. Decoding segments allows the video stream to be reproduced, albeit at varying quality, with minimal lag, resulting in a good user experience. This approach is commonly referred to as Adaptive Bitrate (ABR) streaming.

[0004] However, ABR relies on HTTP, which uses unicast (one-to-one) delivery technology. Therefore, ABR is inefficient for live streams with large audiences due to the numerous copies of the content being delivered. Multicast (one-to-many) transmission would be more efficient. However, multicast is currently rarely used for any service other than the linear video channel on the internet for network operators to deliver content to their own set-top boxes. The main reason is that multicast itself is not well-suited for open use on the internet.

[0005] To bring the benefits of multicast scalability to HTTP-based Internet media streaming, a class of technologies known as multicast adaptive bit rate (m-ABR) is being researched and standardized.

[0006] The purpose of m-ABR is to allow ABR content to be delivered more efficiently over the network by allowing the use of multicast on the content stream when many clients request the same content at approximately the same time.

[0007] A common desire for many m-ABR systems is to deploy multicast and enable m-ABR without making any changes to client devices and applications that already support HTTP (unicast) streaming. This can be achieved using a hybrid approach that combines multicast and unicast delivery, where a proxy is inserted between the client device and the content server. The proxy can inspect content requests from client devices and, when appropriate, join the multicast channel, receive the multicast content, and deliver it to the client, packaging the content to appear as if it were delivered unicast.

[0008] Examples of such mixed solutions are described in: Cable Labs' "IP Multicast Adaptive Bit Rate Architecture Technical Report" OC-TR-IP-MULTI-ARCH-C01-161026, 26 / 10 / 2016; 3GPP specifications, 23.246 (MBMS Architecture and functional description), 26.346 (MBMS Protocols and codecs) and 26.347 (MBMS APIs); and DVB's "Adaptive Media Streaming over IP Multicast" ETSI TS 103 769 V1.1.1 (2020-11).

[0009] The applicant's own international application WO2020 / 173878 describes an alternative hybrid unicast / multicast content delivery method. A client device requests content from a content server via unicast. The response containing the requested content is split into two parts: a first part containing elements specific to the individual client device (e.g., session-specific data), and a second part common to all client devices (typically the requested video content). The first part can be delivered via unicast, and the second part via multicast. These parts are reassembled before being sent to the client device via unicast. The splitting and reassembly are handled by an appropriately configured proxy server.

[0010] These m-ABR systems typically place an agent at the root of the multicast network. This agent provides the source of content segments and pushes them into the network via multicast. Agents at the edge of the multicast network (typically in broadband home gateways) receive content segments after joining the appropriate multicast channel and cache them locally, awaiting requests for those segments from clients. The agent typically joins the multicast channel when it knows that a client is consuming a specific media stream, such as when a client has made an initial request for a manifest file or content segment.

[0011] The segment being transmitted on multicast when the agent joins may be the same as or different from the segment requested by the client. The client may also join midway through the transmission of a media segment. Therefore, there is a high probability of a mismatch between the segment already requested by the client and the first complete segment received via multicast. To resolve this mismatch, when the stream first begins serving a corresponding request from the client, the agent requests one or more segments on unicast, giving the agent time to join the multicast channel, and also receives and caches the required content segments to align the cached content with the client's request.

[0012] However, when clients first begin streaming popular live events (such as football matches), the need to make unicast requests to the proxy negates many of the advantages of m-ABR. Large unicast traffic spikes are precisely the problem that m-ABR was designed to avoid, and even if the spikes are short-lived, it still requires sufficient network capacity. Summary of the Invention

[0013] The purpose of the embodiments of the present invention is to solve one or more of the problems described above.

[0014] According to one example of the present invention, a method according to claim 1 is provided.

[0015] Advantageously, examples of the present invention eliminate the need for any unicast requests to the content server for a content segment when the client first begins streaming. This eliminates large unicast traffic spikes as viewers consume a particular stream.

[0016] According to a second example of the present invention, a network element as described in claim 7 is provided. Attached Figure Description

[0017] To better understand the invention, reference will now be made to the accompanying drawings by way of example only, in which: Figure 1 This is a diagram of an exemplary m-ABR network; Figure 2 It is a flowchart that summarizes the steps of existing technical methods; Figure 3 This is a flowchart summarizing the steps of the method in the example of the present invention. Detailed Implementation

[0018] The present invention is described herein with reference to specific embodiments. However, the invention is not limited to such examples.

[0019] An example of the present invention provides a method for managing content delivery to client devices, wherein a proxy server serves unicast requests for content fragments by joining a multicast channel carrying those content fragments. Alternative content fragments are provided to the proxy server in advance before it joins the multicast channel. Then, if the requested content fragment is not received on the multicast and is not stored at the proxy server, for example when the multicast channel is first joined, the proxy server can respond to the request with the stored alternative content fragments, wherein these alternative content fragments are not part of the sequence of content fragments requested by the client device. The alternative content fragments may carry, for example, simple video clips or still images associated with the multicast channel, such as broadcaster logos or program details. Therefore, the proxy server does not need to make a unicast request for any content fragments that it has not yet received on the appropriate multicast channel.

[0020] Figure 1 An example m-ABR streaming network 100 is shown. Network 100 includes 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 112, a provisioning server 114, and a client device 116.

[0021] Content source 102 provides content such as live sports or TV broadcasts to content encoder 103 in the form of video sequences.

[0022] Proxy server 112 includes a cache for storing data. Proxy server 112 may reside within a device such as a home gateway or router. Proxy server 112 has several functions, including acting as a multicast gateway, which will be described in more detail below.

[0023] Client device 116 is running a client application that is the source of content requests. For simplicity, the term "client device" is used to refer to a client device running a client application.

[0024] Content encoder 103 receives content from content source 102 and encodes it using an appropriate compression scheme (e.g., ITU-T Recommendation H.264 for video content). The encoded content is then segmented into a sequence of content segments, each typically lasting 2 to 10 seconds. Content encoder 103 can encode the content at one or more quality levels or bit rates, thereby producing one or more encoded content segments (at various quality levels) corresponding to the individual uncompressed content segments. This configuration is typical for adaptive bitrate streaming services.

[0025] Content encoder 103 transmits encoded content fragment data, encoded at all required bit rates, to unicast server 108. The data is stored in unicast server 108 and made available for transmission via unicast. Unicast server 108 uses the stored data to respond to unicast requests for content fragments using unicast responses.

[0026] Content segments encoded at one or more quality levels (each quality level corresponding to an encoded bit rate) are also passed from content encoder 103 to multicast server 104 for multicast transmission to any device that has joined one or more corresponding multicast channels. Alternatively, multicast server 104 may request encoded content segments from unicast server 108 and process the content segments to prepare them for multicast transmission. The operation of multicast server 104 is controlled by provisioning server 114.

[0027] While the system 100 described herein includes a single client device 116, it should be noted that more than one client device can be connected to the proxy server 112. Similarly, the system may include more than one proxy server 112, each proxy server 112 having one or more client devices 116 connected to it.

[0028] Multicast server 104 can be configured to one of various operating modes.

[0029] In one operating mode, provisioning server 114 monitors requests for content segments made by multiple client devices to unicast server 108 via one or more proxies. When provisioning server 114 determines that a sufficient number of client devices have requested the same content segment at approximately the same time, it may instruct multicast server 104 to transmit the content segment and subsequent content segments in the sequence over the associated multicast channel, anticipating that the sequence will be requested by multiple client devices. Any device already joined to the multicast channel (e.g., proxy server 112) will be able to receive the transmitted segments.

[0030] In another operating mode, multicast server 104 is configured for specific content, such as a specific television channel. This specific content, passed from content encoder 103 to multicast server 104, is transmitted via an appropriate multicast channel.

[0031] Those skilled in the art will understand that other operating modes of the multicast server 104 are also possible.

[0032] The proxy server 112 can also be configured by the provisioning server 114 or via an appropriate multicast control channel. This configuration can provide information about the multicast streams available on the multicast network 104 and further help control when the proxy server 112 should join the multicast channel.

[0033] To request a content fragment, client device 116 may first obtain a manifest file from unicast server 108 or otherwise provided, such as from proxy server 112, which obtained the manifest file during the configuration of provisioning server 114. The manifest file is used by the client device to identify where the content fragment is located (via a URL in the manifest). Then, client device 116 can use an HTTP request ( Figure 1 The client device 116 sequentially requests these content segments from unicast server 108 (path not shown) and concatenates them to form a continuous stream of content segments for playback. Since each content segment is available on unicast server 108 at multiple encoding bit rates, the client device 116 determines the requested encoding bit rate (quality) for each content segment, taking into account factors such as available network throughput and how much data has already been received and buffered at the client device waiting to play.

[0034] Some HTTP requests made by client device 116 for content fragments will not utilize multicast delivery, but will instead be sent directly to unicast server 108, which will deliver the requested content fragments via unicast. Other requests for content fragments from client device 116 that may benefit from multicast delivery will be redirected to proxy server 112, or simply intercepted by proxy server 112, and processed according to the examples described later.

[0035] Client device 116 can request and receive content segments from unicast server 108 from the beginning to the end of a streaming session. However, in some cases, proxy server 112 determines that multicast delivery can be used to receive certain content segments.

[0036] The proxy server 112 monitors unicast content requests from the client device 116 and knows when the content fragment requested by the client device 116 can be received via multicast by joining the appropriate multicast channel.

[0037] The proxy server 112 determines whether it should join the multicast channel to satisfy the client device's request, and if so, joins the relevant multicast channel at the appropriate time, and after receiving data via multicast, responds to the client device's request using content fragments received via multicast but packaged as unicast content responses.

[0038] After joining the multicast channel, proxy server 112 may decide to leave the multicast channel. If proxy server 112 leaves the multicast channel, it may return to satisfy the client device's request for a unicast content fragment by requesting a content fragment from unicast server 108 and sending it as a unicast response to client device 116.

[0039] Client device 116 does not need to know about proxy server 112, nor does it need to know whether the content fragment is transmitted from unicast server 108 via proxy server 112 via unicast, or transmitted to proxy server 112 via multicast and then transmitted to client device 116 in unicast format.

[0040] Reference Figure 2 The following is a description of the operation of proxy server 112 in an example where the present invention is not applied.

[0041] In step 200, proxy server 112 receives a unicast request for a content fragment from client device 116. Then, in step 202, proxy server 112 checks its configuration to determine if the stream from which it requested the content fragment is available on the associated multicast channel. If not, processing proceeds to step 203, and proxy server 112 issues a unicast request for the content fragment from unicast server 108 on unicast network 110 and receives the requested content fragment via unicast. Then, in step 210, proxy server 112 forwards the received content fragment to client device 116 via unicast. Processing can then return to step 200 to process the next client request.

[0042] Alternatively, in step 202, if the stream is available on the associated multicast channel, the process proceeds to step 204, where proxy server 112 determines whether it has joined the associated multicast channel. If yes, the process proceeds to step 208. If not, in step 206, proxy server 112 joins the associated multicast channel and begins receiving content fragments on multicast network 106, which are cached locally, and then the process proceeds to step 208.

[0043] In step 208, proxy server 112 checks whether the requested content fragment is stored in a local cache (previously received via multicast). If it is not in the cache, the process proceeds to step 203, where proxy server 112 issues a unicast request for the content fragment from unicast server 108 on unicast network 110, and in step 210, responsively forwards the received content fragment to client device 116. If the content fragment is stored in the cache, the process proceeds to step 210, where proxy server 112 forwards the stored content fragment to client device 116 via unicast. The process can then return to step 200 to process the next client request.

[0044] Figure 2The method illustrates how, under certain conditions, proxy server 112 might need to make a unicast request for a content segment it is attempting to receive via multicast. This occurs because, in a typical m-ABR system, content segments streamed over a multicast channel are configured to be available slightly earlier than content segments available on a unicast from a unicast server. This makes it possible that when a request is received, the matching content, or at least its initial portion, is typically available in the proxy server's local cache. However, when joining a multicast channel for the first time, the join request may still be made midway through the transmission of the content segment by multicast server 104, and therefore the segment will not be available in the cache. Therefore, proxy server 112 needs to make a unicast request as per step 203 to obtain the requested segment.

[0045] Now refer to Figure 3 An example of the invention is described, wherein an alternative fragment of the "retained" content may be obtained in advance by proxy server 112 and cached locally. This alternative fragment can then be used in response to a client's request for a content fragment not cached at proxy server 112, without requiring a unicast request to unicast server 108.

[0046] Alternative segments can be any encoded segment playable by client device 116, such as encoded video segments. Alternative segments can be provided to proxy server 112 by provisioning server 114 during proxy server 112 configuration before joining any multicast channels, or they can be provided in advance from an appropriate source via some other mechanism such as multicast network 106 or unicast network 110 before they are used. Advantageously, alternative segments can be low-bitrate segments of encoded video or small-sized result files, allowing them to be quickly delivered to proxy server 112 without causing problems with caching. Examples of content types that alternative segments can hold include still images or logos (e.g., a broadcaster's logo) or short animations / videos (e.g., advertisements). Alternative content segments are different from the content requested by client device 116 in step 200 and are generally described herein as content segments. Therefore, alternative content segments are not part of the sequence of content segments requested by client device 116. Or in other words, alternative content segments are segments derived from alternative content.

[0047] Figure 3 An example of the operation of the proxy server 112 in the example of the present invention is illustrated.

[0048] 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, proxy server 112 checks whether the requested content fragment is stored in a local cache (previously received via multicast). This check can be repeated over a predetermined time period to allow time for receiving and caching the fragment. If it is not in the cache, the process proceeds to step 309, where instead of proxy server 112 retrieving the content fragment via unicast (as per steps 203 / 303), proxy server 112 retrieves an alternative fragment from the cache, and then, in response to a content request from client device 116, 112 sends the alternative fragment to client device 116 via unicast.

[0049] In the case where client device 116 receives an alternative segment in response to its content segment request, client device 116 will play the alternative segment as if it had already received the requested segment. Client device 116 will then request the next content segment (its details of which can be obtained from the manifest), and processing resumes at step 300. The next content segment can be received on the multicast channel and cached in proxy server 112 before processing reaches step 308. If the requested next content segment is not cached (or is adequately cached), the alternative segment can be used again by proceeding to step 309.

[0050] However, if the content fragment is stored in the cache in step 308, the process proceeds to step 310, where the proxy server 112 forwards the stored requested content fragment to the client device 116 via unicast. The client device 116 can then play the requested content fragment. The process can then return to step 300 to process the next client request.

[0051] Note that in step 308, even if the requested content fragment is not cached entirely at proxy server 112, as long as at least the first portion has been cached, the process can proceed to step 310, whereby forwarding of the fragment to client device 116 begins, provided that the fragment has been received on multicast and is ready for forwarding before the remaining portion is needed.

[0052] Therefore, when at least part of the requested content segment is not stored in the cache, an alternative content segment effectively replaces the requested content segment. When initially joining a multicast channel, an alternative segment is used to prevent proxy server 112 from making unicast requests. This is especially useful when the number of viewers increases rapidly and can be large, which is typical at the start of major sporting events, which otherwise trigger a large number of unicast requests for segments when client devices initially begin streaming.

[0053] Alternative content snippets can be associated with the content they are used to replace. For example, if used in response to a request for a snippet from a Pro Evolution Soccer stream, an alternative snippet could be a static image showing details of the teams involved in a football match.

[0054] In general, it should be noted that although examples of the invention have been described above, several variations and modifications may be made to the described examples without departing from the scope of the invention as defined by the appended claims. Those skilled in the art will recognize the modifications to the described examples.

Claims

1. A method for managing the delivery of content over a network to a client device by network elements, the content comprising a sequence of content fragments, the method comprising: i) Receive a request from the client device for a content segment from the content segment sequence; ii) Join the multicast channel associated with the content fragment sequence and store any content fragments from the multicast channel in a cache; iii) Determine whether the requested content fragment is stored in the cache at the network element; as well as If the requested content fragment is stored, the requested content fragment is sent to the client device from the cache via unicast; otherwise, an alternative content fragment stored at the network element is sent to the client device via unicast, wherein the alternative content fragment is not part of the content fragment sequence.

2. The method according to claim 1, wherein, The content is a video, and the content segment is an encoded segment of the video.

3. The method according to claim 1 or claim 2, wherein, The alternative content fragment is one of still images, logos, short animations, or short videos.

4. The method according to any one of the preceding claims, wherein, The alternative content fragment is associated with the content fragment sequence.

5. The method according to any one of the preceding claims, wherein, The alternative content fragment is pre-stored at the network element before the network element joins the multicast channel.

6. The method according to any one of the preceding claims, wherein, As part of the configuration process of the network element, the alternative content fragment is received by the network element.

7. A network element for managing the delivery of content to client devices over a network, the content comprising a sequence of content fragments, the network element being operationally configured to: Receive a request for a content segment from the content segment sequence from the client device; Join the multicast channel associated with the content fragment sequence, and store any content fragments from the multicast channel in a cache; Determine whether the requested content fragment is stored in the cache at the network element; as well as If the requested content fragment is stored, the requested content fragment is sent to the client device from the cache via unicast; otherwise, an alternative content fragment stored at the network element is sent to the client device via unicast, wherein the alternative content fragment is not part of the content fragment sequence.

Images