AU2017379421A1

AU2017379421A1 - Content streaming via a communications network

Info

Publication number: AU2017379421A1
Application number: AU2017379421A
Authority: AU
Inventors: Geoff FIELD; Al-Mukaddim Khan PATHAN; Gary Edison TRAVER
Original assignee: Telstra Corp Ltd
Current assignee: Telstra Corp Ltd
Priority date: 2016-12-23
Filing date: 2017-12-21
Publication date: 2019-07-04
Also published as: WO2018112535A1

Abstract

A method of facilitating content streaming via a communications network, the method including the steps of, at a recipient device: (a) in response to a request for obtaining content for consumption, receiving, via the communications network, a prediction of future network throughput available to the recipient device during a future period; (b) based at least on the received prediction, determining a level of content quality of a future content segment to be requested; (c) requesting the future content segment in accordance with the determined level of content quality; and a(d) receiving the requested future content segment.

Description

Content streaming via a communications network

Field

The present disclosure relates to streaming of content over a communications network. In one form, it relates to the streaming of content, such as media content, gaming content, virtual reality content or augmented reality content, to one or more recipient devices such as smartphones, tablets and notebook computers.

Background

Network-connected electronic devices are capable of consuming content. For example, modem devices, such as smartphones, tablets, notebook computers, television sets, set-top boxes or the like, have the audio-visual capability to playback media content such as music videos, movies, sports footage, and television programmes. Gaming equipment, such as handheld gaming consoles, are capable of consuming gaming content by linking up multiple game players in role-playing games, or streaming of video games (e.g. e-sports games). Virtual reality (VR) or augmented reality (AR) emulators, such as VR or AR headsets or flying simulators are capable of consuming VR or AR content to provide an immersive experience to a user. While communications networks are used for streaming of content to devices for user consumption on demand, this streaming of content requires the network to allocate scarce network resources, the availability of which can fluctuate, for example over time and space, due to factors such as network traffic conditions and network coverage. For media content, this fluctuation in availability may manifest in a delayed or choppy playback, affecting user experience in consuming the media content. For gaming content, delayed display may result in a frustrating gaming or spectator experience. For virtual or augmented reality content, distortion of the virtual or augmented reality environment can reduce the degree of reality in the user’s immersive experience.

Reference to any prior art in the specification is not, and should not be taken as, an acknowledgment or any form of suggestion that this prior art forms part of the

WO 2018/112535

PCT/AU2017/051428 common general knowledge in in any jurisdiction or that this prior art could reasonably be expected to be understood, regarded as relevant and/or combined with other pieces of prior art by a person skilled in the art.

Summary

According to a first aspect of the present disclosure, there is provided a method of facilitating content streaming via a communications network, the method including the steps of, at a recipient device:

in response to a request for obtaining content for consumption, receiving, via the communications network, a prediction of future network throughput available to the recipient device during a future period;

based at least on the received prediction, determining a level of content quality of a future content segment to be requested;

requesting the future content segment in accordance with the determined level of content quality; and receiving the requested future content segment.

According to a second aspect, there is provided, on a recipient device, machine-readable medium including instructions which when executed by the recipient device causes the recipient device to perform the method of the first aspect.

According to a third aspect, there is provided, a recipient device for facilitating content streaming via a communications network, the recipient device having received a request for obtaining content for consumption, the recipient device including:

a proxy server for receiving, via the communications network, a prediction of future network throughput available to the recipient device during a future period, the proxy server further including:

a buffer controller for determining, based at least on the received prediction, a level of content quality of a future content segment to be requested; and communications interfaces for:

WO 2018/112535

PCT/AU2017/051428 requesting the future content segment in accordance with the determined level of content quality; and receiving the requested future content segment.

According to a fourth aspect, there is provided, a method of facilitating content streaming to a recipient device via a communications network, the method including the steps of, at a network server:

receiving, from the recipient device a request for obtaining a prediction of future network throughput available to the recipient device during a future period, the request including positional information associated with the recipient device;

generating the requested prediction based on the positional information; and forwarding, via the communications network, the generated prediction to the recipient device.

According to a fifth aspect, there is provided, on a network server, machinereadable medium including instructions which when executed by the network server causes the network server to perform the method of fifth aspect.

According to a sixth aspect, there is provided a network server having machine-readable medium including instructions which when executed by the network server causes the network server to perform the method of fifth aspect.

Brief description of the drawings

