Multicast exit policy

Abstract

A method of managing content delivery to a client device by an agent is described that involves the agent determining whether to leave its previously joined multicast channel. The target is to decide to remain joined to the multicast channel if the client device is expected to continue requesting a piece of content of a quality level delivered on the multicast channel; and deciding to leave the multicast channel if the client device may request a large number of content segments of a different quality level than the quality level delivered on the multicast channel.

Description

Technical Field

[0001] The present invention relates to the field of managing content delivery in a network, and in particular to managing content delivery using a combination of unicast and multicast. Background Art

[0002] Video content is currently delivered to a series of client devices using unicast delivery, where a single data stream is sent to each client device. Web (HTTP) technology is used for content delivery, where the content is segmented into short segment files, typically around six to ten seconds in duration, so that each segment file can be requested by a client device and delivered to the client device using HTTP.

[0003] Each segment can also be encoded at a set of quality levels, each with a different bitrate and therefore a different file size. The client device monitors its buffer level and the achieved network throughput, and based on these determines the quality to request for the next segment in order to achieve a good compromise between media quality and timely delivery. This is often referred to as adaptive bitrate (ABR) streaming.

[0004] However, HTTP is delivered on unicast (one-to-one) transmission, so it is inefficient for delivering the same content to many client devices at the same time. Multicast (one-to-many) transmission will be more efficient. However, multicast is rarely used for any service other than the online linear video channel delivered to its own set-top box by network operators at present. Its main reason is that multicast is not suitable for open use on the Internet.

[0005] In order to bring the benefits of multicast scalability to HTTP-based Internet media streaming, a class of technologies called Multicast-Adaptive Bitrate (m-ABR) is being studied and standardized.

[0006] Multicast Adaptive Bitrate (m-ABR) is a relatively new technology. Its purpose is to allow ABR content to be delivered more efficiently over a network by enabling the use of multicast for content streams where many clients request the same content almost simultaneously.

[0007] One environment for many m-ABR systems is to deploy multicast and enable m-ABR without making any changes to client devices and client applications that already support HTTP (unicast) streaming. This can be achieved using a hybrid approach that utilizes 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 client devices and, when appropriate, join a multicast channel, receive multicast content, and serve that content to the client, with the content encapsulated to look like unicast delivered content.

[0008] Examples of such hybrid solutions include: Cable Labs’ “IP Multicast Adaptive BitRate 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 API); and DVB “Adaptive Media Streaming over IP Multicast” (ETSI TS103769V1.1.1(2020-11)).

[0009] However, the decision about when to join a multicast channel is not straightforward. Some currently available solutions only provide support for a single ABR / quality level, and prevent client devices from adapting to different quality levels by signaling that content is only available at that single quality level. However, when data is not delivered on the network in a timely manner, this gives a poor user experience, wherein the content presentation at the client device is interrupted. Such interruptions may cause the content presentation to stop and / or some content not to be presented at all. A corresponding problem arises when deciding when it is best to leave a multicast channel, as remaining joined to a multicast channel can lead to further network inefficiencies if the multicast channel is not used. Summary of the invention

[0010] It is an object of examples of the present invention to provide an improved method of joining a multicast group.

[0011] According to one aspect of the invention, a method of managing content delivery to a client device by a network element as claimed in claim 1 is provided.

[0012] According to another aspect of the present invention, a network element as claimed in claim 10 is provided.

[0013] A method is described for a proxy to join a multicast channel to satisfy a request for a content segment from a client device. After joining the multicast channel, a decision can then be made as to when to leave the multicast channel, as covered by examples of the present invention. The decision to join is made taking into account the effect that joining the multicast channel may have on the network connection from the content source to the proxy and the segment being requested.

[0014] In practice, the decision to leave the multicast channel is based on the likelihood that the client device requests a large number of content segments at a different quality level than that delivered on the multicast channel. The approach taken to do this is described in an example of the invention.

[0015] While using multicast to satisfy some client requests for content segments will reduce the amount of unicast traffic provided from the content source to the proxy, receiving content segments via multicast that were not requested by the client device (because the client device had already requested the same content but at a different quality level) will waste some capacity on the network connection from the content source to the proxy. This is because the same content will be delivered at an undesirable quality level via multicast and at a desired quality level via unicast.

[0016] The described method solves this problem by considering the impact on the bandwidth on the network connection from the content source to the proxy in the event of joining a multicast channel. Thus, by considering the impact of joining a multicast channel on the bandwidth of the network, the proxy can avoid joining a multicast channel when the available bandwidth is reduced below some limit, and also leave a multicast channel when appropriate. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 a system diagram showing the major components of an example of the present invention; and

[0019] Figure 2 is a flow chart outlining the steps of an example of the present invention;

[0020] Figure 3 is a flow chart outlining further steps of an example of the present invention.

[0021] Figure 4 is a graph showing changes in the parameters Join Threshold and Leave Threshold in an example of the present invention. DETAILED DESCRIPTION

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

