Multicast transmission method

Abstract

Described are methods of managing content delivery in a network with a population of proxies, each proxy having one or more connected clients. The methods determine which content segments to transmit on a multicast channel by taking into consideration the requests for content segments by the clients. More particularly, information relating to requests for segments by one or more clients received from one or more proxies is used to maintain a count of the number of requests made for each given segment. Then a given segment is triggered for transmission over multicast when the count of the number of requests for that given segment reaches or exceeds a predetermined threshold.

Description

[0001] MULTICAST TRANSMISSION METHOD

[0002] Field of the Invention

[0003] This invention relates to the field of managing content delivery in a multicast adaptive bit rate system, in particular for determining which of a plurality of content segments should be transmitted on a multicast channel.

[0004] Background to the Invention

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

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

[0007] However, HTTP is delivered over unicast (one to one) transport, and so is inefficient for delivering the same content at the same time to many client devices. Multicast (one to many) transport would be more efficient. However, multicast is currently rarely used for any services other than network operators’ on-net linear video channels delivered to their own set-top boxes. The main reason for this is that multicast does not lend itself to open use on the Internet.

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

[0009] Multicast-Adaptive Bitrate (m-ABR) is a relatively new technology. It aims to allow more efficient delivery of ABR content over networks by enabling the use of multicast for content streams where many clients are requesting the same content at about the same time. One ambition of many m-ABR systems is to deploy multicast and enable m-ABR without any change to the client device and the client application that are already supporting HTTP (unicast) streaming. This can be achieved using a hybrid approach that uses a combination of both multicast and unicast delivery, where a proxy is inserted between the client device and the content server. The proxy can inspect content requests from the client device, and when appropriate, join to a multicast channel, receive multicast content, and provide this content to the client, packaged to look like unicast delivered content.

[0010] Examples of such hybrid solutions include: “IP Multicast Adaptive Bit Rate Architecture Technical Report” OC-TR-IP-MULTI-ARCH-C01 -161026, 26 / 10 / 2016, by Cable Labs; 3GPP specifications, 23.246 (MBMS Architecture and functional description), 26.346 (MBMS Protocols and codecs) and 26.347 (MBMS APIs); and DVB “Adaptive Media Streaming over IP Multicast” ETSI TS 103 769 V1 .1 .1 (2020-11 ).

[0011] These solutions may integrate the multicast transmission capability directly with the content encoding process, with the content encoder sending encoded data to the multicast transmission capability, which then immediately transmits the data by multicast in the order it is received.

[0012] Alternatively, these solutions operate a replica client device at the multicast transmission capability, to obtain and parse the presentation manifest file, and then to request content segments from the content server, just as a client device would, and then transmit that data by multicast. This approach requires knowledge of the streaming format, the presentation manifest format and the content segment indexing scheme, as well as requiring content protection to not prevent the proxy from obtaining and parsing the presentation manifest file. The multicast transmitter will, like in other solutions, simply transmit the content segments in the order it receives them.

[0013] The Applicant’s own International application W02020 / 173878 describes an alternative hybrid unicast / multicast content delivery method. Content is requested by client devices from a content server over unicast. The responses containing the requested content are separated into two components: a first component containing elements that are specific to individual client devices (for example session specific data), and a second component that is common to all client devices (typically this is the video content being requested). The first component can be delivered over unicast and the second component over multicast. Identifiers are introduced into each of the first and second components to aid recombination of the components to form the original responses. Recombined components are then sent to the client device over unicast. The separation and recombination are handled by suitably configured proxy servers.

[0014] Summary of the Invention

[0015] It is the aim of examples of the present invention to provide methods of determining the order in which content segments should be transmitted by multicast.

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

[0017] According to second example of the invention, there is provided an analysis module for managing content delivery as set out in claim 12.

[0018] Brief Description of the Drawings

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

[0020] Figure 1A is a system diagram showing the main components of an example of the present invention;

[0021] Figure 1 B is a system diagram showing the main components of an example of the present invention having multiple clients and associated proxies;

[0022] Figure 2 is a flow chart summarising the steps of a first example method that could be used to determine which content segment to transmit next on the multicast channel;

[0023] Figure 3 is a table showing an example of records that have been created and maintained of the content segments requested by client devices.

[0024] Description of Preferred Embodiments