Further aspects of the present disclosure and further embodiments of the aspects described in the preceding paragraphs will become apparent from the following description, given by way of example and with reference to the accompanying drawings.

Figure 1 illustrates schematically an example of a method of facilitating content delivery via a communications network.

Figure 2 illustrates schematically an example of a communications system encompassing a communications network.

WO 2018/112535

PCT/AU2017/051428

Figure 3 illustrates schematically an example of information exchange of an on-device buffering component with a content-consuming application on a recipient device and a communications network.

Detailed description of embodiments

While the description hereinafter is focused on streaming of media content, a skilled person would appreciate that the description with minor modifications is also applicable to other types of content, such as gaming content, virtual reality content or augmented reality content.

Some media content players have an internal buffer built into them. In some cases, the internal buffer has a fixed buffer size. This buffer combats the variability of the network bandwidth available to a recipient device. In general, the larger the buffer is the smaller the chance a poor mid-stream play experience will result, but as a consequence the worse the playback startup experience will be. Adaptive bitrate streaming allows a player to address these competing requirements by having access to multiple sizes for content segments (e.g. the video and/or audio segments) and choosing lower quality segments when a content segment is required quickly or if the communications network connection is poor. Here, the trade-off is playing media content at a lower quality for fewer interruption events.

Buffering control logic operates by estimating the bandwidth available to the recipient device. This estimate is formed using a measure of how long it has taken to download content for the previous segments. Such control logic works reasonably well when the player has been playing for a while, the user of a recipient device is stationary, the network connection is fixed, and the network connection is not shared (e.g. a WiFi connection with a single user). However, the inventors recognise that real-world variations add difficulties to this estimation. For example, as soon as the user is on a mobile network, is moving and/or other users are involved, estimating how much bandwidth is available becomes less accurate and the player becomes more susceptible to interruptions and/or unnecessarily low quality content segments. To

WO 2018/112535

PCT/AU2017/051428 address these variations, the inventors have devised methods and systems for facilitating content streaming via a communications network.

Described herein are methods and related systems for facilitating content streaming via a communications network. In one scenario, the content is bandwidthdemanding, such as high-definition media content. The communications network may be any communications network. In one scenario, the communications network is one in which the bandwidth is utilised at or near capacity, such as a mobile network. The described method reduces the requirements or removes the need for a contentconsuming application (e.g. a media content player) on a recipient device to be concerned with one or more of: buffering control logic, network bandwidth availability, determining an appropriate sized buffer, and determining the appropriate quality for a content segment. Instead, the described method relies on throughput predictions externally provided to the recipient device via the communications network to influence the determination on how to adapt the content streams. In one arrangement, the described method provides a size-adjustable buffer, whereby its size adapts to the streaming needs, to improve the content-consumption experience.

Figure 1 illustrates a general example of the described method 100. The method 100 is to be performed at each of one or more recipient devices in a communications system, an example of which is illustrated in Figure 2. The described method 100 includes, at a recipient device: in response to a request for obtaining content for consumption, the step 102 of receiving, via the communications network, a prediction of future network throughput available to the recipient device during a future period, the step 104 of, based at least on the received prediction, determining a level of content quality of a future content segment to be requested, the step 106 of requesting the future content segment in accordance with the determined level of content quality, and the step 108 of receiving the requested future content segment. Accordingly, rather than being provided or estimated internally by the recipient devices, the predicted throughput is provided externally to the recipient devices. In one example, the predicted throughput is provided by the communications network operator, which is expected to have relevant intelligence on the network traffic

WO 2018/112535

PCT/AU2017/051428 conditions and network coverage. In another example, the predicted throughput is provided by a dedicated server reachable by the communications network. The predicted throughput may be determined based on one or more factors. Examples of these factors include user context (such as the location of the recipient device receiving the streamed content), content usage (such as the amount of the streamed content), mobility (such as whether the recipient device is in motion), network content trends (such as the likelihood of an increase or decrease in the content usage) and other external events.

Here, “throughput” is intended to be a measure of data transfer rate to/from a recipient device. Unless specified or the context requires otherwise, “bandwidth” (which describes the maximum data transfer rate of a communications channel based on resource allocation) and “throughput” (which describes an actual data rate experienced by a recipient device based on variable factors) are used interchangeably.

