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, a count is maintained of the number of times a content segment has been requested by a client device immediately after that client device has requested the content segment that has most recently been transmitted on the multicast channel. A content segment with a high value of this count is one that has been requested by many client devices immediately after the one most recently transmitted on the multicast channel and is therefore a good candidate to transmit next on the multicast channel.

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] UK patent application GB2611515A describes a method of managing content delivery to a client device via a proxy. The proxy starts off by receiving content requests from the client device over unicast, and fulfils those requests by forwarding them to a content server, and receiving that content before forwarding it onto the client device using unicast. At some stage, the proxy determines that it may be possible to join a multicast channel from multicast transmitter to more efficiently receive content requested by the client device. However, before a switch to multicast is made, the proxy gathers multicast delivery timing data from the content server without joining the multicast group, and behavioural characteristics of the client device. The proxy uses this data to determine whether the client device would change the quality level of the content segments being requested if the proxy were to join the multicast channel instead. If the client wouldn’t change to a lower quality channel, which is determined through calculating intervals between content segment request times and delivery times of those segments over the multicast channel, the proxy joins the multicast channel to obtain requested content before forwarding that content over unicast to the client device.

[0015] Summary of the Invention

[0016] 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.

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

[0018] According to another example of the invention, there is provided an analysis module as set out in claim 5.

[0019] Brief Description of the Drawings

[0020] For a better understanding of the present invention reference will now be made by way of example only to the accompanying drawings, in which: Figure 1 a 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 can be used to determine which content segment to transmit next on the multicast channel;

[0023] Figure 3 is a flow chart summarising the steps of a further example that can be used to determine which content segment to transmit next on the multicast channel;

[0024] Figure 4 is a flow chart summarising the steps of an example method that could be used to update stored parameters relating to the content segment most recently transmitted on the multicast channel;

[0025] Figure 5 is a flow chart summarising the steps of an example method that could be used to update stored parameters relating to the order in which content segments have been requested by client devices;

[0026] Figure 6a is a flow chart summarising the steps of parts of a second example that could be used to determine which content segment to transmit next on the multicast channel;

[0027] Figure 6b is a flow chart summarising the steps of parts of a third example that could be used to determine which content segment to transmit next on the multicast channel;

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

[0029] Figure 8 is a table showing another example of records that have been created and maintained of the content segments requested by client devices;

[0030] Figure 9 is a table showing another example of records that have been created and maintained of the content segments requested by client devices;

[0031] Figure 10 is a table showing another example of records that have been created and maintained of the content segments requested by client devices

[0032] Description of Preferred Embodiments

[0033] The present invention is described herein with reference to particular examples. The invention is not, however, limited to such examples.

[0034] 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, a count is maintained of the number of times a content segment has been requested by a client device immediately after that client device has requested the content segment that has most recently been transmitted on the multicast channel. A content segment with a high value of this count is one that has been requested by many client devices immediately after the one most recently transmitted on the multicast channel and is therefore a good candidate to transmit next on the multicast channel.

[0035] Figure 1 a 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 1b 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 1b can have more than one client device connected to it.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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 1 10, 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.

[0041] 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.

[0042] 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.

[0043] The proxy 1 12 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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 1 12 sends reports of requests for content segments received from the client device 114 to the request analysis module 108.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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 1 12 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.

[0055] 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.

[0056] 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.

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

[0058] 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.

[0059] 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 from the same requested URL.

[0060] After receiving a request for a content segment, the proxy 1 12 reports to the request analysis module 108 the segment identifier, cSID (current Segment Identifier) of the content segment requested by the client device, and, if the client device 114 has previously requested a content segment, the segment identifier, pSID (previous Segment Identifier), of the immediately previous content segment requested by the client device 114.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] The multicast transmitter 106 on receiving such an instruction from the request analysis module 108, requests the specified content segment from the unicast server 1 10, 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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, and a value of pSID. 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.

[0069] 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.

[0070] 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.

[0071] The request analysis module 108 may maintain a count of how often a content segment with a specific value of SID has been requested immediately after another specific value of SID by the same client device 114. To limit the number of pairs of content segments for which the request analysis module 108 keeps such records, it may limit the counting to specific pairs of content segments. For example, the request analysis module 108 may count how many times a content segment has been requested by a client device 114 immediately after that client device 114 has requested the content segment that the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. A content segment with a high value of this count is one that has been requested by many client devices immediately after the one most recently transmitted on the multicast channel and is therefore a good candidate to transmit next on the multicast channel.

