Microcaching method and apparatus for mobile environments with variable connectivity

Abstract

To provide a content distribution over a network.SOLUTION: A system includes a plurality of micro-cache devices integrated within a corresponding plurality of mobile environments, an address manager that maintains an IP address pool according to IP address information received from a content provider and associates different portions of the address pool with different instances of the micro-cache devices and the corresponding mobile environments, and a local network manager coupled to each micro-cache device in each mobile environment that provides network connectivity to client devices in each mobile environment, and the content provider is provided with visibility of and control of access rights to each micro-cache by client devices in each mobile environment.SELECTED DRAWING: Figure 17

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of the following provisional patent application numbers: U.S. Provisional Patent Application No. 62 / 842,383, filed May 2, 2019; U.S. Provisional Patent Application No. 62 / 842,397, filed May 2, 2019; U.S. Provisional Patent Application No. 62 / 842,408, filed May 2, 2019; U.S. Provisional Patent Application No. 62 / 842,414, filed May 2, 2019; U.S. Provisional Patent Application No. 62 / 842,427, filed May 2, 2019; U.S. Provisional Patent Application No. 62 / 842,446, filed May 2, 2019; U.S. Provisional Patent Application No. 62 / 842,447, filed May 2, 2019; U.S. Provisional Patent Application No. 62 / 842,457, filed May 2, 2019.

[0002] This application is a partial continuation of the following co - pending patent applications assigned to the assignee of this application: U.S. Patent Application Publication No. 15 / 933,327, filed Mar. 22, 2018; U.S. Patent Application Publication No. 15 / 933,330, filed Mar. 22, 2018; U.S. Patent Application Publication No. 15 / 933,332, filed Mar. 22, 2018; U.S. Patent Application Publication No. 15 / 933,336, filed Mar. 22, 2018; U.S. Patent Application Publication No. 15 / 933,338, filed Mar. 22, 2018.

[0003] (Field of the Invention) Embodiments of the present invention generally relate to the field of content delivery over a network. More specifically, the embodiments relate to a micro - caching method and apparatus for a mobile environment having variable connectivity.

Background Art

[0004] Many businesses need to provide Wi-Fi to their customers in mobile environments. For example, many airlines, cruise ships, buses, and train systems provide Wi-Fi to passengers. However, given the variable connectivity and minimum bandwidth during transit in these mobile environments, meeting customer expectations is becoming increasingly difficult.

[0005] A typical household streams content across multiple devices at a rate of around 500GB / month. Consumers are beginning to expect the same level of network access while traveling, but this is difficult to achieve with current systems given the passenger numbers and low-bandwidth connectivity in these environments. A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings. [Brief explanation of the drawing]

[0006] [Figure 1A] One embodiment of the present invention is shown for securely and efficiently delivering media content to a mobile environment configured with a "strand" network. [Figure 1B] The present invention illustrates several embodiments for connecting a mobile edge device to one or more cache systems. [Figure 1C] The present invention illustrates several embodiments for connecting mobile edge devices to one or more caching systems. One embodiment of the present invention, including a capacitor and a content delivery network (CDN), is shown. [Figure 2] This includes additional features such as assigning Content Service Provider (CSP) addresses to mobile environments. [Figure 3] Additional features include the use of Internal Gateway Protocols (IGPs) and Border Gateway Protocols for managing network connectivity. [Figure 4] One embodiment is shown that includes an Internet Service Provider (ISP) cache for storing content service provider content. [Figure 5] Further details of one embodiment, including capacitors and CDN nodes, are shown. [Figure 6] One embodiment including a transparent cache (TIC) is shown. [Figure 7] This describes one embodiment in which a CSP cache stores content from various sources, including content providers. [Figure 8] Further details of one embodiment of this invention are shown below. [Figure 9] This shows the interaction between a capacitor and a TIC in one embodiment. [Figure 10] This document describes one embodiment for redirecting client requests to a local cache. [Figure 11] An exemplary embodiment is shown that has multiple antennas for providing content to the TIC (Train Information Center) on a train. [Figure 12] This document illustrates one embodiment of a hierarchical structure for propagating content. [Figure 13] This document presents one embodiment of an architecture for implementing a microcaching. [Figure 14] This document presents one embodiment of a microcaching architecture that includes dynamic address allocation in a local network. [Figure 15] This document illustrates one embodiment that uses predicted travel paths in a mobile environment. [Figure 16] This describes one embodiment that includes different connections to a local cache within a mobile environment. [Figure 17] This document presents one embodiment of an architecture for delivering content to a mobile environment. [Figure 18] This document presents one embodiment for managing cross-border content distribution. [Figure 19] This document illustrates one embodiment of a CDNE cache hierarchy and technology for monitoring cached content. [Figure 20] This describes one embodiment in which a shared ledger is used to authenticate cached data. [Figure 21]An embodiment in which content is collected from a strand network is shown. [Figure 22] An embodiment including a plurality of fixed edges and movable edges is shown. [Figure 23] An embodiment in which a CDN extender acquires video-on-demand data and distributes videos to a mobile environment cache is shown. **Embodiments for Carrying Out the Invention**

[0007] In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present invention described below. However, it will be apparent to those skilled in the art that the embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the fundamental principles of the embodiments of the present invention.

[0008] Embodiments of the present invention meet the expectations of end users who want to connect at any time, anywhere, in a remote location, and even while on the go where bandwidth has been conventionally limited. Specifically, intelligent caching techniques for hosting content in strategic locations will be described. In one embodiment, a cache and associated content delivery network (CDN) solve network congestion limitations by preloading content behind congestion points.

[0009] For existing caching and CDN technologies to operate properly, they require continuous high-speed connectivity, which is not available in mobile environments such as airplanes, trains, buses, and passenger ships. As a result, these businesses are increasingly in an unfavorable situation, and there is a growing cumulative demand for solutions within a very large market.

[0010] One embodiment of the present invention addresses the lack of available connectivity in a mobile environment by increasing existing connectivity by adding high-speed access points to strategic locations where the mobile environment is expected to be interrupted for either a deterministic or non-deterministic period. In one embodiment, the management of these dual networks is provided by an Internet Service Provider (ISP). However, this entity will be referred to herein as a Content Service Provider (CSP) with a focus on large datasets (e.g., video).

[0011] In one embodiment, the CSP manages each mobile environment as an interconnected subnetwork of the CSP's network collection. In one embodiment, this is achieved by defining IP subnetworks. Specifically, the mobile environment is configured as a routable IP subnetwork that can be reached via either a low-speed communication channel (e.g., a satellite link or cellular network connection available when the mobile environment is in motion) or a high-speed network (e.g., when the mobile environment reaches a strategically located high-speed link).

[0012] When a mobile environment passes through several locations with high-speed networks, in one embodiment, routing protocols such as Internal Gateway Protocol (IGP) are used to notify of the existence of a new route to a subnetwork. The lower-priority route is always available via the slower network.

[0013] The CSP deploys these high-speed networks in strategic locations known to be traversed by the mobile environment. Furthermore, the CSP can ensure that content is reliably transmitted to the mobile environment upon establishment of a high-speed connection. This can be achieved in numerous ways for various aspects of the present invention. Sufficient connectivity to edge locations, combined with high-speed connectivity, can be designed to enable timely data transfer. The data can be sent to the edge location and awaits further transfer to the mobile environment once a high-speed connection is established.

[0014] In one embodiment of the present invention, an existing Content Provider Cache (CPC) may be hosted centrally by a Content Provider Service Provider (CSP) in accordance with a request specified by the content provider. As an example, but not limited to, a Netflix Open Connect Appliance (OCA) may be installed and hosted by the CSP. When a mobile environment establishes a connection to a high-speed connection at one or more edges of the CSP network, another cache (e.g., another Netflix OCA) can initiate a scheduled peer fill from the central cache. The peer fill may be scheduled immediately or predictably.

[0015] In another embodiment of the present invention, an intermediate storage device, which may hereafter be referred to as a “capacitor” device, holds specified data for one or more mobile environments. A locally connected mobile environment includes a content delivery node (CDN) that downloads content from the capacitor when within range of a high-speed connection.

[0016] As will be discussed below, in certain situations, CDN nodes within a mobile environment upload content to a capacitor. For example, a particular capacitor configured in a remote location may not have a high-speed link to the CSP network. In such cases, when a mobile environment with a large number of CDN nodes comes into range (e.g., a cruise ship), the capacitor can retrieve as much data as possible from these CDN nodes and then provide that content to the CDN nodes in the mobile environment. This allows the mobile environment to easily distribute content across its entire network as a CSP mechanism, which is particularly beneficial for large datasets that take days or weeks to transmit.

[0017] In one embodiment, a CDN node mediates one or more cache types that may be associated with the mobile environment. Examples include Netflix OCA, Google Global Cache (GGC), transparent caches that work with content providers, or more traditional transparent caches that simply replicate traffic known to represent desired content. In all cases, the CDN node can propagate a local copy to the mobile environment in a predictable manner, with connectivity extracted from the cache. This enables scheduled cache refills from caches such as Netflix and Google, as well as from other more flexible mechanisms.

[0018] Capacitors in a CSP network host pooled content when quiescent. In one implementation of the present invention, this content may be owned by another party (e.g., Netflix) and requires visibility into where it is copied and distributed. For example, a specific content provider such as Netflix needs to know where all copies of the content are stored. Each copy delivered by the capacitor to a CDN node, and each CDN node delivered to a cache, may be recorded so that all storage locations are known and reported to the content provider. Furthermore, one embodiment provides a technique for purging content as needed (e.g., invalidating the cryptographic key used to decrypt the content). A. Embodiment of a Content Delivery Network Extender (CDNE)

[0019] Figure 1A shows a Content Delivery Network Extender 110 (hereinafter referred to as the "CDN Extender" or "CDNE") which includes circuitry and logic for providing content delivery support to the strand network 130. As used herein, the "strand network" 130 includes any form of local network (wired and / or wireless) where users 152 are concentrated for a particular period and which have limited backhaul connectivity to the Internet overlapping with these periods (e.g., inside a transport vehicle). The strand network 130 can extend from a WiFi network in a mobile environment such as a ferry, train, or airplane through any concentration of consumers and have WiFi / cellular connectivity and limited backhaul. The strand network 130 may be referred to as being located at the "edge" of the CDN Extender 110 network.

[0020] In one embodiment, the CDN extender 110 includes ingestion logic 111 for retrieving content from content channels 190 and / or one or more content delivery networks 101-102; analysis logic 112 for analyzing content usage and related data associated with the current context 120; transformation logic 185 for performing specified transformation operations on the content as described herein; and delivery logic 114 for intelligently pushing the original content and / or transformed content to local CDN extenders 135 on each strand network 130.

[0021] In one embodiment, the CDN extender 110, together with a plurality of local CDN extenders 135 configured within the strand network 130, enhances temporary loss of connectivity to high-speed access points located in strategic locations known to be entered by / passed through by the strand network 130, over either a deterministic or non-deterministic period.

[0022] Specifically, the CDN extender 110 evaluates the current context 120 associated with the content to be delivered (e.g., characteristics associated with the content), then ingests the available streams 111, applies analysis 112, and transforms them 185, and packages them for definitive delivery 114.

[0023] One embodiment of the CDN extender 110 includes an intelligent and efficient push delivery network that delivers content to a local CDN 135 based on characteristics associated with a strand network 130 and characteristics associated with the content to be delivered. Characteristics of the strand network may include, but are not limited to, the geographic location schedule of the strand network 130 (e.g., high-bandwidth connection points that the strand network 130 passes through in a given time), the capacity of the local storage device 142 on the local CDN 135, and how the local CDN 135 manages DNS mappings to IP addresses and their users 152 to implement the technology described herein.

[0024] In different embodiments, the local storage device 142 may be managed transparently and / or configured as an addressed cache. The IP addressing techniques described herein may be used to enable a content provider to determine the geographical location of the local storage device 142 and to direct traffic for a particular consumer / app to a particular CDN (including a CDN extender 110).

[0025] As shown in Figure 1A, content can be obtained via CDN partners 101-102 or directly from content channels (e.g., Netflix, Hulu) 105-106. In the illustrated embodiment, a bidirectional control channel 107 is established between the content channel 190 and the CDN extender 110, providing the content channel 190 with a high level of visibility into how its content is stored / used in the CDN extender storage device 115 and in local storage devices 142 on each strand network 130. In the other direction, the control channel 107 enables the CDN extender 110 to make content requests / queries based on its ongoing analysis and context 120.