The described method provides an on-device buffering component installed on a recipient device. In one arrangement, the on-device buffering component acts as an intermediary between (and hence separate from) one or more content-consuming applications on the recipient device and a content source. In another arrangement, the on-device buffering component is integrated within each of one or more contentconsuming applications to interface with the content source. The on-device buffering component is configured to receive the predicted throughput for improving the content consumption experience, such as faster starts, fewer interruptions and better content quality. Where the on-device buffering component is separate from a contentconsuming application, the request for obtaining content for consumption may be received from the content-consuming application.

The content-consuming application on the recipient device may be a media content player, a web browser loading a website with media content, or a video-ondemand service or app. In such a case, the content is media content (such as either or both of video content and audio content). Alternatively the content-consuming application may be a virtual or augmented reality emulator, in which case the content

WO 2018/112535

PCT/AU2017/051428 is virtual or augmented reality content. Still alternatively the content-consuming application may be a gaming application, in which case the content is gaming content. The content may include or be separated into multiple content segments. Each content segment is associated with a portion of the content (e.g. a short duration of an entire media clip in the case of media content, a particular field of view in a virtual or augmented reality environment in the case of virtual or augmented reality content, or a particular sequence of gaming events in the case of gaming content). Each content segment is associated with one or more levels of content quality. The multitude of levels of content quality provides a choice of the most appropriate level of content quality to facilitate content continuity based on the predicted throughput. Content quality may be quantified in relative terms (e.g. poor, medium and high) or in numeral terms (e.g. in bitrate).

Any one or more of steps 102 to 108 may be carried out while a current content segment is being consumed. For example, while a content segment of 10 seconds in duration is being consumed (e.g. media content being played by a media content player), the method may receive, via the communications network 206, a prediction of future network throughput available to the recipient device during a future period commencing at the end of the 10-second content segment (which taking into account part of the content segment already played will therefore commence in less than 10 seconds). A future period refers to a time period extending into the future, and future content segment refers to a content segment that has yet to be consumed. Alternatively, all of steps 102 to 108 may be carried out while no content segment is being consumed. For example, while a content segment of 10 seconds in duration is being retrieved, the method may receive, via the communications network 206, a prediction of future network throughput available to the recipient device during a future period starting from after the end of the 10-second content segment (which taking into account the time necessary to retrieve the content segment will therefore commence in more than 10 seconds).

Figure 2 illustrates an example of a communications system 200. The system 200 includes one or more recipient devices (202a, 202b, 202c or collectively 202) for

WO 2018/112535

PCT/AU2017/051428 receiving content in accordance with the described method 100, a throughput predictor 204 for predicting throughput to each of the recipient devices 202, and one or more content sources (collectively 210) for providing content to the recipient devices 202. The recipient devices 202, the throughput predictor 204 and the content sources 210 are communicatively coupled via a communications network 206. The recipient devices 202, the throughput predictor 204 and the content sources 210 may be located remotely from one another. As mentioned, the throughput predictor 204 may be operated by the network operator. As such, the throughput predictor 204 may have access to network intelligence such as the available bandwidth at a particular location (e.g. within a particular cell), the number of recipient devices sharing the available bandwidth.

The recipient devices 202 may separately be one of the following electronic devices: a laptop, a mobile phone, a tablet, a television set, a set top box, a streaming device, a handheld gaming console, or the like. The recipient devices each include necessary hardware (e.g. a processing unit, memory, display, speaker, and/or audio jack) and software (e.g. codecs) to consume content. The one or more recipient devices also each includes a machine-readable medium, such as a memory, storing instructions which, when executed by the processing unit, performs the described method 100. The throughput predictor 204 may include a computer system having a processing unit and a machine-readable medium, such as a memory, storing instructions which, when executed by the processing unit, performs a throughput prediction (see more below). Similarly, the content source(s) 210 may each include a computer system having a processing unit and a machine-readable medium, such as a memory, storing instructions which, when executed by the processing unit, provide content to the recipient devices 202 via communications network 206.

In each of the recipient devices 202, the throughput predictor 204 and the content sources 210, through a communications bus, the respective processing unit is in data communication with respective memory, which can be a read-only memory (e.g. storing a BIOS for basic system operations), a volatile memory (e.g. random access memory such as one or more DRAM modules), and a non-transient memory

WO 2018/112535

