Patent Description:
<CIT> describes methods and apparatus to provide content on demand in content broadcast systems are disclosed. An example method comprises receiving a first portion of a program via broadcast signal and receiving a second portion of the program via an Internet protocol (IP) based signal. The method may further comprise combining the first and the second portions and at least one of store the combined first and second portions in a file or playback the combined first and second portions.

<CIT> describes a system for providing home automation information via communication with a vehicle. A home automation system can determine a state of the home and determine when occupants enter a home. The home automation system can identify an occupant and monitor the status and location of the occupant in the home and determine a status change for the occupant, such when the occupant leaves or is scheduled to leave the home, the occupant going to sleep, experiencing a health crisis, or entering an area of the home the occupant is not authorized to enter. The home automation system can send alerts and information to a vehicle operation system of a vehicle and to a communication device of a user. The alerts can include information related to the identity and the status of the occupant and information related to the state of the home.

A computerized method comprises determining (<NUM>) missing portions of received content delivered to a plurality of sub-edge devices; selecting (<NUM>) one or more of the missing portions to recover based at least on one or more content specific metrics or network specific metrics; receiving, from a central cloud device, a content priority for each of the selected one or more of the missing portions, the content priority being based on the received content and a heatmap of missing content created based on information shared by the plurality of sub-edge devices; selecting (<NUM>), for each of the selected one or more missing portions, one of a satellite network or a non-satellite network, based on the received content priority, to recover each of the selected one or more missing portions; and injecting (<NUM>), into the received content, the selected one or more missing portions from the selected one of the satellite network or the non-satellite network to recover the selected one or more missing portions, the recovery coordinated by the central cloud device communicating with the plurality of sub-edge devices; wherein the content is divided into a plurality of segments and the heatmap is created for each segment of the content such that that if the number of sub-edge devices is above a predefined heatmap value threshold in a region for a defined number of missing segments, the recovery is performed using the satellite network given the time sensitivity of the content and the period of satellite.

In the figures, the systems are illustrated as schematic drawings. The drawings may not be to scale.

The computing devices and methods described herein are configured to provide a context-aware and content-aware digital distribution network for optimally and reliably delivering Internet enabled digital services at the last mile (e.g., last hop before the user device), including by performing missing content recovery, particularly content communicated from one or more satellites. Various examples include a system subsuming an intermediate context-aware sub-edge device (e.g., computing devices at the last-mile edge of service) introduced between the cloud and end user device (e.g., consumer device at the edge), which leverages local storage and computation to thereby enhance overall end to end (E2E) network experience and/or performance for the end consumer. For example, reliable content delivery from a satellite to sub-edge devices is provided by introducing a context-aware configuration at the sub-edge coupled with both the cloud and end consumer device and using different recovery methods, such as non-satellite methods (e.g., a peer-to-peer (P2P) recovery method) and satellite methods. That is, a context-aware solution is provided at the sub-edge in various examples.

Sub-edge devices in one example have multiple network interfaces and a customized network stack to support the multiple network interfaces. Using contextual information (from the user, sub-edge, network, application, etc.), the content for the end user is preloaded on the sub-edge device. Instead of accessing content from the cloud, systems described herein allow the end user device to access the preloaded content directly from the sub-edge over a high bandwidth network.

A platform is provided for Internet enabled digital service businesses coordinated by a cloud service and augmented by a sub-edge configuration through properties of the sub-edge devices, including intelligence, storage, and computation, that optimizes the cloud to end user overall network utilization, cost, and performance, along with higher reliability. In one example, the sub-edge device hosts third party applications (e.g., Internet enabled digital service businesses). The third party applications at the sub-edge act as an intermediary between a corresponding end user and the cloud service.

As a result, the overall system is non-intrusive to the end user, and utilizes contextual information and network bandwidth diversity in content acquisition and delivery. The overall system further performs missing content recovery to enhance overall E2E network performance. For example, content recovery is enabled at the sub-edge device as well as at the end user device. Buffered multicast of content is provided directly from the sub-edge to the end user devices. End users also can access different parts of the same content from multiple sub-edges. In this manner, when a processor is programmed to perform the operations described herein, the processor is used in an unconventional way that allows for more efficient and reliable content delivery, which results in an improved user experience.

The present disclosure solves at least one or more of the following technical problems:.

In a satellite content delivery environment, the sub-edge devices of the present disclosure in the same geographic area perform content recovery for the missing portions using satellite or non-satellite networks (e.g., TV White Space(TVWS), Ethernet, cellular, cloud, etc.). In some examples, the sub-edge devices receive most of the content from the satellites, with the missing content recovered via the non-satellite networks.

An architecture of a system <NUM> according to one example is shown in <FIG>. The system <NUM> in this example has an intermediate context aware sub-edge device (between the cloud <NUM> and an end user device <NUM>), which has multiple network interfaces and a customized network stack. By introducing an intelligent intermediate network device (IIND) <NUM> at the last hop between the end user device <NUM> (e.g., mobile phone, an Internet of Things (IoT) device) and the cloud <NUM>, a tiered architecture is provided that improves overall network performance and/or the end user experience. The tiered architecture helps ensure reliable content delivery from satellites at least by performing "intelligent" recovery of missing content. In the various examples, the IIND <NUM> is configured or embodied or referred to as a hub device or a sub-edge device. For example, as illustrated in <FIG>, the IIND <NUM> is a sub-edge device embodied as a bine hub <NUM>.

With particular reference to the IIND <NUM>, this device is configured in various examples as next described. The IIND <NUM> is a highly reliable sub-edge device with local storage and compute that runs PaaS software. The IIND <NUM> hosts multiple network interfaces with the cloud <NUM> both unidirectional as well as bi-directional, but has at least one channel that is bi-directional with the cloud. Possible network channels include Digital Subscriber Line (DSL), Global System for Mobile Communications (GSM), Long-Term Evolution (LTE), LTE-B, satellite downlink, television whitespace (TVWS), etc. The IIND <NUM> can establish bi-directional communication with any other IIND devices over WAN/long-range WiFi/Local Area Network (LAN)/TVWS etc. if the devices are running the PaaS software.

