AU2017383098A1

AU2017383098A1 - Content streaming via a communications network

Info

Publication number: AU2017383098A1
Application number: AU2017383098A
Authority: AU
Inventors: Geoff FIELD; Damitha GUNAWARDENA; Al-Mukaddim Khan PATHAN; Mark Sanders
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: WO2018112539A1

Abstract

A method of facilitating content streaming via a communications network, the method including the steps of, at a recipient device following receipt of a request for content: retrieving, via the communications network, a broadcast/multicast indicator associated with the requested content, the broadcast/multicast indicator being indicative of one or more broadcast/multicast events; and determining whether the broadcast/multicast indicator satisfies a predetermined condition; in accordance with the determination that the broadcast/multicast indicator satisfies the predetermined condition, causing the recipient device to listen to one of the one or more broadcast/multicast events for the requested content.

Description

Content streaming via a communications network

Field

The present disclosure relates to streaming of content, such as media content, gaming content, virtual reality content or augmented reality content, over a communications network. In one form, it relates to the streaming of live content, such as live gaming content or live performance 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, modern 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. 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 of an e-sport event 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 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.

WO 2018/112539

PCT/AU2017/051433

Summary

In 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 following receipt of a request for content:

retrieving, via the communications network, a broadcast/multicast indicator associated with the requested content, the broadcast/multicast indicator being indicative of one or more broadcast/multicast events; and determining whether the broadcast/multicast indicator satisfies a predetermined condition;

in accordance with the determination that the broadcast/multicast indicator satisfies the predetermined condition, causing the recipient device to listen to one of the one or more broadcast/multicast events for the requested content.

In a second aspect, there is provided a recipient device for facilitating content streaming via a communications network, the recipient device including a machinereadable medium containing instructions which on execution by the recipient device cause the recipient device to perform the method of the first aspect.

In a third 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, via the communications network, from one or more recipient devices requesting content, one or more respective retrieval requests for a broadcast/multicast indicator associated with the requested content, the broadcast/multicast indicator being indicative of one or more broadcast/multicast events; and if the broadcast/multicast indicator is made available, providing, via the communications network, to the one or more recipient devices, the requested broadcast/multicast indicator.

In a fourth aspect, there is provided a network server for facilitating content streaming via a communications network, the network server including a machineWO 2018/112539

PCT/AU2017/051433 readable medium containing instructions which on execution by the network server causes the network server to perform the method of the third 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, to be performed at a recipient device, of facilitating content delivery via a communications network.

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

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

Figure 4 illustrates schematically an example of a method, to be performed at a network server, of facilitating content delivery via a communications network.

Figure 5 illustrates schematically an example of a server workflow.

Detailed description of embodiments

The present disclosure relates to delivery of content over a communications network. In one form, the present disclosure is particularly relevant to content that is delivered to multiple (e.g. many) users simultaneously or near simultaneously, which for simplicity is hereinafter referred to as “live” content, regardless of any inherent and extrinsic time delay.

WO 2018/112539

PCT/AU2017/051433

Further, while some description is focused on streaming of live and media content (such as a live concert), the description with minor modifications is also applicable to non-live and/or non-media content (such as virtual or augmented reality content). Non-live media content may include sports footage during a first half of a sports game or event to be delivered during half time. The sports game or event may be within or outside a stadium, or at any geographical scale as long as there is coverage by the communications network. Live non-media content may include live e-sports events. Non-live and non-media content may include a slow-motion replay of an e-sports event segment.

The aim of live content streaming is to deliver live content to a large number of devices simultaneously. Given the “live” nature of the content, it is regarded as perishable, which means there is an expectation that there be little latency. As such, content players receiving live content usually operate with a small internal buffer in conjunction with adaptive bitrates to combat the variability of the network bandwidth or throughput available to the device. In order to survive content interruptions, a content player may be configured to adapt to a lower content quality (e.g. a lower bitrate) if the content player estimates that the network bandwidth available is reduced. Usually content players err on the side of lower content quality given that the alternative is a loss of streamed content entirely and that estimates of network bandwidth and throughput are not overly accurate.