[0026] As described above, in one embodiment, the ingestion logic 111 on the CDN extender 110 pulls / receives content through high-bandwidth connections to the content channels 190 and / or content distribution networks 101-102. In one embodiment, the ingestion logic 111 stores the content in the CDN extender storage device 115 and indexes the content as needed. The ingestion logic 111 creates a master content cache based on variables such as consumer feedback (e.g., from the strand network 130), content provider requests (e.g., as specified in the license agreement between the CDN extender operator and each content provider), schedules associated with the strand network 130, and analysis performed by the analysis logic 112. Depending on the embodiment, the CDN extender storage device 115 may contain part of the master content cache or all of the master content cache. For example, in a small embodiment, there may be a single CDN extender 110 with a single master CDN extender storage device 115. Alternatively, CDN extender 110 may be one of several CDN extenders linked together in a peer-based and / or hierarchical arrangement. In the latter case, the master content cache may be located at the top of the hierarchy, and individual CDN storage caches 115 of the various CDN extenders 110 pull from the master cache as needed and potentially share content among other peers (e.g., other CDN extenders) and various strand networks 130.

[0027] As described later, the analysis logic 112 may evaluate total demand across the entire edge / strand network and prioritize both content delivery and content retention based on that analysis. In one embodiment, the analysis logic 112 performs predictive / selective delivery based on a variety of data points, including, but not limited to, demographics, geography, destination, edge performance characteristics, and content requirements.

[0028] The conversion logic 185 may perform modifications to the content under limited circumstances. For example, for a highly popular title (e.g., identified by the analysis logic 112), the conversion logic 185 may generate one or more low-bitrate versions and have the distribution logic 114 distribute the low-bitrate versions to a network 130 having limited storage and / or bandwidth capabilities.

[0029] For live content 105, such as a championship game in soccer or baseball, the conversion logic 185 may reduce the resolution and / or frame rate of the original live stream to generate N low-bitrate versions that can be temporarily buffered on the CDNE storage device 115. A single stream (rather than a per-user stream) may then be sent to each strand network 130 to reduce bandwidth consumption.

[0030] The delivery logic 114 may then select one of N versions based on the capabilities and other variables associated with each strand network 130, or it may use the original live content 105. In one embodiment, the delivery logic 114 generates one or more individualized content package variations with a specific stream rate, and a customized user manifest to facilitate rapid delivery when the content reaches the strand network 130.

[0031] In various embodiments, the delivery logic 114 may operate according to schedules associated with live content and / or streaming content, schedules associated with each strand network 130, and / or policies associated with the streamed content (e.g., based on agreements with content owners or content providers). Some or all of the scheduling data may be determined / managed by the analysis logic 112 and passed to the delivery logic 114.

[0032] Various characteristics associated with the strand network 130 may be evaluated by the analysis logic 112 to control the transmission of content to the local CDN 135. These may include, for example, the volume size of the local storage device 142 (e.g., 1TB, 2TB, 5TB, etc.), static content utilization (e.g., selective prioritization, up to 100% static utilization which may be VoD), and adaptive utilization (e.g., utilization rate per content title which may be analysis-driven).

[0033] It should be noted that the terms “logic,” “module,” and “engine” are used interchangeably herein and refer to the various functional components shown in the figures (e.g., analysis logic 112). In one embodiment, these components are implemented by program code stored in memory, which is executed by a processor to perform the functions described. These functional components may also be implemented in hardware (e.g., application-specific circuits such as ASICs) or using any combination of hardware and software / firmware.

[0034] One embodiment of the present invention includes a system and apparatus for intelligently caching data based on a predictable schedule of a mobile transport environment. In this embodiment, content is ingested by a CDN extender, delivered to the mobile environment, managed on a remote cache, and then made transparently consumable by end-user applications.

[0035] Figure 1B shows an exemplary embodiment in which the CDN extender 110 operates as an Internet service provider for organizations such as train operations, air routes, bus operations, cruise / ferry operations, or any other operations including a strand network 130. In the specific embodiments described below, the strand network 130 is incorporated into a transport vehicle. However, it should be noted that the basic principles of the present invention can be implemented with any form of strand network 130.

[0036] In the illustrated example, the strand network is configured with mobile edge edges 185 that periodically connect to one or more fixed edges 184 via a high-speed network 161. Various different types of wireless communication devices, wired transceivers, protocols, servers, etc. 102, 103 may be used to form physical high-speed connections, including the 802.11 protocol (WiFi) and the Gigabit Ethernet protocol. When a transport vehicle reaches or passes through a stationary fixed edge 184, connectivity may be established using different technologies.

[0037] In one example, cache 155 connects directly to a transparent cache (TIC) 196 in a mobile environment via a fixed edge 184, a high-speed network 161, and a mobile edge 185. One embodiment relies on scheduled connectivity and sufficient connectivity to complete cache filling, which is defined by peer fill X=Y, as shown in Figure 1B.

[0038] Alternatively, or in addition, the third-party cache 157 peers with the connected third-party cache 115 via the fixed edge 184, the high-speed network 161, and the mobile edge 185. In this case as well, one embodiment completes the peered cache fill depending on scheduled connectivity and sufficient connectivity, which is defined by peer fill X = Y.

[0039] One embodiment includes a system and apparatus for temporally and spatially aggregating connectivity to a mobile cache. Specifically, this embodiment includes a strand network 130 in a mobile environment that can move non-deterministically. Local storage devices are connected to the strand network, and a new set of network management operations is performed to distribute IP addresses in the mobile environment to adapt to the demands of various content providers.

[0040] Figure 1C shows an exemplary embodiment in which connectivity is enhanced at both the capacitor 510 (located in a fixed location) and the CDN node 119 (in a mobile environment). In the illustrated embodiment, these devices manage the transient nature of the high-speed network 161 by pooling data within each device. In one embodiment, the high-speed network 161 may be significantly faster than the network connecting the capacitor 510 to the CSP network 152 via a fixed core 159. By storing cached data in the capacitor 510, the maximum speed available on the high-speed network 161 can be achieved a priori, and multiple mobile environments 150 can be updated simultaneously and / or sequentially from the same capacitor 510.

[0041] For example, in one scenario, a curated cache 155 sends its content to one or more capacitors 510 located in one or more locations. Then, as the mobile environment 150 approaches a particular fixed edge 184, the physical high-speed network 161 is established under the control of the fixed edge 184 and the mobile edge 185. The CDN node 119 establishes connectivity with the capacitors 510 and then downloads the content currently stored in the capacitors 510. In this embodiment, the CDN node 119 is responsible for managing incremental downloads. For example, the mobile environment 150 may be interrupted at two or more fixed edges 151 over a period of time. Each interruption may only facilitate partial data transfer. Once the full transfer to the CDN node 119 is complete, the TIC 196 receives a continuous peer fill from the CDN node 119. This can be defined by the equation incremental peer fill X = ΔY.

[0042] In one example, a third-party cache 157 peer-fills its content to one or more capacitors 510 located in multiple locations. Then, as the mobile environment 150 approaches a particular fixed edge 184, the physical high-speed network 161 is established under the control of the fixed edge 184 and the mobile edge 185. The CDN node 119 establishes connectivity with the capacitors 510 and then downloads the cached content stored in the capacitors 510. The CDN node 119 is responsible for managing incremental downloads (e.g., identifying content it does not have and requesting that content from the capacitors 510). For example, the mobile environment 150 may be interrupted at two or more fixed edges 151 over a period of time, each interruption only facilitating partial data transfers. Once the full transfer to the CDN node 119 is complete, the third-party cache 195 receives a continuous peer-fill from the CDN node 119, which again can be defined as an incremental peer-fill X = ΔY.

[0043] In one embodiment, a portion of the curated cache 155, identified as high priority, is referred to herein as the trend cache 205. In one embodiment, when the high-speed link 161 is unavailable (e.g., while moving through a mobile environment 150), cache filling from the trend cache 205 is possible via the slow network 160. For example, the data in the trend cache 205 may be the most popular / most requested data as determined by the CSP 152. In this embodiment, the fixed core 159 enables the content from the trend cache 205 to be routed via the slow network 160 to the mobile edge 185 and then to the CDN node 119. As described above, the slow network 160 may include (but is not limited to) mobile wireless technologies such as satellite, cellular (e.g., LTE), or long-range WiFi. From there, peer filling X=Y to the TIC 196 and / or third-party cache 195 is completed.

[0044] As mentioned above, in some cases, the capacitor 510 may not have a high-speed connection to the fixed core 159. For example, the capacitor 510 may be configured in a relatively isolated location where a mobile environment 150 is expected to pass through (e.g., along a train or ferry route) according to either a deterministic or non-deterministic schedule. In this case, the connected CDN node 119 may be configured to upload specific cached content to the capacitor 510 via the mobile edge 185, the high-speed network 161, and the fixed edge 184. In one embodiment, this is achieved by the capacitor 510 and the CDN node 119 exchanging messages that identify cached content stored in the CDN node 119 but not yet stored in the capacitor 510. The capacitor 510 may then request such content from the CDN node 119 in priority order based on the popularity, i.e., the "most frequently requested" value, potentially associated with each item of content within the CDN node 119. Thus, various mobile environments 150 become the distribution network for the fixed edge 184, and vice versa. In other words, each mobile environment 150 provides new data when it passes through the capacitor 510, and the capacitor 510 may provide content to mobile environments that do not currently have specific content.

[0045] In one embodiment, the mobile environment 150 is an addressable extension of the CSP 152. For each established high-speed network 161 that the mobile environment 150 encounters, reachability must be achieved by ensuring network connectivity. The fixed core 159 provides policy routing to either the low-speed network 160 (i.e., through the fixed edge 184) or the high-speed network 161. When the high-speed network 161 is established, the mobile edge 185 communicates back to the connected and accessible fixed core 159. In one embodiment, this is achieved by a network router 201 that issues an Internal Gateway Protocol (IGP) update to a router 200 directly associated with the fixed core 159. For example, the router 201 in the mobile environment may provide the router 200 with TCP / IP data (e.g., a new TCP / IP address) that the router 200 can use to establish a connection to the router 201.

[0046] One embodiment of the present invention includes a system and apparatus for propagating content across a network using a mobile environment. One embodiment leverages a mobile environment to move data across a distribution network. For example, a train picking up new data from one station may distribute this new data to other stations. B. Content propagation through mobile environments

[0047] As shown in Figure 2, a content service provider 152 may be allocated a large IP address pool 202, some of which may be allocated to various mobile environments 150 (e.g., trains, ships, buses, airplanes). As mentioned above, this can be achieved by defining a different subnetwork for each mobile environment 150 and allocating all IP addresses within that subnetwork to the mobile environment.

[0048] In one embodiment, Border Gateway Protocol (BGP) may be used to exchange routing and reachability information between different network components. For example, in Figure 2, a BGP peering connection 203 is used to share IP addresses and locations with content providers (e.g., Netflix, Google, Amazon, etc.) that request location information regarding IP addresses within a mobile environment 150.

[0049] Figure 3 highlights how IP addresses within the mobile environment 150 can establish a routable connection to the CSP 152, even when moving from the first high-speed network 161 to the second high-speed network 311. Specifically, the IGP router 302 recognizes that the high-speed network 311 has been established and propagates its local subnetwork information to the IGP router 301 in the CSP network 152. The CSP 152 may then use the updated IGP router 301 to route packets to the mobile environment 150. Note that before the establishment of the high-speed network 311 (for example, while the mobile environment 150 is moving), IP addresses can still be routed through the slow network 160.

[0050] Figure 4 shows an example of content cache management in this environment. In this example, a specific third-party cache 410 is located within the mobile environment 150 and is part of a CSP subnetwork (i.e., has an IP address range assigned by the CSP). In one embodiment, CSP 152 identifies a range of subnetwork addresses adjacent to the third-party content provider 401 via a BGP peering link 203. CSP 152 also places the third-party cache 402 within CSP 152 to operate as an ISP cache 402. In this embodiment, all updates from the third-party content provider 401 are made directly to the ISP cache 402 via the CSP network gateway. The third-party mobile cache 410 is then updated from the ISP cache 402 via the high-speed network 161 in the event of scheduled or unscheduled peer fills or other events.

[0051] In one embodiment, a request to access content from a user device within the mobile environment 150 may first be routed to the content provider 401 via the low-speed network 160. As a result of the BGP peering connection 203 providing network connectivity information to the content provider 401 as described above, the content provider 410 redirects the user device to the mobile cache 410 (assuming it contains a copy of the requested content). The redirection by the content provider also requires that the user be authenticated by the content provider 401 and authorized to render the requested content. In one embodiment, following authentication, the content provider 401 performs a lookup of the user's location (e.g., using BGP peering data) and refers to the association of the user's IP address with the mobile cache 410 (located in the same subnetwork). Subsequent communication may then be directed to the mobile cache 410.

[0052] Figure 5 shows further details of one embodiment including capacitors 510 and CDN nodes 520 (operating, for example, as generally described with respect to Figure 1B). In the illustrated embodiment, network fill of content provider 401 is pushed to one or more ISP caches 402. The ISP caches 402 then perform scheduled peer fills for each capacitor 510 at the fixed edge 184. Once the high-speed network 161 is established at a specific location (e.g., train / airport / bus / ship terminal), capacitors 510 form a connection with CDN nodes 520 and provide content to CDN nodes 520 via the high-speed link 161. As described above, capacitors 510 may send a list of available content to CDN nodes 520, which may compare this list with its existing content. It may then request all (or a subset) of content that is not currently cached locally. Alternatively, the CDN node 520 may send a list of its content to the capacitor, which may perform filtering operations to identify the content required by the CDN node 520. In either case, the list of content required by the CDN node 520 may be prioritized based on variables such as popularity and content size. This ensures that the content most likely to be required within the mobile environment 150 is transferred from the capacitor 510 to the CDN node 520 (i.e., when the high-speed network 161 is only available for a limited time).