After content is delivered to the IIND <NUM>, the IIND <NUM> performs recovery for any missing portions of the content using satellite or non-satellite networks, including the network channels described above. Recovery is performed in multiple ways based on, for example, cost, efficiency, and time, including recovery at the IIND <NUM> using, for example, a low bandwidth (LBW) link, peer-to-peer recovery among other IINDs in the same geographic area (e.g., using television white space (TVWS)), and recovery in the end user device <NUM>.

Other end user devices like smartphones, laptops, IoT devices can connect with the IIND <NUM> and establish bi-directional communication channels over <NUM> a/b/g/n, Bluetooth, NFC, TV Whitespaces etc. To communicate in this architecture, the end user device applications are configured to interact with a version of the PaaS software, which is available in the form of software development kit (SDK), library, or service, and hence can also be added to existing applications.

The end user devices <NUM> have separate 'private' channels with the cloud <NUM> for exchanging sensitive and/or private information with low data exchange requirements such as authentication, financial information, device specific actions etc. The end user devices <NUM> establish P2P communication and exchange any data after consent to do so is acquired from either the IIND <NUM> or the cloud <NUM>. In some examples, the 'private' channels are communication channels having a low-bandwidth connection (e.g., second generation (<NUM>) or third generation (<NUM>) cellular network connections). In one example, a majority of or most of the 'private' channels (e.g., more than <NUM> percent) have a low-bandwidth connection. However, it should be appreciated that the number of 'private' channels that have a low-bandwidth connection can be higher or lower.

An architecture of a platform <NUM> (as a PaaS) according to one example is shown in <FIG>. The PaaS <NUM> is configured in various examples includes a central cloud device (configured or referred to in some examples as a bine cloud <NUM>, shown in <FIG>) and providing a cloud service <NUM> (configured or referred to in some examples as a bine cloud service that controls cloud operations) between edge services <NUM> and cloud services <NUM>. That is, the PaaS <NUM> is configured as a platform that includes both the cloud and the sub-edge. In this example, the bine cloud <NUM> coordinates and controls operations between the edge services <NUM> and cloud services <NUM>, including content delivery from a plurality of communication devices <NUM>, which includes performing recovery of missing content. In one example, the edge services <NUM> in combination with the IIND <NUM> are configured to control communication between the cloud service <NUM> and the end user device <NUM>, including to recover missing content from a different communication device <NUM>. For example, most of the content is received from one of the communication devices <NUM>, such as a satellite, and the missing content is received from the communication device <NUM>, such as via Ethernet, DSL, GSM, etc..

In the illustrated example, the IIND <NUM>, apart from multiple network interfaces, has both local storage and computation power to maintain state, parameters, and host other applications. The IIND <NUM> can have a range of storage and computational capabilities that depend on various factors, such as location, demography, use-cases (personal versus commercial) etc., but runs a bine hub application to leverage functionalities. The IIND <NUM> is also configured to access one or more drivers <NUM> and communication interfaces <NUM> to allow communication through different means, such as the communication device <NUM>. Storage and power <NUM> are also provided.

In one example, the cloud services <NUM> in combination with the bine cloud service <NUM> (and access to standard services <NUM>) run in a particular cloud, manage the hubs (e.g., one or more IINDs <NUM>), and orchestrate tasks and actions for the overall system. For example, the IIND <NUM> runs the bine hub application that monitors storage and computational resource availability, and is also responsible for decision-making at the 'last hop'. The bine hub application is configured in a manner to allow other providers to run third-party (3P) applications <NUM> apart from any first party (1P) applications <NUM> that leverage the bine hub storage, compute, and intelligence. The IIND <NUM> downloads, maintains, and updates machine learning models on the hub device for both the 1P applications <NUM> and 3P applications <NUM>, which run on the IIND <NUM> (e.g., run on the bine hub). The bine edge is the service component <NUM> that runs on the end user device <NUM> and that interacts with both the bine cloud service and the bine hub seamlessly to provide improved digital service delivery, including initial delivery and recovery of missing content.

An example of a bine network stack <NUM> is illustrated in <FIG>. The bine network stack <NUM> is configured in various examples to include two different network stacks <NUM>, one stack 304a for communicating with the bine cloud <NUM> and other bine hubs <NUM>, and another stack 304b for communicating with the bine edge <NUM> service. As described herein, in various examples, the bine cloud <NUM> executes the cloud service <NUM> and the bine edge <NUM> is a service executing on the end user device <NUM>. That is, the cloud service <NUM> operates on the cloud side of the 'bine' and the end user device <NUM> operates on the user device side of the 'bine'.

The two network stacks 304a, 304b are bridged by the bine hub service and host <NUM> at an application layer <NUM>, such that all the PaaS clients are hosted therein, corresponding services are provided, and local storage and computation is performed. In some examples, the bine hub service and host <NUM> include, or are embodied as, the edge services <NUM>.

The cross-layer network stack illustrated in <FIG> facilitates multiple network interfaces, wherein the application layer <NUM> determines/selects the network interface before initiating a communication, and a transport layer <NUM> handles run-time vertical handover to ensure better network performance. It should be noted that the network stacks, including the network stacks 304a, 304b, have other layers including a network layer <NUM>, a data-link layer <NUM>, and a physical layer <NUM>. That is, the network stacks in various examples can be configured using one or more different network communication protocol designs.

Thus, in some examples, two five-layer network stacks <NUM> are configured in the bine hub <NUM> with the network stack 304a configured to communicate with the bine cloud <NUM> (cross-layer customization to support multiple interfaces - preselected or on the fly) or other bine hubs <NUM>. The network stack 304b is configured to communicate with end devices (standard stack). The stacks <NUM> are bridged at the application layer <NUM>.

