Content delivery

Abstract

A method of managing a network for delivering content to a client device, wherein content segments are delivered to proxies in a multicast group before being delivered to the client device from the proxies by unicast. The proxies intermittently leave the multicast group to probe the network by making unicast requests for content segments, receiving these segments from a content server by unicast and forwarding the segments to the client device. This allows the client device to determine the maximum throughput between the content server and the client device via the proxies, and so the client device can use its adaptive bitrate algorithm to determine whether the network can support a switch to a higher bitrate stream, and request the higher bitrate stream accordingly. The higher bitrate stream can be served by proxies joining or establishing appropriate multicast groups.

Description

Technical Field

[0001] This invention relates to the field of content delivery using a combination of unicast and multicast. Background Technology

[0002] An increasing amount of live content is being streamed using HTTP (or HTTPS). The popularity of live streaming events drives highly volatile demand, resulting in very high peak-to-average traffic ratios. For example, Figure 1 Curve 100 shows an example of traffic volume at a gateway near the edge of the mobile network during the 2016 European Football Championship. Curve 102 shows traffic volume on a day without a football match (Friday, June 15th), and curve 104 shows traffic volume on the day after the England vs. Wales match (Friday, June 16th). Both curves roughly show the same traffic volume for a day, except that curve 104 has a significant additional peak in traffic volume between approximately 2 PM and 4 PM, generated by customers streaming the football match.

[0003] This high peak-to-average power ratio poses a particular challenge to the network edge, where such peaks can lead to a decrease in the quality of user experience.

[0004] Most commonly, content is delivered over the Internet using HTTP (or HTTPS) request / response pairs. The client application sends an HTTP request to the server, and a response containing the requested content is returned. This request / response is essentially unicast.

[0005] HTTP(S) can be used for video streaming. Typically, the client receives a manifest file that allows it to determine the URLs of the individual files containing the video segments. The client then requests these segments sequentially and concatenates them to form a continuous stream for playback. Each video segment can also be obtained at a different bitrate to allow the video rate to adapt to the available network throughput. This technique is called HTTP Adaptive Streaming (HAS).

[0006] For users watching the same event (such as a live football match), each client will make its own HTTP request and receive its own HTTP response, even if most of the content passed to them within the HTTP response is the same across clients. This results in very inefficient network usage.

[0007] However, if the access network can use multicast instead of unicast for content delivery, then Figure 1 The impact of peak live content shown can be significantly reduced. Furthermore, using multicast in the access network can significantly reduce peak demand on content delivery network servers.

[0008] Solutions to this problem already exist, in which a proxy is used to insert the multicast path into the unicast path between the client and the content server. Examples of such hybrid solutions include: “IP Multicast Adaptive Bit Rate Architecture Technical Report”, OC-TR-IP-MULTI-ARCH-C01-161026, 26 / 10 / 2016, Wired Labs; 3GPP specifications, 23.246 (MBMS Architecture and functional description), 26.346 (MBMS Protocols and codecs), and 26.347 (MBMS APIs); and DVB document A176, “Adaptive media streaming over IP Multicast”, (March 8, 2018).

[0009] Figure 2 A general example of this solution is shown.

[0010] exist Figure 2 The diagram illustrates a content server 202 providing content such as video to client devices 204a, 204b, and 204c. A multicast agent X 206 and three agents Y 208a, 208b, and 208c are inserted into the unicast path between the content server 202 and the client devices. Agent X 206 retrieves unicast content from the content server 202 and makes it available via multicast. Agent Y receives the multicast content and can provide it to any requesting client device via unicast. All client devices will receive the same response to their requests for segments because all agents Y receive the same multicast content from agent X. Agent Y can reside within a client device, within a separate device, or, depending on the configuration, may consist of only a single agent Y.

[0011] In this solution, agent X is pre-configured to act as a client, independently requesting content fragments and distributing the entire response across the multicast network. Agent X does this by first requesting the manifest file and then promptly requesting the content fragments described in that manifest.

[0012] In this configuration, the rate at which proxy Y makes content available to client devices is limited by the multicast rate between proxy X and proxy Y, as well as other factors such as whether proxy Y has pre-cached any content. Therefore, client devices utilizing HAS may face challenges in properly monitoring the available network throughput from the content server to the client device, which in turn hinders the proper functioning of the client device's adaptive bitrate algorithm and the switching between video rates under HAS.

[0013] Other unicast-multicast hybrid arrangements also have similar problems. Summary of the Invention

[0014] The purpose of this invention is to provide an improved content delivery mechanism.

