British Telecommunications Public Limited Company

British Telecommunications Corporation

Rory Stewart Turnbull

Stephen Clifford Appleby

Michael Erling Nilsson

Ian Barry Crabtree

Timothy Sean Stevens

Roberto Alvarez Arevalo

Matthew D Walker

Timothy Stevens

Richard Gedge

David R Wisely

Brahim Allan

Nicholas J Sim

Peter Paul Smyth

Andrew Gordon Davis

Patrick J Mulroy

Othon Kamariotis

Jonathan Rennison

Ivan Roper

Christopher Mark Reason

Stephen M Thompson

Matthew David Walker

Nicholas James Sim

Roberto Alvarez Arevelo

Michael Eilling Nilsson

David Roger Wisely

Stephen Clifford Aplleby

Patrick Joseph Mulroy

Stephen Michael Thompson

Perter Paul Smyth

Gidon Moshe Reid

A method of managing a network for delivering content to a client device, where content segments are delivered to a proxy in a multicast group, before delivery from the proxy to the client device over unicast. The proxy intermittently leaves the multicast group to probe the network by making unicast request for content segments, receiving those segments over unicast from the content server and forwarding those segments onto the client device. This allows the client device to determine the maximum throughput between the content server and the client device via the proxy, and thus the client device can use its adaptive bit rate algorithms to determine if the network can support a switch to a higher bit rate stream, and request a higher bit rate stream accordingly. The higher bit rate stream can be serviced by the proxy joining or establishing a suitable multicast group.

Content delivery

A method of managing a network for delivering content to a client device, where content segments are delivered over multicast to a proxy. The received segments are stored at the proxy, before delivery of those segments is made from the proxy to the client device over unicast. Whilst the proxy receives further segments over multicast, it probes the network by making unicast requests for data (dummy data or additional content segments), and receiving those segments over unicast from the content server. The multicast rate reception rate and the unicast (probe) rate are measured and a maximum network throughput is calculated as the sum of these two rates. Subsequent segments are then delivered from the proxy to the client device at the calculated maximum network throughput rate, or at some rate dependent thereon. Thus, the client device will receive segments at a rate that is more indicative of the actual maximum network throughput, so can better use its adaptive bit rate algorithms to determine whether a switch to higher bit rate segments is appropriate.

Described is a method of managing a network for delivering content in a hybrid unicast/multicast network, where content is requested by clients over unicast, but all or some of the content is delivered in part over multicast. Typically, a client requests content (in the form of segments) via a first proxy. The segments are delivered to the first proxy over multicast from a second proxy, before onward transmission to the requesting client over unicast. The segments are also cached at the first proxy, and can be transmitted over unicast to other clients requesting those segments. However, problems can arise if cached segments are transmitted to clients too quickly. In one solution, the first proxy measures the multicast rate of delivery of segments from the second proxy over multicast, and limits the transmission rate of those segments over unicast to requesting clients to no greater than the measured multicast delivery rate.

Content delivery—setting the unicast rate

Described is a method of delivering content over a network using an approach referred to as 'Multicast Assisted Unicast Delivery' (MAUD), as a multicast network is used to assist, rather than substituting for, an otherwise unicast path. 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. The separation and recombination are handled by suitably configured proxy servers.

Multicast assisted delivery

Examples of the present invention provide a method of reducing the latency in streaming live media by a client from a server. The client uses manifest information to determine the 'live edge' of the live media stream, where the live edge is represented by the segment from the media stream corresponding to the current time. The client then uses this to identify the next segment, which is the segment in time that will next become available. The client then starts making repeated polling requests for that next segment until the segment becomes available. As a result, the newest possible segment is obtained by the client as soon as it becomes available, and latency is reduced. Further, when adopted by all clients, the latency variation between clients is also reduced.

Low latency media streaming

Described is a method of delivery of content to a client device. In particular, the method can be applied to hybrid unicast/multicast delivery networks, where content is provided by a content server to a root proxy, and that root proxy delivers the content to edge proxies over multicast. However, requests for that content in the form of HTTP GET requests from a client device are received by an edge proxy, which subsequently sends an HTTP HEAD request for header information associated with that content directly to the content server. The content server responds over unicast with a suitable response to the HTTP HEAD request, which is received by the edge proxy. The edge proxy takes the response together with the payload from the content segment received over multicast, to generate a client specific content segment for delivery to the client device over unicast.

Described is a method of managing a network for delivering content in a hybrid unicast/multicast network, where content is requested by clients over unicast, but all or some of the content is delivered in part over multicast. A client requests content (in the form of segments) and receive the responses (segments) over unicast via a first proxy. The first proxy measures the time between requests and associated requested segment sizes. These measurements are used to effectively determine a unicast request rate given by the segment size divided by the time between requests. Subsequent requested segments can then be delivered over multicast over a portion of the route to the client using a multicast rate that is set as a function of (for example, 110% of) the unicast request rate. In general, the multicast path will be from a second proxy to the first proxy.