[0023] A method of managing content delivery to client devices through a proxy is described, wherein the content consists of a sequence of content segments and each segment is encoded at multiple bitrates or quality levels. The proxy begins by receiving content requests from client devices over unicast, and fulfills these requests by forwarding these requests to a content server. In response, the proxy receives content from the content server over unicast and forwards it to the client device. At some stage, the proxy determines whether to join a multicast channel in order to satisfy the client device's request for the content segment, wherein the decision is made taking into account the quality level of the requested segment and the impact that joining the multicast channel may have on the bandwidth of a network connection from a content source to the proxy. These examples may be considered multicast join strategies.

[0024] Other examples of the present invention include methods of managing content delivery to client devices through a proxy, but involving the proxy determining whether to leave a multicast channel that it has previously joined. The intent is to decide to remain joined to a multicast channel if client devices are expected to continue to request content segments at a quality level delivered on the multicast channel, and to decide to leave the multicast channel if client devices are likely to request a large number of content segments at a quality level different from that delivered on the multicast channel.

[0025] Figure 1 An adaptive bit rate (ABR) streaming system 100 including the main components of an example of the present invention is shown. The system 100 includes a content source 102, a content encoder 104, a multicast transmitter 106, a unicast content server 110, a proxy 112, and a client device 114. The content source 102 provides content such as live sports or TV broadcasts to the content encoder 104 in the form of a video sequence.

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

[0027] It is assumed that the client device 114 is running a client application, which is the source of the content request. For simplicity, the term client device has been used to refer to a client device running a client application.

[0028] The content encoder 104 receives 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 divides the encoded content into a sequence of content segments, each of which typically has a duration of 2 seconds to 10 seconds. The content encoder 104 also encodes the content at one or more quality levels or bit rates, thereby generating one or more (at each quality level) encoded content segments corresponding to each uncompressed content segment. This arrangement is typically an adaptive bit rate (ABR) streaming service.

[0029] Content encoder 104 passes the encoded content segment data encoded at all required bit rates to unicast server 110 where the data is stored and made available for delivery via unicast. Unicast server 110 responds to unicast requests for content segments with unicast responses using the stored data.

[0030] The content segments encoded at one quality level corresponding to one encoding bit rate are delivered to the multicast transmitter 106 for delivery by multicast to any device subscribed to the corresponding multicast channel. However, the present invention is not limited to this case and is also applicable when the content segments encoded at multiple quality levels corresponding to multiple encoding bit rates are delivered to the multicast transmitter 106 for transmission by multicast on multiple multicast channels (one channel for each quality level).

[0031] The multicast transmitter 106 may begin sending the content segments before, at the same time as, or after the content segments are available on the unicast server 110. The multicast transmitter 106 may send the content segments at a constant bit rate approximately equal to its encoding rate to fully utilize the multicast channel, or may send the content segments at a faster rate.

[0032] The multicast transmitter 106 may be configured into one of various modes of operation.

[0033] In one mode of operation, the unicast server 110 monitors requests for content segments made by multiple client devices. When the unicast server 110 determines that a sufficient number of client devices have requested the same content segment at approximately the same time, it instructs the multicast transmitter 106 to send the content segment on the multicast channel in anticipation that the content segment will subsequently be requested by additional client devices. The multicast transmitter 106 obtains the content segment from the unicast server 110 and converts the content segment data into a format suitable for multicast delivery, and then sends it on the multicast channel to all devices that have subscribed to the multicast channel.

[0034] In another mode of operation, the multicast transmitter 106 is configured for specific content at a specific encoding quality level, such as a TV channel. Content segments encoded at a specific quality level corresponding to an encoding bit rate are delivered from the content encoder 104 to the multicast transmitter 106 for multicast transmission to all devices that have subscribed to the corresponding multicast source.

[0035] However, the present invention is not limited to these two configurations of the multicast transmitter 106 .

[0036] To request a content segment, the client device 114 may first obtain a manifest file from the unicast server 110. The manifest file is used by the client device to identify where the content segments are located (via the URLs in the manifest). The client device 114 may then request these content segments in sequence using HTTP requests from the unicast server 110, and concatenate them to form a continuous stream of content segments for playback. When each content segment is available at multiple encoding bit rates on the unicast server 110, the client device 110 determines the encoding bit rate (quality) to request for each content segment, taking into account factors such as available network throughput and how much data has been received and buffered at the client device waiting to be played.

[0037] Some HTTP requests made by client devices 114 for content will not utilize multicast delivery, but instead will be sent directly to unicast server 110, which delivers the requested content via unicast. Other requests by client devices 114 for content that may benefit from multicast delivery are redirected to or simply intercepted by proxy 112, and may be handled according to the examples described below.

[0038] The proxy 112 may be inserted into the HTTP path using any of a number of well-known techniques (e.g., using HTTP redirects from the unicast server 110). In this case, the unicast server 110 would be configured such that requests for potentially popular content are not served directly but redirected to an appropriate proxy. For example, instead of providing a normal response, the unicast server 110 may respond with an HTTP status code 307 indicating a temporary redirect. This invites the client device 114 to make a new request in its response to a new URL supplied by the unicast server 110, thereby enabling a request to be made to the proxy 112. This technique allows the unicast server 110 and the proxy 112 to exist in different domains, which is typically the case.