[0015] According to one example of the present invention, a method for managing the delivery of content to a client device over a network is provided, the content comprising a sequence of segments, wherein each segment is encoded according to a plurality of bit rates, the method comprising:

[0016] At the first network element, one or more segments encoded at a first bit rate are received via multicast from a content server, and the segments encoded at the first bit rate are transmitted from the first network element to the client device via unicast.

[0017] A request for one or more subsequent segments encoded at the first bit rate is sent from the first network element to the content server via unicast;

[0018] At the first network element, one or more requested subsequent segments are received via unicast, and the received subsequent segments are forwarded to the client device via unicast.

[0019] At the first network element, a request is received from the client device for one or more additional subsequent segments encoded at a second bit rate, wherein the second bit rate is higher than the first bit rate; and

[0020] At the first network element, one or more additional subsequent segments are received via multicast, and the received additional segments are sent to the client device via unicast.

[0021] The requested one or more fragments, which can be received at the first network element, are sent by the content server.

[0022] After step iv), the method may include sending a request to a content server via unicast for one or more subsequent segments encoded at a second bit rate.

[0023] A segment received via multicast at the first network element may be sent by the second network element.

[0024] The first network element can be a proxy server. The second network element can be a proxy server.

[0025] The content may be video content.

[0026] The first network element and the client device can be co-located.

[0027] According to one example of the invention, a network element is provided for managing the delivery of content over a network to a client device, the content comprising a sequence of segments, wherein each of the segments is encoded at multiple bit rates, and the proxy server is adapted in operation to:

[0028] The device receives one or more segments encoded at a first bit rate by multicast from a content server and sends the segments encoded at the first bit rate to the client device by unicast.

[0029] Send a request for one or more subsequent segments encoded at a first bit rate to the content server via unicast;

[0030] Receive one or more requested subsequent segments via unicast and forward the received subsequent segments to the client device via unicast;

[0031] Receive from the client device a request for one or more additional subsequent segments encoded at a second bit rate, wherein the second bit rate is higher than the first bit rate; and

[0032] Receive one or more additional subsequent segments via multicast and send the received additional segments to the client device via unicast. Attached Figure Description

[0033] To better understand the invention, reference will now be made to the accompanying drawings by way of example only, wherein:

[0034] Figure 1 It is a graph showing the traffic volume on the network on different days;

[0035] Figure 2 This is a typical network diagram of an existing solution;

[0036] Figure 3 This is a network diagram illustrating the main components of an example of the present invention;

[0037] Figure 4 This is a flowchart summarizing the steps for establishing a steady-state multicast session in an example of the present invention;

[0038] Figure 5 This is a flowchart summarizing the steps of unicast probing in an example of the present invention. Detailed Implementation

[0039] This invention is described with reference to specific examples. However, the invention is not limited to these examples.

[0040] An example of the present invention provides a method for managing a network for delivering content to client devices, wherein content fragments are delivered to an agent in a multicast group before being delivered from an agent to the client device via unicast. The agent intermittently leaves the multicast group to probe the network by making unicast requests for content fragments, receiving these fragments from a content server via unicast, and forwarding them to the client device. This allows the client device to determine the maximum throughput between the content server and the client device via the agent, and thus the client device can use its adaptive bitrate algorithm to determine whether the network can support switching to a higher bitrate stream, and accordingly request the higher bitrate stream. The higher bitrate stream can be served by an agent that has joined or established an appropriate multicast group.

[0041] Figure 3 The main components of a simplified "Multicast-Assisted Unicast Delivery" (MAUD) network supporting content delivery are shown. The examples of this invention apply to the simplified MAUD network described herein. Those skilled in the art will also understand that these examples are equally applicable to other hybrid unicast / multicast delivery networks, such as those described above.

[0042] A more detailed MAUD arrangement is described in the applicant's patent application EP19159748.3, which describes an arrangement known as "Multicast-Assisted Unicast Delivery" (MAUD). Client devices request content from a content server via unicast. The response containing the requested content is split into two components: a first component contains elements specific to each client device (e.g., session-specific data), while the second component is common to all client devices (typically the requested video content). The first component can be delivered via unicast, the second component via multicast, and they are subsequently reassembled to form the original response. The splitting and reassembling are handled by a properly configured proxy server. Examples of the present invention can be applied to such a MAUD arrangement, although the splitting and reassembling of the requested content is not critical to the examples of the invention.