Presented are methods for converting a multicast media stream to unicast segments, for delivery over generic IP networks such the Internet. The unicast segments can be converted back again to a multicast stream that is identical to the original multicast stream closer to the consuming client device. Information required to regenerate a multicast stream from the generated unicast segments that is identical to the original multicast stream is also encoded into the file name of the generated unicast segments. Additionally, RTP header information from the multicast stream that is not required when the unicast segments are generated are stored in files linked to the generated unicast segments, enabling the multicast stream that is regenerated to be identical to the original multicast stream even at the RTP level.

Multicast to unicast conversion

Examples of the present invention provide a method of converting a multicast stream into unicast segments. In particular, sequence identifiers are generated based on a clock reference field in the transport stream packets that make up the multicast stream. Every time a new sequence identifier is calculated, a new unicast segment is generated and assigned with the new sequence identifier. Transport stream packets are placed into the new segment until a packet is processed that causes a new sequence identifier to be generated, at which point another new segment is generated and packets placed into that segment. In an improved method, random access indicators in the transports stream packets are used to further constrain when a new segment is generated, to ensure that new segments are coincident with a packet having a random access indicator. This improvement makes random access easier back and forth between and within a stream.

The invention presents a method of providing feedback for receipt of a multicast video stream. The feedback mechanism allows the number of clients receiving over multicast to be determined, which can then be used to manage multicast delivery, including switching decisions between multicast and unicast. Video content is delivered over a multicast stream from a content server to a plurality of client devices. The client devices are each configured to respond at regular intervals whilst receiving the multicast video stream by transmitting an HTTP HEAD request message to the content server. The HTTP HEAD request refers to metadata relating to a manifest file associated with the video stream. The number of client devices receiving the multicast video stream is determined based on the number of HEAD requests received at the content server. The multicast video delivery can then be managed accordingly, and can also take into account the number of unicast clients that are requesting the corresponding unicast stream to the multicast stream.

Multicast streaming

Examples of the present invention present a method of controlling content delivery in a network. A global quality of experience measure, QoE, is calculated based on the packet loss rate in the network. As packet loss rate varies as a result of congestion conditions in the network, so will QoE. A server delivering content over the network will attempt to reach QoEfor the content in its respective session. Those sessions with a quality of experience, QoE, less than QoEwill have its packet dispatch rate increased, and those with a QoE higher than QoEwill reduce its packet dispatch rate, subject to any delivery deadlines associated with the session. If the delivery deadlines of the sessions can be met without exceeding QoE, then all sessions will end up achieving QoE. Since QoEis only a function of packet loss rate that all sessions miming over the same shared network agree upon, all sessions should converge on the same QoE.

Deadline driven content delivery

The invention presents a method of providing a modified manifest to a video client for streaming a video sequence associated with the manifest. An original manifest is modified to replace references to locations of lower quality, or bit rate, segments with references to equivalent segments at a higher quality, or bit rate, if the higher quality segment is cached locally. Then, when the video client determines that a given quality of segment should be streamed, it uses the modified manifest to retrieve the appropriate reference for that segment, and if a replacement has taken place, will be provided with the reference to the replacement segment at the higher quality. Thus, the client will always be provided with the highest possible quality segment taking into account local caching.

Video caching

A method for providing equitable media streaming between an HTTP server and a number of receivers via shared network. The streaming data is processed to split the data across a number of sub-streams. Each sub-stream contains non-contiguous data. A receiver requesting the streaming media establishes a number of TCP sessions, one for each sub-stream and the received sub-stream data is reassembled at the receiver so that the streaming media can be presented.

A client device receives streamed encoded content data, such as encoded video data, which has been encoded at a constant perceptual quality. Several different versions of the content are available to be streamed to the device, at different perceptual quality levels. In order to decide which quality level to request from a content server at intervals the device calculates the delivery rates that would be required for each level of quality. The calculation of the delivery levels is made in dependence on whether the actual delivery rate that has been received so far is greater than or less than a constant bit rate delivery schedule that decreases monotonically but which guarantees to deliver the encoded data in a timely manner such that no buffer underflow and interruption of reproduction takes place. The monotonically decreasing bit rate schedule is defined by one or more 'critical points', which are the points at which the bit rates are decreased, and correspond to the points where the delivery schedule is just equal to the decoding schedule of the encoded data. At such points there would be no encoded data in a buffer at the client. If the delivery rate has been greater than the constant bit rate schedule for a quality then the delivery rate required going forward for a particular quality level can be calculated from the critical point information, and no more complicated calculation is required.

Method for delivering video content encoded at one or more quality levels over a data network

One or more network based video servers is/are connected to one or more video receivers over a shared network. Pieces of video content are each encoded at a number of constant quality levels and stored on one or more of the network based servers. Responsive to requests from a receiver, video content is selected on a server and delivered over the shared network to the receiver. The system selects the quality level of the stream to deliver based on characteristics of the video stream currently being delivered, and the number of bits already buffered at the video receiver and the available network throughput. The aim is to select the video quality being delivered according to the available network throughput to maximize quality while ensuring that video data is delivered over the network in time to be decoded and displayed without interruption. Certain exemplary embodiments make that selection in advance.

Growing community of inventors

Ipswich, United Kingdom

Rory Stewart Turnbull