As the audience of a live content streaming becomes larger, the network bandwidth is reduced due to the increasing load from the number of users, which means each user will receive even poorer quality content. To combat this, the mode of content delivery of the live content stream may be switched from unicast to broadcast (e.g. in LTE mobile networks) and/or multicast (e.g. in IP networks). However, for a content player to be able to properly receive the broadcast/multicast, the relevant broadcast/multicast specifications (different to the unicast specifications) are necessarily provided to and adopted by the content player. Conversely, when a content player needs to survive a loss of broadcast/multicast, the content player needs to fall back to the standard stream (e.g. unicast). In order to revert to the fallback, the

WO 2018/112539

PCT/AU2017/051433 relevant unicast specifications (different to the broadcast/multicast specifications) are again necessarily provided to and adopted by the content player. Additional information needs to be defined and provided to the content player for the different modes of content delivery to co-exist without conflict. Hereinafter, unless explicitly specified and the context requires otherwise, the term “broadcast” is intended to be used interchangeably with, or to include, the term “multicast”.

The inventors recognise that such mode-switching in content delivery as described above requires the content player to undertake additional processing, such as synchronizing the broadcast and falling back to the original live stream. In addition there is the question of determining when it is most efficient to switch from the standard live stream to a broadcasted live stream. The number of users in an area should reach a certain size before it becomes more efficient to broadcast the live stream. Conversely, when the number of users in an area drops below a certain size, it becomes more efficient to revert to a conventional live stream. These determinations are usually predetermined, based on the estimated audience size, but can be inaccurate either entirely or in specific locations given the audience which certain live content streams appeal to may be localised within countries, states, cities or even suburbs and often combinations thereof. To address these requirements, 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 live media content. The communications network may be any communications network. In one scenario, the communications network is one in which the number of recipient devices simultaneously accessing a particular piece of content can fluctuate over time, such as near the start or the end of a live event stream, during which a great number of users can tune in or tune out within a short period of time. The described methods reduce the requirements or remove the need for a content-consuming application (e.g. a media content player) on a recipient device to be concerned with one or more of: supporting broadcast in addition to conventional streams, falling back from broadcast

WO 2018/112539

PCT/AU2017/051433 to conventional streams, and determining the appropriate quality for a content segment. Instead, the described methods rely on a broadcast/multicast indicator that is retrievable by the one or more recipient devices via the communications network to influence the determination to activate or deactivate the recipient device’s broadcast/multicast listener. The number of retrieval requests for the broadcast/multicast indicator may also indicate the size of the audience and hence network bandwidth availability. Further, the appropriate quality for a content segment may be determined by the broadcast/multicast stream based primarily on the size of the audience.

In one aspect, the disclosure provides a method to be performed at each of one or more recipient devices in a communications system. Figure 1 illustrates a general form of the described method 100. Figure 2 illustrates an example of the communications system 200. The described method 100 includes, at a recipient device following receipt of a request for content: the step 102 of retrieving, via the communications network, a broadcast/multicast indicator associated with the requested content, the broadcast/multicast indicator being indicative of one or more broadcast/multicast events, the step 104 of determining whether the broadcast/multicast indicator satisfies a predetermined condition, and in accordance with the determination that the broadcast/multicast indicator satisfies the predetermined condition, the step 106 of causing the recipient device to listen to one of the one or more broadcast/multicast events for the requested content. Accordingly, rather than requiring the content-consuming application to adopt between the broadcast/multicast and unicast mode, the use of a broadcast/multicast indicator retrievable by the recipient device(s) via the communications network determines whether to activate or deactivate the relevant listening hardware, such as the LTE-B modem, of the recipient devices(s). Activation of the relevant listening hardware allows the recipient device to receive the requested content delivered by the listened broadcast/multicast event, and cache the received content delivered by the listened broadcast/multicast event.