One or more examples include local storage, wherein the bine hub PaaS platform provides features where a storage <NUM> of the bine hub <NUM> is leveraged by other applications for a specified duration. In a 'Leaf CDN' example, a media company (MC) is launching a new season of popular television series S_1 in a specific region. Each user opens a new unicast channel for accessing the content. MC can make the content available to the bine cloud <NUM> via API's. The bine cloud <NUM> delivers S_1 to specific hub locations, including content recovery as described herein. Users in nearby locations using an MC application integrated with the bine edge <NUM> receive notifications prompting the users to get files from the nearest hub in high quality at high speed without incurring any data cost. The user can then acquire the content without hitting cloud CDN's of the MC.

In a 'Temporary Personalized Secure Storage' example, a typical end user who does not have access to a high bandwidth (HBW) connection and a lot of local storage can request delivery of any content to a specific hub. Using the bine edge <NUM>, the user of the API can communicate the specific file, duration, and specific hub to which the content needs to be delivered. A download operation is triggered at the specified hub, and after download (including content recovery as described herein), the content is encrypted and stored for a specified duration. The content is only accessible by the user via the specific end user device <NUM> that triggered the request.

An architecture of a CDN <NUM>, illustrated as a leaf CDN, according to one example is shown in <FIG>. With continued reference to <FIG>, various examples leverage the sub-edge and the CDN. In an example, the bine cloud <NUM> uses control messages and telemetry from the bine hub <NUM> to make decisions on appropriate delivery channels. The bine hub PaaS platform has a machine learning (ML) module that is a collection of several models that are downloaded and updated and made available for different end application uses. The ML models are both for specific use cases of the 3P applications <NUM> and facilitate bine hub services <NUM>. The bine hub <NUM> ensures that any 1P application <NUM> or 3P application <NUM> that runs and stores data on the platform conforms to policies deployed on the hub. The policies are application specific and encapsulate user consent, data retention and deletion, sharing etc. The ML models can be deployed on the bine hub <NUM> by both 1P and 3P applications along with a custom policy around updates, data-use, etc. The bine hub <NUM> has the ability to maintain sovereignty of data <NUM> (e.g., data of the MC), which may be stored in a bine database <NUM>, by running ML models only on the bine hub <NUM> and not pushing user data to the cloud <NUM>. Anonymized and aggregated data can be shared with 3P services based on policies in place to improve the ML models.

In some examples, metadata is used to determine content to download to the bine hub <NUM>. A key <NUM> is used to access the content <NUM> by the end user device <NUM> (to leverage storage at the bine hub <NUM>). It should be noted that diversity of channels provides increased communication speed (e.g., select the fastest channel). In an example for enhancing a video experience using ML, an MC has developed ML models that can enhance the user experience of watching videos in real-time by upscaling the videos. The ML models are trained on the videos apriori and different types of videos have different types of models. For example, a sports movie model is different from a talk show model. Also, the ML models use specific hardware for the models to run effectively. The MC can attach ML models with specific content to be delivered to the bine hubs <NUM>. Whenever a user acquires specific content, the bine hub <NUM> and the bine edge <NUM> coordinate to either push the content with ML models to the end user device <NUM> or upscale the video and push that content directly to the end user device <NUM> depending on device specifications.

<FIG> illustrates a workflow <NUM> for intelligent content acquisition and delivery according to an example. The workflow <NUM> in this example includes the following operations:.

It should be appreciated that the operations can be performed in a different order, additional or fewer operations may be provided, and operations can be performed at the same or different times (e.g., simultaneously, concurrently, or sequentially).

<FIG> illustrates a process <NUM> for content acquisition and delivery according to an example. The process <NUM> performs intelligent content acquisition and delivery. A prioritized content list generator <NUM> in the bine cloud <NUM> generates a content acquisition priority (e.g., a prioritized content list <NUM> including a plurality of content <NUM>) based on one of more metrics <NUM> (e.g., PaaS client metrics, such as content type, end user demand, business model/promotion, time sensitivity, storage cost, network bandwidth cost, etc.) provided by the PaaS client and bine services. The metrics <NUM> can vary from bine hub <NUM> to bine hub <NUM> depending on, for example, geographic location, demography of user community, etc. In one example, computational metrics <NUM> (e.g., metrics of storage and network bandwidth, among others) are also considered.

Content acquisition is then handled by the bine service in two high-level operations. This acquisition includes (<NUM>) a network analyzer <NUM> making decisions on using a particular network interface to obtain content from the cloud <NUM> and (<NUM>) performing a recovery and storing the content.

The network analyzer <NUM> is configured to make decisions on using the network interface to acquire the content from the cloud <NUM> depending on one or more network metrics <NUM> (e.g., network bandwidth utilization, quality, and cost). For example, if the same content is requested by multiple bine hubs <NUM>, a satellite broadcast is performed in consideration of bandwidth utilization and cost. However, depending on the weather, the satellite broadcast can be hampered. In such cases, the network quality is a factor depending on the network quality forecast or run-time network analysis. Another example is cellular network quality at the location of the bine hub <NUM> based on the distance of the cellular tower, antenna gain, loss of signal (LOS), etc. In the initial stage, the network metrics <NUM> are determined and analyzed based on a heuristic. However, ML is utilized in some examples in determining and analyzing optimal metrics over time.

In the illustrated example, the network analyzer <NUM> determines at <NUM> whether a target bine hub <NUM> is able to operate above a threshold, for example, based on the network metrics <NUM>, and/or other metrics. If operation above the threshold is possible, a broadcast or multicast interface is used to broadcast or multicast the content at <NUM> (e.g., satellite communication). If operation is below the threshold, then a unicast interface is used to unicast the content at <NUM> (e.g., LAN or cellular communication). A hub-specific interface priority list generator <NUM> then generates a hub-specific interface priority list <NUM> based on the selected communication method and bine hub network metrics.