[0025] The present invention is described herein with reference to particular examples. The invention is not, however, limited to such examples. Described are methods of managing content delivery in a network with a population of proxies, each proxy having one or more connected clients. The methods determine which content segments to transmit on a multicast channel by taking into consideration the requests for content segments by the clients. More particularly, information relating to requests for segments by one or more clients received from one or more proxies is used to maintain a count of the number of requests made for each given segment. Then a given segment is triggered for transmission over multicast when the count of the number of requests for that given segment reaches or exceeds a predetermined threshold.

[0026] Figure 1A shows a multicast adaptive bit rate (m-ABR) streaming system 100 comprising the main components of an example of the invention. The system 100 comprises a multicast transmitter 106, a request analysis module 108, a unicast server 110, a plurality of proxies 112 and a plurality of client devices 114. Each client device 114 is logically associated with one proxy 112, although in practice a single proxy could serve content to more than one client device. For simplicity only one proxy 112 and associated client device 114 has been shown in Figure 1A. Figure 1 B shows the same example system 100, but with the plurality of the proxies 112 each having an associated client 114, and where each of the plurality of proxies is connected to the multicast transmitter 106, request analysis module 108 and unicast server 110. Similarly, some of the proxies 112 in Figure 1 B can have more than one client device connected to it.

[0027] The unicast server 110 stores content, including live sports and TV broadcast content, that has been encoded using a suitable compression scheme, such as ITU-T Recommendation H.264 for video content, and segmented into a sequence of content segments, each content segment typically of duration 2 to 10 seconds. The content stored on the unicast server 110 has been encoded at one or more quality levels or bit rates, resulting in one or more (at each quality level) encoded segments corresponding to each uncompressed content segment. Such an arrangement is typical of an adaptive bit rate streaming service. The unicast server 110 responds to unicast requests for content segments with unicast responses using the stored data.

[0028] The proxy 112 may be located within a device such as a home gateway or router. As suggested above, the system 100 may include a plurality of proxies, with each proxy connected and operable as described here with reference to proxy 112. The client device 114 is assumed to be running a client application, which is the source of content requests. For simplicity, the term client device has been used to refer to a client device running a client application.

[0029] The request analysis module 108 receives reports from the plurality of proxies of the content segments requested by the plurality of client devices, determines from these reports which content segments should be transmitted on the multicast channel, and instructs the multicast transmitter 106 to transmit them by multicast. The operation of the request analysis module 108 which will be described in detail later.

[0030] The multicast transmitter 106, receives instructions from the request analysis module 108 specifying which content segments to transmit by multicast. The multicast transmitter 106 requests and receives these content segments from the unicast server 110, and transmits the received data on a suitably configured multicast channel to all devices that have subscribed to that multicast channel.

[0031] The client device 114 can obtain a manifest file from the unicast server 110. Manifest files are used by client devices to identify where segments are located (by a URL in the manifest). The client device 114 can then request these segments in sequence using HTTP requests from the unicast server 110, and concatenate them to form a continuous stream of segments for playback. As each segment is available on the unicast server 110 at a plurality of encoded bit rates, the client device 110 determines for each content segment, the encoded bit rate (quality) at which to request it, taking into account such factors as the available network throughput and how much data is already received and buffered at the client device awaiting play-out.

[0032] Some HTTP requests made by the client device 114 for content will not make use of multicast delivery and are sent directly to the unicast server 110, which delivers the requested content by unicast. Other requests for content from the client device 114 that may benefit from multicast delivery are re-directed to, or simply intercepted by, the proxy 112, and can be handled in accordance with the examples described below.

[0033] The client device 114 could request and receive segments from the unicast server 110 from the start to the end of a streaming session. However, in some cases the proxy 112 determines that multicast delivery could be used to receive some segments. The proxy 112 monitors unicast content requests from the client device 114 and is aware of when content requested by the client device 114 could be received by multicast.

[0034] The proxy 112 determines when it is possible to satisfy the client device’s requests for content using data that could be delivered by multicast, joins the relevant multicast channel at an appropriate time, and, after receiving data by multicast, replies to the client device’s requests for unicast content with content received by multicast, but packaged as a unicast content response to the client device.

[0035] The client device 114 does not need to be aware of the proxy 112 and does not need to be aware of whether content is being delivered by unicast from the unicast content source via the proxy 112, or is delivered by multicast to the proxy 112 which then delivers the content to the client device 114 in a unicast format.