WO 2018/112539

PCT/AU2017/051433

In one example, the broadcast/multicast indicator is provided by the communications network operator, which is expected to have relevant intelligence on the network traffic conditions and the audience size of a content stream. In another example, the broadcast/multicast indicator is provided by a dedicated server, such as the content provider, reachable by the communications network. Hereinafter, as illustrated Fig. 2, the broadcast/multicast indicator (if present) is stored and retrievable in a content delivery mode server.

The described method provides an on-device mode-switching component installed on each recipient device. In one arrangement, the on-device mode-switching 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 mode-switching component is integrated within each of one or more content-consuming application to interface with the content source. The on-device mode-switching component is configured to request retrieval of the broadcast/multicast indicator from a content delivery mode server. Apart from influencing the determination to activate or deactivate the recipient device’s broadcast/multicast listener, the retrieval requests may be counted or otherwise processed by the content delivery mode server for estimating the size of the audience for a particular piece of requested content. In some instances, the retrieval requests may include additional information, such as location information, to allow determination of the geographical distribution of the audience. Where the on-device mode-switching component is separate from a content-consuming application, the request for 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 live streaming 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 gaming application, in which case the content is gaming content. The content may include or be separated into multiple content segments. Each content

WO 2018/112539

PCT/AU2017/051433 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 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 size of the audience and hence network bandwidth availability. Content quality may be quantified in relative terms (e.g. poor, medium and high) or in numeral terms (e.g. in bitrate).

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) configured to receive content in accordance with the described method 100, a content delivery mode server 204 configured to receive requests for retrieving a broadcast/multicast indicator from the recipient devices 202 and to provide the requested broadcast/multicast indicator to 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 content delivery mode server 204 and the content sources 210 are communicatively coupled via a communications network 206. The recipient devices 202, the content delivery mode server 204 and the content sources 210 may be located remotely from one another. As mentioned, the content delivery mode server 204 may be operated by the network operator. As such, the content delivery mode server 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 include a machine-readable medium, such as a memory, storing instructions which, when executed by the processing unit, performs the described

WO 2018/112539