[0039] Other mechanisms for inserting the proxy 112 in the HTTP path include: a proxy configured as a transparent proxy (although all requests are intercepted by it and it only works with unencrypted traffic); a proxy configured as a forward proxy (wherein the client device sends its requests directly to the proxy by being explicitly configured to do so); DNS hijacking (wherein a DNS server is configured to provide the proxy's IP address for domains of interest); and manifest manipulation (wherein the manifest file is rewritten so that requests are made directly to the proxy).

[0040] The client device 114 may request and receive content segments from the unicast server 110 from the beginning to the end of the streaming session. However, in some cases, the proxy 112 determines that multicast delivery may be used to receive some content segments.

[0041] Proxy 112 monitors unicast content requests from client devices 114 and knows when content requested by client devices 114 is available for multicast reception.

[0042] The proxy 112 determines whether it should join a multicast channel to satisfy the client device's request for content using the data delivered by multicast, and if so, joins the relevant multicast channel at the appropriate time. After receiving the data via multicast, the proxy replies to the client device's request for unicast content with the content received by multicast but encapsulated as a unicast content response.

[0043] If the proxy 112 has joined the multicast channel, the proxy 112 determines whether it should remain joined to the multicast channel or whether it should leave. In the event that the proxy 112 decides to leave, the proxy 112 leaves the multicast channel and returns to satisfying client device requests for unicast content by requesting content from the unicast server 110 and delivering the requested content to the client device 114 as a unicast content response.

[0044] Client devices 114 need not be aware of proxy 112 and whether the content is delivered by unicast from unicast server 110 via proxy 112 or by multicast to proxy 112 which then delivers the content to client devices 114 in a unicast format.

[0045] A detailed example of how the agent 112 may determine whether to join a multicast channel and, if deciding to do so and join a multicast channel, how the agent 112 may determine whether to leave the multicast channel is now described. Figure 2 and Figure 3 The flowchart describes the steps of the example.

[0046] Starting with a detailed example, the proxy 112 maintains a parameter called an ABR Level Metric. In the case where content segments encoded at multiple quality levels corresponding to multiple encoding bit rates are available on corresponding multicast channels (one channel for each quality level), the proxy 112 maintains an instance of the parameter ABR Level Metric for each of these multicast channels. The ABR Level Metric is a parameter that indicates the number or proportion of recent requests made by client devices 114 for content segments of a quality level of content segments available on the corresponding multicast channel. Therefore, when the number or proportion of recent requests made by client devices 114 for content segments of a quality level of content segments available on the corresponding multicast channel is high, the ABR Level Metric is high, and when the number or proportion of recent requests made by client devices 114 for content segments of a quality level of content segments available on the corresponding multicast channel is low, the ABR Level Metric is low.

[0047] The proxy 112 also maintains a parameter referred to as a bandwidth estimate, which indicates the bandwidth available between the content server 110 and the proxy 112 for delivering content segments via unicast delivery.

[0048] The proxy 112 initially sets the value of each instance of the ABR level metric to zero and sets the bandwidth estimate to zero.

[0049] Proxy 112 receives requests for content segments from client devices 114 , forwards these requests to unicast server 110 , receives corresponding responses, and forwards these responses to client devices 114 .

[0050] The proxy 112 determines the rate at which the content segments are received from the unicast server 110 and stores the determined value in the parameter Delivery Rate. The proxy 112 may, for example, determine the value of the Delivery Rate as the size of the content segment divided by the time it takes to receive the content segment.

[0051] The agent 112 then determines a value for the bandwidth estimate using one or more previously determined values ​​of the delivery rate in any of a number of different ways. For example, the agent 112 may determine the value for the bandwidth estimate as the average of the most recent N values ​​of the delivery rate, or as the maximum, minimum, or median of those values, or using some similar approach. The average may be calculated, for example, as the arithmetic mean, geometric mean, or harmonic mean of the values ​​of the delivery rate. N may be any integer greater than or equal to 1. Alternatively, instead of using a fixed value N, the agent 112 may use all values ​​of the delivery rate determined in a previous time period T, where T may be, for example, 60 seconds or any other time period.

[0052] For each content request from client device 114, proxy 112 compares the quality level of the requested content segment with the quality levels available on one or more multicast channels. If the requested quality level is available on the multicast channel indexed i, proxy 112 sets variable L to i Set to 1, otherwise L i Set equal to zero.

[0053] Then, for each multicast channel i, the proxy 112 uses the variable L i The value of the channel parameter ABR level metric ABR_LM is updated i .

[0054] The parametric ABR level metric may be calculated in any of a number of ways. The following are three example methods. However, other methods may be used.

[0055] In a first example method, ABR_LM iis calculated as the number of consecutive segment requests made by the client device 114 for content segments of a quality level available on the multicast channel indexed i. In this case, ABR_LM is updated according to the following equation 1 i :

[0056]

[0057] In a second example method, ABR_LM is calculated using a sliding window of M requests for a content segment. i , that is, ABR_LM i Calculated as L i For example, if there are no M requests for the content segment from the client device 114, then zero is used instead of the corresponding L. i In this case, ABR_LM i It is calculated as follows according to Equation 2, where L i (t) is L i The latest value of L i (tn) is the L of the previously requested content fragment since n additional content fragments have been requested i The value of .

[0058]

[0059] M may be set, for example, to a value of ten content fragments, or to any other value.

[0060] In the third example method, the use of the application to L i The infinite impulse response (IIR) of the value of is used to calculate the ABR_LM i That is, ABR_LM i The previous value of is scaled by factor f and added to L scaled by 1 minus that factor (scaled by 1-f). i In this case, ABR_LM i is updated according to Equation 3 below.

[0061] ABR_LM i ←f×ABR_LM i +(1-f)×L i

[0062] Equation 3

[0063] The factor f should be set to a value between 0 and 1, where larger values ​​of the factor f make ABR_LM i A large number of L i The factor f can be set to a value of 0.85, for example.

[0064] As described in more detail later, if the value of the ABR level metric determined for a multicast channel is greater than or equal to a threshold for the multicast channel, the proxy 112 will join the multicast channel. Here, the threshold is given by the parameter Join Threshold. After joining the multicast channel, the proxy 112 will be able to satisfy requests for content segments from client devices 114 by data already received on the multicast channel and stored at the proxy 112, as long as these content segments are requested at the quality level delivered on the multicast channel. Any content segments requested by the client device 114 at a different quality level will have to be satisfied by requesting them from the unicast server 110. In the latter case, the proxy 112 will receive the requested segments by unicast, and receive the same content segments at different quality levels on the multicast channel.

[0065] If there is a lot of bandwidth between the unicast server 110 and the proxy 112, occasionally delivering the same content segment to the proxy 112 at more than one quality level may not be a problem. However, in some cases, the bandwidth between the unicast server 110 and the proxy 112 may not be sufficient to deliver the same content segment at more than one quality level at the same time, or in other cases, there may be just enough bandwidth to do so. In each of these latter cases, delivery of the requested content segment to the client device 114 may be delayed enough to cause media playback to stop at the client device 114 or cause the client device 114 to request a subsequent content segment at even lower quality. This behavior is highly undesirable.

[0066] While the intent is for the proxy 112 to join a multicast channel only if it is expected that client devices 114 will continue to request content segments at a quality level delivered on the multicast channel, the importance of making the decision to join the multicast channel is greater when there is less bandwidth between the unicast server 110 and the proxy 112, as the consequences of making the wrong decision have a greater impact on the quality of experience presented on the client devices 114.

[0067] Therefore, the agent 112 uses the determined value of the bandwidth estimate to determine the value of the join threshold for each multicast channel. The higher the value of the bandwidth estimate, the more optimistic the agent 112 can be about joining the multicast channel. Therefore, the agent 112 sets the value of the join threshold to a higher value when the value of the bandwidth estimate is lower, and sets the value of the join threshold to a lower value when the value of the bandwidth estimate is higher.

[0068] The proxy 112 also determines the value of the join threshold based on the method used to calculate the value of the ABR level metric. In the case of using the first (continuous request) or second (sliding window) method described previously, the value of the ABR level metric will be an integer, while in the case of using the third (IIR) method described previously, the value of the ABR level metric will be a rational value between 0 and 1.

[0069] The following is one example of a method that the proxy 112 may use to set the value of the join threshold if the third (IIR) method is used to calculate the ABR level metric described previously. The present invention is not limited to this example method, and other methods may be used.

[0070] The proxy 112 may know the data rate of the multicast channel. However, if this is unknown, the proxy 112 may estimate a value for the multicast channel data rate based on the size of the segments of the quality level available on the multicast channel divided by the segment interval, which is the typical time between successive requests for segments.

[0071] If the bandwidth estimate is less than 1.25 times the data rate of the multicast channel, the proxy 112 may set the join threshold to a value higher than the ABR level metric would reach, so that in this case, if the client device 114 were to request a content segment at a different quality level than that delivered on the multicast channel, it would never decide to join the multicast channel, because in this case joining the multicast channel would leave little bandwidth to deliver the segment via unicast. An example of a value for such a join threshold may be 1.01.

[0072] If the bandwidth estimate exceeds 3 times the data rate of the multicast channel, the proxy 112 may set the join threshold to a minimum value such that a decision to join the multicast channel may be made when there are requests for a reasonable percentage of content segments of the quality level delivered on the multicast channel. An example of a value for such a join threshold may be 0.50.

[0073] If the bandwidth estimate is between these two extremes of the data rate of the multicast channel, then the agent 112 may set the join threshold linearly between these extremes.

[0074] In this example method, the agent 112 will calculate the joining threshold JT for the multicast channel i. i , as shown in Equation 4 below, where r is the ratio of the bandwidth estimate to the data rate of multicast channel i.

[0075]

[0076] Then, for each multicast channel i, the proxy 112 determines the parameter ABR level metric ABR_LM for that channel i Is the value greater than or equal to the channel joining threshold JTi The value of , and if so, determines to join the multicast channel i.

[0077] In some cases, by following this process, the agent 112 may determine to join more than one multicast channel. If so, the agent 112 selects one of these multicast channels to join and does not join the other multicast channels. For example, it may be determined to join the multicast channel with the highest data rate among these multicast channels, i.e., the multicast channel that delivers a higher or highest quality level.

[0078] If the proxy 112 has determined to join a multicast channel, the proxy 112 initiates the process of joining the multicast channel. This may be done, for example, by issuing an IGMP join request.

[0079] The agent 112 sets the value of the parameter Join Time to be equal to the time at which the agent 112 joins the multicast channel.

[0080] The proxy 112 also updates the parameter bandwidth estimate to take into account that the proxy 112 has joined a multicast channel and therefore less bandwidth is available for unicast delivery of content segment requests. The proxy 112 reduces the value of the bandwidth estimate by the data rate of the multicast channel it has joined.

[0081] When the agent 112 joins a multicast channel, it receives data on the multicast channel and stores the data.

[0082] Proxy 112 intercepts requests from client devices 114 for content segments.

[0083] The proxy 112 compares the quality level of the requested content segment with the quality levels available on one or more multicast channels. If the quality level is available on the multicast channel indexed i, the proxy 112 sets the variable L i Set to 1, otherwise the variable L i Set equal to zero.

[0084] The proxy 112 determines whether the content segment requested by the client device 114 is at a quality level that is available on the multicast channel to which it has joined and that has been received and stored at the proxy 112 .

[0085] If so, the proxy 112 then delivers the content segment received over the multicast to the client device 114, with the data formatted as a unicast response.

[0086] If the content segment requested by the client device 114 is not stored at the proxy 112 , the proxy 112 forwards the request to the unicast server 110 , receives a response, and forwards the response to the client device 114 .

[0087] For example, during a process in which proxy 112 is not joining a multicast channel, proxy 112 determines the rate at which content segments are received from unicast server 110 and stores the determined value in parameter delivery rate. Proxy 112 then uses one or more previously determined delivery rate values ​​to determine a value for bandwidth estimate.

[0088] Then, regardless of whether the proxy 112 uses the stored data or issues a request to the unicast server 110 to satisfy the request from the client device 114, for each multicast channel i, the proxy 112 uses the variable L i The value of the channel parameter ABR level metric ABR_LM is updated i .

[0089] Compared to when the proxy 112 does not join the multicast channel, the method for calculating the ABR level metric can be changed. The second and third methods previously described for calculating the ABR level metric using a sliding window or an IIR filter can be used without change. However, the first method of counting consecutive requests for the same quality level is not suitable as a metric for determining whether to leave the multicast channel. In this case, the metric can continue to be determined for each multicast channel, but in addition, one or more other parameters can be determined with respect to the multicast channel that has been joined. For example, the number of requests by the client device 114 for content segments that are not available on the multicast channel can be counted and used as a metric for determining when to leave the multicast channel. And in this case, for example, when the count of consecutive requests for content segments available on the multicast channel by the client device 114 reaches a threshold, the method can be further extended by resetting the count of the segments to zero, wherein the threshold is the same or similar to the threshold that has been applied to determine whether to join the multicast channel, if this situation has not occurred before. This is to avoid determining to leave the multicast channel after multiple requests by client devices 114 for content segments that are not available on the multicast channel are interleaved into a large number of requests for content segments that are available on the multicast channel.

[0090] As described in more detail later, the proxy 112 will leave the multicast channel if the value of the ABR level metric determined for the multicast channel is less than a certain threshold set by the value of the parameter Leave Threshold for the multicast channel.

[0091] The goal is for proxy 112 to leave the multicast channel when client devices 114 make requests for a significant percentage of content segments at a quality level that is not delivered on the multicast channel.

[0092] Similar to the reasoning presented previously when the proxy 112 did not join the multicast channel, this significance depends on the relationship between the data rate of the joined multicast channel and the bandwidth estimate after the data rate of the multicast channel is inferred, which now indicates the bandwidth available between the unicast server 110 and the proxy 112.

[0093] Such importance may also depend on the amount of time that has passed since the proxy 112 joined the multicast channel, which the proxy 112 may determine having stored the time of joining the multicast channel in the parameter jointime. In some cases, the act of joining the multicast channel may affect the quality level decision made by the client device 114, for example, because the time taken to respond to the client device 114's request for the content segment may have changed due to the relative timing of the data on the multicast channel and the timing of the request for the content segment.

[0094] Thus, the agent 112 determines the value of the leave threshold using the determined value of the bandwidth estimate, the time that has elapsed since the agent 112 joined the multicast channel, or both.

[0095] The higher the value of the bandwidth estimate, the more optimistic the agent 112 can be to remain joined to the multicast channel. Therefore, the agent 112 sets the value of the leave threshold to a higher value when the value of the bandwidth estimate is lower, and sets the value of the leave threshold to a lower value when the value of the bandwidth estimate is higher.

[0096] The more time that has passed since proxy 112 joined the multicast channel, the less likely it is that the act of joining will result in client devices 114 requesting content segments at a different quality level than those delivered on the multicast channel. Therefore, proxy 112 sets the value of the leaving threshold to a higher value when the elapsed time is lower, and sets the value of the leaving threshold to a lower value when the elapsed time is higher.

[0097] The proxy 112 also determines the value of the exit threshold based on the method used to calculate the value of the ABR level metric. In the case of using the first (continuous request) or second (sliding window) method described previously, the value of the ABR level metric will be an integer, while in the case of using the third (IIR) method described previously, the value of the ABR level metric will be a rational value between 0 and 1.

[0098] The following is one example of a method that the proxy 112 may use to set the value of the leaving threshold if the third (IIR) method is used to calculate the ABR level metric described previously. The present invention is not limited to this example method, and other methods may be used.

[0099] The proxy 112 may know the data rate of the multicast channel. However, if this is unknown, the proxy 112 may estimate a value based on the size of the segments of the quality level available on the multicast channel divided by the segment interval, which is the typical time between successive requests for segments.

[0100] If the bandwidth estimate is less than zero, i.e., the calculated bandwidth between the unicast server 110 and the proxy 112 is less than the data rate of the multicast channel, the proxy 112 may set the leave threshold to a value higher than that attainable by the ABR level metric, such that a decision to leave the multicast channel is made. Such a leave threshold may have a value of 1.01.

[0101] If the bandwidth estimate exceeds 2 times the data rate of the multicast channel, the proxy 112 may set the leave threshold to a minimum value such that a decision may be made to remain joined to the multicast channel while a reasonable percentage of requests for content segments are at a quality level delivered on the multicast channel. The value of the leave threshold may be set lower than the corresponding value of the join threshold to provide hysteresis in the decision to join and the decision to leave and to avoid flipping between joining and leaving. Such a value of the leave threshold may be 0.40.

[0102] If the bandwidth estimate is between these two extremes of the data rate of the multicast channel, then the agent 112 may set the leave threshold linearly between these extremes.

[0103] In this example, the agent 112 will calculate the departure threshold LT as shown in Equation 5 below, where r is the ratio of the bandwidth estimate to the data rate of the multicast channel.

[0104]

[0105] If the elapsed time is less than the threshold, e.g., less than 30 seconds, the agent 112 may use a higher value for the departure threshold, and if the elapsed time is higher, a lower value for the departure threshold may be used. The agent 112 may alternatively not apply a threshold to the elapsed time, but instead set the value of the departure threshold to a continuous function of the elapsed time, where the continuous function may be a monotonically decreasing function.

[0106] In this example using only a threshold of elapsed time, the agent 112 would calculate a departure threshold LT as shown in Equation 6 below, where r is the ratio of the bandwidth estimate to the data rate of the multicast channel, and ET is equal to 1 if the elapsed time is less than 30s, otherwise ET is equal to zero.

[0107]

[0108] Figure 4 It is shown how the joining and leaving thresholds (ET=1 and ET=0) vary depending on r for these example methods of calculating thresholds.

[0109] If the proxy 112 has determined to leave the multicast channel, the proxy 112 initiates the process of leaving the multicast channel. This can be done, for example, by issuing an IGMP leave request.

[0110] In another example of the present invention, when the proxy 112 joins a multicast channel, it does not use a parameter called a leave threshold, and does not compare the ABR level metric to the leave threshold to determine whether to leave the multicast channel. Instead, the proxy 112 operates the previously described process when not joining a multicast channel, but with the following changes.

[0111] The proxy 112 maintains an instance of the parameter ABR level metric for each multicast channel. The value of the instance of the ABR level metric for the multicast channel that has been joined is compared with the corresponding instance of the joining threshold, and if the value of the instance of the ABR level metric is greater than or equal to the threshold, no further action is taken. Otherwise, the value of each other instance of the ABR level metric is compared with the corresponding instance of the joining threshold, and if one or more of the values ​​of these other instances are greater than or equal to the corresponding threshold, the proxy 112 determines to leave the multicast channel it is currently joined and determines to join the multicast channel corresponding to the instance of the ABR level metric. In the event that more than one instance of the ABR level metric is greater than or equal to the corresponding threshold, the proxy 112 selects one instance of the ABR level metric and joins the corresponding multicast channel.

[0112] In this example of the invention, the proxy 112 remains joined to the multicast channel until a request from the client device 114 meets the criteria to join another multicast channel, at which time the proxy 112 leaves the current multicast channel and joins another multicast channel.

[0113] Now turn to Figure 2 Flowchart of the process. Figure 2 The flowchart of summarizes the steps of an example of the present invention, in which the agent 112 determines whether to join a multicast channel, where only a single multicast channel is available and therefore only one instance of the parameter ABR level metric and one instance of the parameter joining threshold. The flowchart presents a simplified overview of the method that has been described above.

[0114] Starting from step 200, the proxy 112 sets the parameters ABR level metric and bandwidth estimate to zero.

[0115] In step 202, the client device 114 requests a content segment stored at the unicast server 110. The proxy 112 intercepts the request.

[0116] Client device 114 can request content segments using HTTP GET requests, which are essentially unicast, pointing to content segments encoded with a specific bit rate or quality level. The initial quality level can be selected as the lowest quality level available, or the initial quality level can be selected in some other way, such as based on historical data or user preferences. Each HTTP GET request includes a URL from which the content segment can be retrieved. The URL is found in a manifest file associated with the content.

[0117] In step 204, the proxy 112 obtains the requested content segment via unicast from the unicast server 110. The proxy 112 determines the rate at which the content segment is received from the unicast server 110 and stores the determined value in the parameter delivery rate.

[0118] In step 206, proxy 112 updates its estimate of the bandwidth of its connection with unicast server 110 stored in parameter Bandwidth Estimate. As previously described, proxy 112 may determine the value of the bandwidth estimate in any of a number of different ways using the values ​​of one or more previously determined delivery rates.

[0119] In step 208, proxy 112 forwards the content segment data received from unicast server 110 to client device 114 as a unicast response to the request from client device 114. Client device 114 receives the content segment and may then play the content segment.

[0120] In step 210, proxy 112 determines whether the content segment requested by client device 114 is at a quality level available on the multicast channel and sets parameter L equal to 1 if so, and sets L equal to zero otherwise.

[0121] In step 212, the proxy 112 updates the parameter ABR level metric. This may be performed using any of the methods previously described.

[0122] In step 214, the agent 112 uses the bandwidth estimate to update the parameter join threshold. This may be performed using any of the methods previously described.

[0123] In step 216, the proxy 112 compares the parameter ABR level metric to the threshold parameter adding threshold, and if the ABR level metric is greater than or equal to the threshold, the flow moves to step 218. Otherwise the flow moves to step 202.

[0124] In step 218, a proxy 112 that has observed client devices 114 making a sufficient number of requests for content segments available on the multicast channel (ie, by determining that the ABR level metric is greater than or equal to a value of the join threshold) determines to join the multicast channel.

[0125] The proxy 112 initiates the process of joining the multicast channel. This can be done, for example, by issuing an IGMP join request.

[0126] In step 220, the proxy 112 receives the data on the multicast channel and stores the data.

[0127] While the proxy 112 joins the multicast channel, the client device 114 continues to request content segments stored at the unicast server 110. The proxy 112 intercepts these requests and responds to the client device 114 with a unicast response that includes the data that it has received and stored on the multicast channel, or if the requested data has not been received on the multicast channel, the data that it has requested and received on unicast from the unicast server 110. The content segment is received by the client device 114 and can then be played.

[0128] This will refer to Figure 3 Describing in more detail, Figure 3 A flow chart outlining the steps of an example of the invention is shown, in which the proxy 112 has joined a multicast channel and determines whether to leave the multicast channel. In this simplified example, there is only a single multicast channel, and therefore there is only one instance of the parameter ABR level metric and only one instance of the parameter leaving threshold. The flow chart presents a simplified overview of the method that has been described above.

[0129] Starting at step 300, the proxy 112 sets the parameter Join Time to the current time. Join Time stores the time when the proxy 112 joined the multicast channel. The proxy 112 also updates the parameter Bandwidth Estimate to take into account that the proxy 112 has joined the multicast channel and therefore less bandwidth is available for unicast delivery of content segments. The proxy 112 reduces the value of the bandwidth estimate by the data rate of the multicast channel. This may be known, but if not, the proxy 112 may estimate a value based on the size of the segments for the quality level available on the multicast channel divided by the segment interval, which is the typical time between consecutive requests for segments.

[0130] In step 302, the proxy 112 receives data on the multicast channel and stores the data.

[0131] In step 304, the client device 114 requests a content segment stored at the unicast server 110. The proxy 112 intercepts the request.

[0132] In step 306, the proxy 112 determines whether the content segment requested by the client device 114 is at a quality level that is available on the multicast channel and has been received and stored at the proxy 112, and if so, the flow proceeds to step 308. Otherwise, the flow proceeds to step 310.

[0133] In step 308 , proxy 112 responds to client device 114 with a unicast response that includes the data that has been received and stored on the multicast channel. The content segment is received by client device 114 and can then be played. Flow then moves to step 316 .

[0134] In step 310, the proxy 112 obtains the requested content segment from the unicast server 110 via unicast. The proxy 112 determines the rate at which the content segment is received from the unicast server 110 and stores the determined value in the parameter delivery rate. The proxy may determine the value of the delivery rate using the same method as in step 204.

[0135] In step 312, the proxy 112 updates its estimate of the bandwidth of the connection between the proxy and the unicast server 110 stored in the parameter bandwidth estimate. The proxy 112 may determine the value of the bandwidth estimate using the same method as in step 206, but taking into account that the proxy 112 has joined the multicast channel and therefore less bandwidth is available for unicast content segment requests.

[0136] In step 314, proxy 112 forwards the content segment data received from unicast server 110 to client device 114 as a unicast response to the request from client device 114. Client device 114 receives the content segment, which can then be played.

[0137] In step 316, the proxy 112 updates the parametric ABR level metric. This may be performed using any of the methods previously described.

[0138] In step 318, the agent 112 updates the parameter leave threshold using the bandwidth estimate and the time elapsed since joining the multicast channel. This may be performed using any of the methods previously described.

[0139] In step 320, the proxy 112 compares the parameter ABR level metric to a threshold parameter called the exit threshold, and if the ABR level metric is less than the threshold, the flow passes to step 322. Otherwise the flow passes to step 302.

[0140] In step 322, proxy 112, having observed client devices 114 making a sufficient number of requests for content segments that are not available on the multicast channel (ie, by determining that the ABR level metric is less than a value of a leave threshold), determines to leave the multicast channel.

[0141] The proxy 112 initiates the process of leaving the multicast channel. This can be done, for example, by issuing an IGMP leave request.

[0142] In step 324, the proxy 112 updates the parameter bandwidth estimate to take into account that the proxy 112 has left the multicast and therefore more bandwidth is available for unicast content segment requests. The proxy 112 increases the value of the bandwidth estimate by the data rate of the multicast channel that has just been left. The process then returns to step 200.

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

Claims

1. A method of managing, by a network element, the delivery of content to a client device, the content comprising a sequence of segments, and wherein: Each of the segments is encoded at a plurality of quality levels, the method comprising: i) receiving a unicast request from a client device for a segment encoded at one or more of the plurality of quality levels, forwarding the request to a unicast content source, receiving the requested segment, and sending the requested segment to the client device via unicast; ii) determining the time taken to receive each given fragment and the size of each given fragment, and estimating the delivery rate of each given fragment as the quotient of the size of the fragment and the time taken to receive the fragment; iii) determining the bandwidth estimate as the average of the estimated delivery rates; iv) joining a multicast channel, receiving segments on the multicast, and sending the segments requested by the client device to the client device via unicast; v) calculating an adaptive bit rate (ABR) level metric based on a number of unicast requests by said client devices for content segments at said quality level delivered on said multicast channel; vi) determining to leave the multicast channel based on the bandwidth and the quality level metric; vii) leaving the multicast channel, receiving a segment request on unicast, and forwarding the request to a unicast content source, receiving the requested segment, and sending the requested segment to the client device via unicast.