[0036] There are many ways in which the proxy 112 may determine it is possible to satisfy the client device’s requests for content using data that could be delivered by multicast.

[0037] For example, if client device 114 has made a plurality of consecutive requests for content segments at the same encoding quality level, that quality level is available by multicast delivery, and each of these content segments has been delivered in less time than the segment period.

[0038] In another example, the proxy 112 may ignore the fact that some segments have taken more time than a segment period to be delivered, provided that many segments are delivered in much less than a segment period. The proxy 112 may also ignore some variations in the quality at which segments are requested, if for much or all of the time there is easily sufficient network throughput to deliver content segments at the quality level available by multicast.

[0039] In typical systems, when the proxy 112 has decided to satisfy the client device’s requests for content using data that could be delivered by multicast, the proxy 112 stops forwarding the client device’s requests for content to the unicast server 110, and instead takes appropriate action to join and obtain from the multicast channel, the data requested by the client device 114. The proxy 112 then delivers that content received over multicast to the client device 114, with the data formatted as a unicast response. The proxy 112 sends reports of requests for content segments received from the client device 114 to the request analysis module 108.

[0040] The request analysis module 108 receives these reports from the plurality of proxies of requests for content segments received from the plurality of client devices. The request analysis module 108 determines from these reports which content segments should be transmitted on the multicast channel. The request analysis module 108 triggers the transmission of content segments on the multicast channel by sending instructions to the multicast transmitter 106 specifying which content segments to transmit by multicast. The multicast transmitter 106, from time to time, or on request, indicates to the request analysis module 108 whether the multicast channel is in use or not. When the multicast channel is in use, the multicast transmitter 106 may indicate when transmission is expected to have completed and the multicast channel become available for further transmission.

[0041] In other m-ABR systems, rather than be instructed by a request analysis module 108, the multicast transmitter 106 may be supplied with a sequence of content segments from the content encoder for transmission in sequence. Alternatively, the multicast transmitter 106 may include functionality similar to a client device, getting and parsing a content presentation manifest file, and requesting content segments from the unicast server in the order defined in the content presentation manifest file. In either case, the multicast transmitter transmits content segments by multicast in the order it receives them.

[0042] In each of these cases in other m-ABR systems, neither the multicast transmitter 106, nor the request analysis module 108, if present, makes intelligent decisions of which content segment to transmit next on the multicast channel.

[0043] However, there are benefits from an m-ABR architecture that does not require such close integration with the content generation process. These include not having to have a relationship with the content provider beyond agreement to the use of multicast for content delivery, not having to have permission to access manifest files, and not having to understand either manifest file formats or content segment indexing schemes. This is especially an advantage considering that rights to valuable content can change quickly and unpredictably.

[0044] If the request analysis module 108 were to simply instruct the multicast transmitter 106 to transmit a requested content segment on the multicast channel when the multicast channel is available and the segment has not been transmitted before, there may be problems. Some client devices may be operating at a different point on the timeline of the content than the live edge, for example, the user may have paused playback or jumped to a different point on the timeline, or may have used the restart (start-over) function. A request for a content segment from such a client together with this simplistic algorithm, could cause that content segment to be transmitted on the multicast channel. This could be wasteful of the multicast channel as no other client device may request that content segment in the immediate future.

[0045] While the proxy 112 can store content segments received on the multicast channel and use a stored content segment to satisfy a later request from the client device 114, storage at the proxy 112 is limited. Therefore, to make the most effective use of the multicast channel, it is advantageous to only transmit content segments on the multicast channel if it is likely that many client devices will request them in the immediate future.

[0046] Described now are examples of operating an m-ABR system that is independent of the content encoding process and does not get or parse a content presentation manifest file. Instead, the system 100, by the request analysis module 108 analysing the statistics of which content segments are requested by client devices, determines the order in which content segments should be transmitted by multicast, and instructs the multicast transmitter 106 to obtain them from the unicast server in time for transmission by multicast.

[0047] Examples of the invention apply independently to each content stream, such as a particular TV channel or film. A content stream could be identified using elements of the URL’s domain and path associated with the requested segment. For example, it may be possible to identify a content stream from a path prefix or using a regular expression. In the description below, it will be assumed that all URLs relate to the same content stream.