[0053] Furthermore, as described above, if the capacitor 510 has a relatively low-bandwidth link back to the ISP cache 402 and / or content provider 401 (for example, if the capacitor is in a remote location), a reverse fill operation may be performed. In such a case, for example, if a CDN node 520 on a cruise ship forms a high-speed connection with the capacitor 510, a reverse fill operation may be performed during the connection period to provide content to the capacitor. The capacitor 510 may then provide this content to other CDN nodes in other mobile environments 150.

[0054] Figure 6 shows another embodiment utilizing the transparent cache 610. One advantage of the transparent cache 610 is that it can be configured as a complex of multiple caches from several different content providers 401, 601. The additional content providers 601 may interact with the system in the same way as described above for content provider 401 (e.g., performing network fill operations on the ISP cache 602). This embodiment addresses the issue of a market that is not of a suitable size for a mobile environment 150 to guarantee a full third-party / content provider cache. For example, the OCA cache from Netflix supports streaming traffic as high as 80 Gbps, which is excessive for a bus or airplane environment. Furthermore, content providers such as Netflix may not deploy such devices in a mobile environment with fewer than 100 or even 500 users.

[0055] In embodiments where the content of ISP caches 402, 602 is trusted and can be hosted on a transparent cache (TIC) 610, the TIC 610 may have a complete representation of the ISP caches 402, 602. "Authorized peer fill" refers to the ability of ISP caches 402, 602 to share their content with the TIC 610. Capacitors 510, the high-speed network 161, and the CDN node 520 operate as described above to deliver the content. The TIC 610 in this embodiment more easily identifies requests to be intercepted. For example, when a user in a mobile environment 150 requests content from a third-party content provider 401, 601 (e.g., Netflix), the request is made to the content providers 401, 601 via the internet 200. The content providers return references to their ISP caches 402, 602, respectively, rather than the content physically located within the mobile environment 150. In this embodiment, IP addresses within the mobile environment 150 are not distinguished. The BGP peering connection 203 advertises all addresses of CSP152, including content providers 401 and 601, to the internet. Furthermore, the nearest caches are ISP caches 402 and 602. Therefore, user devices attempt to connect to ISP caches 402 and 602, and transparent cache 610 only needs to know this destination address, securely intercept and redirect this request, and serve the content from a local copy.

[0056] In the embodiment shown in Figure 7, the curated CSP cache 710 stores data from multiple content providers 401, 601 according to a cache fill policy. The cache is curated to the extent that a specific set of rules / policies is used to determine which content to store. For example, to make caching decisions, data 702 such as cache miss data and popularity data may be collected from each of the field-placed transparent caches 610. In addition, data 701 may be collected from honeypots configured in strategic network locations on the internet and designed to observe user behavior. Other variables may be factored into a caching policy that includes, but is not limited to, customer requests (e.g., requests from content providers 410, 610 to cache specific items of content). C. Transparent Cache Embodiment

[0057] One embodiment of the present invention includes a transparent caching system and method for transparently caching multimedia content from multiple content providers. This embodiment performs content caching from multiple content providers and delivers the content to a mobile environment 150 as a single solution.

[0058] Figure 8 shows one embodiment in which a cache centralized management controller 850, managed by CSP152, makes decisions regarding specific content to store from each of the content providers 401, 601 (e.g., based on cache miss variables, content provider preferences, and / or other variables described above). In addition, the cache management controller 850 determines when and how to fill content for each of the capacitors 510 based on a specified cache management policy 870. For example, the cache management policy 870 may specify a particular rate at which the local cache 815 is filled, and / or a particular period during which local cache filling is performed (e.g., midnight when bandwidth is available). The cache fill policy 870 may be specified by user requests and / or feedback from content providers 401, 601 (e.g., Netflix). For example, if a particular video is frequently viewed by a user, the cache fill policy 870 may specify that the cache management controller 850 should fill all local caches 115, 175 with this particular video.

[0059] In one embodiment, one or more content provider caches 140, 160 periodically (e.g., nightly) fill one or more CSP caches 710 with specified content. This may be done, for example, for the most popular multimedia content (e.g., the most popular movies and TV shows). The cache management controller 850 then fills the local caches 815 at various capacitors 510 via communication with the corresponding local cache managers 812. In one embodiment, each local cache manager 812 may implement its own local cache policy 870 to fill the respective TIC 825 with content in order to establish communication with the TIC administrators 822 of different transport vessels / vehicles 820. In one embodiment, interfaces 828, 818 include a high-speed wired or wireless link (as described above with respect to the high-speed network 161) operating at maximum capacity (e.g., 30 GB / s, 100 GB / s, etc.) as soon as the transport vessels / vehicles 820 arrive at or pass through the capacitors 510. For example, but not limited to, the stationary content distribution locations in which the capacitor 510 is configured may be railway stations, bus terminals, cruise ship ports / terminals, or airport terminals / gates. In addition, in the specific embodiments described herein, the capacitor 510 is strategically positioned along known routes that various transport vessels / vehicles 820 will travel.

[0060] In one embodiment, a user device 827 on a passenger transport vessel / vehicle 820 first establishes a local wireless connection with a connection manager 823 on the passenger transport vessel / vehicle 820 (e.g., on an airplane, on a train, etc.). Once connected, the user device 827 may request content from content providers 401, 601, for example, by logging into Netflix and attempting to stream a particular movie. If a connection via the Internet 200 is available, the content providers 401, 601 receive the request, identify the user device 827 as operating within the content distribution network of the content service provider 152 (for example, by identifying this based on the dynamic network address assigned to the user device 827), and send a redirect message instructing the user device 827 to connect to the CSP cache 710 (e.g., the Netflix OCA cache). When attempting to access content from the CSP cache 710, the connection manager 823 and / or TIC manager 822 may determine that the requested content is locally cached in the TIC 810 and redirect the request to the TIC 810.

[0061] Next, the user device 827 streams content from the TIC 810 via a local wireless connection provided by the connection manager 823 (e.g., a local WiFi connection). Therefore, even if the passenger transport vessel / vehicle 820 is outside the range of the internet 200 (e.g., a cruise ship at sea, a train traveling through mountainous areas, etc.), the user device 827 can still access authorized content locally. Alternatively, if the internet connection 200 is available, only the initial user request and / or user authentication may be transmitted via this link (a relatively low-bandwidth transaction), while the content is streamed from the local TIC 810.

[0062] It should be noted that the above-mentioned TIC610 may include any or all of the components shown in Figure 8, including the TIC manager 822, the physical TIC cache 810, and potentially the connection manager 823 and the high-speed interface 828.

[0063] Some embodiments of the present invention include systems and devices for realizing a high-speed link between a mobile cache and an edge cache, which establish a secondary connection between the mobile cache and the edge cache, potentially using different communication protocols and / or technologies. D. Implementing high-speed links to mobile environments

[0064] Figure 9 shows a configuration in which multiple transparent caches (TICs) 610 configured within different types of transport vessels / vehicles are periodically updated via a high-speed network link 161 established with multiple capacitors 510. As described above, the content service provider 152 fills the cache at each of the capacitors 510 according to the cache fill policy 870. For example, the cache management controller 850 may distribute content in response to content usage data received from the content provider and / or from individual TICs 610. In this embodiment, the TICs 610 may monitor content usage throughout the day and report usage statistics to the cache management controller 850. The cache management controller 850 may then uniquely tailor the content for the location of individual capacitors and / or individual TICs.

[0065] As described above, the content service provider 152 may deploy high-speed networks and capacitors 510 in numerous strategic locations for its customers and / or specific industries. Each of the capacitors 510 is updated from the cache centralized management controller 850 via the cache distribution network, as described above. It is important that all of the relevant capacitors 510 have consistent data, and therefore each vessel / vehicle 820 can consistently request data at any time when connected.

[0066] In one embodiment, the various TIC components described above are deployed on the transport vessel / vehicle 820 as a network appliance comprising memory for storing program code and data, a processor for executing the program code and processing the data, and a mass storage device for running the TIC storage device, such as one or more hard drive sets. One or more other network interfaces may also be included and used while the vessel / vehicle 820 is in motion (e.g., satellite services, cellular services, long-range WiFi, etc.). The appliance may have various shapes, sizes, and capabilities. Since the goal is to have a common cache database for all appliances, storage performance may vary significantly from deployment to deployment (for example, $1,000 per 30TB storage array may be sufficient for 50 streaming sessions, but $10,000 / 30TB storage array may be required for 1,000 streaming sessions).

[0067] In one embodiment, the appliance may be located within one or more physical components. In one extreme example, the appliance is a single server, and in another example, the appliance is a rack of servers. This is because the core functions of the TIC may be distinguished as a) management functions, b) cache storage management, c) packet interception / packet flow redirection, and d) service provision (via redirection) for video requests from clients. As a result, the entire functionality may be contained within a single server, or each function may be separated / expanded by one or more servers. The basic principles of the present invention are not limited to any particular configuration.

[0068] Figure 10 provides an overview of an exemplary transaction via one embodiment of the connection manager 823 of the TIC610. The random detection terminal access point (TAP) 1010 monitors packets / flows on the network, and after some analysis, a positive search in the cache triggers a redirect (1003). The client then requests content again from the local redirect HTTP server 1020, which provides content from the local TIC610. In one embodiment, the connection manager 823 monitors out-of-band high-speed connectivity via interface 828 and then downloads cache updates whenever and wherever possible.

[0069] One requirement for the TIC is that it be part of the management service. Ideally, the customer simply plugs in and turns on the TIC. As a result, one embodiment of the system handles all operational elements autonomously via a centralized management component 895. For example, with each installation, it may connect to the centralized management component 895, which provides numerous provisioning functions for the new installation. In one embodiment, the management component 895 uses the Linux® command line, and further services are invoked and added as needed.

[0070] Some exemplary functions of the centralized management component 895 include software updates, notifications to network users and / or customers, status monitoring including reporting functions on CPU, memory, storage, and network usage, and LAN management tools for determining the number of devices in the stream and how the LAN is running (for example, to identify bottlenecks).

[0071] Referring again to Figure 10, one embodiment of the random detection TAP 1010 uses an Ethernet port running in random detection mode. In this embodiment, access to an Ethernet LAN segment is provided, through which all traffic traverses. The random detection TAP 1010 listens to all traffic, but traffic not associated with relevant web requests is allowed to pass through.

[0072] In one embodiment, the random detection TAP1010 uses the Data Plane Development Kit (DPDK) library for managing packets to perform functions such as distinguishing flows, timestamps, and maintaining packet order using a 5-Tuple Hash, and supports hardware assistance. In this embodiment, packets read from the random detection port are classified, timestamped, and either dropped or scheduled in a FIFO for processing. A multithreaded architecture may be used.

[0073] In one embodiment, once the hashed stream is identified, the URI is extracted and checked against the TIC database. If a match is found, both the source and destination points of the stream are reset using FIN packets. However, first, the source of the request sends an HTTP 1003 that is redirected to the appliance. Load balancing may also be performed. The redirection may, for example, implement round-robin load balancing, or a single interface may be managed by a load balancer, with multiple servers load balancing behind it.

[0074] In one embodiment, an efficient "cache information base" (CIB) is maintained by mirroring the actual TIC database, enabling efficient determination of whether a requested entry exists locally. Once the TIC is loaded onto the appliance, various functions need to quickly retrieve content. In one embodiment, packets destined for the appliance (e.g., management and redirected cache hits) are forwarded to the management function or the TIC. These are essentially ignored by the random detection TAP1010.

[0075] Assuming wireless technology is used for high-speed link 161, a standard MIMO implementation with an 80GHz bandwidth achieves 655Mbps. 4X MIMO can achieve 2.4Gbps. 24GHz and 60GHz wireless devices can also be considered. Products exist with wireless devices achieving 2.4Gbps in the 24GHz spectrum and 6-10Gbps in the 60GHz bandwidth. In all cases, link aggregation may be used to combine multiple wireless connections (utilizing GPS synchronization, frequency spacing, and signal isolation) to increase this number. It is conceivable that this could provide throughput in the range of 10-50Gbps.

[0076] As shown in Figure 11, in one embodiment, each stationary content distribution location, such as a railway station, airport terminal, bus terminal, or cruise ship terminal, has multiple antennas 1101-1105 aligned with the ships / vehicles entering the station / terminal. One or more capacitors 815 are connected to the multiple antennas 1101-1105 via a LAG switch. The multiple antennas simultaneously transmit content from the local capacitors 815 via multiple links, potentially achieving N times the bitrate of a single wireless link (where N is the number of antennas).