A content delivery coordinator <NUM> then uses content specific metrics <NUM> or 'content metrics' (e.g., live streaming, offline content, online content, gaming, etc.) to deliver the content <NUM> via a network interface <NUM> based on the hub-specific interface priority list <NUM>. For example, a network interface <NUM> (e.g., satellite, TVWS, cellular CTE, etc.) is used to transmit the content <NUM> to the bine hub <NUM> wherein content reception and storage <NUM> is performed. Thus, in some examples, content type also can be a factor. For example, for a live streaming content, network quality gets the highest priority as the scope of recovery is very little. On the other hand, offline content gets more acquisition and recovery time. Another consideration is allowable latency for content. For example, gaming requires the lowest possible latency in some examples. Thus, in various examples, intelligent content acquisition and delivery are provided.

The network interface from the cloud <NUM> to bine hubs <NUM> is selected by running the network analyzer <NUM>, which can include a determination of whether the transmission is multicast or broadcast. In some examples, bine hub network metrics (e.g., quality, cost, etc.) are used to determine a list of switchable network interfaces for each bine hub <NUM> with a determination of the type of content. The content delivery coordinator <NUM> then runs an algorithm to coordinate content delivery (it should be noted that fragments can be sent over different channels, which can be different for different bine hubs <NUM>). Content is delivered to the bine hubs, recovery is performed, and the content is stored in the bine hub. A notification is then provided to the PaaS client of this storage of the content. For example, the PaaS client notifies the end client when the content is stored.

<FIG> illustrates a process <NUM> for content acquisition and delivery. The process <NUM> performs intelligent content acquisition and delivery that includes recovery of missing portions of content. In one example, the process <NUM> provides reliable content delivery from a satellite to sub-edge devices by introducing a context-aware device (bine hub <NUM>) at the sub-edge coupled with both the cloud <NUM> and the end user device <NUM>, and using one or more recovery methods. That is, all sub-edge devices (e.g. all the bine hubs <NUM>) in a geographic area (e.g., city) should have the same content. However, error rates from different satellites differ, so some sub-edge devices will have missing content portions, and those missing portions may differ among sub-edge devices. As part of the process <NUM>, the sub-edge devices in the same geographic area perform recovery for the missing portions using non-satellite networks. As such, in this satellite example, the sub-edge devices will then have received most of the content from one or more satellites, with the missing content recovered via non-satellite means. However, in some examples, content recovery may also be performed using satellite means (e.g., recovery of low priority content).

With particular reference to <FIG>, after content acquisition is performed as described herein (see, e.g., <FIG>), recovery can be performed, such as when the bine hub <NUM> misses some part or portion of the content for various reasons. It should be noted that recovery is coordinated by the bine cloud <NUM>, in some examples. In various examples, the recovery can be performed using non-satellite means (e.g., using a P2P connection between the bine hubs <NUM>, using the cloud <NUM>, using a cellular network, etc.) or satellite means (e.g., using one or more orbiting satellites).

More particularly, once the content reaches the bine hub <NUM>, and it is determined that some content is missing, recovery is performed. The recovered content is then delivered to the end user devices <NUM> by the bine hub <NUM>. The delivery of content is performed using the HBW network interface between the end user device <NUM> and the bine hub <NUM> (e.g., using a HBW connection <NUM>). The HBW network connection and the intelligent delivery system improves the end user experience by enabling high throughput.

In one example, a recovery coordinator <NUM> is configured to perform content recovery of a missing content fragment <NUM> among received content fragments <NUM>. A medium recovery decider <NUM> uses content specific metrics <NUM> and/or network specific metrics <NUM> (or 'network metrics') (e.g., content type and recovery sensitivity, time sensitivity, a number of missing content fragments <NUM>, available network interface bandwidth and cost, available bine hubs <NUM>, etc.) to coordinate or control the recovery process, such as to select and/or download one or more missing portions of the missing content to recover. As such, the recovery coordinator <NUM> is configured to perform content recovery in multiple ways based on cost, efficiency, and time (e.g., based on available bandwidth, the speed of the connection, etc.), with different recovery interfaces including (i) at the bine hub <NUM> using the LBW connection <NUM> (with the bine cloud <NUM>), (ii) P2P recovery among the bine hubs 302a, 302b (e.g., using television white space (TVWS)), and (iii) recovery in the end user device <NUM>. Recoveries are coordinated by the bine cloud <NUM> over the LBW connection <NUM>. For example, the bine cloud <NUM> receives telemetry data from the bine hubs 302a, 302b and selects which connection(s) to use to provide the missing content portions. After recovery, the content is stored depending on the content type, storage size/cost, content demand, etc. as described herein. As described in more detail, the content recovery, including the coordination of the content recovery, is performed at least in part using one or more heatmaps <NUM> (shown in <FIG>). For example, the bine cloud <NUM> creates or generates one or more heatmaps <NUM> of missing content at the bine-hub level based on information shared by the bine hubs <NUM>. In this way, the recovery of the missing content (e.g., connections to use, size of the recovery zone <NUM>, recovery scheme used, etc.) is controlled and/or coordinated based on heatmaps <NUM> (shown in <FIG>) created from information shared among the bine hubs <NUM>. Moreover, the parameters and/or methods for performing the content recovery are based at least in part on the heatmaps <NUM>.

In one example, the user can download different parts of the same content from different bine hubs <NUM> at different locations and different times. The end user device <NUM> can perform the recovery of the missing fragments <NUM> in content received from one bine hub (e.g., bine hub 302a) through another bine hub (e.g., bine hub 302b) at different locations. Also, end user devices <NUM> connecting to different bine hubs <NUM> can determine if missing fragments <NUM> are at the other bine hubs <NUM>.