[0048] Described now are some examples of the invention.

[0049] Firstly, the client device 114 makes requests for segments of content from the unicast server 110. These requests, and the associated responses, pass through the proxy 112.

[0050] The proxy 112 creates and stores a segment identifier, SID (short for Segment Identifier), for each content segment requested by the client device 114. This may be created in any of many different ways, including but not limited to being part of the requested URL and being calculated from all or part of the requested URL, for example using a hash function. It is important that each of the plurality of proxies creates the segment identifiers using the same method in response to segment requests from respective client devices, so that the same value of SID is created by each proxy for the same segment, for example using the same requested URL. The segment identifier should effectively be unique for each segment.

[0051] After receiving a request for a content segment, the proxy 112 reports to the request analysis module 108 the segment identifier, cSID (current Segment Identifier) of the content segment requested by the client device.

[0052] The request analysis module 108 receives reports from the population of proxies about the content segments requested by the population of client devices. The request analysis module 108 may receive status information from the multicast transmitter 106 of whether the multicast channel is currently in use or whether it is currently available for the transmission of content segment data.

[0053] The request analysis module 108 analyses the data it has received from the population of proxies about the content segments requested by the population of client devices, and using the result of this analysis, specifies to the multicast transmitter 106 which content segment to deliver next on the multicast channel.

[0054] The request analysis module 108 may take into account the status information received from the multicast transmitter 106, if any, by, for example, only instructing the multicast transmitter 106 to transmit a content segment when the multicast channel is available for the transmission of content segment data.

[0055] The multicast transmitter 106 on receiving such an instruction from the request analysis module 108, requests the specified content segment from the unicast server 110, and, when the multicast channel is available, transmits the received data on the multicast channel to all the proxies that have subscribed to the multicast channel.

[0056] Examples will now be described of methods that the request analysis module 108 may use to determine which content segment to instruct the multicast transmitter 106 to transmit next on the multicast channel, when to instruct the multicast transmitter 106, and when to make the determination. The request analysis module 108 may be configured to make the determination at any time and instruct the multicast transmitter 106 at the same time or at a later time.

[0057] Alternatively, the request analysis module 108 may be configured to make the determination only when the multicast transmitter 106 has indicated that the multicast channel is currently available for the transmission of content segment data. The request analysis module 108 may be configured to instruct the multicast transmitter 106 immediately or soon after making the determination.

[0058] Alternatively, the request analysis module 108 may be configured to make the determination only when it has received a report from a proxy of a content segment requested by a client device, the report including a value of cSID. In this case, the request analysis module 108 may be additionally configured to make the determination only on receipt of such a report when the multicast transmitter 106 has indicated that the multicast channel is currently available for the transmission of content segment data. The request analysis module 108 may be configured to instruct the multicast transmitter 106 immediately or soon after making the determination.

[0059] In the following examples, for simplicity of description, the request analysis module 108 determines which content segment to instruct the multicast transmitter 106 to transmit next on the multicast channel when it has received such a report from a proxy and the multicast channel is currently available for the transmission of content segment data.

[0060] The request analysis module 108 may maintain a count of how many requests have been made for a content segment with a specific value of SID, for one or more or all of the content segments listed in reports received from proxies. The request analysis module 108 may determine to instruct the multicast transmitter 106 to transmit the content segment with a specific value of SID when the number of requests from client devices for that content segment has reached or exceeded a predetermined threshold.

[0061] The request analysis module 108 may take the timing of the requests for content segments into account, to avoid using the multicast channel to transmit a sequence of content segments that have been requested by client devices spread over a long period of time, as few if any other client devices may request these content segments in the near future. The request analysis module 108 may also make allowance for small differences in the timing of requests for content segments in the alternative and multicast sequence of content segments.

[0062] The request analysis module 108 may, from time to time, choose to delete some of the records it has been keeping. The records deleted may be older records, with more recent records being maintained. It may do this to limit the amount of data that it needs to store and process, especially in the case of a continuous broadcast.

[0063] As an example, it is possible that over a long period of time, the number of requests for a specific content segment may eventually reach the threshold for being transmitted on the multicast channel. But as these requests are spaced over a long period of time, it is likely that no or few client devices will request the same content segment in the near future, and hence there is no benefit from transmitting the content segment on the multicast channel. The request analysis module 108 may delete the record for a specific content segment if it has not reached the threshold within a predetermined period of time. As an example, the threshold could be measured in seconds, and be, for example, 60s, or could be measured in units of segment periods, and be, for example, five or ten segment periods.