[0077] A train embodiment is shown in Figure 11, but similar configurations may be made for ships, planes, and buses. Certain embodiments may not be able to achieve the same connectivity aggregation (e.g., supporting only one wireless connection). Nevertheless, 2.5 Gb / s may be achieved for a single-antenna solution, which should be sufficient if the ship / vehicle remains stationary at this location for a sufficient period of time. In any case, partial updates to the TIC may occur each time the vehicle / ship stops near or passes another capacitor (e.g., at each railway station).

[0078] As shown in Figure 12, one embodiment includes one or more distribution gateways 1200-1203, which are repositories of content pushed to capacitors 1201-1203. Each distribution gateway (DG) 1200 may be located locally (e.g., West Coast, East Coast, Midwest). When capacitors 1201-1203 are initialized, they attempt to register with the nearest DG (e.g., West DG if located in California). These local DGs may be identified via DNS scoping (e.g., capacitor 1201 may connect to a Vancouver-based DG versus a New York DG due to its proximity).

[0079] In one embodiment, the DG may simply be an API to a CDN network such as CloudFront or Akamai. Ultimately, each DG is provided with data from the CSP cache 710 that capacitors 1201-1203 request / push. Given the size of the cache dataset, content can be streamed through the cache hierarchy using efficiencies such as multicast.

[0080] In one embodiment, all capacitors 1201-1203 in the field are registered with DG1200. When including some exchanged datasets, it is necessary to determine which data needs to be sent to specific capacitors 1201-1203. When new data is curated in the CSP cache 710, each DG1200 initiates the transfer to its registered capacitors 1201-1203. This may be performed as a push or pull transaction (or both). Scheduling requirements for each capacitor 1201-1203 may play a role in a particular push / pull configuration. In one embodiment, capacitors 1201-1203 are notified when new content is available and then need to request the data.

[0081] In one embodiment, each capacitor 1201-1203 is a server with sufficient storage to hold multiple cache datasets (or a single master cache dataset from which nearly derived datasets may be created). The primary purpose of capacitors 1201-1203 is to have as much data as possible at the high-speed network edge. This may receive requests from a single or concurrent CDN node 1220-1230 (and / or TIC) and fill available pipes.

[0082] When CDN nodes 1220-1230 (and / or TIC) connect to capacitors 1201-1203, the CDN nodes identify themselves and request the latest updates to the itinerary. CDN nodes may identify themselves based on, for example, vehicle / ship, customer ID, etc. Based on this, capacitors 1201-1203 provide CDN nodes 1220-1230 with an appropriate itinerary specific to their device. The CDN nodes then evaluate the itinerary and compare it to what they are currently downloading and what still needs to be downloaded. They then request specific elements from capacitors 1201-1203.

[0083] In one embodiment, capacitors 1201-1203 include at least 30TB of storage with a read speed of at least 10Gbps, preferably 50Gbps. The internet interface has a minimum connection of 1Gbps, but the actual internet connection should be at least 100Mbps. The high-speed network interface needs to be at least 10Gbps, preferably 40Gbps (4 x 10Gbps or 1 x 40Gbps). These interfaces connect to the single link aggregated high-speed link or an array thereof described above. In addition, capacitors 1201-1203 may initiate connections back to a centralized management component 895 for management purposes. In one embodiment, the centralized management component 895 supports operation, management, maintenance, and provisioning (OAMP) functions.

[0084] In one embodiment, each capacitor 1201-1203 may declare its inventory assets, provisioning location, etc., and request identification information of all expected customers and / or corresponding CDN nodes that may be adjacent to capacitors 1201-1203. For example, in one embodiment, a centralized management component 895 maintains an account database 1240 that identifies all CDN nodes / TICs and associated customers, as well as the relationship between these CDN nodes / TICs / customers and one or more capacitors 1201-1203.

[0085] In one embodiment, if an unexpected CDN node / TIC attempts to register with capacitors 1201-1203, an error is reported to a centralized management component 895, which has the ability to approve or reject the CDN node / TIC. If approved, capacitors 1201-1203 record this action and always accept it (e.g., no reprovisioning is required).

[0086] Based on all known customers / CDN nodes / TICs adjacent to capacitors 1201-1203, the capacitors may request a current list of itineraries and cache datasets (individual or master), as well as any other customer-related information. Capacitors 1201-1203 may also register update notifications so that if the centralized management component 895 and / or curated cache contains new information, it can be pushed to all capacitors 1201-1203 as needed. In one embodiment, scheduling may also be employed so that when a capacitor receives a notification, it does not operate until a specified time (e.g., 2 a.m.). In one embodiment, a proxy device may be configured to mimic the presence of a CDN node / TIC and adjust the capacitors as if they were connected in a standard operating mode.

[0087] Capacitors 1201-1203 await registration requests from high-speed networks (e.g., for arriving ships, buses, trains, or airplanes). Once a request is received and authenticated, a download service is initiated to the remote CDN node / TIC to download the new content. Essentially, once authorized, the download can be performed in a manner similar to an FTP service. The structure of the cache dataset should be considered as a set of tuples and blocks of tuples. The CDN node / TIC is aware of what has been received elsewhere and is responsible for maintaining continuity between download sessions. In this embodiment, capacitors 1201-1203 may simply be responsible for creating tuple sets that the CDN node / TIC can use.

[0088] Capacitors 1201-1203 should be able to handle two or more TICs at once. Clearly different capacitor configurations have different constraints in terms of simultaneous download sessions. The main constraint is the available network capacity. In scenarios where many CDN nodes / TICs can make simultaneous requests, a rack of servers connected to a single storage array and high-capacity switches may be used, with each server supporting two or three download sessions. Overall, the rack can handle several hundred sessions.

[0089] In one embodiment, a point-to-point / multipoint high-speed network is used. Vehicles / ships may connect to point-to-point or multipoint radio equipment. The key difference between these is that large datasets are transmitted between two points. If two or more vehicles / ships connect to the same access point, the total throughput simply decreases. As in the example above, the maximum transfer speed is approximately 10 hours for 10 TB. This doubles with two simultaneous transfers.

[0090] In one embodiment, the wireless device initially connects based on a known SSID and WPA2 / PSK. Once the vehicle / ship station is within range, a wireless link is established. In one embodiment, the vehicle / ship station is configured as a DHCP client. The access point or capacitor behind the access point provides a DHCP server. Within the server, a common DNS entry is configured. For example, "capacitor.netskrt.io" resolves to a local IP address.

[0091] In one embodiment, the CDN node / TIC610 may continuously poll capacitor 510 regardless of the state of the high-speed link (for example, if capacitor 510 on a particular port can be polled and therefore must be connected), or the TIC may make an API call to the local radio equipment to determine whether / when the link exists. The advantage of the latter solution is more deterministic behavior versus timeout, which can be linked to a variety of reasons. The disadvantage is that a hardware abstraction layer may be required to deal with changing technologies. Once a connection to capacitor 510 is established, the TIC610 proceeds with the cache update process described above. Of course, the basic principles of the present invention are not limited to any particular method by which the connection between the capacitor and the TIC is made.

[0092] The point-to-point array high-speed network exists for an array of wireless connections linked together between the ship / vehicle and the terminal where the capacitor 510 resides (as described above with respect to Figure 5). The advantage of this approach is that 10 or 20 high-speed connections can be established. If each connection achieves 2.5 Gbps, this will generate 25-50 Gbps high-speed links. From a theoretical standpoint, depending on the number of elements in the array, a 10 TB cache dataset 725 can be transmitted in about 30-60 minutes, or a 30 TB cache dataset 725 in 2-4 hours.

[0093] This solution will work particularly well on "long" vessels / vehicles such as ships and trains. Shorter vessels / vehicles may not adequately isolate the radio equipment from each other to allow for multiple connections that do not interfere with each other at a wireless level.

[0094] The array concept requires a series of radio devices positioned on the side of a vessel / vehicle. Therefore, in one embodiment, the radio devices are arranged at regular intervals at the terminal. Thus, when a train or vessel enters a dock, it will align vertically with the corresponding radio device. Sectors of 30-45 degrees may be suitable to allow some play (for example, a deviation of several tens of degrees is ideal, but this can still be captured by the width of the corresponding radio).

[0095] If each wireless device has the same SSID but only supports point-to-point connections, once connected, subsequent wireless devices will need to connect to a different available SSID. This works well when the vehicle / ship is stopped and then its wireless device is turned on. However, if the wireless device is connected and the vehicle / ship stops, it may result in a suboptimal wireless device while maintaining the connection.

[0096] For example, if a ship has radios s1, s2, s3, s4, and s5, and the ship enters a port, radio s1 establishes a connection to the corresponding port radio p5. As it moves forward, it loses this association and connects to p4, p3, and p2. Finally, when it comes to a standstill, s1 may not shift, resulting in suboptimal connections of s1-p2, s2-p3, s3-p4, and s4-p5. s5 or p1 will not connect. One solution is for each radio to have a predetermined SSID mate such that both s1 and p1 have "Netskrt-1" as their paired SSID.

[0097] In one embodiment, the management component 895 is used to place the capacitor 510. When the capacitor 510 is activated, it registers itself with the management component 895, which then adds the capacitor 510 to the database 640 and begins monitoring its status. When a customer logs into the portal 741, they will see the presence of the capacitor 510 and its current status.

[0098] Updates may be pushed to the capacitor 510 via the management component 895, which may also provide various capabilities, monitor the installed high-speed network, and perform other standard OAMP functions. The management component 895 identifies all known cache datasets suitable for the capacitor 510. Furthermore, the management component may schedule the capacitor 510, which may be specified via the operator portal 740 and / or the customer portal 741.

[0099] In one embodiment, the management component 895 is used to deploy a new CDN node / TIC610. When the CDN node / TIC610 is started, it registers itself with the management component 895, which then adds the CDN node / TIC610 to the database 640 and begins monitoring its status, cache content, and connection status. The CDN node / TIC610 may be provisioned to be in monitoring mode or as an active cache. The management component 895 can push cache provisioning updates to the appropriate capacitor 510, which, once within range, triggers an action on the target CDN node / TIC610.

[0100] In one embodiment, the CDN node / TIC 610 is configured to have a GPS location that is periodically reported to the management component 895. In one embodiment, the system operator and / or customer can track the location of the CDN node / TIC. Each CDN node / TIC 610 may also periodically report its operational status, including data such as cache hits, misses, and monitoring status. These updates may be reported via the capacitor 510.

[0101] New cache datasets may be generated periodically. At the scheduled time, each customer cache update is scheduled and sent to the appropriate capacitor 510. The mechanism for packaging cache datasets is currently considered to be a single master cache dataset, each with a journey associated with each customer / CDN node / TIC. Customers can log in via a web portal and enhance the management policies 870 associated with their journeys. For example, customers may select content specific to their geography, language, or delivery stream.

[0102] As described above, trend caching is a special type of push operation that can be performed over slow network links. This cache is automatically generated based on specifications from either the customer or another source (e.g., the content provider itself). Constraints may be placed on the cache dataset size. Scheduling data may also be required for its delivery and can be configured by the customer via the customer portal. The latest news feeds need to be delivered in a timely manner, either directly to the TIC or via capacitors.

[0103] One embodiment includes an operator portal with a hierarchical GUI that displays all currently active customers. When a single customer is selected, the GUI displays customer details; the total number of customer-specific capacitors; the status of those capacitors; currently active cache datasets; the number of CDN nodes / TICs currently connected, and those connected an hour ago, yesterday, last week, etc.; the capacitor's error log; high-speed network, CDN nodes / TICs, etc.; the total number of cache dataset transfers to the capacitor; and the number of cache dataset transfers to CDN nodes / TICs. Additional information that may be displayed hierarchically includes, but is not limited to, the following: Total number of customer CDN nodes / TICs Location of each TIC Current status of TIC Total traffic generated by TIC Total number of cache misses by TIC Number of updates to cache dataset 725 by TIC Average update time of cache dataset 725 Number of capacitors 510 visited by TIC Maximum number of devices connected to TIC Average number of devices connected to TIC Itinerary data related to statisCDN nodes / TIC Cache dataset 725 / Total number of itineraries Usage metrics for cached dataset 725 / trips. The efficiency of cache delivery (for example, sending 4 cache datasets of 725 per download). The effectiveness of cached dataset 725 for other customers / CDN nodes / TICs (for example, dataset 3 has a 20% hit rate for this customer, while all other customers have a 60% hit rate for the same dataset). Customer portal activity / history. If a customer experiences an issue, it's necessary to be able to review the history of their requests. The location, content, timing, and type of the data should be included. In some cases, it should have a function to revert changes.

[0104] Accordingly, embodiments of the present invention aim to deploy caches to mobile environments having various levels of connectivity, including predictable and unpredictable connectivity. In one embodiment, the system operator is an ISP on behalf of customers having mobile environments such as trains, planes, buses, and passenger ships.