[0072] The request analysis module 108 may count how many times a content segment has been requested by a client device 114 immediately after that client device 114 has requested another specific content segment. The request analysis module 108 may keep such records for one or more other specific content segments, trading off the information it can gather with the amount of data it needs to store and the amount of processing of that data it would need to carry out. The examples that follow have only one such other specific content segment to simplify the description.

[0073] Keeping a record of how many times a specific content segment has been requested immediately after another specific content segment can be useful in the case that the request analysis module 108 later determines to instruct the multicast transmitter 106 to transmit the other specific content segment on the multicast channel. In this case the specific content segment may be a good candidate to transmit on the multicast channel after the other specific content segmented

[0074] Keeping a record of how many times a specific content segment has been requested immediately after another specific content segment can also be useful in the case that the other specific content segment has been requested many times immediately after the content segment that the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. In this case the request analysis module 108 may determine to instruct the multicast transmitter 106 to transmit the specific content segment on the multicast channel, effectively skipping over the other specific content segment. One reason for doing so is to bring the data on the multicast channel closer to the live edge of the content quickly. While some client devices will need to obtain the other specific content segment by unicast from the unicast server 110, clients near the live edge may now be able to obtain content segment data from the multicast channel, not just for the specific content segment, but for subsequent content segments.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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. 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 transmitted ByMulticast. 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.

[0086] 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.

[0087] 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.

[0088] 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 .

[0089] 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.

[0090] 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. 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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. 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.

[0096] 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.

[0097] 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.

[0098] 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. 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] Figure 7 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.

[0103] 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”

[0104] At this time there have been 4 requests for segment EC7A. There have been 9 requests for segment 7CDB. 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.

[0105] Thus, the example of Figure 2 described illustrates how requests for a current content segment from client devices can be used to determine what segment to transmit next on the multicast channel in a first example.

[0106] In a second example, the request analysis module 108 uses an alternative method to determine which content segment to instruct the multicast transmitter 106 to transmit next on the multicast channel. The request analysis module 108 may count how many times a content segment has been requested by a client device 114 immediately after that client device 1 14 has requested the content segment that the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. A content segment with a high value of this count is one that has been requested by many client devices immediately after the one most recently transmitted on the multicast channel and is therefore a good candidate to transmit next on the multicast channel.

[0107] In a third example, the request analysis module 108 uses another method to determine which content segment to instruct the multicast transmitter 106 to transmit next on the multicast channel. The request analysis module 108 may count how many times a content segment has been requested by a client device 114 immediately after that client device 114 has requested a specific segment, and how many times that specific segment has been requested by a client device 114 immediately after that client device 114 has requested the content segment that the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. A content segment with high values of these counts is one that has possibly been requested by many client devices after, but not immediately after, the one most recently transmitted on the multicast channel and is therefore a good candidate to transmit next on the multicast channel. Skipping the (intermediate) specific segment enables the multicast channel to be brought closer to the live edge of the content quickly.

[0108] The second and third examples will now be described with reference to the flow chart shown in Figure 3, which also references the flow charts shown in Figure 4, Figure 5, Figure 6a and 6b. The features specific to the second example are shown in Figure 6a, and features specific to the third example are shown in Figure 6b, though both the second and third examples have features in common shown in the other Figures.

[0109] In Figure 3, step 300, the request analysis module 108 initialises the parameters multicastChannel Available to true and multicastTransmissionEndTime to an arbitrary time in the past as described in the previous example. The request analysis module 108 also sets the threshold multicastSegmentCountTheshold to a value greater than or equal to 1 as described in the previous example.

[0110] The request analysis module 108 also initialises the parameter mostRecentMulticastSID which indicates the SID of the content segment it has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. As no such instruction has yet been given at the start of this process, the request analysis module 108 sets mostRecentMulticastSID to indicate that it does not contain a valid value.

[0111] The request analysis module 108 sets a timeout value, multicastTransmissionTimeout.

[0112] From time to time, but not shown in the flowchart, the request analysis module 108 determines whether the time since most recently instructing the multicast transmitter 106 to transmit a content segment on the multicast channel exceeds the value of multicastTransmissionTimeout, and if so, the request analysis module 108 sets mostRecentMulticastSID to indicate that it does not contain a valid value.