2. The method according to claim 1, wherein: The step of determining to leave comprises comparing the quality level metric with a threshold, and wherein the threshold depends on the determined bandwidth.

3. The method according to claim 2, wherein: When the determined bandwidth is lower, the threshold is higher, and when the determined bandwidth is higher, the threshold is lower.

4. The method according to claim 2 or 3, wherein: The threshold value also depends on the time since joining the multicast channel.

5. The method according to claim 4, wherein: When the time since joining the multicast channel is low, the threshold is high, and when the time since joining the multicast channel is high, the threshold is low.

6. The method according to any one of claims 2 to 5, wherein: The step of determining to leave includes determining whether the quality level metric is less than the threshold, and leaving the multicast channel when the quality level metric is less than the threshold.

7. A method according to any preceding claim, wherein: When the number of unicast requests at the quality level delivered on the multicast channel is high, the corresponding quality level metric is high, and when the number of unicast requests at the quality level delivered on the multicast channel is low, the corresponding quality level metric is low.

8. A method according to any preceding claim, wherein: When the unicast request at the quality level delivered on the multicast channel is newer, the corresponding quality level metric is higher, and when the unicast request at the quality level delivered on the multicast channel is older, the corresponding quality level metric is lower.

9. A method according to any preceding claim, wherein: Step iii) further comprises forwarding one or more of the requests from the client device to a unicast content source, receiving the requested segments over unicast, and updating the bandwidth using a bit rate at which the one or more segments are received by the network element.

10. A network element for managing delivery of content to a client device, the content comprising a sequence of segments, and wherein: Each of the segments is encoded at a plurality of quality levels, the network element being adapted to: receiving a unicast request from a client device for a segment encoded at one or more of the quality levels, forwarding the request to a unicast content source, receiving the requested segment, and sending the requested segment to the client device via unicast; determining a time taken to receive each given fragment and a size of each given fragment, and estimating a delivery rate for each given fragment as a quotient of the size of the fragment and the time taken to receive the fragment; determining a bandwidth estimate as an average of the estimated delivery rates; joining a multicast channel, receiving segments on the multicast, and sending the segments requested by the client device to the client device via unicast; calculating an adaptive bit rate (ABR) level metric based on a number of unicast requests by the client devices for content segments at the quality level delivered on the multicast channel; determining to leave the multicast channel based on the bandwidth and the quality level metric; Leaving the multicast channel, receiving a segment request on unicast, and forwarding the request to a unicast content source, receiving the requested segment, and sending the requested segment to the client device via unicast.

Images