[0043] Back Figure 3Network 300 includes content server 302, proxy X 306, proxy Y 308a, 308b and 308c, client devices 304a, 304b and 304c, and multicast controller 312. Content server 302 provides content such as video to requesting entities such as client devices. Content server 302 may be located within a content delivery network (CDN), and more than one content server may exist. Proxy X 306 communicates with content server 302 via unicast. Proxy X 306 may also communicate with proxies Y 308a, 308b and 308c via both unicast and multicast. Proxy Y may be located within client devices, in separate devices (such as home gateways), or, depending on the configuration, may be a single proxy Y.

[0044] Note that in Figure 3 In the diagram, bidirectional unicast communication paths are marked with solid lines, unidirectional multicast communication paths are marked with dashed lines, and control interface communication paths are marked with dotted lines. Control interface communication paths transmit control messages / commands between the multicast controller 312 and other components in the network. Other related communication paths will be described later.

[0045] Assume that client devices are running their own client applications, which are the source of content requests. For simplicity, the term "client device" will be used from this point onward to refer to the client device running the client application. Client devices can issue HTTP (or HTTPS) unicast requests to content stored at address 302 on the content server.

[0046] The content stored at content server 302 typically comprises media content (e.g., television programs, movies, or entire linear TV channels) consisting of video sequences encoded according to appropriate standards such as ITU H.264. The video sequences are stored in content server 302 as sequential time segments, where each segment is typically equal to 2 to 10 seconds of decoded video. The video sequences are also encoded at multiple bitrates or quality levels, resulting in multiple encoded sequences, each encoded at one of multiple bitrates. This arrangement is typical of adaptive bitrate streaming services.

[0047] The manifest file is used by the client to identify where segments are located (via URLs in the manifest). Therefore, the client device uses the manifest to determine where to direct sequential unicast requests for each segment, streaming the video sequence as needed at specific bit rates. This arrangement is used in HTTP adaptive streaming technologies such as MPEG-DASH and Apple's HLS (HTTP Live Streaming).

[0048] The multicast controller 312 (MCC) monitors the operations of agent X and agent Y and controls the agents accordingly.

[0049] Some HTTP requests made by the client device to content will not take full advantage of the MAUD deployment; instead, the requests can be sent directly to the content server. Other content requests from the client device that could benefit from MAUD will be redirected to one of the proxies Y, or simply intercepted by one of the proxies Y.

[0050] Any of several well-known techniques can be used, such as using an HTTP redirect from content server 302, to insert proxy Y into the HTTP path. In this case, content server 302 will be configured to not directly handle requests for potentially popular content, but instead be redirected to the appropriate proxy Y. For example, instead of providing a normal response, content server 302 can respond with HTTP status code 307, indicating a temporary redirect. This invites the client device to make a new request to the new URL provided by the content server in its response, thus enabling the request to be made to proxy Y. This technique allows the content server and proxy Y to exist in different domains, which is often the case.

[0051] Other mechanisms for inserting proxy Y into the HTTP path include: proxy Y configured as a transparent proxy (although all requests are intercepted by it and only work for unencrypted traffic); proxy Y configured as a forward proxy (where client devices are explicitly configured to send their requests directly to proxy Y); DNS hijacking (where a DNS server is configured to provide the IP address of proxy Y for the domain of interest); and manifest manipulation (where a manifest file is rewritten to make requests directly to proxy Y).

[0052] Figure 4 A flowchart outlining the steps for establishing a multicast session to deliver content to a client device is shown.

[0053] Starting at step 400, one or more client devices request content fragments (e.g., movies stored at content server 302) and receive responses (the fragments) via unicast through proxy Y. For example, client device 304a makes an HTTP GET request, which is essentially a unicast request for a content fragment encoded at a specific bitrate. This initial or first bitrate can be selected as the lowest available bitrate, or it can be selected in some other way, such as based on historical data or user preferences. Each HTTP GET request includes a URL indicating where the fragment can be obtained. The URL is found in a manifest file associated with the content. Proxy Y 308a receives the request and forwards it to content server 302.

[0054] Content server 302 responds with an HTTP response, each containing the requested segment. The HTTP response is a unicast response. The response is received by proxy Y 308a and sent to client device 304a. The received segment can then be viewed by client device 304a.

[0055] Client device 304a may continue to request and receive segments according to step 400 until the streaming of the content is complete. However, in this example of the invention, multicast controller 312 determines whether a multicast group should be used to deliver subsequent segments.

[0056] In step 402, agent Y 308a sends a consumption report to multicast controller 312. This consumption report contains data related to the proxied HTTP request / response pairs, such as the URL of each HTTP request. The consumption report may be sent to multicast controller 312 at intervals (time intervals or after a certain number of requests / received segments).