PCT/AU2017/051433 method 100. The content delivery mode server 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, estimates the size of the audience for the requested content (see 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 content delivery mode server 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 (e.g. one or more hard disk drives, solid state drives, flash memory devices and suchlike). The recipient devices 202, the content delivery mode server 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 content delivery mode server 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 reality emulator for simulating virtual reality. The memory in content source(s) 210 may be used for storing content.

The recipient devices 202, the content delivery mode server 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

WO 2018/112539

PCT/AU2017/051433 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 content delivery mode server 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 mode-switching component 300 (e.g. 300a, 300b and 300c) for interfacing with other on-device components, such as a contentconsuming application 350, broadcast middleware components 380, modem (modulation/demodulation) component 390 and the communication network 206. In another example, on-device mode-switching component 300 may be integrated with the content-consuming application 350. In one arrangement, the on-device modeswitching component 300 includes a cache 310 which is configured to provide buffered content to the content-consuming application 350.

In the described method 100, the step 104 of determining whether the broadcast/multicast indicator associated with the requested content satisfies a predetermined condition may include determining whether the broadcast/multicast indicator is available. For example, the on-device mode-switching component 300 may send a request to the content delivery mode server 204 for retrieving the broadcast/multicast indicator. Where the indicator is available for retrieval, the content delivery mode server may provide the indicator to the on-device modeswitching component 300, or return with a reply to the on-device mode-switching component 300 indicating the availability of the indicator. Where the indicator is unavailable for retrieval, the content delivery mode server may return with a reply to the on-device mode-switching component 300 indicating the unavailability of the indicator.

WO 2018/112539

PCT/AU2017/051433

In another aspect, as illustrated in Figure 4, the disclosure provides a method 400, complementary to the described method 100, to be performed at a network server, such as the content delivery mode server 204, in a communications system (e.g. communications system 200). The described method 400 includes the step 402 of receiving, via the communications network 206, from one or more recipient devices 202 requesting content, one or more respective retrieval requests for a broadcast/multicast indicator associated with the requested content, the broadcast/multicast indicator being indicative of one or more broadcast/multicast events. The described method 400 also includes the step 404 of, if the broadcast/multicast indicator is made available, providing, via the communications network, to the one or more recipient devices, the requested broadcast/multicast indicator.

Availability of the broadcast/multicast indicator can act as a flag with which the communication network operator or the content provider is able to inform the recipient devices 202 to listen to a broadcast/multicast stream or not. In one scenario of the described method 400, the network server (e.g. content delivery mode server 204) may further determine that the requested content is to be made available by broadcast/multicast. In an alternative arrangement, the determination may be made not by the network server or the network operator but by another party, for example, the content provider. Determining that the requested content is to be made available by broadcast/multicast may be based on the current number of the recipient devices associated with a location exceeding a predetermined number of recipient devices. For example, if the request content has an audience of sufficient size, the content delivery mode server 204 may determine that it is more resource-efficient to broadcast/multicast or that recipient devices may obtain higher-quality content via broadcast/multicast than unicast. In accordance with the determination that the requested content is to be made available by broadcast/multicast, the content delivery mode server 204 may make available the broadcast/multicast indicator for retrieval by the recipient devices 202.

WO 2018/112539

PCT/AU2017/051433

Conversely, in another scenario of the described method 400, the network server (e.g. content delivery mode server 204) may determine that the requested content is to be made unavailable by broadcast/multicast. Again, the determination may be made not by the network server or the network operator but by another party, for example, the content provider. If the broadcast/multicast indicator is made unavailable, content delivery mode server 204 omits provision of the requested broadcast/multicast indicator to the one or more recipient devices. Determining that the requested content is to be made unavailable by broadcast/multicast may be based on the current number of the recipient devices associated with a location falling below a predetermined number of recipient devices. For example, if the request content has an audience of insufficient size, the content delivery mode server 204 may determine that it is less resource-efficient to broadcast/multicast or that recipient devices may obtain higher-quality content via unicast than broadcast/multicast.

In either scenario, the described method 400 may further include the step of determining the current number of the recipient devices associated with the location based on the number of received retrieval requests. Each of the received retrieval requests may include location information associated with the respective recipient device. For instance, the location information may be categorised according to any one or combination of cell ID, countries, states, cities, and suburbs. In one arrangement, the content delivery mode server 204 is responsible for processing retrieval requests, such as collecting metrics and determining the appropriate mode of content delivery based on the collected metrics. For example, the collected metrics include the location and number of recipient devices requesting a broadcast/multicast indicator. These location and device counts enable the content delivery mode server 204 to determine whether to switch broadcasts/multicasts either on or off in specific geographic regions or in a more localized manner, dependent on the location and number of users of the live stream.

In one arrangement, the broadcast/multicast indicator includes an electronic broadcast/multicast guide (EBG) containing one or more broadcast/multicast events for the requested content. Each one or more broadcast/multicast events may be a past,

WO 2018/112539

PCT/AU2017/051433 current and future broadcast/multicast event. Each event may include associated with a time schedule, such as the scheduled start time, the scheduled start time and/or the scheduled duration. Each event may include geographical information. For example, an EBG may include two broadcast/multicast events for a requested live sports game, one for cell ID X providing geographical network coverage to suburb A and another for cell ID Y providing geographical network coverage to suburb B. The broadcast/multicast event(s) included in the exemplified EBG may be based on the estimated sufficiently large audience size in suburbs A and B.

In one arrangement, the EBG includes one or more broadcast delivery paths associated with each broadcast/multicast event. In the example above, the broadcast/multicast event for suburbs A and B may each include one or more of: the content being delivered (e.g. a URL), a broadcast flag (e.g. a combination of some of the following: identifier, service, class, handle), a multicast flag (e.g. usually an IP multicast address or set of IP multicast addresses or sometimes a group address). In this example, the step 106 of causing the recipient device to listen to one of the one or more broadcast/multicast events for the requested content may include the step of causing the recipient device to listen to one of the one or more broadcast delivery paths.

Continuing on this example, the step 104 of determining whether the broadcast/multicast indicator associated with the requested content satisfies a predetermined condition may include determining whether the EBG includes a broadcast/multicast event associated with the geographical information. For instance, a recipient device may be in suburb A covered by cell ID X. On retrieval of the EBG, the on-device mode-switching component 300 may determine that the EBG includes a broadcast/multicast event associated with cell ID X or suburb A. In this particular instance, the on-device mode-switching component 300 causes the recipient device to listen to the corresponding event accordingly. In another instance, a recipient device may be connected to cell ID Z providing geographical network coverage to suburb C. On retrieval of the EBG, the on-device mode-switching component 300 may determine that the EBG does not include any broadcast/multicast event associated

WO 2018/112539

PCT/AU2017/051433 with cell ID Z or suburb C. In this particular instance, the on-device mode-switching component 300 would not cause the recipient device to listen to any of the events in the indicator.

In one arrangement, in accordance with the determination that the broadcast/multicast indicator does not satisfy the predetermined condition (e.g. in the instance of the recipient device in suburb C), the on-device mode-switching component 300 may cause the recipient device to retrieve the requested content by unicast. In one scenario, in response to a location change of the recipient device, for example, from suburb A to suburb C, the on-device mode-switching component 300 may request retrieval of the broadcast/multicast indicator. On determining that the EBG does not include any broadcast/multicast event associated with cell ID Z or suburb C, the recipient device will deactivate any broadcast/multicast listeners on the device, and fall back to unicast. Accordingly, the switch of content delivery mode to unicast may be a result of the recipient device having a location change, for example, having moved from suburb A (where the device was previously listening to the corresponding broadcast/multicast event) to suburb C (where a broadcast/multicast stream for the content is unavailable). In another scenario, the switch of content delivery mode to unicast may be a result of a broadcast/multicast event previously associated with suburb C being removed from the EBG due to, for example, a decreased number (e.g. beyond a predetermined threshold) of recipient devices requesting the same content, making broadcast/multicast a less efficient mode of content delivery than unicast.

In one arrangement, particularly during switching between different modes of content delivery (e.g. from broadcast to unicast), the present disclosure may be combined together with a predictive adaptive streaming (PAS) technique, which is the subject of the present applicant’s co-pending Australian provisional patent application 2016905366 filed on 23 December 2016 and titled “Content streaming via a communications network”. The PAS technique provides a more accurate or an alternative estimate of the best requested quality of buffered content segments. In particular, when the content-consuming application 350 falls back to the unicast mode

WO 2018/112539

PCT/AU2017/051433 of content delivery, the PAS technique may be applied to take over the responsibility for the network decisions or buffer control logic of content-consuming application 350. Without PAS, when the present disclosure falls back from broadcast/multicast to unicast, the network statistics as seen by the content-consuming application 350 may be skewed given the content segments as seen by a player immediately before the switching would be returned almost instantly, incorrectly guiding the contentconsuming application 350 to determine that the communications network 206 is returning large amount of content and therefore has a high available throughput. This incorrect guidance may lead the content-consuming application 350 to request unsustainably high quality content segments to buffer.

Further, upon switching from unicast to broadcast/multicast, the network operator may be required to commence broadcasting/multicasting from an appropriate content segment, such that what has already been buffered in the cache 310 does not overlap with what is to be broadcasted/multicasted. For example, a unicast stream is buffered up to the i-th content segment as requested by a buffer controller, the network operator is configured to commence broadcast of the i+l-th content segment such that no identical content segment is delivered via broadcast/multicast and fetched via unicast simultaneously.

In one arrangement, the step 102 of retrieving the broadcast/multicast indicator is responsive to a request to switch a retrieval mechanism of the requested content from unicast to broadcast/multicast. In other words, the broadcast/multicast mode of content delivery may be “on-demand”, such as requested by a user of the recipient device. Alternatively, on-demand content delivery may be requested by the content owner, product owner, or network owner, where a broadcast/multicast stream would be enabled irrespective of the number of recipient devices requesting the live content. To ensure that the recipient device is able to receive the requested content, the on-device mode-switching component 300 first checks for an available broadcast/multicast stream before activating the recipient device’s broadcast/multicast listener. Alternatively or additionally, the step 102 of retrieving a broadcast/multicast indicator is repeated periodically. In other words, the on-device mode-switching

WO 2018/112539

PCT/AU2017/051433 component 300 regularly checks for an available broadcast/multicast stream (which tends to be of higher content quality than unicast streams) to ensure the recipient device is obtaining the best available content quality. In some arrangements, unicast is disabled and step 102 is necessary to enable broadcast/multicast-only operation.

Figure 3 illustrates schematically an example of information exchange between the content-consuming application 350 and the on-device mode-switching 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 also includes a content management system (CMS) 354 for storing manifest information (e.g. in MPD format) and/or electronic program guides (EPG). The on-device mode-switching component 300 includes a proxy component 302 running a proxy service, a broadcast component 304 running a broadcast service, a content delivery aggregator module 306 for interfacing between the on-device mode-switching component 300 and the device receiver (which in turn includes broadcast middleware component 380 such as software middleware which is responsible for protocol management (including codec, repair, reporting, service announcements), maintaining registration mechanism for preparing the delivery channel, and interfacing with the modem (modulation/demodulation) component 390, such as a LTE-B modem), 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. a live sports game). 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 manifest information and/or EPG for the specific content. At step 314, the content player 352 is activated using 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.