[0105] One embodiment of the system associates a subnetwork of public addresses with another mobile environment (i.e., another ship / vehicle) and peers with a content provider using BGP (or other protocol). The system associates different subnetworks with caches located therein, so that the content provider can direct client devices to the local cache.

[0106] Client devices connect to content providers via network links, and predictable connectivity is defined by time and location. In specific locations where high-speed connectivity can be established for extended periods, and where a mobile environment exists on a fixed, regular schedule, connectivity is predictable.

[0107] One embodiment of the system schedules cache refills by content providers during these scheduled periods, as this ensures that connection speeds meet the content provider requirements. While the diagram shows a single curated cache 155, one embodiment includes at least one cache per content provider to enable cache refills and peering from there. One embodiment provides connectivity to each high-speed network and returns to the content cache used for peering.

[0108] Accordingly, embodiments of the present invention extend the concept of ISP to include special connectivity to mobile environments that would otherwise not qualify as a) an ISP and b) a suitable connection location for cache filling. These embodiments also uniquely enable existing mechanisms to be localized to mobile environments by controlling connectivity to IP addressing, delivery, and content providers. In addition, these embodiments uniquely define dual-homing connectivity to enable both connectivity in transit and connectivity at rest, thereby realizing a unique aspect of the cache lifecycle.

[0109] As described above, in some embodiments, the cache is also placed in a mobile environment with unpredictable connectivity, i.e., high-speed connectivity is unpredictable in terms of time or location. For example, a cruise ship traveling from Vancouver to Alaska may dock at several ports over several days where cache filling can be performed. Since the duration of docking may vary from place to place, it is difficult to complete cache filling in a single dock. Therefore, the cache may be incrementally updated with each dock, and the speed of the high-speed link from land to ship is set as high as possible to minimize the time required.

[0110] One embodiment uses capacitors and CDN nodes to manage the non-deterministic nature of high-speed networks. A capacitor is a storage device having one network connection used for cache delivery and one network connection to a high-speed connection used for transferring content to mobile environments. A CDN node is located in the mobile environment and has one connection to the high-speed network and one connection to the mobile environment. Its role is to fully receive cache updates from one or more capacitors across one or more locations and over separate periods. Once the content is aggregated, the CDN node can perform scheduled cache fills using local cache devices. The local content cache is assumed to be operating on a consistent schedule, even if the mobile environment is interrupted several times to complete the process.

[0111] Many capacitors are located in many places and, for cost-effectiveness, can deliver cached content little by little over slower network connections. Thus, a relationship exists between many mobile environments and many capacitor locations. Temporary connections perform cache updates in mobile environments. When a cache is updated, the cache's address domain notifies the content provider which cache is serving which client.

[0112] Therefore, embodiments of the present invention uniquely enable environments that cannot definitively satisfy cache placement requirements by aggregating connectivity over a certain period and space to shift update requirements to a local mobile environment. If sufficient connectivity events can be guaranteed between periodic cycles to aggregate content in the local environment, the local cache can satisfy its cache-filling requirements without being aware of its limited connectivity. Multiple caches from multiple content providers can be satisfied by these techniques.

[0113] One embodiment involves deploying CDN nodes / TICs that provide content caching in a highly scalable configuration. Based on the above embodiment, deploying a large number of caches can begin to become uneconomical. This is because (1) existing caches are designed to handle tens of Gbps of streaming traffic, and (2) IP addressing is used to direct end-user devices to the appropriate cache.

[0114] A transparent cache (TIC) containing content from one or more content caches can address these issues. For example, a single transparent cache can maintain up-to-date caches for multiple content providers using the high-speed network mechanism described above. Furthermore, in an ISP model, a single addressable cache may be identified to handle an entire user address domain. For example, thousands of end-user devices can all be associated with a single cache and logistics shared with content providers via BGP. In the system described herein operating as an ISP, hundreds of transparent caches may be deployed to intercept traffic targeting exposed cases (and thus intercept requests locally). These transparent caches then scale well beyond existing mechanisms. In addition, since the ISP provides a single transparent cache for multiple content channels, economies of scale can be achieved across multiple content channels, making the solution viable.

[0115] Peering with a specific content channel introduces content and security certificates. If Netflix is ​​permitted to deploy a transparent cache for content corresponding to a CPC, TLS encryption may be used for content delivery, as reported. As a result, a Netflix-signed certificate is required to intercept and deliver intercepted requests. If the same content approved by Netflix is ​​used similarly to an upstream CPC, all requests to that CPC are valid cache hits. Each flow initiated to a known CPC may be intercepted, followed by a 303 redirect to the device, and the request may be delivered locally. The redirected request establishes a TLS session with a transparent cache executed by the Netflix certificate, thereby giving Netflix a level of control over the delivery of that content. Locally stored content, delivered with the permission of the content provider (e.g., Netflix), may now be served to the client device. Netflix or other content owners may introduce numerous constructs to ensure that the way the content is accessed is outside of their explicit control.

[0116] In a purely transparent caching environment, where cached data is curated in one region and deployed in another, it is necessary to understand which requests are collectively identical. For example, there may be over 6500 CPC caches deployed globally. In some cases, each transparent cache present in a mobile environment may need to consider all 6500 addressable locations to determine whether a given request is for a locally stored content segment. One embodiment crawls the internet to obtain cache addresses and provides a list of addresses for comparison. Another embodiment applies contextual information about the location of the transparent cache (or the mobile environment in which the transparent cache resides) to identify CPC cache addresses that are likely to be considered.

[0117] If the operator of the above system is the ISP of the records, either explicitly or via the overlay network, the target cache address can be limited to the cache address provided by the operator.

[0118] Given the nature of the temporary high-speed / constantly low-speed links described above, one embodiment of the present invention assesses the urgency or importance of specific content and, if necessary, fills the TIC with low-speed links. The portion of the TIC containing this urgent / important content is referred to herein as the “Trend Cache.”

[0119] One embodiment involves allocating a certain percentage of slow bandwidth to a trend cache so that high-demand data is always filled into the trend cache. In some examples, all or a significant percentage of the slow bandwidth may be temporarily allocated to fill the cache with specific multimedia files that are frequently requested.

[0120] One embodiment uses a mobile environment to propagate content across a network. In the particular embodiment described above, the capacitor may be located in a remote location that does not necessarily have sufficient high-speed connectivity. For example, if a 100Mbps link is the maximum that the remote port can support to the capacitor, filling 30TB would take approximately 28 days. In contrast, a 15Gbps link would allow the transfer to be completed in less than 5 hours. As a result, one embodiment establishes high-speed connectivity with passing ships / vehicles whenever it is possible to download content from the ephemeral cache via a high-speed link. For example, the capacitor may retrieve content from an ephemeral cache on a ship that is traveling to another port over the course of a day. The ephemeral cache on another ship traveling in the reverse direction can then be updated more quickly from the remote capacitor.

[0121] Therefore, the capacitor has two operating modes. The capacitor always has a broadband connection, but <1G is a maintenance connection and >=1G is a cache fill connection. If only the maintenance connection is present, the capacitor is filled over the WAN. If the cache fill connection is present, the capacitor is never fully filled over the WAN.

[0122] One embodiment of the capacitor retrieves only data that is more recent than the currently stored data from passing ships / vehicles. For example, if the capacitor requires only image A, it retrieves only image A from passing ships / vehicles. In contrast, a temporary cache on a ship / vehicle may have older copies of images B and C, in which case it retrieves these images from the capacitor.

[0123] For example, a maintenance connection may be used to deliver metadata about the current cache dataset. Images A, B, and C are considered current, and the capacitor should have these images. When a CDN node connects to the local high-speed network, the following protocols may be invoked. Do you have CDN nodes A, B, or C? Start the download, or continue downloading from where the CDN node previously stopped filling. If the capacitor does not have A, B, or C, do nothing. Does it have capacitors A, B, or C? If "Yes," the capacitor will either start the download or continue downloading from the connected CDN node. If the capacitor already has A, B, or C, or if the CDN node does not have any of them, do nothing.

[0124] In one embodiment, a cache-fill connection is used for delivering both metadata and the actual dataset. Depending on the link speed and / or content availability, a reverse fill from a temporary cache on a ship / vehicle may be appropriate.

[0125] With a 1Gbps connection, filling 30TB takes 3 days. If a vessel has a full link and 50% has been downloaded over the WAN, it makes sense to calculate the percentage that can be downloaded over the 15Gbps link when it is available. One embodiment of a capacitor operates according to a set of rules / policies. For example, one requirement is that the capacitor downloads 1-50% over the WAN and simultaneously downloads 51-100% in reverse order over the high-speed connection. Then, it determines when the entire cache has been downloaded completely.

[0126] Another embodiment may download a certain percentage (e.g., half) if a fast link is available. Once that is complete, download the remaining half. Once that is complete, download the other half again (similar to a binary search algorithm). In one embodiment, the cache is downloaded in segments, and any random point in time may result in a loss of the link. Therefore, one embodiment includes checkpoint circuitry / logic to check the download (i.e., restart or continue as permitted).

[0127] One embodiment globally tracks all capacitors and all vessels / vehicles that may cross paths with them. By performing analysis, it is possible to determine the time required for all capacitors to be updated. With a sufficient number of high-speed network connections, all capacitors or all sizes can be refilled within 1-2 days.

[0128] Therefore, using the above technology, ships / vehicles become the mobile part of the network and are used to propagate updates to remote network components (i.e., remote capacitors).

[0129] Existing ISP partner programs allow caching providers such as Netflix and Google to have their properties hosted by ISPs. While ISPs can manipulate some of the logistical aspects of the deployment using various mechanisms, ultimately, the only place an ISP can access the content is on the network. The content is stored only within stationary over-the-top (OTT) provider devices.

[0130] For the specific embodiments described herein to function, the OTT provider must be prepared to support content pooling within the network, for example, within capacitors, CDN nodes, and CDN node / TIC (e.g., stationary within the ISP infrastructure). To make this configuration acceptable to the OTT provider, one embodiment of the present invention introduces certain protection mechanisms.

[0131] ISPs cannot extract native content in a static form. In addition, OTT providers are given the ability to track where content is pooled. Furthermore, OTT providers are given the ability to delete pooled data and do not allow third parties to copy and / or extract pooled data.

[0132] Based on these preconditions, one embodiment of the present invention implements an additional encryption layer on the content and provides a marker (e.g., a blockchain) within the data to verify its authenticity. For example, each copy of the data may receive a unique blockchain entry and key, and can only be decrypted on the blockchain. If the data is deleted or removed, the data becomes useless.

[0133] Another embodiment uses time-dependent cryptographic keys instead of blockchain. For example, copies created may only be valid for a specified period (e.g., a week, a few days, etc.). E. Content Provider (CPC), Micro CPC Cache, and Primary Cache

[0134] The embodiments of the present invention described above include caching technologies that operate in remote, potentially mobile environments such as aircraft, buses, trains, or ships. These technologies deliver large datasets to remote locations within predictable delivery times. By leveraging this mechanism, an effective caching solution comparable to existing delivery mechanisms of internet service providers and media service providers can be provided.

[0135] Today, for example, Netflix and other providers use ISP partnership models to deliver content across the entire ISP network to content provider caches (CPCs), such as Open Connect Appliances (OCAs) deployed by Netflix. While some embodiments described below focus on specific media providers such as Netflix, the fundamental principles of the present invention are not limited to any particular media provider architecture.

[0136] One embodiment of the present invention includes a microcaching method and apparatus for a mobile environment with variable connectivity. A particular embodiment uses various techniques to deliver a Netflix cache to a mobile environment.

[0137] One embodiment of the present invention includes the following features: (1) an ISP (e.g., Netflix) hosts CPCs within and throughout its network; (2) the ISP communicates client IP addresses associated with deployed CPCs; (3) the ISP ensures that cache refills are performed on a schedule; and (4) if content is unavailable in the CPC cache, the ISP provides connectivity back to Netflix where the long-tail content is held.

[0138] One embodiment of the present invention is built on an ISP partnership model and includes the deployment of CPCs within these remote locations. These embodiments are particularly beneficial in vehicles such as ships, where a large number of potential viewers are highly concentrated. However, the basic principles of the present invention may be implemented in smaller mobile environments such as trains, airplanes, and buses.

[0139] Figure 13 shows one embodiment in which a micro CPC cache system 1301 configured within a mobile environment 150 does not interface with the media provider 1310 as if it were within an ISP network. For example, instead of relying on a protocol such as BGP to deliver the current user's address to the media provider 1310, the onboard micro CPC system 1301 informs the media provider 1310 (e.g., Netflix) that (a) the system has an onboard CPC cache containing a specific dataset, and (b) the cache is associated with an IP address pool 1320, which can then be associated with passengers (e.g., via satellite or cellular networks). In one embodiment, an address manager 1307 performs IP address allocation within the micro CPC system. For example, if CSP152 is associated with a specific range of IP addresses, such as 10.32.50.x~10.32.63.x (where x is any number permitted by the IP addressing scheme), the address manager 1307 may assign a block of IP addresses, such as 10.32.50.0~10.32.50.800 or 10.32.50.x~10.32.51.x, to the mobile environment 150. In one embodiment, the address manager 1307 dynamically assigns these address blocks to individual micro CPC systems 1301, which then assign addresses within the permitted range to user devices 1321.