[0064] The request analysis module 108 may keep a record of which content segments have been transmitted on the multicast channel, so that it does not instruct the multicast transmitter to transmit the same content segment again in a short period of time. But after a threshold period of time, after which the number of client devices requesting the content segment in a window of time is zero or very low, the request analysis module 108 may delete the records it has maintained for that content segment.

[0065] As an example, the threshold could be measured in seconds, and be, for example, 300s, or could be measured in units of segment periods, and be, for example, 25 or 50 segment periods. Alternatively, the request analysis module 108 could keep a record of the most recent time at which a request for the content segment was made, and delete the record when the time since that request exceeds a threshold, where that threshold could be shorter, for example, 60s or five or ten segment periods.

[0066] A first example method that the request analysis module 108 could use to determine which content segment to instruct the multicast transmitter 106 to transmit next on the multicast channel will now be described with reference to the flow chart shown in Figure 2. In step 200, the request analysis module 108 initialises the parameters multicastChannelAvailable and multicastTransmissionEndTime, setting multicastChannelAvailable to true to indicate that the multicast channel is currently not in use and that it is available for the transmission of content segment data, and setting multicastTransmissionEndTime to an arbitrary time in the past.

[0067] The request analysis module 108 sets the threshold multicastSegmentCountTheshold to a value greater than or equal to 1 . The request analysis module 108 does not consider instructing the multicast transmitter 106 to transmit a content segment on the multicast channel until the number of requests for that content segment from client devices has reached or exceeded the threshold multicastSegmentCountTheshold.

[0068] The request analysis module 108 sets the value of the threshold multicastSegmentCountTheshold to trade-off transmitting a content segment on the multicast channel as soon as possible and being confident that a significant number of client devices may request the content segment.

[0069] The request analysis module 108 may, for example, set the value of the threshold multicastSegmentCountTheshold to 1 to allow a content segment to be transmitted on the multicast channel as soon as a first client device has made a request for it. Alternatively, the request analysis module 108 may, for example, set the value of the threshold multicastSegmentCountTheshold to a larger value such as 15 to be more confident that the content segment would be requested by a large number of client devices.

[0070] In step 202, the request analysis module 108 receives a report from a proxy of a content segment requested by a client device, the report including a value of SID for the content segment, for which the term cSID (short for current SID) is used.

[0071] The request analysis module 108 creates and maintains a SegmentRecord for each value of SID received in a report from a proxy. A SegmentRecord contains the variables segmentID, requestcount, firstRequestTime and transmittedByMulticast. segmentID stores the value of SID. requestcount stores the number of times a proxy has reported a client requesting the content segment with this value of SID. firstRequestTime stores the first time that a proxy has reported a client requesting the content segment with this value of SID. transmittedByMulticast stores whether the request analysis module 108 has instructed the multicast transmitter 106 to transmit the content segment with this value of SID on the multicast channel.

[0072] In step 204, the request analysis module 108 determines whether it has a SegmentRecord for the value of cSID. If so, flow passes to step 208, otherwise flow passes to step 206.

[0073] In step 206, the request analysis module 108 creates a SegmentRecord for the value cSID. The term cSR (short for current SegmentRecord) is used for this SegmentRecord. The request analysis module 108 initialises the variables stored within cSR as follows: segmentID is set to cSID, requestcount is set to 1 , firstRequestTime is set to the current time and transmittedByMulticast is set to false. Flow then passes to step 210.

[0074] In step 208, the request analysis module 108 has previously created a SegmentRecord, cSR, for the value cSID. The request analysis module 108 identifies this previously created SegmentRecord and increases the value of its requestcount by 1.

[0075] For simplicity in the following description, the variables stored in the SegmentRecord created in step 206 or stored in the SegmentRecord identified in step 208 are referred to using just the variable name: segmentID, requestcount, firstRequestTime or transmittedByMulticast.

[0076] In step 210, the request analysis module 108 examines the variable transmittedByMulticast, and if true, flow passes to back to step 202 because the multicast transmitter 106 has previously been instructed to transmit the content segment with SID equal to cSID on the multicast channel. Otherwise flow passes to step 218.