WO 2018/112539

PCT/AU2017/051433

The proxy component 302 is configured to detect whether the subject of the request from step 316 relates to a content segment. Where a content segment request is detected, the proxy component 302 interrogates at step 318 the cache 310 for matched content segment. Step 318 may involve checking for the requested or an equivalent (e.g. of better quality) content segment. 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. In an alternative or additional process, which is preferred, where a content segment request is detected, the proxy component 302 triggers requests at step 322 for the broadcast service in the broadcast component 304 to either activate or deactivate the recipient device’s receiver to listen to broadcast/multicast.

To determine whether to activate or deactivate, the broadcast service of the broadcast component 304 is configured to retrieve at step 324, from the content delivery mode server 204 via network 206, any EBG containing past, present or future broadcast/multicast events, usually broken down by geographic areas. Where no EBG is present, there are no broadcasts planned and any broadcast/multicast listeners of the recipient device should be deactivated (as per steps 326, 328 and 330). Where there is an EBG with matching geographic information of the device and no broadcast/multicast is currently active, the broadcast/multicast listeners should be activated (as per steps 326, 328 and 330).

Where the broadcast/multicast listeners are activated, the modem component 390 receives at step 332 the incoming content and passes to the broadcast middleware component 380. At step 334, the modem component 390 passes the content to the broadcast middleware component 380. As step 336, the broadcast middleware component 380 stores the content in the cache 310 and updates the dereferencing map for the proxy. In one example, the content delivery mechanism is LTE-B, which