[0140] Figure 14 shows one embodiment of a microCPC system 1301, which includes a microCPC cache 1460, a microCPC cache manager 1470, and a connection manager 823 (some examples of which were previously described with respect to Figure 8). In one embodiment, a range of IP addresses 1321 assigned to a particular mobile environment is provided to the connection manager 825, which includes a dynamic address assigner 1475 for assigning IP addresses from the range to user devices 827 that establish a link over the local WiFi network 1470. The microCPC manager 1470 manages the content stored in the microCPC cache and, in one embodiment, exposes an API to a media provider 1310 to provide complete visibility and control over the content.

[0141] The micro-CPC cache 1460 may be filled directly from the media provider 1310 or through the CPC cache 1302 (for example, if the media provider 1310 fills the CPC cache 1302 according to an existing fill policy). In either case, the micro-CPC system 1301 fills the micro-CPC cache 1460 according to a set of rules and / or cache curation policies enforced by the content service provider 152 and accepted / approved by the media provider 1310. Various different rules / policies for updating the micro-CPC cache 1460 are described above (for example, as described for the CDN node 520 and the transparent cache 610). Any of these techniques may be used to determine a particular set of media content to be deployed in the micro-CPC cache 1460.

[0142] When a passenger interacts with the media provider using the media provider's app, application, or browser (or other content channel) on user device 827, the media provider 1310 searches the nearest CPC cache 1302 as usual, but also searches the nearest micro-CPC 1460 if such a device is registered with it. The media provider's app, application, or browser is then directed to the micro-CPC cache 1460 instead of the CPC cache 1302 assigned to CSP 152 (after all credentials, DRM, Silverlight, etc., have been executed).

[0143] Significantly, media provider 1310 still has complete visibility and control over the distribution of CPC content and peers with micro-CPC provider 152 as a CPC ISP. However, micro-CPC provider 152 uses an enhanced peer-fill embodiment, as described herein, to ensure that the most relevant content reaches micro-CPC system 1301.

[0144] During operation, the user device 827 is dynamically assigned an IP address by the dynamic address assigner 1475 (for example, using a media provider's application). A protocol such as Dynamic Host Configuration Protocol (DHCP) may be used to dynamically assign a client IP address from within the assigned range 1321.

[0145] When user device 827 is connected, it may access the Internet via a connection provided by an airplane, train, ship, or bus. This may include, for example, satellite connections, cellular services, and / or any other connections available in a mobile environment while in motion. If the user chooses to access media content provided by media provider 1310 (e.g., a Netflix show or movie), a request is sent to media provider 1310 via the established Internet connection to authenticate user device 827. Media provider 1310 may then use the IP address of requesting device 827 or connection manager 823 (which may be configured as, for example, an Internet router or gateway) to identify a micro CPC cache 1460 within the same mobile environment. If the content is locally available in the micro CPC cache 1460, a redirect response is then sent to user device 827 containing the local IP address of the micro CPC cache 1460 (and / or micro CPC manager 1470). If the content is unavailable locally, the response redirects user device 827 to CPC cache 1302 via an internet link (or another CPC cache).

[0146] Therefore, in the above embodiment, network fill operations from media provider 1310 may be performed against one or more CPC caches 1302 configured at strategic locations within the CSP's network, and a subset of this content may be transmitted via a high-speed network 161 connecting a mobile environment 150 to the CSP network via edge / router devices 1304, where the mobile environment is located at stations, docks, terminals, etc. Regardless of the technology used for filling the micro-CPC system 1301, the media provider maintains complete visibility and control over the content stored in each micro-CPC cache.

[0147] In one embodiment, this solution is implemented with only a selected subset of the media provider's content. In practice, depending on the nature of the environment, the media provider may provide a restricted user portal that is limited to content available within the micro CPC cache 1460. Thus, in this embodiment, passengers / customers do not request content that is not available on the cache.

[0148] In another embodiment, the same dataset is fed into a transparent cache, such as the TIC810 described above with respect to Figure 8. Instead of directing the client directly to the onboard micro-CPC cache, the media provider 1310 directs the requesting device 827 to a customer-specific CPC, such as the CPC cache 1302 hosted by the CSP152. The transparent cache intercepts media requests targeting the CPC cache 1302, determines whether the media content is stored locally, and if so, provides the content locally. In this case, the IP range may be sent to the media provider 1310 via BGP (or other protocol). However, it should be noted that, in contrast to the micro-CPC cache 1460, the media provider 1310 has no access to or control over the transparent cache. However, the advantage is that these transparent caches propagate media content much faster than the micro-CPC cache embodiment. In a transparent caching model, the Content Service Provider (CSP) 152 may notify the Media Provider 1310 that only specific IP addresses have access to the CPC cached content, and therefore may trigger a restricted portal view within the user interface of the user device 827.

[0149] Several optional features may be implemented, such as a centralized approach in which the customer downloads a content catalog from a media provider 1310 that recognizes content residing on a micro-CPC cache 1460 or a transparent cache, or a delivery approach in which network-based authentication is performed, followed by delegating the catalog to a local cache. Both mechanisms essentially direct a media provider application running on the user device 827 to a subset of locally available media content on the micro-CPC cache 1460. Note that the term “application” is used herein to include mobile device applications (e.g., iPhone® apps), browser-based program code, and applications running on a laptop computer). In short, any form of program code installed on the user device 827 that provides media streaming functionality may be configured to leverage the embodiments described herein.

[0150] Numerous configurations exist to suit various mobile environments. For example, a bus may only need sufficient streaming capacity to support 50-80 passengers. On the other hand, an airplane may need to support 100, 200, or more passengers, depending on the type of aircraft. A train may need to support as many as 1500 passengers, and a cruise ship may need to support as many as 6000 simultaneous streams. The existing CPC cache 1302 may be suitable for a cruise ship, but it is unnecessarily large for a bus (e.g., in terms of price, power consumption, and capacity).

[0151] However, a standard 30-100 TB cache may be specified as the standard benchmark for all the embodiments described above. The CSP152 provides a form-factor caching device that addresses the delivery of cache updates when high-speed connectivity is available and delivers sufficient media streaming capabilities to each mobile environment.

[0152] Media provider 1310 uses an existing BGP peering model to recognize the nearest CPC cache 1302. In one embodiment, media provider 1310 provides additional data indicating whether an IP address represents a location with restricted access and / or a higher dependency on the CPC cache 1302. In this scenario, media provider 1310 handles the device in a special way, simply by sharing a catalog that may be provided by the local cache. An existing media provider 1310 may extend the existing networking infrastructure to support (a) the inherent properties of an address pool, and (b) the content cached locally for that address pool.

[0153] In one embodiment, the CSP152 implements only a single "core" CPC cache 1302 and replicates content to various microcaches configured on different transport vehicles / ships. By having an ISP relationship with the media provider 1310, the CSP152 simply references the core CPC cache 1302 using BGP, providing the media provider with visibility into its media content. Each of the micro-CPC caches 1460 distributed across the various transport vehicles is populated with the same media content (or a subset thereof) from the core CPC cache 1302.

[0154] In one embodiment, the media provider 1310 does not need to have full visibility of the micro-CPC caches, but is aware that these caches contain media content that is no more than the same set of allowed media content on the CPC cache 1302. A temporary cache (TIC) configuration may be used in this embodiment. In another embodiment, each micro-CPC cache 1460 is registered individually with the media provider 1310, which explicitly manages the media content and redirects clients to its local micro-CPC cache 1460 as described above. F. Reverse fill of fixed cache devices

[0155] As described above, if a fixed environment (FE) cache, such as capacitor 510, has a relatively low-bandwidth link back to the CPC cache and / or media provider (for example, if the capacitor is in a remote location), a “reverse fill” operation may be performed. In such a case, for example, if a micro CPC cache or ephemeral cache on a cruise ship forms a high-speed connection with the fixed environment cache, a reverse fill operation may be performed during the connection period to provide content to the FE cache. The edge device may then provide this content to other micro CPC caches or ephemeral caches in other mobile environments as it passes through range.

[0156] In one embodiment, the CPC cache 1302 does not simultaneously provide the same media content to all FE caches from the CPC cache 1302, but rather sends different data to each FE cache. Figure 15 shows one particular example including three FE devices 1501-1503, each having an FE cache 1511-1513. In this embodiment, instead of streaming all of the same content from the CPC cache 1302, the content may be divided among each of the three FE caches 1511-1513. Therefore, for example, if the bandwidth to each FE device 1501-1503 is the same, one-third of the total media content may be sent to each FE cache 1511-1513. For example, if each FE device 1501-1503 is configured at a different railway station (i.e., the mobile environment 150 is a train), the micro CPC cache or temporary cache 1520 would receive one-third of the total content from each FE device 1501-1503 and have all the content when it leaves the station where the FE device 1503 is located. The advantage of this approach is that the total capacity for FE devices 1501-1503 is the sum of all links to all stations, rather than being limited to the slowest link to one of the multiple stations. In one embodiment, the reverse-fill technique described above may also be implemented in this environment to transmit media content from the micro CPC cache or temporary cache 1520 to one or more of the FE devices 1501-1503 (for example, if the network connection to the CPC cache 1302 deteriorates or is lost).

[0157] In one embodiment, the amount of media content sent to each FE device 1501-1503 is allocated according to its link capacity to the CPC cache 1302. For example, if FE device 1501 has a 200Mbps link, FE device 1502 has a 300Mbps link, and FE device 1503 has a 500Mbps link, then 2 / 10, 3 / 10, and 5 / 10 of the media content may be sent to these devices, respectively. Once the allocated portions of the media content have been transferred to each FE device 1501-1503, the CPC cache 1302 may begin sending the remaining data. For example, if 2 / 10 of the media content has been delivered to FE device 1501 and there are still 30 minutes remaining before the train leaves the station, the CPC cache 1302 may send as much of the remaining 8 / 10 of the media content as possible to FE cache 1511 within the remaining time.

[0158] Additional optimizations may be applied to the above embodiment. Media content can be encoded into many small files, most of which have meaningless hash names. The core CPC cache 1302 may attempt to aggregate these files so that a complete set of media content can be reliably obtained from each FE device 1501-1503. For example, 10 movies could each be encoded into 100 files, resulting in a total of 1000 files, and the usefulness of the media content would depend on the specific grouping of files available to the user device. For example, a user may only begin playing a movie if they have the correct set of files necessary for playback (e.g., files numbered 1-10 associated with movie number 1). If the media content in the above embodiment is delivered from each movie to each FE cache 1511-1513 as 33 files, none of the FEs would have a complete movie, and the usefulness would be zero.

[0159] To address this problem, one embodiment of the system attempts to determine a specific set of files associated with each movie and deliver these files to the same FE cache 1511. For example, movies 1-3 may be sent to FE device 1501, movies 4-7 to FE device 1502, and movies 8-10 to FE device 1503. Furthermore, the files for a given movie may be sent sequentially, starting from the beginning of the movie and ending with the end. These movies can then be viewed while waiting for the rest of the movies to reach the micro CPC cache or temporary cache 1520.

[0160] In this embodiment, the media streaming analysis engine 1540 may monitor which files are consecutive to each other. For example, when a user watches movie number 1, the media streaming analysis engine 1540 may track a specific sequence of files streamed to the client and store it as a media file mapping 1530 (e.g., a table data structure that associates each media item with multiple files). Naturally, if the media provider 1310 provides metadata that associates files with media items, the metadata may be used for this purpose.

[0161] Upstream content delivery networks (CDNs), such as those operated by Akamai and Amazon CloudFront, act as proxy caches that request and store content from upstream caches when content is requested locally. One embodiment of the present invention utilizes the components of this architecture but intelligently requests upstream data based on cumulative requests delivered across all vehicles / ships within a vehicle.

[0162] Referring to Figure 16, the bulk updates described herein between the fixed edge 1610 and the local cache 1620 within the mobile environment 150 address some of the physical constraints associated with sending requests upstream. When the vehicle / ship 150 arrives at the station, the high-speed network link 161 is used to deliver these bulk updates. By providing bulk data at the lowest layer of the CDN hierarchy (e.g., the local cache 1620), the upstream requests generated within the mobile environment 150 will be significantly reduced.

[0163] Given the presence of a large number of vehicles / vessels (e.g., 100) on site, cache misses will occur to some extent distributed across different vehicles / vessels, but some may occur simultaneously (e.g., when breaking news is being broadcast). In one embodiment, a cache miss request generated within the mobile environment 150 is sent back to the core proxy cache 1605 via a slower network (e.g., cellular, satellite) 1350. If necessary, the core proxy cache 1605 calls the upstream 1600 to fetch the data and sends it to the local cache 1620 within the requesting mobile environment 150. All other passengers within the mobile environment 150 who wish to view media are served directly from the local cache 1620.