[0077] In step 218, the request analysis module 108 compares the value of requestcount with the threshold multicastSegmentCountTheshold, and if less than this threshold flow passes to back to step 202, otherwise flow passes to step 220.

[0078] In this way, the request analysis module 108 does not consider instructing the multicast transmitter 106 to transmit a content segment on the multicast channel until the number of requests for that content segment from client devices has reached or exceeded the threshold multicastSegmentCountTheshold. Note that on some occasions in step 218, the value of requestcount may be greater than multicastSegmentCountTheshold because the multicast channel was not available for the transmission of content segment data when the request analysis module 108 received one or more previous reports from one or more proxies of client devices requesting this content segment.

[0079] In step 220, the request analysis module 108 determines whether the multicast channel is currently available for the transmission of content segment data. If not, flow passes to back to step 202 because it is not currently possible to transmit the content segment with SID equal to cSID on the multicast channel. Otherwise flow passes to step 224.

[0080] The request analysis module 108, by not instructing the multicast transmitter 106 to transmit a content segment on the multicast channel when that channel is not available, avoids the need for the multicast transmitter 106 to store the content segment before transmitting it on the multicast channel, and allows the decision of which content segment to transmit next on the multicast channel to be delayed until that channel is available, potentially enabling a better decision to be made.

[0081] The request analysis module 108 may determine whether the multicast channel is currently available for the transmission of content segment data by issuing a query to the multicast transmitter 106. The response from the multicast transmitter 106 may indicate whether the multicast channel is currently available, and if not, when it is likely to be available. The request analysis module 108 stores whether the multicast channel is currently available in the parameter multicastChannelAvailable, and if not available and the multicast transmitter 106 has indicated when it is likely to be available, the request analysis module 108 stores that time in the variable multicastTransmissionEndTime.

[0082] Alternatively, the request analysis module 108 may determine whether the multicast channel is currently available for the transmission of content segment data by considering a previous response from the multicast transmitter 106, and the parameters multicastChannelAvailable and multicastTransmissionEndTime. If a previous response indicated that the multicast channel was available, that is, if multicastChannelAvailable is true, and the request analysis module 108 has not since instructed the multicast transmitter 106 to transmit a content segment on the multicast channel, the request analysis module 108 may determine that the multicast channel is still available. Alternatively, if a previous response indicated that the multicast channel was not available, that is, if multicastChannelAvailable is false, but indicated when it would become available, the request analysis module 108 could determine whether the multicast channel is now available by comparing the variable multicastTransmissionEndTime with the current time, and if the current time is after (later than) multicastTransmissionEndTime, determine that the multicast channel is available.

[0083] In step 224, the request analysis module 108 instructs the multicast transmitter 106 to transmit the content segment with SID equal to cSID on the multicast channel, sets the variable transmittedByMulticast to true and multicastChannelAvailable to false. Flow passes back to step 202.

[0084] It is undesirable to transmit a content segment on the multicast channel if the time from the first request for that content segment to the time when the number of requests reaches multicastSegmentCountTheshold is a long time. The benefit from transmitting a content segment by multicast is achieved when it is received on the multicast channel by many proxies and used to satisfy requests from many client devices. This is unlikely to occur for a content segment if the requests for it are spread over a long time.

[0085] It is also undesirable for the request analysis module 108 to retain indefinitely a SegmentRecord after it has instructed the multicast transmitter 106 to transmit on the multicast channel the content segment with the value of segmentID stored in that SegmentRecord. While it is necessary to keep these records in the short term to prevent further requests for a content segment causing the request analysis module 108 to instruct the multicast transmitter 106 to transmit the content segment on the multicast channel again, it is not necessary to keep them forever.

[0086] Consequently, from time to time, but not shown in the flowchart, the request analysis module 108 may inspect some or all of the reports received from the proxies. For example, it may choose to delete a report if the difference between the time the report was received and the current time is more than a threshold.

[0087] Alternatively, from time to time, but not shown in the flowchart, the request analysis module 108 may inspect some or all of the SegmentRecords it has created and maintained and delete some of them. For example, the request analysis module 108 may choose to delete a SegmentRecord if the difference between the current time and the value of firstRequestTime stored in the SegmentRecord is more than a threshold. The request analysis module 108 may use a different value for the threshold when the content segment has not been transmitted on the multicast channel compared to when it has been. It may choose a shorter threshold in the former case and a longer one in the latter.