WO 2018/112539

PCT/AU2017/051433 includes activation and listening for payloads via FLUTE. Alternative content delivery mechanism may be used, such as any other broadcast technology targeted at the specifics of the delivery path.

In one arrangement, the content-consuming application 350 is directed at the proxy component 302. Its buffer may be set as small as possible. The contentconsuming application 350 may be unaware of the delivery path via unicast or broadcast (i.e. no new specifications to be adopted), where synchronization is the responsibility of server side components.

In one arrangement, the content source(s) 210 undertakes these steps either once or repeatedly to generate a unicast stream:

1. Receiving content source

2. Encoding into content segment(s)

3. Optionally applying digital rights management (DRM)

4. Updating manifest(s)

5. Publishing manifest(s) and/or content segment(s)

6. Generating an EPG (Electronic Program Guide) or variation therein

7. Publishing EPG or variation therein

To enable a broadcast stream, the content source(s) 210 may undertake additional steps:

1. Scheduling LTE-B broadcast (or multicast) with content segment(s)

2. Generating an EBG (Electronic Broadcast Guide)

3. Publishing EBG at the content delivery mode server 204

In a slightly more detailed example and referring to Figure 5 illustrating a server workflow:

• The Content Provider 502 supplies raw video source which is sent to the Encoder 504.