[0164] In this embodiment, the core proxy cache manager 1601 is provided by the upstream CDN server 1600 and is aware of cumulative activity from all mobile environments 1610, including all local cache misses stored in the core proxy cache 1605. When each individual mobile environment 150 arrives at the fixed edge 1610 using the high-speed network 161, the core proxy cache will include the latest content from the accumulated misses, and this content will be pushed to each mobile environment. In effect, for example, in a train of 100 trains, the misses of 100 trains will be aggregated, and the results will be shared after the next update cycle.

[0165] In one embodiment, if the same request is observed to originate from multiple mobile environments (for example, using thresholds such as 10% and 15%), the requested content may be classified as a high-demand item. Consequently, this media item may be pushed to all mobile environments 150 via the low-speed network 1350, with the expectation that a very high percentage of passengers will wish to access it.

[0166] In summary, a single core proxy cache 1605 represents the sum of requests from N mobile environments (e.g., N = 50, 100, 400, or any other number). The requested content is pushed from the core proxy cache 1605 to all N mobile environments via the high-speed network at a coarse frequency (e.g., daily), and for items determined to be extremely high-demand, it is pushed via the potentially slower network 1350 using a finer frequency (e.g., per minute).

[0167] In certain embodiments, the most important static content is managed and a media cache is deployed in a remote location where it can be viewed locally. In this embodiment, the delivery technology can be considered orthogonal to the consumption technology, similar to current video-on-demand (VOD) systems.

[0168] Using one embodiment of the present invention, instead of deploying a VOD system on a single vessel / vehicle, the VOD system may be deployed on a public or private website. Therefore, all people who can access the website are provided with the same experience as passengers on the vessel / vehicle.

[0169] In one embodiment, a public / private website is mapped to the CDN shown in Figure 16, or to one of the other embodiments described above, and the entire website and CDN content is replicated simultaneously and consistently to each ship / vehicle. What train passengers experience is, for example, a visit to the public / private website, but instead, a local cache 1620 provides the website data and media content as a cached instance.

[0170] As described above, one embodiment of the present invention includes a system and method for prioritizing and scheduling content delivery by analyzing content usage and mobile environment data. G. Prioritizing and scheduling the delivery of learned content

[0171] Figure 17 shows one embodiment of an architecture that includes authentication and access logic 1705 for securely connecting to a content origin 1701 (e.g., a content provider) and retrieving the delivered content. The analysis engine 1710 evaluates data related to the content and its use to determine a demand value for each content item. The demand engine 1715 evaluates the demand value in combination with timing data, cache misses, and profile data related to the mobile environment (e.g., storage capacity, overall bandwidth, and user bandwidth).

[0172] Based on evaluations performed by the demand engine 1715, the packager logic 1720 performs modifications to specific content. For example, in the case of a highly popular title (e.g., identified by the analysis engine 1710 or the demand engine 1715), the packager 1720 may generate or retrieve different bitrate versions of the content. All transformations performed are specified by the packager 1720 in customized manifest files 1750B-D and may be sent to their respective corresponding mobile environments 150. The customized manifest files 1750B-D may be generated using data from the original manifest file 1750A provided by the content provider. Briefly, the manifest files specify the different bitrates available for the relevant content. In this embodiment, manifest file 1750A is modified to generate customized manifest files 1750B-D for each mobile environment 150, so that a video player or web browser can identify the highest quality content available locally (e.g., when a high-speed network is disconnected).

[0173] In one embodiment, the scheduler 1725 generates a delivery schedule for sending various content items based on known or expected schedules of the mobile environment 150 and expected demand for each content item within each mobile environment 150.

[0174] Once the schedule is set, the delivery logic 1730 manages the transmission to each of the mobile environments 150 and reports the results back to the scheduler 1725 and / or content provider. The content may be delivered via any available network technology, including but not limited to high-speed Ethernet, WiFi cellular (e.g., 5G), mmWave, and SneakerNet.

[0175] In one embodiment, the architecture in Figure 17 maximizes the use of constrained connectivity to the mobile environment 150 by performing one or more of the following: (1) multifactor analysis for prioritizing and determining the order in which titles are sent, (2) a multipath delivery system, (3) real-time queue constraints, and (4) profile-based constraints.

[0176] With respect to multifactor analysis, the demand engine 1715 may perform explicit prioritization and / or selection based on learned demand. Explicit prioritization may be used by setting a priority value for a particular title based on the expected demand for that title. For example, a blockbuster movie may be assigned a relatively high priority when it is first released for streaming. Then, the demand for that movie may be tracked over time, and the priority level may be adjusted accordingly. Learned demand is the demand determined by monitoring the use of the content. In one embodiment, the priority is selected from one of several individual priority values ​​(e.g., priority 1-5). Thus, learned demand may be adjusted to the content based on exceeding thresholds (e.g., total number of requests, number of cache misses, etc.). In addition, multifactor analysis may involve explicit timed delivery. That is, a particular piece of content may be "monitored" at a specific time, regardless of cache misses, and delivered with a high priority.

[0177] With respect to multipath distribution, in one embodiment, the scheduler 1725 uses different queues 1726A and 1726B to schedule content of different priorities. For example, low-priority content may be stored in a "bulk" queue matrix 1726B for distribution when an edge node in the mobile environment 150 has high-capacity connectivity (such as when the edge node is located at a station). High-priority content may be stored in a "real-time" queue 1726A for distribution via any available connection, such as a cellular connection.

[0178] With respect to real-time queues, scheduler 1725 may consider various constraints. These may include, for example, constraints on the amount of bandwidth that can be consumed at different times, and constraints on the amount of data that can be used within a given time frame.

[0179] With respect to profile-based constraints, the packager 1720 may adjust any transformation / packaging of content according to the constraints of each mobile environment 150. For example, edge nodes may have different cache capacities, and therefore content may be selectively targeted to different nodes based on available space versus priority. In addition, the demand engine 1715 may evaluate profile data and other relevant data to adjust prioritization based on geographic location (for example, certain content may have different priorities in different geographic regions). H. Embodiments of cross-border movement of CDN content

[0180] One embodiment of the present invention includes a system and method for supporting the cross-border movement of media content. Specifically, because different jurisdictions have different laws related to the proper management of media content, these embodiments dynamically adjust how media content is managed as a transport vehicle passes through a jurisdictional area.

[0181] In one embodiment, content availability needs to be aligned with the region where the vehicle is located at any given time; therefore, applications accessing the mobile cache need to know their own location and access the cache information appropriately. Thus, in a mobile CDN environment, connections that remain fixed within the local transport environment need to reflect the current geographical location.

[0182] Referring to one embodiment with respect to Figure 18, in this embodiment, the mobile environment 150 provides an example of movement between a first country 1810 using a first public IP address (1.2.3.4) and a second country 1811 using a second public IP address (5.6.7.0 / 32). In one embodiment, the vehicle IP address within the mobile environment 150 passes through the NAT circuit 1820 to perform network address translation to the IP subnetwork of the “home” region as described above. The NAT circuit 1820 may be integrated with a network router configured within the mobile environment 150.

[0183] In one embodiment, the IP mapping 1830 is stored within the network router and used for translation between public IP addresses in countries 1810-1811 and local IP addresses used within the mobile environment 150. The cached content within the mobile environment 150 is a superset of all regions associated with the itinerary route. Based on the detection of a GPS event 1815 (e.g., in response to a GPS device indicating movement between countries 1810-1811), the route is inserted before the network address translation to reflect the new regional IP address (e.g., 5.6.7.0 instead of 1.2.3.4).

[0184] When a user app 1850 (e.g., the Netflix app on a mobile device or another app for rendering video content) continues to use a home source, the new regional IP address is geolocated by the content owner's current process (e.g., a lookup that links the IP address to a specific country), and a decision is made on whether to continue streaming based on the request for the new country 1811. I. CDNE caching tier with advanced content tracking, security, and visibility to content owners

[0185] One embodiment of a CDNE includes a multi-layered caching hierarchy with advanced content tracking, security, and visibility. For example, one embodiment implements an immutable ledger to track and manage content delivered across multiple mobile environments and supplied by multiple content providers. Specifically, a blockchain-based immutable ledger may be used to track and verify where content is delivered within the CDN network extender footprint, including all fixed and mobile caches maintained by the CDN extender 110. For content providers and owners who require demonstrable control of content titles across the entire network, these embodiments also provide a secure and fully auditable tracking of each title from the moment it enters the CDN extender 110 network until it is removed from the system. At any intermediate point where a title is cached, this is an encrypted blob, providing content owners or providers with all the features of an encrypted tunnel from its current large-scale edge network to all cached instances of the content, including, to name a few, content stored in fixed edges 184, mobile edges 185, and micro CPC caches 1460.