PCT/AU2017/051428 (e.g. one or more hard disk drives, solid state drives, flash memory devices and suchlike). The recipient devices 202, the throughput predictor 204 and the content source(s) 210 may each store one or more applications in their respective memory. Further, the processing unit in each of recipient devices 202, the throughput predictor 204 and the content sources 210 may run one or more such applications through the respective communications bus. Such applications will typically include at least an operating system such as Microsoft Windows, Apple OSX, Unix, Linux, Apple iOS, Google Android, or other operating system. For the recipient devices 202, such applications may further include one or more of the following: a video and/or audio player for consuming content, a web browser for consuming web content, a virtual or augmented reality emulator for simulating virtual or augmented reality. The memory in content source(s) 210 may be used for storing content.

The recipient devices 202, the throughput predictor 204 and the content sources 210 are each network-connected to facilitate the content streaming. For example, each have a network interface configured to communicatively couple to the communications network 206. For example, the communications network 206 may include one or more of a mobile network (e.g. a fourth-generation network, such as a Long Term Evolution (LTE) network), a wireless network (e.g. a Wi-Fi network) and a wired network (e.g. ADSL network). The network interface may correspondingly include a mobile communication interface, a wireless communication interface and a wired communication interface. The communications protocol employed by the recipient devices 202, the throughput predictor 204 and the content sources 210 may include any suitable communications protocols, such as the Transmission Control Protocol (TCP) and/or the Internet Protocol (IP).

As illustrated in Figure 2, in one example, each of the recipient devices 202 includes a corresponding on-device buffering component 300 (e.g. 300a, 300b and 300c) for interfacing with other on-device components, such as a content-consuming application 350, and the communication network 206. In another example, on-device buffering component 300 may be integrated with the content-consuming application 350. The on-device buffering component 300 is configured to provide buffered

WO 2018/112535

PCT/AU2017/051428 content to the content-consuming application 350. In particular, the on-device buffering component 300 is configured to determine the amount (e.g. the duration and/or the number of content segments) and quality of content segments to be cached based on the predicted throughput.

The throughput predictor 204 is configured to predict the future network throughput available based on at least one or more of the following: positional information associated with the recipient device, movement or a likelihood of movement of the recipient device; and presence of other devices connected to the communications network. Where the recipient device is logged on to a subnet of the communications network 206, such as a specific WiFi network within the Internet, the predicted throughput may be calculated locally based on past download bandwidth and signal strength changes of the subnet.

The throughput prediction may be generated by the throughput predictor 204 in one or more ways. For example, where the recipient is connected to a WiFi network, the throughput predictor 204 may generate the predicted throughput based on a sliding window on the recipient device, or based on real-time measures if the recipient device is on the gateway. Where the recipient device is connected to a mobile network, the throughput predictor 204 may generate the predicted throughput based on statistical measures and/or machine learning data as provided by a third party vendor.

Alternatively or additionally, the throughput prediction may be based on a location and/or a time at which the recipient device retrieves the throughput prediction. In this scenario, the throughput predictor 204 includes a relevant database of throughput predictions which are generated once per location and/or time period and reused by many recipient devices. The location may be based on a cell tower identity or a geo-hash or a WiFi access point. The time period may be based on the interval at which the throughput predictions are generated, e.g. once every 20 seconds. The database of generated predictions may include predictions associated with multiple locations, such as a collection of neighbouring cells. In anticipation of device

WO 2018/112535

PCT/AU2017/051428 movement, the generated predictions associated with the neighbouring cells may be retrieved by a recipient device in batches of predictions for the current and surrounding cells. In this case, small movement of the recipient device (e.g. into one or more of the surrounding cells) need not trigger another retrieval of predicted throughput via the communications network.

The prediction generated by the throughput predictor 204 is provided to the on-device buffering component 300. In some arrangements, the generation of the prediction is responsive to a request by a recipient device. For example, a recipient device may repeat the request for a prediction periodically (and hence repeatedly receiving a prediction). In other arrangements, the generation of the prediction is responsive to predetermined conditions having been met. For example, generation of the prediction may be responsive to a change of positional information (e.g. location) associated with the recipient device. Any change of positional information may be provided by the communication networks (e.g. a cell tower) to the throughput predictor 204. The positional information associated with the recipient device may be a location relative to a cellular base station. As another example, generation of the prediction may be responsive to a change of current network throughput available to the recipient device. In one scenario, the recipient device may be configured to send a request for an updated bandwidth prediction if the recipient device experiences a deviation of network throughput beyond a threshold value from past or predicted network throughput. In another scenario, upon detection by the communications network 206 of an overall network congestion (e.g. due to an increased number of devices sharing network resources in the cell in which the recipient device is located), an updated prediction may be sent to, and thus received by, the recipient device.