[0057] The HTTP requests and responses described so far are essentially unicast. However, it should be noted that requests for the same content can be made by other client devices. This is typical, for example, during a live football match. Depending on the situation, agent Y 308a and other agents Y (308b or 308c) send consumption reports to multicast controller 312 for their respective client devices, allowing multicast controller 312 to determine whether to use multicast to help deliver further content.

[0058] In step 404, multicast controller 312 uses the received reports to determine whether HTTP requests reported from a given group of proxies Y justify using multicast for their responses. This group of proxies Y is referred to as a "group". Assuming certain conditions are met (e.g., more than a certain number of client devices request the same content at similar times), multicast controller 312 will configure proxies X and any associated proxies Y (i.e., the group) for multicast-assisted delivery by establishing an appropriate multicast group. Once the multicast group is established, multicast is used to send the content (the requested fragment) from proxies X to proxies Y.

[0059] In step 406, multicast controller 312 can add agent Y 308a to the group by sending an agent Y 308a instruction to establish an HTTP request route, thereby directing requests matching a specific URL path / pattern / string to agent X 306. Multicast controller 312 also sends an agent Y 308a instruction to provide a multicast listener. The instruction tells agent Y 308a to be ready to receive multicast. The multicast listener causes agent Y to issue an IGMP join command to the multicast address specified by the multicast controller.

[0060] To allow agent X 306 to use multicast for the return path of responses to requests that satisfy a matching pattern established for agent Y 306, multicast controller 312 configures agent X 306 to use multicast for certain responses sent by the content server. For example, this instruction could be to only use multicast for responses containing video files or MIME types (e.g., "video / mp4" or "video / MP2T"), thus sending only responses containing video traffic via multicast. In an alternative example, responses could be selected based on a specific ETAG or a set of ETAGs. ETAGs (Entity Tags) are part of the HTTP 1.1 specification and are used to uniquely identify response payloads.

[0061] Agent X 306 and one or more agents Y are now configured to send and receive content via multicast, respectively.

[0062] In step 408, for the other segments encoded at the first bit rate, an HTTP GET request is sent by client device 304a via unicast and received at proxy Y 308a. Proxy Y 308a checks to see if the request matches the previously proposed pattern. A match effectively means that the response to the request will be delivered via multicast. In this example, it is assumed that a match exists, and proxy Y 308a sends the HTTP GET request to proxy X 306 (instead of directly to content server 302).

[0063] Agent X 306 sends the received HTTP GET request to content server 302, which responds to agent X 306 with the requested fragment (encoded at a first bit rate) in an HTTP response. Agent X 306 then sends these fragments via multicast. These fragments are typically sent at a transmission rate sufficient to ensure timely delivery.

[0064] Agent Y 308a is configured to receive multicast and therefore will receive segments sent via multicast from agent X 306. The received segments are then sent from agent Y 308a to client device 304a via unicast.

[0065] Repeat step 408 until the client device 304a stops requesting fragments.

[0066] Figure 4The flowchart illustrates the establishment of a steady-state multicast session for content delivery, whereby a content fragment is requested by a client device and delivered to the agent (agent Y) via multicast before being sent from the agent to the client device via unicast. However, the rate at which the client device 304a receives fragments from agent Y 308a will be limited by the multicast rate between agent X and agent Y. The applicant's patent application EP19194759.7 proposes a method for setting possible multicast rates.

[0067] However, fixing the multicast rate means that client device 304a can never truly determine the maximum throughput between the content server and client device 304a. Therefore, client device 304a cannot use its adaptive bitrate algorithm to correctly determine whether the network can support streaming segments at a higher bitrate, and thus cannot accurately determine whether requests for decoding of segments encoded at a higher bitrate can be delivered in a timely manner.

[0068] Figure 5 A flowchart summarizing the steps of an example of the invention is shown, wherein agent Y 302 probes the network in a manner that allows client device 304a to determine the maximum throughput between the content server and the client device via agent Y. Client device 304a can then use its adaptive bitrate algorithm to determine whether the network can support switching to a higher bitrate stream and request the higher bitrate stream accordingly. Figure 5 The processing in Figure 4 After processing.

[0069] Therefore, assuming a stable state is reached while step 408 is being processed, the client device 304a continues to encode subsequent content fragments at the first bit rate via multicast requests. Figure 5 Step 500 begins from this stable state.

[0070] In step 500, agent Y 308a will periodically (e.g., after a period of time or after n fragment requests) leave the multicast group established in step 406. Agent Y 308a also sends HTTP GET requests received from the client device for subsequent fragments encoded at a first bit rate to the content server via unicast. These subsequent fragments are those requested and delivered in step 408. These requests may go directly to content server 302.