[0113] This threshold multicastTransmissionTimeout should be more than one segment period, as it would be expected that when the multicast channel is fully utilised, a content segment would start to be delivered on average every segment period. The value of multicastTransmissionTimeout could be set to a value greater than one segment period, and could, for example, be 1 .50 segment periods.

[0114] In step 302, 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 (current Segment Identifier) is again used and a value of pSID (previous Segment Identifier).

[0115] The parameter pSID indicates the value of SID for the immediately previous content segment requested by the same client device, that is, the value of SID for the content segment requested by the same client device immediately before it requested the content segment with SID equal to cSID. If this content segment with SID equal to cSID is the first content segment requested by this client device, the parameter pSID indicates that there is no previous content segment.

[0116] The request analysis module 108, as in the previous example, creates and maintains a SegmentRecord for each value of SID received in a report from a proxy. In the previous example, each SegmentRecord contained the variables segmentID, requestcount, firstRequestTime and transmittedByMulticast. In this example, each SegmentRecord additionally contains the variables multicastSID, requestCountPreviouslsMulticast, alternativeSID and requestCountPreviouslsAlternative. multicastSID stores the value of SID for the most recent content segment that the request analysis module 108 has instructed the multicast transmitter 106 to transmit on the multicast channel, and if no such instruction has yet been given indicates this fact. requestCountPreviouslsMulticast stores the number of times a proxy has reported a client requesting the content segment where in addition the value of pSID in the report is equal to multicastSID. This indicates how many times this content segment has been requested by client devices immediately after requesting the content segment the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. alternativeSID stores a value of SID that is not equal to segmentID or multicastSID, or it indicates that it does not have a valid value. It may, for example, be the first value of pSID received in a report from a proxy that cannot be used as the value of multicastSID. requestCountPreviouslsAlternative stores the number of times a proxy has reported a client requesting the content segment where in addition the value of pSID in the report is equal to alternativeSID.

[0117] This therefore indicates how many times this content segment has been requested by client devices immediately after requesting the content segment with SID equal to alternativeSID. This is useful information if this content segment is frequently requested immediately after the content segment with SID equal to alternatives ID, and that content segment is frequently requested immediately after the content segment with SID equal to multicastSID.

[0118] The request analysis module 108 may only update the variables within a SegmentRecord when it has received in a report from a proxy of a client device requesting a content segment with SID equal to the value of segmentID in the SegmentRecord. In this case, the request analysis module 108 on first receiving such a report and identifying the corresponding SegmentRecord, may find that multicastSID does not indicate the SID of the content segment the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel, because that instruction was issued as a result of processing a report from a proxy relating to a different content segment. As described below, the request analysis module 108 may update the value of multicastSID during the processing that results from receiving a report from a proxy.

[0119] In step 304, the request analysis module 108 determines whether it has a SegmentRecord for the value of cSID in the report it has received from a proxy. If so, flow passes to step 308, otherwise flow passes to step 306.

[0120] In step 306, 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 the cSR as follows. As in the first example, segmentID is set to cSID, requestcount is set to 1 , firstRequestTime is set to the current time and transmittedByMulticast is set to false. In addition, multicastSID and alternativeSID are set to indicate that they do not contain a valid value, and requestCountPreviouslsMulticastand requestCountPreviouslsAlternative are set to zero. Flow then passes to step 310.

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

[0122] For simplicity, as in the first example, in the following description, the variables stored in cSR, the SegmentRecord created in step 306 or stored in the SegmentRecord identified in step 308, are referred to using just the variable name. In step 310, the request analysis module 108 examines the variable transmittedByMulticast, and if true, flow passes to back to step 302 to process further proxy reports 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 312.

[0123] In step 312, the request analysis module 108 determines whether to update the value of multicastSID, and if determining to do so, determines and sets an updated the value of multicastSID. An example method that the request analysis module 108 could use to update this will now be described with reference to the flow chart shown in Figure 4.

[0124] In Figure 4, step 400, the request analysis module 108 determines whether it has recently instructed the multicast transmitter 106 to transmit a content segment on the multicast channel. If not, the request analysis module 108 sets mostRecentMulticastSID to indicate that it does not contain a valid value and flow passes to step 402, otherwise flow passes to step 404.

[0125] If the request analysis module 108 has not previously instructed the multicast transmitter 106 to transmit a content segment on the multicast channel, then flow passes to step 402 as indicated above.