Thus, the determination of whether and how to perform recovery can be based on different factors, such as time sensitivity, the number of missing fragments and what network interfaces are available. It should be noted that some content portions (e.g., missing content fragment <NUM>) may be missing from all sub-edge devices. In one example, an acknowledgement <NUM> is sent to a satellite provider <NUM>, which then communicates to one or more satellites <NUM> to send that missing content to all the sub-edge devices on the next orbit of the one or more satellites <NUM>. Alternatively, the acknowledgement <NUM> is sent to the satellite provider <NUM>, which then packages up the missing content <NUM> for transmission from another network (non-satellite network), such as a cellular network <NUM> (e.g., for <NUM> broadband transmission to the sub-edge devices).

In the above configuration, a multihoming system is defined. It should be noted that although the multihoming system is described in connection with cellular and satellite content delivery, other communication and data delivery networks can be used. Transmission in the multihoming system configuration can also be based on different factors, such as time and content sensitivity/priority. In some examples, weather is used as a factor, such as using predicted weather to determine time windows for content delivery, recovery, and download. For example. satellite signal strength can be estimated based on predicted weather conditions, such that high priority content is scheduled for delivery during higher signal strength conditions.

Variations and modifications are contemplated. In one example, the satellites <NUM> are low earth orbit (LEO) satellites, and the sub-edge devices have an antenna with a controllable motor to aim the antenna at one or more of the LEO satellites as they pass overhead. In another example, as signal strength varies, and using geographic location information for the sub-edge devices (e.g., cellular or GPS location information), the type or amount of content that is sent can be adjusted. In another example, the location of the sub-edge devices are known, and the content is prioritized, such that the most important or highest priority content is sent where signal strength is expected to be the best at the sub-edge devices.

Thus, as can be seen in the process <NUM> illustrated in <FIG>, the missing content fragment (Frag <NUM>) is recovered as a content fragment (Frag <NUM>) <NUM>, which can be transmitted from the bine hub 302a that recovered the missing content to the bine hub 302b as new content <NUM> in a recovery process. The new content <NUM> is stored with old content <NUM> (e.g., previously received content fragments <NUM>) in a local storage <NUM> of the bine hub 302b.

The content, including the recovered content, also can be accessed by the end user devices <NUM> from the bine hub 302a through the bine cloud <NUM> (e.g., after receiving a recovery complete notification, which is also communicated to the end user devices <NUM>) or through a local server <NUM> from the bine hub 302b.

Alternatively or in addition, the missing content, which becomes recovered content, in some examples, is communicated directly to the end user devices <NUM>. In some examples, depending on the priority of the content, etc., the missing content can be transmitted to the end user devices <NUM> by the one or more satellites <NUM> or the cellular network <NUM>.

In one example, a recovery zone <NUM> defines a group of sub-edge devices (e.g., bine hubs <NUM>) that participate in the recovery scheme described herein (see <FIG> illustrating content discovery and recovery scheme selection performed in one example). The recovery zone <NUM> in some examples is defined as a geographic area, an area defined by device latency, or an area defined by other factor to identify a group of bine hubs <NUM> that participate in the content recovery. For example, inclusion in the recovery zone <NUM> is defined by a latency among the sub-edge devices, or a latency among the end user devices <NUM>. Devices with latencies less than a defined or threshold amount (e.g., value) are part of the recovery zone <NUM>. This allows for the selection of bine hubs <NUM> to participate in the recovery. However, it should be appreciated that other factors or criteria can be used to define the recovery zone <NUM>. It should also be noted that the recovery zone <NUM> is dynamically configurable. That is, in some examples, the size of the recovery zone <NUM> dynamically changes, such as based on predicted weather and/or the actual weather being experienced (e.g., increase or decrease the composition or size of the recovery zone <NUM>, such as the number of bine hubs <NUM>). For example, the quantity of devices in the recovery zone <NUM> decreases during good weather.

The system in some examples also leverages weather predictions for arranging content recovery. For example, the system prioritizes the missing content, such that once the system knows the locations of the sub-edge device (or the end user devices <NUM>), and once an expected signal strength is known (e.g., based on weather, orbit, etc.), the most important/highest priority content that is missing is then sent to the sub-edge device (or the end user devices <NUM>) when the signal strength is expected to be the best.

As another example, if the content is a new popular TV series streamed by an MC, which is a PaaS client, depending on the user demand aggregated in the bine cloud <NUM>, the MC can store the TV series beforehand in the bine hubs <NUM>. If there is high user demand of the content across different geographic locations, in one example, the bine cloud <NUM> decides to use satellite broadcast for delivering the content to multiple bine hubs <NUM>, which reduces the bandwidth utilization and cost. After receiving the content, each bine hub <NUM> starts recovery if there are any errors during the reception. In one example, a first attempt is P2P recovery among the bine hubs <NUM>. Next, recovery is attempted from the cloud <NUM> using either the LBW connection <NUM> or the HBW connection <NUM> depending on the amount of recovery needed, or using other methods as described herein. After the recovery is completed, the recovered content is stored in the local storage of the bine hub <NUM> with an expiry date predicting the decreasing user demand over the time.

Once the content is stored, the bine cloud notifies the corresponding MC about the content availability in the bine hub <NUM>. The MC then notifies the end user in the corresponding region where the bine hubs <NUM> are deployed. The end user then can obtain the content downloaded/streamed to the end user device <NUM> of the user through the HBW connection <NUM> with the bine hub(s) <NUM>. As the content is locally stored in the bine hub(s) <NUM>, the content does not have to be obtained or fetched from the cloud <NUM> for the demand by different end users at different times, which in turn, increases the throughput, as well as the end user experience. It should be noted that in contrast to a router, the present disclosure stores the content in the bine hub <NUM>.