WO 2018/112539

PCT/AU2017/051433 • The Encoder 504 chops up video into its audio / video components into segments and encodes in multiple different sizes / qualities which can optionally have DRM applied and sent to the Packager 506.

• The Packager 506 assembles the Manifests / MPDs.

• The Segments and Manifests / MPDs will be published to the CDN (packager CDN origin 508 & edge 510).

• Optionally the Manifests / MPDs can have an EPG or similar, published to a content management system or the like (not shown) • The Live Stream will at this point be “playable” in the usual Unicast manner.

• The Manifest / MPDs is required to be sent through to the Broadcast

Micro-Service (packager broadcast micro-service), where a decision is made about whether or not to start / stop / continue broadcasting.

• The decision, in one form, can be based on exceeding a threshold for the number of requests made of the broadcast micro-service for specific content by recipient devices 202 in a geographic area; or it can involve a prediction of content consumption and network usages across the geographic areas.

• When a broadcast is deemed appropriate, the broadcast will be activated, as shown in the LTE-B Controller 512 which passes the event to BMC 514, which in turn passes the event to BDC 516 and an EBG (electronic broadcast guide) generated for the activated broadcasts.

• The Broadcast Micro-service is queried by the recipient device 202 which then is returned with the EBG when a broadcast has been scheduled or no EBG where there is no broadcast active Broadcast Micro-Service).

• The Manifest / MPDs remains the same and independent of the transport mechanism actually occurring in the underlying component (CDN Edge 510 <=> recipient device 202).

WO 2018/112539

PCT/AU2017/051433 • The content-consuming application 350 is able to fallback to conventional unicast should a broadcast fail (CDN Edge 510 <=> recipient device 202).

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 following receipt of a request for content:

retrieving, via the communications network, a broadcast/multicast indicator associated with the requested content, the broadcast/multicast indicator being indicative of one or more broadcast/multicast events; and determining whether the broadcast/multicast indicator satisfies a predetermined condition;

in accordance with the determination that the broadcast/multicast indicator satisfies the predetermined condition, causing the recipient device to listen to one of the one or more broadcast/multicast events for the requested content.
2. The method of claim 1 wherein the step of determining whether the broadcast/multicast indicator satisfies a predetermined condition includes the step of determining whether the broadcast/multicast indicator is available.
3. The method of claim 1 wherein the broadcast/multicast indicator includes an electronic broadcast/multicast guide (EBG) containing information associated with the one or more broadcast/multicast events.
4. The method of claim 3 wherein the EBG includes one or more of past, current and future broadcast/multicast events.
5. The method of claim 4 wherein the EBG includes a time schedule of the one or more of past, current and future broadcast/multicast events.
6. The method of claim 3 or 4 wherein the EBG includes geographical information associated with the one or more of past, current and future broadcast/multicast events.
7. The method of claim 3 wherein the EBG includes one or more broadcast delivery paths associated with the respective one or more of past, current and

WO 2018/112539