[0126] If the request analysis module 108 has previously instructed the multicast transmitter 106 to transmit a content segment on the multicast channel, it may calculate the difference in time between the current time and the time of its most recent such instruction, and compare this difference to the threshold multicastTransmissionTimeout, and if greater than the threshold, conclude that it has not recently instructed the multicast transmitter 106 to transmit a content segment on the multicast channel.

[0127] In step 402, the request analysis module 108, having determined that the multicast channel has not been used at all or a period of time greater than multicastTransmissionTimeout has elapsed since it last instructed the multicast transmitter 106 to transmit a content segment on the multicast channel, sets multicastSID to indicate an invalid value and sets requestCountPreviouslsMulticast to zero. Flow then passes back to step 314 of the flow chart shown in Figure 3. This allows the later determination of which content segment to transmit on the multicast channel to be made independently of which content segment, if any, was previously transmitted on the multicast channel, when that channel has been idle for a while.

[0128] In step 404, the request analysis module 108 determines whether multicastSID is valid and equal to mostRecentMulticastSID, that is, if it is equal to the SID of the most recent content segment that the request analysis module 108 instructed the multicast transmitter 106 to transmit on the multicast channel. If so, flow passes back to step 314 of the flow chart shown in Figure 3, otherwise flow passes to step 406.

[0129] In step 406, the request analysis module 108 determines whether altemativeSID is valid and equal to mostRecentMulticastSID. If so, flow passes to step 408, otherwise flow passes to step 410.

[0130] In step 408, the request analysis module 108 sets multicastSID equal to altemativeSID, sets requestCountPreviouslsMulticast equal to requestCountPreviouslsAlternative, sets altemativeSID to indicate that it does not contain a valid value, and sets requestCountPreviouslsAlternative to zero.

[0131] This has the effect of copying the values associated with the altemativeSID to the values associated with multicastSID, and then resetting the former.

[0132] Flow passes back to step 314 of the flow chart shown in Figure 3.

[0133] In step 410, as neither multicastSID nor altemativeSID is equal to mostRecentMulticastSID, the request analysis module 108 sets multicastSID to mostRecentMulticastSID and sets requestCountPreviouslsMulticast to zero. Flow then passes back to step 314 of the flow chart shown in Figure 3.

[0134] In Figure 3, step 314, the request analysis module 108 examines the report it has received from a proxy of a content segment requested by a client device, and determines whether the parameter pSID is included in the report received from the proxy and if so, whether it has a valid value. If both are true, flow passes to step 316, otherwise flow passes to step 318. In step 316, the request analysis module 108 updates parameters in cSR in dependence on the value of pSID. An example method that the request analysis module 108 could use to do this will now be described with reference to the flow chart shown in Figure 5.

[0135] In Figure 5, step 500, the request analysis module 108 determines whether pSID is equal to multicastSID. If so, flow passes to step 502, otherwise flow passes to step 504.

[0136] In step 502, the request analysis module 108 increases requestCountPreviouslsMulticast by one, and flow passes back to step 318 of the flow chart shown in Figure 3.

[0137] In step 504, the request analysis module 108 checks whether alternativeSID is valid. If it is valid, flow passes to step 508, otherwise flow passes to step 506.

[0138] In step 506, as alternativeSID is currently not set to a valid value, the request analysis module 108 sets alternativeSID equal to pSID and sets requestCountPreviouslsAlternative to one. Flow passes back to step 318 of the flow chart shown in Figure 3.

[0139] In step 508, the request analysis module 108 determines whether pSID is equal to alternativeSID. If so, flow passes to step 510, otherwise flow passes back to step 318 of the flow chart shown in Figure 3.

[0140] The latter case occurs when both multicastSID and alternativeSID have valid values and neither is equal to pSID. This leaves no way in this example for the request analysis module 108 to record that a client device requested the current content segment immediately after the one with SID equal to pSID. This deficiency could be overcome by the request analysis module 108 storing more than one pair of alternativeSID and requestCountPreviouslsAlternative, at the small cost of more storage and more processing being required.

[0141] In step 510, the request analysis module 108 increases requestCountPreviouslsAlternative by one, and flow passes back to step 318 of the flow chart shown in Figure 3. In Figure 3, step 318, 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 302 to process further proxy reports.

[0142] Flow then passes to step 320.

[0143] In step 320, as in the first example, 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 302 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 321 .