Figure 3 illustrates schematically an example of information exchange between the content-consuming application 350 and the on-device buffering component 300 and with the communications network 206. In this example, the content consuming application 350 includes a content player 352 for consuming content. The content consuming application 350 may include or have access to a content management system (CMS) 354 for storing the location of manifest

WO 2018/112535

PCT/AU2017/051428 information (e.g. in MPD format) and other information. For example, the CMS 354 includes information for the content player 352 to determine where on the communications network 206 a piece of content’s manifest is. The CMS 354 allows navigation to the piece of content (e.g. a movie) and contains the detail about the piece of content (e.g. synopsis, actors etc) and the manifest to consume the piece of content. The on-device buffering component 300 acts as a proxy server for the content consuming application 350, and includes a proxy component 302 running a proxy service, a manifest component 304 running a manifest service, a buffer controller 306 for controlling buffering functions, a throughput prediction module 308 for receiving throughput prediction via the communications network 206, and a cache 310, such as a least recently used (LRU) cache.

In one operation, a user of a recipient device indicates intention for the recipient device to consume specific content retrievable via the communications network 206 (e.g. an online video clip). The content-consuming application 350 receives a request for obtaining the specific content for consumption. In response, at step 312, the content-consuming application 350 makes a request to a CMS 354 for receiving a location (e.g. a URL) for retrieving manifest information for the specific content. At step 314, the content player 352 is activated using the retrieved location of the manifest information returned from step 312. On activation, the content player 352 requests one or more content segments to be consumed. The content player 352 is configured to send at step 316 all requests for content segments via the proxy component 302. Following receipt of the requested content segments, the proxy component 302 is configured to return the received content segments to the content player 352. Any internal buffer of the content player 352 may be disabled or reduced in size.

The proxy component 302 is configured to detect whether the subject of the request from step 316 relates to a manifest or a content segment. Where a manifest request is detected, the manifest service in the manifest component 304 is activated at step 322 to retrieve the manifest information associated with the requested content at step 324. Alternatively, where a content segment request is detected, the proxy

WO 2018/112535

PCT/AU2017/051428 component 302 interrogates at step 318 the cache 310 for matched content segment. Step 318 may involve checking for the requested or an equivalent content segment. In one example, for media content, the manifest service in the manifest component 304 receives a mapping of all content segments and their quality levels (e.g. the 10th content segment in the case where content segments are 10 seconds duration, is from 1:40 - 1:50 and has five quality levels - ranging from a highest to a lowerst bitrate). Each content segment’s quality level is referenced by or otherwise associated with a respective universal resource locator (URL). To interrogate the cache 310 at step 318, the proxy component 302 performs a lookup where the different respective URLs for the same content segment are mapped to those stored in the cache 310. The content player 352 in one example may request the second highest quality level of the 10th content segment. Where the cache 310 has stored in it the highest quality level, the content player 352 will receive the content segment at the highest quality level instead of the second highest quality level.

Where the requested or equivalent content segment exists in the cache 310, the requested or equivalent content segment is returned as part of step 318 to the proxy component 302, which in turn passes the returned cached content segment to the player 352. Otherwise, the proxy component 302 is configured to execute either or both of the following content retrieval processes.

In one process, the proxy component 302 retrieves in step 323 the requested or equivalent content segment from a content source(s) 210 via the communication network 206. This process does not involve caching contents in the cache 310, and may occur in the event that content caching is delayed in activation. In this case, the first few content segments may continue to be retrieved via step 323. For example, such a delay can happen in situations where the content player 352 does not have its buffer size reduced, or the manifest service in manifest component 304 is experiencing latencies, or where the content player 352 is aggressive and there is no content buffered in the cache 310 yet. Content caching may also temporarily be disabled by the on-device buffering component 300 to avoid situations where the

WO 2018/112535

PCT/AU2017/051428 same request for a content segment is being made simultaneously by the content player 352 and the buffer controller 306.

In an alternative or additional process, which is more preferred, where a content segment request is detected, the proxy component 302 activates the buffering functions of the buffer controller 306 at step 320. On activation, the buffer controller 306 is configured to determine a level of content quality of a future content segment to be requested. The buffer controller 306 employs a configurable algorithm for determining the level of content quality of a future (e.g. next) content segment to be requested.

