Method and network unit for managing content distribution

Abstract

Methods and network elements for managing content distribution are described. A method for managing a network for distributing content in a hybrid unicast / multicast network, wherein content is requested by a client via unicast, but all or some of the content is distributed partially via multicast. Typically, a client requests content (in the form of fragments) via a first proxy. These fragments are distributed from a second proxy to the first proxy via multicast, and then sent onward to the requesting client via unicast. The fragments are also cached at the first proxy and can be sent to other clients requesting these fragments via unicast. However, problems may arise if the cached fragments are sent to the client too quickly. In one solution, the first proxy measures the multicast rate at which the fragments are distributed from the second proxy via multicast, and limits the rate at which the fragments are sent to the requesting client via unicast to no greater than the measured multicast distribution rate.

Description

Technical Field

[0001] The present invention relates to the field of content distribution using a combination of unicast and multicast. Background Art

[0002] Live content is increasingly being streamed using HTTP (or HTTPS). Popular live events result in highly volatile demand, resulting in very high peak-to-average traffic ratios. For example, Figure 1 The diagram 100 in Figure 1 shows an example of traffic flow at a gateway near the edge of a mobile network during the UEFA Euro 2016 football match. Curve 102 shows the traffic flow on a day without a football match (Wednesday, June 15), and curve 104 shows the traffic flow on the second day with a football match (England vs. Wales) (Thursday, June 16). Both diagrams show roughly the same traffic flow on a day, except that curve 104 has a significant additional peak between 14:00 and 16:00, which is caused by customers streaming the football match.

[0003] This high peak-to-average ratio creates special challenges at the edge of the network, where these peaks can lead to a degradation in the quality of user experience.

[0004] Most commonly, content is delivered over the Internet using HTTP (or HTTPS) request / response pairs. A client application will send an HTTP request to a server, and a response containing the requested content will be returned. This request / response is unicast in nature.

[0005] HTTP can be used for video streaming. Typically, the client will get a manifest file that will allow the URLs of individual files containing video segments to be determined. The client will then request these segments in sequence and concatenate them to form a continuous stream for playback. Individual video segments may also be available at different bit rates to allow the video rate to adapt to the network throughput. This technique is known as HTTP Adaptive Streaming (HAS).

[0006] For users watching the same event (such as a live football game), each client will issue its own HTTP request and get its own HTTP response, even though most of the content delivered to them in the HTTP response is the same between clients. This results in very inefficient use of the network.

[0007] However, if the access network can use multicast instead of unicast for content distribution, it can significantly reduce Figure 1 The impact of a peak in live content is shown in Figure 2. In addition, using multicast in the access network can significantly reduce the peak demand on the content delivery network servers.

[0008] Solutions to this problem already exist, where a proxy is used to insert a multicast path into the originally 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-MULTl-ARCH-C01-161026, 26 / 10 / 2016, by Cable Labs; 3GPP 15 specifications, 23.246 (MBMS Architecture and functional description), 26.346 (MBMS Protocols and codecs) and 26.347 (MBMS APls); and DVB document A176, "Adaptive Media Streaming over IP Multicast", (8th March 2018).

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

[0010] exist Figure 2 , a content server 202 is shown providing content, such as video, to client devices 204a, 204b, and 204c. A multicast proxy X 206 and three proxy Ys 208a, 208b, and 208c are inserted into the otherwise unicast path between the content server 202 and the client devices. Proxy X 206 retrieves the unicast content from the content server 202 and makes it available via multicast. Proxy Y receives the multicast content from proxy X and caches it so that it can be sent via unicast to any requesting client device. Since all proxy Ys receive the same multicast content from proxy X, all client devices will receive the same response to their requests for segments. Depending on the setup, proxy Y may be located within the client device, may be located within a separate device, or there may be only a single proxy Y.

[0011] In this solution, Proxy X is pre-configured to act as a client and request content segments independently and distribute the entire response into the multicast network. Proxy X first requests the manifest file and then requests the content segments described therein in a timely manner. In some cases, the content server may require the client device to authenticate with valid credentials before providing the content. Proxy X 206 actually acts like a pseudo-client.

[0012] Furthermore, in such a setup it is important to manage the sending of content segments from proxy Y to the client device to avoid causing problems for adaptive streaming. Summary of the invention

[0013] It is an object of examples of the present invention to provide an improved content distribution mechanism.

[0014] According to an example of the present invention, there is provided a method for managing content delivery at a network element to a client device, wherein the content includes a plurality of segments, the method comprising:

[0015] receiving, at a first network element, one or more segments via multicast;

[0016] determining a bit rate for receiving the one or more segments;

[0017] receiving, at the first network element, a unicast request for a segment from a client device; and

[0018] The requested fragment is sent via unicast from the first network element to the client device at a sending rate no greater than the determined rate.