[0144] In step 321 , the request analysis module 108 checks whether mostRecentMulticastSID indicates a valid value. If not, that is, the request analysis module 108 has not recently instructed the multicast transmitter 106 to transmit a content segment on the multicast channel, the request analysis module 108 determines to instruct the multicast transmitter 106 to transmit the content segment with SID equal to cSID on the multicast channel, and flow passes back to step 324. Otherwise flow passes to step 322.

[0145] In step 322, the request analysis module 108 determines whether to instruct the multicast transmitter 106 to transmit the content segment with SID equal to cSID on the multicast channel. If so, flow passes to step 324, otherwise flow passes to back to step 302 to process another proxy report.

[0146] A second example of the invention is described with reference to the flow chart of Figure 6a setting out how the request analysis module 108 determines whether to instruct the multicast transmitter 106 to transmit content segment with SID equal to cSID.

[0147] A third example of the invention is described with reference to the flow chart of Figure 6b setting out how the request analysis module 108 determines whether to instruct the multicast transmitter 106 to transmit content segment with SID equal to cSID.

[0148] Either of the methods described in Figure 6a or Figure 6b can be applied individually or both can be applied. In the second example shown in Figure 6a, the request analysis module 108 counts how many times a content segment has been requested by a client device 114 immediately after that client device 114 has requested the content segment that the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. A content segment with a high value of this count is one that has been requested by many client devices immediately after the one most recently transmitted on the multicast channel and is therefore a good candidate to transmit next on the multicast channel.

[0149] In the third example, the request analysis module 108 uses another method to determine which content segment to instruct the multicast transmitter 106 to transmit next on the multicast channel. The request analysis module 108 may count how many times a content segment has been requested by a client device 114 immediately after that client device 114 has requested a specific segment, and how many times that specific segment has been requested by a client device 114 immediately after that client device 114 has requested the content segment that the request analysis module 108 has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. A content segment with high values of these counts is one that has possibly been requested by many client devices after, but not immediately after, the one most recently transmitted on the multicast channel and is therefore a good candidate to transmit next on the multicast channel. Skipping the (intermediate) specific segment enables the multicast channel to be brought closer to the live edge of the content quickly.

[0150] Starting with Figure 6a, in step 610, the request analysis module 108, by considering the SegmentRecord cSR, determines whether there is evidence that more than a threshold number of client devices has requested the content segment with SID equal to cSID immediately after the one indicated by mostRecentMulticastSID, that is, immediately after the one it has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. The threshold can be any number equal to or greater than zero. The request analysis module 108 determines this by verifying that multicastSID is equal to mostRecentMulticastSID, and that requestCountPreviouslsMulticast is greater than the threshold. If this is the case, flow can pass back to step 324 of the flow chart in Figure 3 for the segment to be transmitted or can optionally pass onto step 612, otherwise if this is not the case, flow passes back to step 302 of the flow chart in Figure 3 or the specific method of Figure 6b can be applied. In step 612, the request analysis module 108 may additionally consider, in turn, every other SegmentRecord that it has created and maintained, and for those for which multicastSID is equal to mostRecentMulticastSID, compares that SegmentRecord’s value of requestCountPreviouslsMulticast with the value of requestCountPreviouslsMulticast in cSR, and if none is greater than the latter, determines to instruct the multicast transmitter 106 to transmit the content segment with SID equal to cSID on the multicast channel, and flow can pass back to step 324 of the flow chart in Figure 3 for the segment to be transmitted. Otherwise flow passes back to step 302 of the flow chart in Figure 3 or the specific method of Figure 6b can be applied.

[0151] That is, in this case, the request analysis module 108 determines to transmit the content segment with SID equal to cSID on the multicast channel when there is evidence that at a threshold number of client devices have requested the content segment with SID equal to cSID immediately after requesting the one that was most recently transmitted on the multicast channel, and at this time, there is no evidence that any other content segment has been requested by more client devices immediately after requesting the one that was most recently transmitted on the multicast channel.

[0152] Turning now to Figure 6b, steps 620 to 626 describe the second specific method that the request analysis module 108 could use to do determine whether to instruct the multicast transmitter 106 to transmit the content segment with SID equal to cSID on the multicast channel.

[0153] The request analysis module 108 considers whether there is evidence that the content segment with SID equal to cSID follows a content segment that follows the one it has most recently instructed the multicast transmitter 106 to transmit on the multicast channel. In other words, the request analysis module 108 considers whether client devices have requested this content segment immediately after another content segment, which was requested immediately after the one most recently transmitted on the multicast channel.