[0088] As an example, when the content segment has not been transmitted on the multicast channel, the threshold could be measured in seconds, and be, for example, 60s, or could be measured in units of segment periods, and be, for example, five or ten segment periods. And when the content segment has been transmitted on the multicast channel, the threshold could be, for example, 300s or 25 or 50 segment periods.

[0089] Figure 3 shows an example of the SegmentRecords that the request analysis module 108 may have created and maintained as the number of client devices requesting content segments builds up from zero, at the time it has determined to instruct the multicast transmitter 106 to transmit the content segment with segmentID equal to 1049 on the multicast channel. It shows that there are SegmentRecords for five values of segmentID, and these are shown in columns, left to right, in increasing values of firstRequestTime.

[0090] For convenience in the following description, the term “segment” is used instead of “the content segment with segmentID equal to”, so that “segment EC7A” is used in place of “the content segment with segmentID equal to EC7A”

[0091] At this time there have been 4 requests for segment EC7A. There have been 9 requests for segment 7CDB.

[0092] There have been 15 requests for segment 1049. As 15 is greater than or equal to multicastSegmentCountTheshold, the request analysis module 108 determines to instruct the multicast transmitter 106 to transmit segment 7CDB on the multicast channel. This is according to the flowchart of Figure 2.

[0093] Examples of the invention are realised, at least in part, by executable computer program code which may be embodied in an application program data. When such computer program code is loaded into the memory of a processor in the request analysis module 108, it provides a computer program code structure which is capable of performing at least part of the methods in accordance with the above-described examples. A person skilled in the art will appreciate that the computer program structure referred to can correspond to the flow chart shown in Figure 2, where each step of the flow chart can correspond to at least one line of computer program code and that such, in combination with the processor in the request analysis module 108, provides apparatus for effecting the described process.

[0094] In general, it is noted herein that while the above describes examples of the invention, there are several variations and modifications which may be made to the described examples without departing from the scope of the present invention as defined in the appended claims. One skilled in the art will recognise modifications to the described examples.

Claims

CLAIMS1 . A method of managing content delivery by an analysis module in a network, said network comprising a plurality of proxies each connected to respective one or more client devices, said content comprising a sequence of segments, said method comprising: i) receiving information relating to requests for segments by one or more clients from each of the respective proxies; ii) determining using the information, for each of one or more of requested segments, a count of the number of requests for the segment; ill) triggering the transmission of a segment of content on a multicast channel when the said count of the number of requests for that segment has reached or exceeded a predetermined threshold.

2. The method according to claim 1 , wherein the information comprises a unique segment identifier associated with the requested segment.

3. The method according to claim 2, wherein the segment identifier is generated from a URL associated with the requested segment.

4. The method according to any preceding claim, wherein the requests for segments are unicast requests.

5. The method according to any preceding claim, wherein the triggering of the transmission is performed when the multicast channel to be available.

6. The method according to any preceding claim, wherein the transmission of a segment is by a multicast server over the multicast channel to one or more of the proxies.

7. The method according to any preceding claim, wherein the information further comprises the time that the request for a given segment was made, and deleting the information associated with a given segment when the difference between the time that the request for that segment was made and the current time exceeds a threshold.

8. The method according to claims 1 to 6, wherein the information further comprises the time that the request for a given segment was made, and deleting the information associated with every request for the given segment when the difference between thetime that a preceding request for that segment was made and the current time exceeds a threshold.

9. The method according to claim 8, wherein the preceding request for the segment is the first request for the segment.

10. The method according to claim 8, wherein the preceding request for the segment is the most recent request for the segment.

11. The method according to any preceding claim, wherein the triggering of transmission is performed when the segment not to have previously been transmitted on the multicast channel.

12. An analysis module for managing content delivery in a network, said network comprising a plurality of proxies each connected to respective one or more client devices, said content comprising a sequence of segments, said analysis module adapted in operation to: i) receive information relating to requests for segments by one or more clients from each of the respective proxies; ii) determine using the information, for each of one or more of requested segments, a count of the number of requests for the segment; ill) trigger the transmission of a segment of content on a multicast channel when the said count of the number of requests for that segment has reached or exceeded a predetermined threshold.

Images