[0019] The one or more fragments received at the first network element may be buffered at the first network element.

[0020] The determined bit rate may be the multicast network rate.

[0021] The fragment received at the first network element may be sent by the second network element.The first network element and the second network element may be proxy servers.

[0022] The method according to any one of the preceding claims, wherein the content may be media content. The media content may include a video sequence.

[0023] According to another example of the present invention, a network unit is provided for managing content delivery to a client device, wherein the network unit is adapted to:

[0024] receiving one or more fragments via multicast;

[0025] determining a bit rate at which to receive one or more segments;

[0026] receiving a unicast request for a segment from a client device; and

[0027] The requested segments are sent to the client device via unicast at a sending rate no greater than the determined rate. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0029] Figure 1 is a graph showing traffic flow on a network on different dates;

[0030] Figure 2 It is a network diagram of general existing solutions;

[0031] Figure 3 is a network diagram showing the main components of an example of the present invention;

[0032] Figure 4 is a flow chart summarizing example steps of the present invention. DETAILED DESCRIPTION

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

[0034] The example of the present invention provides a method for managing a network for distributing content in a hybrid unicast / multicast network, wherein the content is requested by a client via unicast, but all or some of the content is partially distributed via multicast. Typically, a client requests content (in the form of fragments) via a first proxy. These fragments are distributed from a second proxy to a first proxy via multicast before being sent forward to the requesting client via unicast. These fragments are also cached at the first proxy and can be sent to other clients requesting these fragments via unicast. However, if the cached fragments are sent to the client very quickly, problems may arise because the cached fragments may be exhausted faster than they are received. This can cause the client's buffer to be underflowed, and the client obtains an incorrect network sending rate, which may result in switching to an unsustainable higher bit rate stream in an adaptive streaming system. This problem is solved here by measuring the rate at which the fragments are distributed from the second proxy via multicast by the first proxy, and limiting the fragment sending rate to the client via unicast to no more than the measured multicast rate.

[0035] Examples of the present invention are applicable to known unicast / multicast hybrid networks as described above, as well as the invention set forth in the applicant's patent application EP19159748.3, which describes a setting called "multicast assisted unicast delivery" (MAUD). In MAUD, the multicast network is used to assist, rather than replace, the path that was originally unicast. Content is requested from a content server by a client device via unicast. The response containing the requested content is divided into two parts: the first part contains elements specific to a single client device (e.g., session-specific data), and the second part is common to all client devices (usually this is the requested video content). The first part can be delivered via unicast, the second part can be delivered via multicast, and then reassembled to form the original response. The separation and reassembly are handled by a suitably configured proxy server. After reassembly, the content can be delivered to the client device via unicast. Examples of the present invention can be used to set the delivery rate of content delivered to the client device via unicast.

[0036] Figure 3 The main components of a "Multicast Assisted Unicast Delivery" (MAUD) network that supports content delivery are shown. Network 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 there may be more than one content server. Proxy X 306 may communicate with content server 302 via unicast. Proxy X 306 may also communicate with proxy Y 308a, 308b, and 308c via unicast and multicast. Depending on the setup, proxy Y may be located within the client device, in a separate device (e.g., a home gateway), or there may be a separate proxy Y.

[0037] Note that Figure 3 In FIG. 3 , 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 dot-dash lines. The control interface communication paths carry control messages / commands between the multicast controller 312 and other units in the network.

[0038] Assume that the client device is running respective client applications, which are the source of the content request. For simplicity, the term "client device" herein is used to refer to the client device running the client application. The client device can issue an HTTP unicast request for the content stored on the content server 302.

[0039] The content stored at the content server 302 is typically media content (e.g., a television program, a movie, or an entire linear television channel) including a video sequence encoded according to a suitable standard such as the ITU H.264 standard. The video sequence is stored at the content server 302 in the form of sequential time segments, where each segment is typically equivalent to 2 to 10 seconds of decoded video. The client uses a manifest file to identify the location of the segments (via URLs in the manifest). Thus, the client device streams the video sequence by using the manifest to determine where to direct sequential unicast requests for each segment in turn as needed. This arrangement is used for HTTP adaptive streaming technologies such as MPEG-DASH and Apple's HLS (HTTP Live Streaming).

[0040] The multicast controller 312 (MCC) monitors the operation of the proxy X and the proxy Y to determine which services should use multicast assistance (MAUD) and controls the proxy accordingly. Thus, in an example of the present invention, the client device may receive some traffic directly from the content server 302 via unicast and receive other traffic using MAUD.

[0041] Many HTTP requests for content made by client devices will not use MAUD, but will be sent directly to the content server.

[0042] Other requests from client devices for content that may benefit from MAUD are redirected to one of the proxies Y, or intercepted by one of the proxies Y.