The determination is based at least on the prediction received at step 328 by the throughput prediction module 308 and provided at step 330 to the buffer controller 306. Additionally, the determination of the level of content quality of the future content segment to be requested may be further based on current or past network throughput to the recipient device 202. Alternatively or additionally, the determination of the level of content quality to be requested may be further based on the amount of future content segments cached at the recipient device, such as the cache 310. Still alternatively or additionally, the determination of the level of content quality to be requested may be further based on whether the request for obtaining content is a request for obtaining new content for consumption. Still alternatively or additionally, the determination of the level of content quality to be requested may be further based on the size of the cache 310. The following arrangements provide further examples of buffer controller 306 and its determination of content quality.

Generally the duration of the segments is fixed as indicated by manifest information provided at step 326 by the manifest service of the manifest component 304 to the buffer controller 306. As an illustrative example, a piece of content may include n segments, each of d seconds in duration (such that n x d = content length in seconds) and each with q quality levels (i.e. q choices of bitrate atbi b2·.. b_q). The content may have combined or separate channels (e.g. video channels, audio left/right channels, audio language channels), each of which may have the same duration or

WO 2018/112535

PCT/AU2017/051428 different durations per channel. The buffer controller 306 is configured to determine the number of content segments (i.e. n) and the level of content quality (i.e. which of bi b2... b_q) to cache and thus requests them accordingly.

In one arrangement, the buffer controller 306 maintains a list of past performance measures, such as the content size, the time taken to retrieve a content segment, and the number of retries. The past performance measures may be based on the latest content being requested and completed as per steps 316 and 320 for any cache misses, and step 332 for the requested content it controls. The buffer controller 306 also maintains information on the currently buffered content segments, such as level of content quality (i.e. which of b i. b2... b_q) and the number of content segments (i.e. n) the cache 310 has already stored but not yet consumed), the throughput predictions (e.g. in terms of predicted throughput over the next η x d seconds and how likely the predicted throughput will change).

In one arrangement, there may be restrictions placed on the buffer controller 306 based on the content in use such as for live content streaming, where the delay of the streamed content from the actual live moment is restricted to be no more than m seconds. This restriction translates to an upper limit on the size of the cache buffer (e.g. a maximum permitted delay of 15 seconds from the live moment means that the size of the cache 310 can at most contain 15 seconds worth of content segments). There may also be restrictions placed on the buffer controller 306 based on the conditions of the recipient device, such as space limitations (which translate to a maximum buffer size) or user-imposed data transfer limitations (which translate to upper limits on the quality which may be selected).

In one arrangement, the buffer controller 306 determines the level of content quality (i.e. which of b i. b2... b_q) to retrieve at 332 for the next unbuffered content segment based on (1) the duration of cached (i.e. unconsumed) content stored in the cache 310 (i.e. how soon before the cache 310 runs out of content to provide to the content-consuming application 350), (2) the predicted throughput (with or without likelihood of variance in the predictions) for the duration of the cached content (i.e.

WO 2018/112535

PCT/AU2017/051428 how quickly it can retrieve new content segments at step 332) and (3) the duration of next content segment at each quality level). The buffer controller 306 selects a particular b_x for the next content segment, which can be requested in time before the cache 310 runs out of content. For example, at a given moment, the cache 310 may contain 2 seconds of unconsumed content. The predicted throughput for the next 2 seconds may be 100kbps (kilobits per second), and is therefore estimated to be able to retrieve a total of 200kb (kilobits) of data until the cache 310 runs out of content. The next content segment may be of 3-second duration and of a range of available content qualities at qi = 25, q2 = 50, q3 = 100 and q4 = 200 kbps, respectively requiring 75, 150, 300 and 600kb of data transfer. In this example, retrieving the next content segment at content quality qi or q2 (since the required 75 and 150 kb are both less than the retrievable 200kb) is expected to provide the next content segment before the cache 310 runs out, but not at content quality q3 or q4 (since the required 300 and 600 kb are both more than the retrievable 200kb). In this case, the buffer controller 306 may select q2 = 50 kbps as the best available and retrievable content quality level at step 332. The above determination may be repeated until the nominal size of the cache 310 is full. Alternatively or additionally, every time content is consumed from the cache the determination may be repeated.

In one arrangement, the determination of content quality level is based on the determined quality level of a previously retrieved content segment, such as the immediately previous content segment. In the above example, if the quality of the previously retrieved content segment was at 20 kbps, the buffer controller 306 may in the alternative case select qi = 25 kbps as the quality level that is closest to, but still better than the quality level of the previous content segment. In this alternative case, the determined levels of content quality from one content segment to the next is in effect smoothed to avoid an abrupt increase (and similarly an abrupt decrease in the opposite case) of content quality level.