[0154] The request analysis module 108, by determining to skip the intermediate content segment, that is, determining not to transmit it on the multicast channel, and determining to transmit the current content segment (with SID equal to cSID) instead, the delay between a content segment being produced and its being transmitted on the multicast channel could be reduced. This may allow more client devices to be served by multicast, at the cost of some client devices not receiving the skipped content segment by multicast. As such skipping is only likely to happen as the audience (the number of client devices requesting content) increases, building up from a base of client devices that are making requests for content segments well after they first become available, the skipping may only affect a small number of client devices.

[0155] In step 620, the request analysis module 108 checks that alternativesegment Index n cSR is valid, and if not, flow passes back to step 302 of Figure 3. If it is valid, the request analysis module 108 identifies the SegmentRecord in which segmentID is equal to the value of alternativeSegmentlndex in cSR. The term aSR (short for alternative SegmentRecord) is used for this SegmentRecord.

[0156] In step 622, the request analysis module 108 determines whether multicastSID in aSR is equal to mostRecentMulticastSID and that requestCountPreviouslsMulticast in aSR is greater than a threshold. The threshold can be any number equal to or greater than zero If so, flow can optionally pass to step 624 or flow can pass back to step 324 of the flow chart in Figure 3 for the segment to be transmitted, otherwise flow passes back to step 302 of Figure 3.

[0157] In step 624, the request analysis module 108 has already determined that at least one client device requested the current content segment (with SID equal to cSID) immediately after the one with segmentID equal to alternatives / D, and at least one client device, potentially being a different one, requested the content segment with segmentID equal to alternativeSID immediately after the one that the request analysis module 108 most recently instructed the multicast transmitter 106 to transmit on the multicast channel.

[0158] The request analysis module 108, considers, in turn, every other SegmentRecord that it has created and maintained, and for those for which multicastSID is equal to mostRecentMulticastSID, compares that SegmentRecord s value of requestCountPreviouslsMulticast with the value of requestCountPreviouslsMulticast in aSR, and if none is greater than the latter determines that the current segment is still a valid candidate to be transmitted on the multicast channel and flow can optionally pass to step 626 for an additional check or flow can pass back to step 324 of the flow chart in Figure 3 for the segment to be transmitted. Otherwise flow passes back to step 302 of Figure 3. In step 626, the request analysis module 108, considers, in turn, every other SegmentRecord that it has created and maintained, and for those for which altemativeSID is equal to altemativeSID in cSR, compares that SegmentRecords value of requestCountPreviouslsAlternative with the value of requestCountPreviouslsAlternative in cSR, and if none is greater than the latter determines to instruct the multicast transmitter 106 to transmit the content segment with SID equal to cSID on the multicast channel, and flow passes back to step 324 of the flow chart shown in Figure 3. Otherwise flow passes back to step 302 of Figure 3.

[0159] Turning back to Figure 3, and step 324, the request analysis module 108 instructs the multicast transmitter 106 to transmit content segment with SID equal to cSID on the multicast channel. Processing then passes back to step 302 to receive process further proxy reports.

[0160] There now follows some illustrated examples of the methods described above with reference to Figures 8, 9 and 10.

[0161] Figure 8 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.

[0162] 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”

[0163] At this time there have been 4 requests for segment EC7A, all from client devices that have not previously requested a content segment. There have been 9 requests for segment 7CDB, 4 of which were from client devices that had previously requested segment EC7A.

[0164] There have been 15 requests for segment 1049, 7 of which were from client devices that had previously requested segment 7CDB. 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, and according to step 321 of the flowchart of Figure 3, as mostRecentMulticastSID is not valid as no content segment has been transmitted on the multicast channel.

[0165] Figure 9 shows an example of the SegmentRecords that the request analysis module 108 may have created and maintained about one segment period later. There have been no further requests for segments EC7A and 7CDB, and two further for segment 1049. There have been 18 requests in total for segment BB8A, but the request analysis module 108 has not previously determined to instruct the multicast transmitter 106 to transmit this content segment on the multicast channel as that channel was not available, but now that it is available, it determines to do so.