With respect to content recovery, <FIG> illustrates a content recovery scheme <NUM> in one example to recover missing content. In this example (and with continued reference to <FIG>), the plurality of heat maps <NUM> are used when performing content recovery, including to facilitate coordination of the recovery, as well as to define different recovery parameters, such as the creation and adjustment of the recovery zone <NUM>, the method of recovery, etc..

In the illustrated example, the bine cloud <NUM> creates or generates one or more heatmaps <NUM> of missing content at the bine hub level based on the information shared by the IINDs (illustrated as the bine hubs <NUM>). Different designations or indicators of the level of missing content are contemplated, such as when the heatmap is more red, more segments <NUM> of the content <NUM> is missing. As can be seen, the complete content <NUM> is divided into the multiple segments <NUM> (which correspond to the content fragments <NUM> in one example), and the heatmap <NUM> is created for each segment <NUM> of the content <NUM>. It should be noted that the smaller the size of the segment <NUM> (corresponding to the illustrated width of the segments <NUM>), the larger the overall heatmap <NUM>, which has more precise information. On the other hand, the larger heatmap <NUM> requires higher bandwidth while sharing the heatmap <NUM> with the bine hubs <NUM> from the cloud <NUM>.

A segment <NUM> can have multiple data chunks and the segments <NUM> can be of the same or different sizes (i.e., the amount of data in each segment <NUM> can be the same or different). It should be noted that a data chunk 'missed' from a segment <NUM> is considered as a missing segment (e.g., the missing content fragment <NUM>). The formula or determination for the content segmentation is defined in the bine hub <NUM> and the bine cloud <NUM>. In some examples, the heatmap <NUM> is created for popular content that was broadcast to multiple bine hubs <NUM> in a region, and as discussed herein, content is selected based on aggregated user demand.

In one particular example, the bine cloud <NUM> is configured to analyze one or more of the heatmaps <NUM> and select a recovery method based on the analysis, for example, whether to use satellite recovery or non-satellite recovery. If a defined number of bine hubs <NUM> (e.g. above a threshold amount) in a region is 'red' for a defined number of segments <NUM> (e.g., above a threshold amount, such as a significant number of segments), the recovery is performed using a satellite broadcast given the time sensitivity of the content and the period of satellite. For example, if a large number of bine hubs <NUM> in the region have red colored segments <NUM>, indicating a large amount of missing data, satellite recovery of the missing data is performed as discussed herein. Such a condition can occur, for example, when the weather is bad in a particular region during the satellite broadcast. As a result, there is greater likelihood that the bine hubs <NUM> in that region will miss multiple segments <NUM> of content from satellite broadcast. However, it should be noted that other factors may be determinative, such as the size of the region and the number of bine hubs <NUM> in the region. In some examples, the default selection is to first perform local recovery.

To perform content recovery in some examples, each bine cloud <NUM> shares the following information with one or more other bine hubs <NUM> after the decision making is completed using a reliable non-satellite network: satellite or local recovery for the bine hub <NUM>, and if local recovery is selected and/or recommended based on the analysis, the bine cloud <NUM> shares a heatmap dictionary <NUM> of missing content and timeout information for the local recovery. It should be noted that the bine cloud <NUM> does not share any recovery method related information with the bine hubs <NUM>, in some examples. With the above discussed information, local recovery can be performed in different ways.

In one example of local recovery, after receiving the heatmap dictionary <NUM> (identifying the missing content), which can also include instructions for local recovery, each bine hub <NUM> prepares for content sharing with other bine hubs <NUM> in the local network (e.g., within the recovery zone <NUM>). Depending on the availability of infrastructure, the local network can be, for example, a TVWS network, long-range WiFi network using directional antenna, and/or LAN over the ethernet.

From the heatmap dictionary <NUM>, each bine hub <NUM> is able to determine the missing segments <NUM> of the content <NUM> in other bine hubs <NUM> in the local network. It should be noted that the bine hub <NUM> does not send any requests to other bine hubs <NUM> in the local network for sharing the missing content because each bine hub <NUM> already has the heatmap dictionary <NUM>. If a bine hub <NUM> has the segments <NUM> that are missing in other bine hubs <NUM>, the bine hub <NUM> starts multicasting the segments <NUM> over the local network.

As another example of local recovery, content can flow at a multi-hop level in one or multiple local networks over one or multiple network interfaces. The bine hub <NUM> can be a part of multiple local networks. For example, in the case of a TVWS (or long-range Wi-Fi) network, the local network of the bine hub <NUM> is formed to include other bine hubs <NUM> within the antenna coverage of the bine hub <NUM>. In such case, the bine hub <NUM> can be connected to multiple local networks that can form a mesh network. Also, the bine hub <NUM> can be part of multiple distinct local networks over different network interfaces.

After receiving a missing segment <NUM> of the content <NUM> from one or more bine hubs <NUM> in the local network, the bine hub <NUM> checks whether there is another local network where the sender bine hub <NUM> is not present, and forwards the newly received part of the content <NUM> (e.g., one or more segments <NUM>) to that local network if any bine hub <NUM> has missed that part according to, or as determined from, the heatmap dictionary <NUM>. As part of recovering content from other bine hubs <NUM>, mobile applications (e.g. the applications <NUM> and <NUM>) that run on 'bine-edge' can also assist in content recovery. For example, when an end consumer application running the 'bine-edge' comes into proximity or the vicinity of the bine hub <NUM>, the end user device <NUM> running one or more of the mobile applications connects over the local bine hub network. Then, after an initial handshake between the bine hub <NUM> and the end user device <NUM>, the content availability and/or missing matrix (e.g., segments <NUM> still missing) is shared. If the end user device <NUM> has any data chunks of content that the bine hub <NUM> is missing (e.g., any of the still missing segments <NUM> of the content <NUM>), data transfer is initiated over the local network, such as Bluetooth, Wi-Fi or NFC, while the end user device <NUM> is still in proximity or vicinity to the bine hub <NUM> (such that communication is still possible). In one example, the bine hub <NUM> communicates these 'events' to the bine cloud <NUM>, which updates one or more corresponding heat maps <NUM> and the now transmitted missing segments <NUM> are made available for further distribution, such as to other bine hubs <NUM>.