PCT/AU2017/051433 future broadcast/multicast events, and the step of causing the recipient device to listen to one of the one or more broadcast/multicast events for the requested content includes the step of causing the recipient device to listen to one of the one or more broadcast delivery paths.
8. The method of claim 5 wherein the step of determining whether the broadcast/multicast indicator satisfies a predetermined condition includes determining whether the EBG includes a broadcast/multicast event associated with the geographical information.
9. The method of claim 1 further including the step of, in accordance with the determination that the broadcast/multicast indicator does not satisfy the predetermined condition, causing the recipient device to retrieve the requested content by unicast.
10. The method of claim 1 wherein the step of retrieving a broadcast/multicast indicator is responsive to a request to switch a retrieval mechanism of the requested content from unicast to broadcast/multicast.
11. The method of claim 1 wherein the step of retrieving a broadcast/multicast indicator is responsive to a change of a location of the recipient device.
12. The method of claim 1 wherein the step of retrieving a broadcast/multicast indicator is repeated periodically.
13. The method of claim 1 further including the steps of:

receiving the requested content delivered by the listened broadcast/multicast event; and caching the received content delivered by the listened broadcast/multicast event.
14. A recipient device for facilitating content streaming via a communications network, the recipient device including a machine-readable medium containing instructions which on execution by the recipient device cause the recipient device to perform the method of any one of claims 1-13.

WO 2018/112539

PCT/AU2017/051433
15. 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, via the communications network, from one or more recipient devices requesting content, one or more respective retrieval requests for a broadcast/multicast indicator associated with the requested content, the broadcast/multicast indicator being indicative of one or more broadcast/multicast events; and if the broadcast/multicast indicator is made available, providing, via the communications network, to the one or more recipient devices, the requested broadcast/multicast indicator.
16. The method of claim 15 further including the step of determining that the requested content is to be made available by broadcast/multicast.
17. The method of claim 16 wherein the step of determining that the requested content is to be made available by broadcast/multicast is based on the current number of the recipient devices associated with a location exceeding a predetermined number of recipient devices.
18. The method of claim 16 or 17 further including, in accordance with the determination that the requested content is to be made available by broadcast/multicast, the step of making available the broadcast/multicast indicator.
19. The method of claim 15 further including the step of, if the broadcast/multicast indicator is made unavailable, omitting provision of the requested broadcast/multicast indicator to the one or more recipient devices.
20. The method of claim 19 further including the step of determining that the requested content is to be made unavailable by broadcast/multicast.
21. The method of claim 20 wherein the step of determining that the requested content is to be made unavailable by broadcast/multicast is based on the

WO 2018/112539

PCT/AU2017/051433 current number of the recipient devices associated with a location falling below a predetermined number of recipient devices.
22. The method of claim 19 or 20 further including, in accordance with the determination that the requested content is to be made unavailable by broadcast/multicast, the step of making unavailable the broadcast/multicast indicator.
23. The method of claim 17 or 21 further including the step of determining the current number of the recipient devices associated with the location based on the number of received retrieval requests, each of received retrieval requests including location information associated with the respective recipient device.
24. The method of claim 15 wherein the broadcast/multicast indicator includes an electronic broadcast/multicast guide (EBG) containing one or more broadcast/multicast events.
25. The method of claim 24 wherein the EBG includes one or more of past, current and future broadcast/multicast events.
26. The method of claim 25 wherein the EBG includes a time schedule of the one or more of past, current and future broadcast/multicast events.
27. The method of claim 25 wherein the EBG includes geographical information associated with the one or more of past, current and future broadcast/multicast events.
28. The method of claim 25 wherein the EBG includes one or more broadcast delivery paths associated with the respective one or more of past, current and future broadcast/multicast events.
29. A network server for facilitating content streaming via a communications network, the network server including a machine-readable medium containing instructions which on execution by the network server causes the network server to perform the method of any one of claims 15-28.