[0043] Proxy Y may be inserted into the HTTP path using any of a number of known techniques, such as using HTTP redirects from content server 302. In this case, content server 302 would be configured such that requests for potentially popular content are not satisfied directly, but redirected to the appropriate proxy Y. For example, content server 302 may respond with HTTP status code 307 indicating a temporary redirection, rather than providing a normal response. This would invite the client device to make a new request to the new URL provided by the content server in its response, thereby allowing the request to be made to proxy Y. This technique allows content server and proxy Y to exist in different domains, which is typically the case.

[0044] Other mechanisms for inserting Proxy Y in the HTTP path include: Proxy Y configured as a transparent proxy (although all requests are intercepted by it and only unencrypted traffic is applied); Proxy Y configured as a forward proxy (where the client device sends requests directly to Proxy Y through explicit configuration); DNS hijacking (the DNS server is configured to provide the IP address of Proxy Y to the domain of interest); and manifest manipulation (the manifest file is rewritten so that requests are made directly to Proxy Y).

[0045] Figure 4 A flow chart summarizing general example steps of the present invention is shown.

[0046] Beginning at step 400, a client device issues a request for a content segment (e.g., representing a movie or a live sporting event) stored at a content server 302 and receives a response (segment) via unicast via proxy Y. For example, client device 304a issues an HTTP GET request, which is unicast in nature, directed to a content segment. Each HTTP GET request contains a URL from which the segment can be retrieved. The URL is located in a manifest file associated with the content. The request is received by proxy Y 308a and forwarded to content server 302.

[0047] The content server 302 responds with an HTTP response, each containing the requested segment. The HTTP response is also effectively a unicast response. The response is received by proxy Y 308a and sent to the client device 304a. The client device 304a can then view the received segments.

[0048] The client device 304a may continue to request and receive segments according to step 400 until the streaming of the content is complete. Other client devices may make requests for the same content and receive responses in a similar manner. However, in the example of the present invention, the multicast controller 312 determines whether the multicast group should be used to distribute subsequent segments.

[0049] In step 402, proxy Y 308a sends consumption report data related to HTTP request / response pairs passing through the proxy, such as the URL of each HTTP request. Consumption reports can be sent to multicast controller 312 at intervals, either at time intervals or after a certain number of segments have been requested / received.

[0050] Now, the HTTP requests and responses described so far are all unicast in nature. However, it should be noted that requests for the same content may be issued by multiple client devices. This is common at live football games. Agent Y 308a and other Agent Y (308b or 308c) send consumption reports of their respective client devices to the multicast controller 312 as appropriate so that the multicast controller 312 can determine whether to use multicast to assist in the distribution of further content.

[0051] In step 404, the multicast controller 312 uses the received reports to determine whether the HTTP requests reported from a given proxy Y population justify the use of multicast as its response. Such a proxy Y population is called a "queue." Assuming certain conditions are met (e.g., more than a certain number of client devices request the same content), the multicast controller 312 will configure proxy X and any related proxy Y (i.e., the queue) for multicast-assisted delivery by setting up the appropriate multicast group.

[0052] After the multicast group is established, the content (requested segments) is sent from the content server 302 to proxy X via unicast, and from proxy X to proxy Y via multicast, and then to the requesting client device via unicast from proxy Y. This advantageously provides multicast delivery efficiency without interrupting the operation of the client device.

[0053] In the described queue arrangement, content received via multicast at proxy Y is cached so that other client devices requesting the same content can get that content delivered from the cache at proxy Y.

[0054] The multicast controller 312 can add proxy Y 308a to the queue by sending instructions to proxy Y 308a to establish HTTP request routing, thereby directing requests that match a specific URL path / pattern / string to proxy X 306. The multicast controller 312 also sends instructions to proxy Y 308a to provide multicast listeners. These instructions tell proxy Y 308a to prepare to receive multicast. The multicast listener causes proxy Y to issue an IGMP join command to the multicast address specified by the multicast controller. Other proxy Ys can also be configured in the same way.

[0055] To allow Proxy X 306 to use multicast as a return path for responses to requests that satisfy the matching pattern set for Proxy Y 306, the multicast controller 312 configures Proxy X 306 to use multicast for specific responses sent by the content server. For example, the instruction may be to use multicast assistance only for responses containing video files or MIME types such as "video / mp4" or "video / MP2T" so that only responses containing video traffic are sent via multicast. In an alternative example, the responses may be selected based on a specific ETag or a range of ETags. ETags (Entity Tags) are part of the HTTP 1.1 specification and are used to uniquely identify response payloads.

[0056] Proxy X 306 and one or more Proxy Ys are now configured to send and receive content via multicast, respectively.