[0071] In step 502, content server 302 responds by sending the requested subsequent fragments to agent Y 308a via unicast. Agent Y 308a forwards these fragments directly to client device 304a via unicast without any delay. Thus, the delivery of subsequent fragments is via unicast and will be delivered as quickly as allowed by the network between agent Y 308a, content server 302, and client device 304a. Client device 304a can therefore assess the maximum throughput from content server 302 to client device 304a, rather than being limited by the multicast rate of agent Y 308a, which prevents client device 304a from receiving fragments only via multicast.

[0072] Steps 500 and 502 can be viewed as unicast probes for maximum throughput between client device 304a and content server 302.

[0073] Therefore, in step 504, the client device 304a determines the maximum throughput based on the rate at which subsequent segments are received, which can be calculated as the total segment size divided by the time it takes to receive the segment.

[0074] In step 506, client device 304a determines whether a segment encoded at a higher bit rate (above the first bit rate) can be delivered in time based on the determined maximum throughput. This is done by the client using its ABR algorithm. Typically, the ABR algorithm will consider both the maximum throughput and bit rate of the encoded segment.

[0075] If client device 304a decides not to switch to a segment encoded at a higher bit rate, the process returns to step 408 and continues to receive segments via multicast without switching to a higher bit rate. If the determination is yes, the process proceeds to step 508.

[0076] In step 508, client device 304a requests another subsequent segment, but this time the requested segment is encoded at a higher bit rate (higher than the first bit rate). This request for the higher bit rate encoded segment is sent to agent Y 308a via unicast.

[0077] In step 510, agent Y 308a can respond to the request for a segment encoded at a higher bit rate in several ways. If an existing multicast group carrying a higher bit rate stream exists, agent Y 304a can join that group. Agent Y 304a will then receive the requested higher bit rate encoded segment from the content server via multicast and send it to client device 304a via unicast, as described in step 408.

[0078] However, if no suitable multicast group exists, the process can return to step 400, in which the request is initially responded to by unicast, but at some later point, a suitable multicast group can be established to deliver the fragment encoded at a higher bit rate to agent Y 308a via multicast.

[0079] Generally, 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 in the appended claims. Those skilled in the art will recognize the modifications to the examples.

Claims

1. A method for managing the delivery of content to a client device over a network, the content comprising a sequence of segments, wherein, Each segment in the segment is encoded at multiple bit rates, and the method includes: i) At the first network element, one or more segments encoded at a first bit rate are received via multicast from the content server and transmitted from the first network element to the client device via unicast. ii) Sending a request for one or more subsequent segments encoded at the first bit rate from the first network element to the content server via unicast; iii) At the first network element, receive one or more requested subsequent segments via unicast and forward the received subsequent segments to the client device via unicast; iv) At the first network element, receive from the client device a request for one or more additional subsequent segments encoded at a second bit rate, wherein the second bit rate is higher than the first bit rate; v) Sending a request for one or more additional subsequent segments encoded at a second bit rate to the content server via unicast; and vi) At the first network element, one or more additional subsequent segments are received via multicast, and the received additional segments are sent to the client device via unicast.

2. The method according to claim 1, wherein, The requested one or more additional subsequent fragments received at the first network element are sent by the content server.

3. The method according to claim 1, wherein, The segments received at the first network element via multicast are transmitted via the second network element.

4. The method according to claim 3, wherein, The second network element is a proxy server.

5. The method according to claim 1, wherein, The first network element is a proxy server.

6. The method according to claim 1, wherein, The content described is video content.

7. The method according to claim 1, wherein, The first network element and the client device are co-located.

8. A network element for managing the delivery of content to client devices over a network, the content comprising a sequence of segments, wherein, Each segment in the fragment is encoded at multiple bit rates, and the network elements are adapted during operation as follows: The device receives one or more segments encoded at a first bit rate via multicast from a content server and sends the multiple segments encoded at the first bit rate to the client device via unicast. Send a request for one or more subsequent segments encoded at a first bit rate to the content server via unicast; Receive one or more requested subsequent segments via unicast, and forward the received subsequent segments to the client device via unicast; The client device receives a request for one or more additional subsequent segments encoded at a second bit rate, wherein the second bit rate is higher than the first bit rate; Requests for one or more additional subsequent segments encoded at a second bit rate are sent to the content server via unicast; and Receive one or more additional subsequent segments via multicast and send the received additional segments to the client device via unicast.

Images