[0166] In Figure 8, the SegmentRecord for segment BB8A indicated that alternatives! D was 1049 and that requestCountPreviouslsAltemative was 10. But on receiving a request for segment BB8A after instructing the multicast transmitter 106 to transmit segment 1049 on the multicast channel, the request analysis module 108 copied the values of alternatives ID and requestCountPreviouslsAlternative to multicastSID and requestCountPreviouslsMulticast and reset the former two parameters, according to the flowchart of Figure 4. Hence in Figure 9, the SegmentRecord for segment BB8A indicates that alternativeSID is invalid and shows segment BB8A has been requested 13 times by a client device immediately after it requested segment 1049.

[0167] The request analysis module 108 determines to instruct the multicast transmitter 106 to transmit segment BB8A on the multicast channel. This is according to the flowchart of Figure 2, and according to steps 610 to 612 of the flowchart of Figure 6a, noting that no client device has requested any other content segment immediately after segment 1049, the most recent content segment transmitted on the multicast channel.

[0168] Figure 10 shows an example of the SegmentRecords that the request analysis module 108 may have created and maintained about one segment period later still. The SegmentRecords for segments EC7A and 7CDB are not shown. This is for clarity in the figure as no further requests have been made for these content segments, but alternatively, the request analysis module 108 may have determined to delete these SegmentRecords as their respective values of firstRequestTime are sufficiently far into the past. There have been 23 requests in total for segment B26F and 19 for segment B039, but the request analysis module 108 has not previously determined to instruct the multicast transmitter 106 to transmit either of these content segments on the multicast channel as that channel was not available, but now it is available.

[0169] In this example, by chance, the first of these two content segments that are requested after the multicast channel becomes available is segment B039. If the request analysis module 108 is operating according to the flowchart of Figure 2, it determines to instruct the multicast transmitter 106 to transmit segment B039 on the multicast channel.

[0170] If it is operating according to the flowchart of Figure 3, then according to steps 620 to 626 of the flowchart of Figure 6b, as explained below, the request analysis module 108 also determines to instruct the multicast transmitter 106 to transmit segment B039 on the multicast channel.

[0171] In step 620, the SegmentRecord aSR for alternativeSegmentlndex of the SegmentRecord for segment B039 is the SegmentRecord for segment B26F. In step 622, multicastSID in the SegmentRecord for segment B26F is equal to mostRecentMulticastSID being BB8A, and requestCountPreviouslsMulticast is greater than zero, being 13. In step 624, no content segment has been requested more often immediately after mostRecentMulticastSID-. in fact, no other content segment has been requested immediately after mostRecentMulticastSID. In step 626, no content segment has been requested more often immediately after alternativeSegmentlndex (B26F) than the current segment B039: in fact, no other content segment has been requested immediately after alternativeSegmentlndex.

[0172] 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.

[0173] 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 performed 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) triggering transmission of a segment of content on a multicast channel; ii) receiving information relating to requests for segments by one or more clients from each of the respective proxies; iii) determining using the information, for each of one or more of requested segments, a first count of the number of requests for the segment; iv) determining, for each requested segment, the immediately previous segment requested by the client device making the said request; v) determining, for each of one or more of the requested segments, a second count equal to the number of requests for the segment for which the determined immediately previous segment is the segment that has been most recently multicast; vi) triggering transmission of a segment of content on the multicast channel when the said first count of requests for the said segment of content has reached or exceeded a first predetermined value and the said second count for the said segment of content is greater than a second predetermined value.

2. A method as claimed in claim 1 wherein the second predetermined value is zero.

3. A method as claimed in claim 1 or claim 2, wherein said second count for the said segment of content has a value no less than that for any other segment of content.

4. A method as claimed in claim 2 or 3, said method further comprising: determining, for each of one or more of the requested segments, a third count equal to the number of requests for the segment for which the determined previous segment is a specific segment different to the segment that has been multicast; after the specific segment is transmitted on the multicast channel, setting the value of the second count to the value of the third count.

5. 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 configured in operation to: i) trigger transmission of a segment of content on a multicast channel; ii) receive information relating to requests for segments by one or more clients from each of the respective proxies; iii) determine using the information, for each of one or more of requested segments, a first count of the number of requests for the segment; iv) determine, for each requested segment, the immediately previous segment requested by the client device making the said request; v) determine, for each of one or more of the requested segments, a second count equal to the number of requests for the segment for which the determined immediately previous segment is the segment that has been most recently multicast; vi) trigger transmission of a segment of content on the multicast channel when the said first count of requests for the said segment of content has reached or exceeded a first predetermined value and the said second count for the said segment of content is greater than a second predetermined value.

Images