[0186] To illustrate a specific embodiment with respect to Figure 19, this embodiment shows a content origin service 1905A such as Netflix connected to multiple content provider caches (CPCs) 1911-1913 (e.g., Netflix's OCA cache) via a source network 1901. In this embodiment, the CDN extender 110 includes a CDNE core cache 1920 that establishes peer connections to one or more of the CPCs 1912 to receive peer fill operations, into which content from the CPCs 1911-1913 is populated.

[0187] In one embodiment, the CDNE core 1920 is at the top of the CDNE 110 caching hierarchy and potentially caches all or a large subset of titles provided by the content origin service 1905A. Although only a single CDNE core 1920 is shown for simplicity, the CDNE extender 110 may include several CDNE cores 1920 that maintain consistency via peer-based message passing, a shared directory database, or other synchronization techniques. In one embodiment, the CDNE core 1920 participates as a direct network peer to the content owner's ISP.

[0188] Multiple intermediate hub devices 1930-1932 receive content updates from the CDNE core 1920 via a secure communication channel within the CDNE extender 110 network and pass the content updates to the edge caches 1940-1942. In one embodiment, the content is transmitted via an encrypted communication channel to protect the underlying media content (e.g., encrypted with Transport Layer Security (TLS) and / or using the shared ledger architecture described below).

[0189] One embodiment of the present invention continuously updates the content directory 1950 to reflect the propagation of content across the entire network of the CDN extender 110. For example, Figure 19 shows a CDNE core 1920 that generates entries to update the content directory when a particular media content title is received, and edge caches 1940-1942 that update the content directory 1950 when media content is received from hubs 1930-1932. In one embodiment, for each content title received by each edge cache 1940-1942 and CDNE core 1920, a new entry is added to the content directory 1950. Each entry includes an identifier of its current location, a decryption key, a source indication (i.e., specifying the network component from which the content originated), and a timestamp (indicating the time the content was received). By using appropriate authentication, the content owner / provider 1905A can thereby track the location of any part of its content as it is distributed across the entire network of the CDN extender 110.

[0190] As shown in Figure 20, in one embodiment, a shared ledger fabric 2000 is used to provide enhanced authentication and security. The shared ledger fabric 2000 establishes channels to each content owner carried over the CDNE 110 network. When a content title is received, a ledger entry is generated within the shared ledger fabric 2000 to record the event. The content owner / provider may then authenticate and view the ledger entry.

[0191] In one embodiment, an encryption key is received from the content owner, and CDNE 110 uses this encryption key to encrypt and package the content for distribution. CDNE 110 (They CDNE 110) may receive the encryption key directly or via a shared ledger 2000. The encrypted title package is transmitted through the CDNE network, such as intermediate hub locations 1930-1932, which are stored in encrypted form. When a content title reaches one of the edge caches 1940-1942, the encryption key is received from the content owner 1905A-B, and edge caches 1940-1942 use it to decrypt the package and load the underlying content into one or more available caches. Ledger entries record events and can be immediately viewed by content owners / providers as a record of each new copy of the content. For example, a content title can be cleared from edge caches 1940-1942 to make space for newer / more in-demand content.

[0192] The shared ledger 2000 is updated with rapid responsiveness to reflect changes, making them immediately visible to content owners. In one embodiment, content owners are provided with the option to issue a “cancel” transaction (either via or outside the shared ledger) that they may perform to erase content titles from various locations in the CDNE (e.g., core, edge cache).

[0193] In one embodiment, the shared ledger fabric 2000 is implemented using blockchain-based security. Specifically, the ledger fabric 2000 includes a list of records called blocks, each block containing the cryptographic hash, timestamp, and transaction data (generally represented as a Merkle tree) of the previous block. In this embodiment, each entry in the content directory 1950 contains a key, which is the hash of the previous entry. In this embodiment, an immutable ledger is obtained for tracking and verifying the distribution destination of content within the CDNE 110.

[0194] In addition, at any intermediate point such as hub devices 1930-1932, media content titles are stored as encrypted blobs, effectively establishing encrypted tunnels between content provider edges such as CPC cache 1302 and CDNE edges 1940-1942 and / or micro CPC 1460. J. Caching aggregated content based on limited cache interactions

[0195] Referring to Figure 21, one embodiment of the present invention aggregates content across its cache 2105 using data collected from various mobile environments, thereby reducing bandwidth from various content channels 190. Specifically, this embodiment constructs the cache 2105 based on the total input from strand networks 130A-B and context awareness of specific data being cached.

[0196] Conventional content delivery networks cache content accessed by a user, and therefore can provide the same content to other users more quickly the next time. However, in a constrained mobile environment, this mechanism is not large enough to function effectively. One embodiment reverses this problem. Specifically, in response to a specific event (e.g., the number of threshold misses in the local storage devices 142A-N of local CDN extenders 135A-N), a trigger-based content collector 2110 attempts to retrieve all segments of all content titles from the strand network 130A-N passing through the mobile environment 150. In one embodiment, the trigger-based content collector 2110 attempts to retrieve segments for all or a specified content bitrate set.

[0197] In addition, as the CDN extender 110 passes through the strand network 130A-N in the mobile environment, the trigger-based content collector 2110 progressively pushes segments that are not found in the associated local storage devices 142A-N, thereby synchronizing the local storage devices 142A-N with respect to a particular content title.

[0198] The content collector 2110 may implement both proactive and dynamic techniques to populate its cache 2105. For example, it may scan content provider websites for new content titles based on a regular schedule and add each new network address to the search queue 2111. It may then process the queue 2111 to pull content titles from the websites.

[0199] In addition, the trigger-based content collector 2110 may operate based on cache miss data aggregated across all edge nodes. Each cache miss may be evaluated, the corresponding URL may be estimated, and the complete content title may be identified. This title may be added to the collector's queue 2111. Finally, the complete title is collected in the CDN extender 119's core cache 2105, and this title is available for delivery to the edge.

[0200] One embodiment of the present invention includes a system and method for transforming a video manifest for more efficient media distribution and storage. Specifically, this embodiment reduces the number of active flows in a manifest that constitutes a title (reducing storage space) and performs progressive flow distribution to ensure that a given title is delivered more quickly (for example, by sending the lowest bitrate content first, then the intermediate bitrate content, and then the highest bitrate content).

[0201] As previously mentioned with respect to Figure 17, the manifest file 1750A notifies the playback application on the end-user device of the available stream rates for the title. The high-speed streams collected by the content collector 2110 are significantly larger than the low-speed streams, which presents an opportunity to optimize delivery and / or storage.

[0202] To maximize the use of the real-time delivery channel, packager 1720 generates a special package for the content title with the high-speed stream removed, modifies the manifest file 1750A associated with the content title, and generates one or more customized manifests 1750B-D by excluding one or more entries associated with the highest bitrate. The smaller media files can then be sent via the real-time queue 1726A of scheduler 1725 for immediate availability within the mobile environment 150. In contrast, the complete package (and complete manifest 1750A) containing all stream rates can be added to the bulk delivery queue 1726B. In one embodiment, when the mobile environment edge enters the bulk time window, for example, when the mobile environment 150 has a high-capacity connection (e.g., at a station), the low-bitrate version is replaced with the high-bitrate version.

[0203] Furthermore, in one embodiment, cache misses are provided in real time. Specifically, this embodiment proactively creates and delivers a special manifest for content that specifically refers only to low streaming rates, even though it has not yet been delivered. This leverages normal caching behavior to cache low-rate segments as they stream. In one embodiment, the number of concurrent streams allowed is limited, and once the limit is reached, other streams are prevented from starting. K. Distribution of cached data utilizing mobile environments

[0204] One embodiment of the present invention leverages a mobile environment and delivers cached data using reverse fill. This embodiment enables rapid delivery of content across a variety of vessels in a mobile environment 150, depending on the delivery protocol.

[0205] Moving petabytes of data across the entire network can result in high data costs. By introducing intermediate "hub" nodes 1930-1932 between CDNE core 1920 and edge nodes 1940-1942, an opportunity arises to leverage the movement of edge nodes 1940-1942 to progressively distribute content across the entire network.

[0206] When new titles are collected, they can be "sprayed" across hub nodes 1930-1932. For example, content title 1 may proceed to hub 1930, and content title 2 may proceed to hub 1931. When edge 1940 reaches hub 1930, it picks up content title 1 and then moves to hub 1931. At hub 1931, it drops content title 1 and then picks up content title 2. Returning to hub 1930, it then drops content title 2. Using more edges and hubs increases the process and significantly reduces the utilization and costs associated with content providers connecting to the network.

[0207] Figure 22 shows one embodiment in which fixed edges 2210-2212 are fed from both core cache 2201 and mobile edges 2220-2222. The status collector 2205 collects data from each of the fixed edges 2210-2212 and mobile edges 2220-2222, indicating the content titles and associated segments stored therein. The data is then provided to the content delivery manager via the dashboard's graphical user interface (GUI) 2201. L. Realizing a walled garden using a mobile CDN

[0208] One embodiment of the present invention implements a walled garden using a mobile content delivery network (CDN). This embodiment transforms a walled garden solution in which all mobile environments host their own footprints into a solution in which a single over-the-top (OTT) or intranet-based streaming solution is managed by a CDN extender 110.

[0209] Current walled garden solutions, also known as video-on-demand (VoD) systems, are not widely adopted due to two significant challenges: they are relatively static and updating older content is cumbersome. Additionally, accessing content requires users to download a special app before boarding, or to visit a locally managed website on each vehicle.

[0210] In one embodiment, the VoD system is deployed as a public or private website and then mapped as a content source within the mobile content delivery network described herein. The technology described herein is then used to replicate the content across all mobile environments 150. End users within the mobile environments 150 then access the content like any other website, except that all data is provided by caching and therefore external connectivity is not required. From the service provider's perspective, users only need to update one primary website, and the CDN extender 110 handles the distribution to all of those vehicles.

[0211] Figure 23 shows one embodiment of a video-on-demand (VoD) node 2311 of a content distribution network 2301. The CDN extender 110 pulls content from the VoD node 2311 as described herein and stores the content in the micro CDN core cache 2320. The CDN extender 110 pushes the content to the micro CDN caches 1921 of various mobile environments 150 as described herein.

[0212] Embodiments of the present invention may include the various steps described above. These steps can be embodied in machine-executable instructions that can be used to cause a general-purpose or special-purpose processor to perform these steps. Alternatively, these steps can be performed by specific hardware components including hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

[0213] Where used herein, instructions may refer to a specific configuration of hardware, such as an application-specific integrated circuit (ASIC), which is configured to perform a particular operation or stores a predetermined function or software instruction in memory embodied in a non-temporary computer-readable medium. Accordingly, the techniques shown in the drawings may be implemented using code and data stored and executed on one or more electronic devices (e.g., end stations, network elements, etc.). Such electronic devices store and communicate code and data (internally and / or with other electronic devices via a network) using computer-readable storage media such as non-temporary computer-readable storage media (e.g., magnetic disks, optical disks, random-access memory, read-only memory, flash memory devices, phase-change memory) and temporary computer-readable communication media (e.g., carrier waves, infrared signals, digital signals, and other forms of propagating signals, such as electrical, optical, acoustic, or other forms).

[0214] In addition, such electronic devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-temporary machine-readable storage media), user input / output devices (e.g., keyboards, touchscreens, and / or displays), and network connectivity. The coupling of the set of processors to the other components is typically done through one or more buses and bridges (also called bus controllers). Each of the storage devices and the signals carrying network traffic represents one or more machine-readable storage media and machine-readable communication media. Thus, the storage devices of a given electronic device typically store code and / or data to be executed on the set of one or more processors of that electronic device. Naturally, one or more parts of embodiments of the present invention may be implemented using different combinations of software, firmware, and / or hardware.

[0215] Throughout this detailed description, numerous specific details have been included for illustrative purposes to provide a complete understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be implemented without some of these specific details. In certain examples, well-known structures and functions have not been described in detail to avoid obscuring the subject matter of the invention. Therefore, the scope and spirit of the invention should be judged in terms of the following claims.

Claims

1. It is a system, Multiple mobile edge caches integrated across multiple compatible mobile environments, A local network manager connected to each edge cache device in each mobile environment provides network connectivity to client devices within each mobile environment, When the aforementioned mobile environment is within range, a high-bandwidth link is established to one or more fixed high-speed network interfaces, with each mobile high-speed network interface within the mobile environment. When the aforementioned high-bandwidth link is unavailable, a low-bandwidth link is established to one or more low-speed network interfaces within each mobile environment, A system comprising: a multifactor analysis engine that evaluates data on content usage across multiple mobile edge caches to determine the priority of sending content titles to each mobile edge cache, wherein low-priority content is provided to the mobile edge cache when the high-bandwidth link is established, and high-priority content is provided to the mobile edge cache even when only the low-bandwidth link is established.

2. The system according to claim 1, wherein the multifactor analysis engine includes a machine learning engine for determining the priority based at least in part on the number of cache misses associated with one or more content titles.

3. The system according to claim 2, wherein the multifactor analysis engine determines the priority based at least in part on data relating to when each content title is likely to be viewed.

4. The system according to claim 3, further comprising a multipath distribution system including the bulk queue and the real-time queue, wherein the low-priority content is provided to the mobile edge cache via a bulk queue and the high-priority content is provided to the mobile edge cache via a real-time queue.

5. The system according to claim 4, wherein content from the bulk queue is transmitted to the mobile edge cache only when the high-bandwidth link is established, and content from the real-time queue is transmitted to the mobile edge cache both when the high-bandwidth link is established and when only the low-bandwidth link is available.

6. To provide network connectivity to a client device within multiple mobile environments in order to connect the client device to multiple mobile edge caches, wherein each mobile edge cache is integrated within one of the multiple mobile environments. When the aforementioned mobile environment is within range, a high-bandwidth link is established between each edge cache and one or more fixed high-speed network interfaces. When the aforementioned high-bandwidth link is unavailable, a low-bandwidth link is established between each edge cache and one or more low-speed network interfaces. The content provider stores content titles owned by the content provider in a fixed cache, and the content titles are distributed to the multiple mobile edge caches. A method in a multifactor analysis engine that evaluates data relating to content usage across a plurality of mobile edge caches to determine the priority for sending the content titles to each mobile edge cache, wherein low-priority content is provided to the mobile edge cache when the high-bandwidth link is established, and high-priority content is provided to the mobile edge cache even when only the low-bandwidth link is established.

7. The method according to claim 6, wherein the multifactor analysis engine includes a machine learning engine for determining the priority based at least in part on the number of cache misses associated with one or more content titles.

8. The method according to claim 7, wherein the multifactor analysis engine determines the priority based at least in part on data relating to when each content title is likely to be viewed.

9. The low-priority content is provided to the mobile edge cache via the bulk queue, The method according to claim 8, further comprising providing the high-priority content to the mobile edge cache via a real-time queue.

10. The method according to claim 9, wherein the content from the bulk queue is transmitted to the mobile edge cache only when the high-bandwidth link is established, and the content from the real-time queue is transmitted to the mobile edge cache both when the high-bandwidth link is established and when only the low-bandwidth link is available.

11. A non-transient machine-readable medium having program code stored on the non-transient machine-readable medium, wherein when the program code is executed by a machine, the machine, To provide network connectivity to a client device within multiple mobile environments in order to connect the client device to multiple mobile edge caches, wherein each mobile edge cache within one of the multiple mobile environments is integrated and provides the connectivity. When the aforementioned mobile environment is within range, a high-bandwidth link is established between each edge cache and one or more fixed high-speed network interfaces. When the aforementioned high-bandwidth link is unavailable, a low-bandwidth link is established between each edge cache and one or more low-speed network interfaces. The content provider stores content titles owned by the content provider in a fixed cache, and the content titles are distributed to the multiple mobile edge caches. In a multifactor analysis engine, the data is evaluated in relation to content usage across multiple mobile edge caches to determine the priority for sending content titles to each mobile edge cache, with low-priority content being provided to the mobile edge cache when the high-bandwidth link is established, and high-priority content being provided to the mobile cache even when only the low-bandwidth link is established. A non-transient, machine-readable medium that enables the execution of processes including those mentioned above.

12. The non-transient machine-readable medium according to claim 11, wherein the multifactor analysis engine includes a machine learning engine for determining the priority based at least in part on the number of cache misses associated with one or more content titles.

13. The non-transient machine-readable medium according to claim 12, wherein the multifactor analysis engine determines the priority based at least in part on data relating to when each content title is likely to be viewed.

14. The low-priority content is provided to the mobile edge cache via the bulk queue, The non-transient machine-readable medium according to claim 13, further comprising program code causing the machine to perform the operation of providing the high-priority content to the mobile edge cache via a real-time queue.

15. The non-transient machine-readable medium according to claim 14, wherein the content from the bulk queue is transmitted to the mobile edge cache only when the high-bandwidth link is established, and the content from the real-time queue is transmitted to the mobile edge cache both when the high-bandwidth link is established and when only the low-bandwidth link is available.

Images