In one arrangement, the determination of content quality level is based on multiple unbuffered content segments. For example, to allow for the changing network condition experienced, the buffer controller 306 may give less or no weight

WO 2018/112535

PCT/AU2017/051428 to drops in the predicted throughput in immediate future duration (e.g. over a short term), where the cache 310 has sufficient buffered content over immediate future duration (or longer) and where it is likely that the throughput is predicted to increase after the immediate future duration. In another example, where the cache 310 has insufficient content buffered to provide uninterrupted content to the contentconsuming application 350 based on the predicted throughput, the buffer controller 306 may be configured to maximize the content quality provided to the contentconsuming application 350 by dropping the quality slightly for the next set of loaded segments such that the predicted throughput can sustain highest lower quality consumption rather than dropping to a low quality as the cache 310 runs out of content.

In one arrangement, the size of the cache 310 may be dynamically adjusted by the buffer controller 306. For example, where a long throughput drop is predicted in the immediate future period, the buffer controller 306 will increase the size of the cache 310 by loading the cache 310 with as much high quality content as allowable, to sustain high-quality content consumption through the long period of low throughput.

In one arrangement, the buffered content in the cache 310 may be rebuffered. For example, where the throughput predictions now indicate availability of high throughput and there was lower quality content buffered, the content may be reloaded at a higher quality.

In one arrangement, the buffer controller 306 may adjust the predicted throughput received from the throughput predictor 204. For example, the buffer controller 306 may be configured to increase or decrease the received predicted throughput by a correction to provide an adjusted predicted throughput. In one case, an aggressive buffer controller 306 may assume that the prediction is 100% accurate, whereas a defensive buffer controller 306 may assume that the prediction accuracy is variable. In case of a defensive buffer controller 306, the buffer controller 306 may determine the correction based on periodic audits of the received predicted throughput against the actual throughput.

WO 2018/112535

PCT/AU2017/051428

Once the level of content quality of the next content segment to be requested is determined, the buffer controller 306 requests and receives at step 332 a future (e.g. next) content segment at the determined level of content quality from the content sources 210 via the communications network 206. The received content segment is stored at step 334 in the cache 310 for use by the proxy component 302 as per step 318 (i.e. when the proxy component 302 checks or otherwise interrogates the cache 310 for the requested or equivalent content segment). In one scenario, the buffer controller 306 may be configured to flush at step 336 the content segment(s) explicitly from the cache 310, for example after a predetermined time elapses or a content segment is known to have been consumed. Alternatively, flushing can be intrinsically achieved by using a least-recently-used (LRU) cache or similar. In scenarios where cached content is flushed immediately after consumption, the cache 310 is maximized in size for use by buffering future content segments. On the other hand, where cached content is retained for a certain period, the cache 310 is not maximized in size but allows for “rewind” of content.

In one arrangement, the manifest service of the manifest component 304 may include receiving the requested manifest information. In this arrangement, the step 322 executed by the buffer controller 306 of requesting the future content segment can be in accordance with the received manifest information. For example, the manifest component 304 may be configured to analyse one or more manifest files and prepares a digest to facilitate the buffer controller 306 in buffer controlling functions, such as providing manifest information including content segments available and the quality available. The digest allows the buffer controller 306 to request one or more future content segments in accordance with the received manifest, such as requesting the future content segment at one of the available levels of content quality that is equal or close to the determined level of content quality determined at step 320. Alternatively or additionally, the digest may be converted to a dereferencing map for the proxy component 302. The receipt and analysis of the manifest information may be responsive to (a) a request for obtaining new content for consumption (e.g. when a new play is requested) or (b) a change of manifest information (e.g. for live content which is not static).

WO 2018/112535

PCT/AU2017/051428

While the manifest component 304 is illustrated in the arrangement of

Figure 3 to be built into the on-device buffering component 300 installed on the recipient device 202, in another arrangement, the manifest component 304 may be resident on a separate server, such as the throughput predictor 204, reachable by the one or more recipient devices 202 via the communications network 206. Where the manifest component 304 is resident on a separate server, there may be more flexibility in terms of repair and maintenance. For example, turn-around for repair and maintenance can be in the order of hours rather than weeks. A skilled person would appreciate that the present disclosure also provides a corresponding method, at a network server (such as throughput predictor 204), of facilitating content streaming to a recipient device (such as recipient device 202) via a communications network (such as communications network 206). In one example, the method include the steps of (a) receiving, from the recipient device a request for obtaining a prediction of future network throughput available to the recipient device during a future period, the request including positional information associated with the recipient device; (b) generating the requested prediction based on the positional information, and (c) forwarding, via the communications network, the generated prediction to the recipient device.