[0057] In step 406, proxy Y 308a will begin receiving the content segments via multicast from proxy X. Note that for simplicity, this step and the following steps are described with reference to proxy Y 308a, although the skilled person will appreciate that any other proxy Y configured for multicast assistance will operate in a similar manner. Some or all of these segments are cached at proxy Y so that multiple client requests for the same segment can be satisfied without having to obtain the segment again from the content server.

[0058] The bit rate of the data segments sent by agent X is at least equal to the media (coding) rate of the segments to ensure timely delivery of the segments to agent Y. In practice, the actual bit rate used can be set in a variety of other ways, including but not limited to the way described in the applicant's co-pending application EP19194759.7.

[0059] In step 408, agent Y 308a determines the bit rate of the segments received via multicast from agent X. That is, the network bit rate rather than the media encoding rate. For example, if the received segment size is 10Mb and takes 4 seconds to receive, the network bit rate is 2.5Mb / s. This network bit rate is also called the multicast rate.

[0060] In step 410, proxy Y 308a receives a unicast request from a client device for a segment cached at proxy Y 308a. Now, as long as the requested segment is cached, proxy Y 308a can send the requested segment at almost any rate supported by the network link between proxy Y 308 and the client device. However, doing so will cause the client device to have a false understanding of the rate that the network as a whole can support, because the client device is not aware that multicast is being used to assist in distribution from the content server through partial routing. In fact, in an adaptive streaming system, distributing segments at a higher bit rate will cause the client device to believe that the network can support a higher bit rate stream and begin requesting higher rate segments. However, the network as a whole may not support the distribution of a higher bit rate stream without buffer underflow on the client device. This will cause the client to switch to a lower bit rate stream. This will cause the client to fluctuate between higher and lower bit rate streams, which will be annoying to the end user.

[0061] Therefore, in view of the above, in step 412, proxy Y sends the requested segment to the client device via unicast at a unicast rate no greater than the multicast rate determined in step 408. Requests by the client device for subsequent segments cached at proxy Y 308a may be transmitted at the same bit rate limit.

[0062] Note that the segments are received continuously at proxy Y 308a, with requests being made for some at the same time.

[0063] It should be noted that the above invention examples of setting the multicast rate can be applied to other hybrid unicast / multicast settings. For example, the applicant's European patent application EP19159748.3 specifies a setting called "Multicast Assisted Unicast Delivery" (MAUD). Content is requested by a client device from a content server via unicast. The response containing the requested content is divided into two parts: the first part contains elements specific to the individual client device (e.g. session-specific data), and the second part is common to all client devices (usually this is the requested video content). The first part can be delivered via unicast and the second part can be delivered via multicast and then reassembled to form the original response. Typically, the client or session-specific data is the segment header and the common part is the payload portion of the segment. With this setting, the above example can measure the multicast rate as the delivery rate of the common / payload portion, rather than some combined reception rate of the payload plus the header. This is because the size of the payload portion is usually much larger than the header portion, and the header portion is usually delivered in parallel with the payload portion, so it does not increase the delivery overhead.

[0064] Note that the term "unicast" used in the described examples is generally intended to cover point-to-point communication services. Similarly, the term "multicast" is intended to cover point-to-multipoint services, including broadcast services.

[0065] In general, it is noted here that although the above describes examples of the present invention, some changes and modifications may be made to the described examples without departing from the scope of the present invention defined in the appended claims. Those skilled in the art will recognize modifications to the described examples.

Claims

1. A method of managing content delivery to a client device at a network element, wherein: The content includes a plurality of segments, and the method includes: i) receiving one or more fragments at a first network element by multicast, and buffering the one or more fragments at the first network element; ii) determining a network bit rate at which the one or more fragments are received; iii) receiving, at said first network element, a unicast request for a segment from a client device; and iv) sending the requested segment from the first network element to the client device via unicast at a sending rate no greater than the determined network bit rate, Therein, the determined network bit rate is a multicast network rate.

2. The method according to claim 1, wherein: The received fragment at the first network element is sent by a second network element.

3. The method according to claim 2, wherein: The first network element and the second network element are proxy servers.

4. The method according to claim 1, wherein: The content is media content.

5. The method according to claim 4, wherein: The media content comprises a video sequence.

6. The method according to claim 1, wherein: The method also includes sending, from the first network element, consumption reporting data associated with the request that has been received by the first network element.

7. A network unit for managing content delivery to a client device, wherein: The network unit is adapted to: receiving one or more fragments via multicast; caching the one or more received fragments; determining a network bit rate at which the one or more fragments are received; receiving a unicast request for a segment from a client device; and sending the requested segment to the client device via unicast at a sending rate no greater than the determined network bit rate, Therein, the determined network bit rate is a multicast network rate.

8. The network unit according to claim 7, wherein: The network element is further adapted to send consumption report data related to a request that has been received by the network element.

Images