In some examples, local recovery is expedited through global data injection. For example, during the local recovery, the bine cloud <NUM> also injects missing content to one or more selected bine hubs <NUM> over a non-satellite global network. In one particular example, based on the heatmap <NUM>, the bine cloud <NUM> selects one or more bine hubs <NUM> for injecting missing content (e.g., inserting the missing segments <NUM> into the rest of the content <NUM> to complete the content) directly from the cloud <NUM> which then can be shared with other bine hubs <NUM> over the local network. This implementation makes the local recovery faster, but at a cost of higher global bandwidth. Hence, in one example, the bine hub <NUM> attempts to optimize the global bandwidth utilization cost by minimizing the number of selected bine hubs <NUM> for missing content injection from the cloud <NUM> and maximizing the local connectivity coverage of the selected bine hubs <NUM>. In one example, the local connectivity coverage of the selected bine hubs <NUM> is measured based on the number of other bine hubs <NUM> to which the bine hub <NUM> is connected and that are missing one or more segments <NUM> of the content <NUM>.

It should be noted that post recovery, in some examples, after a recovery timeout period (e.g., a defined time period after the recovery operation is completed), the bine cloud <NUM> prepares one or more new heatmaps <NUM> aggregating the latest status of missing content from the bine hubs <NUM>. Based on the updated heatmap <NUM>, the bine cloud <NUM> then performs additional analysis or decision making as to whether further recovery is to be performed. If further recovery is to be performed, this recovery can be performed using satellite or non-satellite recovery methods as described herein. It should be noted that in some examples, time sensitivity of the content <NUM> gets the highest priority in a condition where further recovery is performed and followed by a number of the bine hubs <NUM> (e.g., above a threshold amount) still being 'red colored'. In the case of time sensitive content, the bine cloud <NUM> directly injects the content from the cloud <NUM> to the 'red' bine hubs <NUM> in some examples. In other examples, the bine cloud <NUM> can determine that another satellite or non-satellite (e.g., local or global network) recovery is to be performed after analyzing the updated heatmap <NUM> as discussed herein.

<FIG> is a flowchart of a method <NUM> illustrating operations of a computing device (e.g., the computing apparatus <NUM> illustrated in <FIG>) to deliver content to sub-edge devices using a context-aware device at the sub-edge coupled with both cloud and end user devices, and using a recovery process. For example, the method <NUM> controls the delivery of content and recovery of missing content using different types of communication means.

It should be appreciated that the computing device may be implemented in different systems and applications. Thus, while the below-described example can be used in connection with a satellite application, the computing device configured according to the present disclosure is useable, for example, in many different applications, including any application to provide content delivery to end user devices.

More particularly, and with respect to the operations performed by the method <NUM>, at <NUM> missing portions of received content delivered to a plurality of sub-edge devices (e.g., bine hubs <NUM>) are determined. For example, a determination is made as to missing content fragments from content transmitted by satellite to the plurality of sub-edge devices. It should be noted that a recovery zone defines which sub-edge devices perform recovery of missing portions of the received content, and the recovery zone is adjustable as described herein.

At <NUM>, the missing portions to recover are selected. For example, the specific missing fragments or groups of fragments of missing content are selected for recovery. In some examples, the missing fragments represent the content missing from all of the sub-edge devices That is, all the missing content is automatically selected for recovery is various examples.

At <NUM>, one of a satellite network or a non-satellite network is selected, based on at least one of a content priority and weather, to recover the selected one or more missing portions. It should be noted that other recovery factors can be used to determine which network to select for delivering the missing content (e.g., expected signal strength).

At <NUM>, the selected one or more missing portions from the selected one of the satellite network or the non-satellite network are downloaded to recover the selected one or more missing portions (e.g., inject or insert the one or more missing portions into the received content previously delivered to a plurality of sub-edge devices). The recovery is coordinated by a central cloud device communicating with the plurality of sub-edge devices. As described herein, many different factors can be used in the various steps of the recovery process. In one particular example, a weather condition, such a predicted weather or actual observer weather is used as a recovery factor by the central cloud service. The central cloud service then schedules delivery of the missing portions to the sub-edge devices.

The present disclosure is operable with a computing apparatus <NUM> according to an example as a functional block diagram <NUM> in <FIG>, such as a hub. In one example, components of the computing apparatus <NUM> may be implemented as a part of an electronic device according to one or more examples described in this disclosure. The computing apparatus <NUM> comprises one or more processors <NUM> which may be microprocessors, controllers, or any other suitable type of processors for processing computer executable instructions to control the operation of the computing apparatus <NUM>. Platform software comprising an operating system <NUM> or any other suitable platform software may be provided on the computing apparatus <NUM> to enable application software <NUM> to be executed on the computing apparatus <NUM>.

Computer executable instructions may be provided using any computer-readable media that are accessible by the computing apparatus <NUM>. Computer-readable media may include, for example, computer storage media such as a memory <NUM> and communications media. Computer storage media, such as the memory <NUM>, include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or the like. Computer storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing apparatus. In contrast, communication media may embody computer readable instructions, data structures, program modules, or the like in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media do not include communication media. Therefore, a computer storage medium should not be interpreted to be a propagating signal per se. Propagated signals per se are not examples of computer storage media. Although the computer storage medium (the memory <NUM>) is shown within the computing apparatus <NUM>, it will be appreciated by a person skilled in the art, that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using a communication module, such as a communication interface <NUM>).