It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

Claims

Claims

1. A method of facilitating content streaming via a communications network, the method including the steps of, at a recipient device:

(a) in response to a request for obtaining content for consumption, receiving, via the communications network, a prediction of future network throughput available to the recipient device during a future period;

(b) based at least on the received prediction, determining a level of content quality of a future content segment to be requested;

(c) requesting the future content segment in accordance with the determined level of content quality; and (d) receiving the requested future content segment.
2. The method of claim 1 wherein any one or more of steps (a) to (d) are carried out while a current content segment is being consumed.
3. The method of claim 1 wherein the request for obtaining content for consumption is received from a content-consuming application on the recipient device.
4. The method of claim 1 wherein the future network throughput available is predicted based on at least one or more of the following:

• positional information associated with the recipient device;

• movement or a likelihood of movement of the recipient device; and • presence of other devices connected to the communications network.
5. The method of claim 1 wherein the step of receiving a prediction may be repeated periodically.
6. The method of claim 1 wherein the step of receiving a prediction may be repeated responsive to a change of positional information associated with the recipient device.

WO 2018/112535

PCT/AU2017/051428
7. The method of claim 4 or 6 wherein the positional information associated with the recipient device includes a location relative to a cellular base station.
8. The method of claim 1 wherein the step of receiving a prediction includes retrieving the prediction responsive to a change of current network throughput available to the recipient device.
9. The method of claim 1 wherein the step of receiving a request for obtaining content for consumption includes receiving a request for a manifest of available content segments, the manifest including one or more available levels of content quality for each of the available content segments.
10. The method of claim 9 further including the step of receiving the requested manifest, and wherein the step of requesting the future content segment is in accordance with the received manifest.
11. The method of claim 10 wherein the step of requesting the future content segment in accordance with the received manifest includes the step of requesting the future content segment at the determined level of content quality or at one of the available levels of content quality near to the determined level of content quality.
12. The method of claim 9 wherein the step of receiving the requested manifest includes retrieving the manifest responsive to (a) a request for obtaining new content for consumption or (b) a change of manifest information.
13. The method of claim 1 wherein the step of determining a level of content quality is further based on current or past network throughput to the recipient device.
14. The method of claim 1 wherein the step of determining a level of content quality is further based on the amount of future content segments cached at the recipient device.

WO 2018/112535

PCT/AU2017/051428
15. The method of claim 1 wherein the step of determining a level of content quality is further based on whether the request for obtaining content is a request for obtaining new content for consumption.
16. The method of claim 1 wherein the step of determining a level of content quality is further based on the duration of a content segment.
17. The method of claim 1 further including the step of caching the received future content segment.
18. The method of claim 17 wherein the step of receiving a request for obtaining content for consumption includes the step of receiving a request for one or more content segments.
19. The method of claim 18 further including, responsive to receiving the request for one or more content segments, determining whether the cached content segment matches any of the requested one or more content segments.
20. On a recipient device, machine-readable medium including instructions which when executed by the recipient device causes the recipient device to perform the method of any one of claims 1-19.
21. A recipient device for facilitating content streaming via a communications network, the recipient device having received a request for obtaining content for consumption, the recipient device including:

a proxy server for receiving, via the communications network, a prediction of future network throughput available to the recipient device during a future period, the proxy server further including:

a buffer controller for determining, based at least on the received prediction, a level of content quality of a future content segment to be requested;

communications interfaces for:

requesting the future content segment in accordance with the determined level of content quality; and

WO 2018/112535

PCT/AU2017/051428 receiving the requested future content segment.
22. A method of facilitating content streaming to a recipient device via a communications network, the method including the steps of, at a network server:

receiving, from the recipient device a request for obtaining a prediction of future network throughput available to the recipient device during a future period, the request including positional information associated with the recipient device;

generating the requested prediction based on the positional information; and forwarding, via the communications network, the generated prediction to the recipient device.
23. On a network server, machine-readable medium including instructions which when executed by the network server causes the network server to perform the method of claim 22.
24. A network server having machine-readable medium including instructions which when executed by the network server causes the network server to perform the method of claim 22.