The computing apparatus <NUM> in one example includes an input/output controller <NUM> configured to output information to one or more input devices <NUM> and output devices <NUM>, for example a display or a speaker, which may be separate from or integral to the electronic device. The input/output controller <NUM> in some examples is configured to receive and process an input from one or more input devices <NUM>, such as a control button or touchpad. In one example, the output device <NUM> acts as the input device <NUM>. An example of such a device may be a touch sensitive display. The input/output controller <NUM> in one example also outputs data to devices other than the output device <NUM>, e.g. a locally connected printing device. In some examples, a user provides input to the input device(s) <NUM> and/or receives output from the output device(s) <NUM>.

The functionality described herein can be performed, at least in part, by one or more hardware logic components. According to an example, the computing apparatus <NUM> is configured by the program code when executed by the processor(s) <NUM> to execute the example of the operations and functionality described. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs).

At least a portion of the functionality of the various elements in the figures may be performed by other elements in the figures, or an entity (e.g., processor, web service, server, application program, computing device, etc.) not shown in the figures. Additionally, in some aspects, the computing apparatus <NUM> is a hub configured to perform content delivery and recovery.

Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the disclosure include, but are not limited to, mobile or portable computing devices (e.g., smartphones), personal computers, server computers, hand-held (e.g., tablet) or laptop devices, multiprocessor systems, gaming consoles or controllers, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, mobile computing and/or communication devices in wearable or accessory form factors (e.g., watches, glasses, headsets, or earphones), network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. In general, the disclosure is operable with any device with processing capability such that it can execute instructions such as those described herein. Such systems or devices may accept input from the user in any way, including from input devices such as a keyboard or pointing device, via gesture input, proximity input (such as by hovering), and/or via voice input.

A system comprises a central cloud device and a plurality of sub-edge devices configured to receive content from one or more satellites. The plurality of sub-edge devices perform recovery of missing portions of the received content and are further configured to determine the missing portions of the received content, select one or more of the missing portions to recover based at least on one or more content specific metrics or network specific metrics, select, for each of the selected one or more missing portions, one of a satellite network or a non-satellite network, based on at least one of a content priority and weather, to recover each of the selected one or more missing portions, and inject into the received content the selected one or more missing portions from the selected one of the satellite network or the non-satellite network to recover the selected one or more missing portions, the recovery coordinated by the central cloud device communicating with the plurality of sub-edge devices.

A computerized method for content delivery comprises determining missing portions of received content delivered to a plurality of sub-edge devices and selecting one or more of the missing portions to recover based at least on one or more content specific metrics or network specific metrics. The computerized method further comprises selecting, for each of the selected one or more missing portions, one of a satellite network or a non-satellite network, based on at least one of a content priority and weather, to recover each of the selected one or more missing portions, and injecting into the received content the selected one or more missing portions from the selected one of the satellite network or the non-satellite network to recover the selected one or more missing portions, the recovery coordinated by a central cloud device communicating with the plurality of sub-edge devices.

One or more computer storage media have computer-executable instructions for content delivery, upon execution by a processor, cause the processor to at least determine missing portions of received content delivered to a plurality of sub-edge devices, select one or more of the missing portions to recover based at least on one or more content specific metrics or network specific metrics, select , for each of the selected one or more missing portions, one of a satellite network or a non-satellite network, based on at least one of a content priority and weather, to recover each of the selected one or more missing portions. The computer-executable instructions, upon execution by a processor, further cause the processor to inject into the received content the selected one or more missing portions from the selected one of the satellite network or the non-satellite network to recover the selected one or more missing portions, the recovery coordinated by a central cloud device communicating with the plurality of sub-edge devices.

It will be understood that the benefits and advantages described above may relate to one example or may relate to several examples. The examples are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.

The examples illustrated and described herein as well as examples not specifically described herein but within the scope of aspects of the claims constitute exemplary means for content delivery and recovery.

In some examples, the operations illustrated in the figures may be implemented as software instructions encoded on a computer readable medium, in hardware programmed or designed to perform the operations, or both. For example, aspects of the disclosure may be implemented as a system on a chip or other circuitry including a plurality of interconnected, electrically conductive elements.

Claim 1:
A system (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) comprising:
a central cloud device (<NUM>); and
a plurality of sub-edge devices (<NUM>, <NUM>) configured to receive content (<NUM>, <NUM>) from one or more satellites (<NUM>, <NUM>), the plurality of sub-edge devices (<NUM>, <NUM>) performing recovery of missing portions (<NUM>, <NUM>) of the received content (<NUM>, <NUM>) at least by:
determining the missing portions (<NUM>, <NUM>, <NUM>) of the received content (<NUM>, <NUM>),
selecting one or more of the missing portions (<NUM>, <NUM>, <NUM>) to recover based at least on one or more content specific metrics or network specific metrics (<NUM>, <NUM>, <NUM>, <NUM>),
receiving, from the central cloud device, a content priority for each of the selected one or more of the missing portions, the content priority being based on the received content and a heatmap of missing content created based on information shared by the plurality of sub-edge devices;
selecting, for each of the selected one or more missing portions (<NUM>, <NUM>, <NUM>), one of a satellite network (<NUM>) or a non-satellite network (<NUM>), based on the content priority, to recover each of the selected one or more missing portions (<NUM>), and
injecting, into the received content (<NUM>, <NUM>), the selected one or more missing portions (<NUM>) from the selected one of the satellite network (<NUM>) or the non-satellite network (<NUM>) to recover the selected one or more missing portions (<NUM>), the recovery coordinated by the central cloud device (<NUM>) communicating with the plurality of sub-edge devices (<NUM>, <NUM>);
wherein the content is divided into a plurality of segments and the heatmap is created for each segment of the content such that that if the number of sub-edge devices is above a predefined heatmap value threshold in a region for a defined number of missing segments, the recovery is performed using the satellite network given the time sensitivity of the content and the period of satellite.