Microcache method and apparatus for mobile environment with variable connectivity

The microcache method and apparatus within the CDN system addresses the challenges of variable connectivity in mobile environments by strategically preloading content, ensuring efficient and timely delivery and enhancing user experience.

JP2025060649AActive Publication Date: 2025-04-10NETSKRT SYSTEMS INC
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
JP2024214255
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2020-04-30
Filing Date
2024-12-09
Publication Date
2025-04-10
Estimated Expiration
2040-05-01

AI Technical Summary

Technical Problem

Existing content delivery systems struggle to meet customer expectations in mobile environments with variable and limited connectivity, such as airplanes, trains, and ships, due to network congestion and bandwidth constraints.

Method used

The implementation of a microcache method and apparatus that utilizes a content delivery network (CDN) with strategic cache placement and dynamic address allocation, along with capacitors and transparent caches, to preload content behind congestion points and ensure timely data transfers.

Benefits of technology

This solution effectively addresses network congestion and bandwidth limitations by preloading content in strategic locations, ensuring efficient and timely content delivery to mobile environments, thereby enhancing user experience and meeting customer expectations.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025060649000001_ABST
    Figure 2025060649000001_ABST
Patent Text Reader

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
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of the following provisional patent application: U.S. Provisional Patent Application No. 62 / 842,383, filed May 2, 2019; No. 62 / 842,397, filed May 2, 2019; No. 62 / 842,408, filed May 2, 2019; No. 62 / 842,414, filed May 2, 2019; No. 62 / 842,427, filed May 2, 2019; No. 62 / 842,446, filed May 2, 2019; No. 62 / 842,447, filed May 2, 2019; No. 62 / 842,457, filed May 2, 2019.

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

[0003] FIELD OF THEINVENTION FIELD OF THE DISCLOSURE

[0002] Embodiments of the present invention relate generally to the field of content distribution over networks, and more specifically to a micro-cache method and apparatus for mobile environments with variable connectivity. [Background technology]

[0004] Many businesses have a need to provide WiFi to their customers in mobile environments. For example, many airlines, cruise ships, bus fleets, and train systems provide WiFi to their passengers. However, given the variable connectivity and minimal bandwidth during transit in these mobile environments, achieving customer expectations is becoming increasingly impossible.

[0005] A typical household streams in the range of 500GB / month of content across multiple devices. Consumers are beginning to expect the same level of network access when traveling, but current systems make it difficult to deliver given the passenger volume and low bandwidth connectivity in these environments. A better understanding of the present invention can be obtained from the following detailed description taken in conjunction with the following drawings. [Brief description of the drawings]

[0006] [Figure 1A] 1 illustrates one embodiment of the present invention for securely and efficiently delivering media content to a mobile environment configured with a "strand" network. [Figure 1B] Several embodiments of the present invention are described for connecting a mobile edge device to one or more cache systems. [Figure 1C] 1 illustrates several embodiments of the present invention for connecting a mobile edge device to one or more cache systems. 2 illustrates an embodiment of the present invention, including a condenser and a content delivery network (CDN). [Diagram 2] Additional features include assigning a Content Service Provider (CSP) address to the mobile environment. [Diagram 3] Additional features include the use of Interior Gateway Protocols (IGPs) and Border Gateway Protocols to manage network connectivity. [Figure 4] 1 illustrates an embodiment that includes an Internet Service Provider (ISP) cache for storing content service provider content. [Diagram 5] 13 illustrates further details of an embodiment including a capacitor and a CDN node. [Figure 6] 1 illustrates an embodiment including a transparent cache (TIC). [Figure 7] 1 illustrates an embodiment in which a CSP cache stores content from a variety of sources, including content providers. [Figure 8] 2 shows further details of one embodiment of the present invention; [Figure 9] 1 illustrates the interaction of a capacitor with a TIC in one embodiment. [Figure 10] 1 illustrates one embodiment for redirecting a client request to a local cache. [Figure 11] 1 illustrates an exemplary embodiment having multiple antennas for providing content to TIC on trains. [Figure 12] 1 illustrates one embodiment of a hierarchical structure for propagating content. [Figure 13] 1 illustrates one embodiment of an architecture for implementing a microcache. [Figure 14] 1 illustrates one embodiment of a microcache architecture including dynamic address allocation in a local network. [Figure 15] 1 illustrates an embodiment that uses a predicted travel path of a mobile environment. [Figure 16] 1 illustrates an embodiment including different connections to a local cache in a mobile environment. [Figure 17] 1 illustrates one embodiment of an architecture for delivering content to a mobile environment. [Figure 18] 1 illustrates one embodiment for managing cross-border content distribution. [Figure 19] 1 illustrates one embodiment of a CDNE cache hierarchy and techniques for monitoring cached content. [Figure 20] 1 illustrates an embodiment in which a shared ledger is used to authenticate cached data. [Figure 21]1 illustrates an embodiment in which content is collected from a strand network. [Figure 22] 1 illustrates an embodiment including multiple fixed and movable edges. [Figure 23] 1 illustrates an embodiment in which a CDN extender obtains video-on-demand data and delivers the video to a mobile environment cache. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention described below. However, it will be apparent to one skilled in the art that embodiments of the 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 underlying principles of embodiments of the invention.

[0008] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention satisfies end-users' expectations to stay connected anytime, anywhere, even in remote locations and on the go where bandwidth is traditionally limited. Specifically, intelligent caching techniques are described that host content in strategic locations. In one embodiment, caches and associated content delivery networks (CDNs) solve network congestion limitations by preloading content behind congestion points.

[0009] To function properly, existing caching and CDN technologies require continuous, high-speed connectivity that is not available in mobile environments such as planes, trains, buses, and cruise ships. As a result, these businesses are increasingly at a disadvantage, creating pent-up demand for solutions within a very large market.

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

[0011] In one embodiment, the CSP manages each mobile environment as a connected sub-network of the CSP's network collection. In one example, this is accomplished by defining IP sub-networks. Specifically, the mobile environment is configured as a routable IP sub-network that can be reached either through a low-speed communication channel (e.g., a satellite link or a 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, a routing protocol, such as an Interior Gateway Protocol (IGP), is used to advertise the existence of new routes to subnetworks, where a lower priority route is always available through a slower network.

[0013] The CSP places these high speed networks in strategic locations that are known to be passed through by the mobile environment, and the CSP can ensure that content can be transmitted to the mobile environment upon establishment of a high speed connection. This can be accomplished in a number of ways for the various aspects of the present invention. > Sufficient connectivity to edge locations + high speed connections can be designed to ensure timely data transfer. > Data can be sent to an edge location awaiting further transfer to the mobile environment upon establishment of a high speed connection.

[0014] In one embodiment of the present invention, an existing Content Provider Cache (CPC) may be centrally hosted by a CSP according to requirements specified by the content provider. By way of example and not limitation, a Netflix Open Connect Appliance (OCA) may be installed and hosted by a 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) may initiate scheduled peer fills from the central cache. Peer fills may be either immediately scheduled or predictable.

[0015] In another embodiment of the invention, an intermediate storage device, hereinafter sometimes referred to as a "condenser" device, holds data designated for one or more mobile environments. The locally connected mobile environments include a content distribution node (CDN) that downloads content from the condenser when in range of a high speed connection.

[0016] As discussed below, in certain circumstances, CDN nodes in the mobile environment upload content to the condenser. For example, a particular condenser configured in a remote location may not have a high-speed link to the CSP network. In such a case, when a mobile environment with many CDN nodes comes within range (e.g., a cruise ship), the condenser can obtain 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 network as a mechanism for the CSP, which is particularly beneficial for large data sets that may take days or weeks to transmit.

[0017] In one embodiment, the CDN node brokers one or more cache types that may be associated with the mobile environment, such as the 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 local copies to the mobile environment in a predictable manner where connectivity is extracted from the cache. This allows scheduled cache fills from caches such as Netflix and Google, as well as other more flexible mechanisms.

[0018] The condenser of the CSP network hosts the pooled content at rest. In one implementation of the invention, this content may be owned by other parties (e.g., Netflix) and requires visibility to where it has been replicated and distributed. For example, certain content providers, such as Netflix, require knowledge of where all copies of the content are stored. Each copy distributed by the condenser to a CDN node, and the CDN nodes that distributed to caches, may be recorded so that all storage locations are known and reported to the content provider. Additionally, one embodiment provides techniques to purge content (e.g., invalidate encryption keys used to decrypt the content) as needed. A. Content Delivery Network Extender (CDNE) Embodiments

[0019] FIG. 1A illustrates a content delivery network extender 110 (hereinafter "CDN extender" or "CDNE") that includes circuitry and logic for providing content delivery support to a strand network 130. As used herein, a "strand network" 130 includes any form of local network (wired and / or wireless) with a concentration of users 152 during certain time periods and with limited backhaul connectivity to the Internet (e.g., in a transportation vehicle) that overlaps these time periods. A 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, with Wifi / cellular connectivity and limited backhaul. A 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 ingest logic 111 for obtaining content from a content channel 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 the transformed content to local CDN extenders 135 on each strand network 130.

[0021] In one embodiment, CDN extender 110, along with multiple local CDN extenders 135 configured within strand network 130, augments temporary lack of connectivity with high speed access points located in strategic locations where strand network 130 is known to enter / pass through, for either deterministic or non-deterministic periods of time.

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

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

[0024] In different embodiments, local storage 142 may be transparently managed and / or configured as an addressed cache. The IP addressing techniques described herein allow content providers to geolocate local storage 142 and can be used to direct traffic for specific consumers / apps to specific CDNs (including CDN extender 110).

[0025] As shown in Figure 1A, content can be obtained 105-106 either through CDN partners 101-102 or directly from a content channel (e.g., Netflix, Hulu). 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 within the CDN extender storage 115 and within the local storage 142 on each strand network 130. In the other direction, the control channel 107 allows 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 over the content channel 190 and / or a high bandwidth connection to the content delivery network 101-102. In one embodiment, the ingestion logic 111 stores the content in the CDN extender storage 115 and indexes the content as needed. The ingestion logic 111 operates based on variables such as consumer feedback (e.g., from the strand network 130), content provider requirements (e.g., as specified in a 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 to create a master content cache. The CDN extender storage 115 may include a portion of the master content cache or the entire master content cache, depending on the implementation. For example, in a small implementation, there may be a single CDN extender 110 with a single master CDN storage 115. Alternatively, the CDN extender 110 may be one of several CDN extenders linked together in a peer-based and / or hierarchical arrangement. In the latter case, a master content cache may be located at the top of the hierarchy, with individual CDN storage caches 115 of the various CDN extenders 110 pulling from the master cache as needed, potentially sharing content among other peers (e.g., other CDN extenders) and various strand networks 130.

[0027] As described below, the analytics logic 112 may evaluate the aggregate demand across all edge / strand networks and prioritize both content delivery and content retention based on that analysis. In one embodiment, the analytics logic 112 performs predictive / selective delivery based on a variety of data points, which may include, but are not limited to, demographics, geography, destination, edge performance characteristics, and content requests.

[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 lower bitrate versions and have the distribution logic 114 distribute the lower bitrate versions over a network 130 that has limited storage and / or bandwidth capabilities.

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

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

[0031] In various embodiments, the distribution logic 114 may operate according to schedules associated with the live 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 distribution 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. This may include, for example, local storage device 142 volume size (e.g., 1TB, 2TB, 5TB, etc.), static utilization of content (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 analytics driven).

[0033] It should be noted that the terms "logic," "module," and "engine" are used interchangeably herein to refer to various functional components (e.g., analysis logic 112) illustrated in the figures. In one embodiment, these components are implemented by program code stored in memory that is executed by a processor to perform the described functions. These functional components may also be implemented in hardware (e.g., application specific circuitry 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 in a mobile transportation environment, where content is ingested into a CDN extender, delivered to the mobile environment, managed on a remote cache, and then made transparently consumable by end user applications.

[0035] 1B illustrates an exemplary embodiment in which CDN extender 110 operates as an Internet service provider for an organization such as a train operation, an airline, a bus operation, a cruise / ferry operation, or any other operation that includes a strand network 130. In the particular embodiment described below, strand network 130 is incorporated into a transportation vehicle. However, it should be noted that the underlying principles of the present invention may be implemented with strand network 130 of any form.

[0036] In the illustrated example, the strand network is configured with mobile edges 185 that periodically connect to one or more fixed edges 184 via a high speed network 161. A variety of different types of wireless communication devices, wired transceivers, protocols, servers, etc. 102, 103 may be used to form the physical high speed connections, including 802.11 protocols (WiFi) and Gigabit Ethernet protocols. When a transportation 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 fixed edge 184, high speed network 161, and mobile edge 185. One embodiment relies on scheduled connectivity and sufficient connectivity to complete a cache fill, which is defined by peer fill X=Y as shown in FIG. 1B.

[0038] Alternatively, or in addition, third-party cache 157 peers with connected third-party cache 115 via fixed edge 184, high speed network 161, and mobile edge 185. Again, an embodiment relies on scheduled connectivity and sufficient connectivity to complete peered cache fills, which is defined by peer fill X=Y.

[0039] One embodiment includes a system and apparatus for temporally and spatially aggregating connectivity to mobile caches. Specifically, this embodiment includes a strand network 130 in a mobile environment that may come and go non-deterministically. Local storage devices are coupled to the strand network, and a new set of network management operations are implemented to distribute IP addresses in the mobile environment and accommodate the needs of various content providers.

[0040] 1C illustrates an exemplary embodiment in which connectivity is enhanced at both the condenser 510 (at 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 in each device. In one embodiment, the high speed network 161 may be significantly faster than the network connecting the condenser 510 to the CSP network 152 via the fixed core 159. By storing cache data in the condenser 510, a priori, the maximum speed available on the high speed network 161 can be achieved, and multiple mobile environments 150 can be updated simultaneously and / or continuously from the same condenser 510.

[0041] For example, in one example, the curated cache 155 sends its content to one or more condensers 510 in one or more locations. Then, when the mobile environment 150 approaches a particular fixed edge 184, a 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 condenser 510 and then downloads the content currently stored in the condenser 510. The CDN node 119 in this embodiment is responsible for managing incremental downloads. For example, the mobile environment 150 may interrupt two or more fixed edges 151 for a period of time. Each interruption may only facilitate a partial transfer of data. Once a full transfer to the CDN node 119 is completed, the TIC 196 receives successive peer fills from the CDN node 119. This may be defined by the formula incremental peer fill X=ΔY.

[0042] In one example, the third-party cache 157 peer-fills its content to one or more condensers 510 in multiple locations. Then, as the mobile environment 150 approaches a particular fixed edge 184, a 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 condenser 510 and then downloads the cached content stored in the condenser 510. The CDN node 119 is responsible for managing the incremental downloads (e.g., identifying content it does not have and requesting that content from the condenser 510). For example, the mobile environment 150 may break at two or more fixed edges 151 for a period of time, with each break facilitating only a partial transfer of data. Once the full transfer to the CDN node 119 is complete, the third-party cache 195 receives successive peer-fills from the CDN node 119. Again, this may be defined as an incremental peer-fill X=ΔY.

[0043] In one example, the 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 the mobile environment 150 is moving), cache fills from the trend cache 205 are possible over the low speed network 160. By way of example, the data in the trend cache 205 may be the most popular / most requested data as determined by the CSP 152. In this example, the fixed core 159 allows content from the trend cache 205 to be routed over the low speed network 160 to the mobile edge 185 and then to the CDN node 119. As mentioned above, the low speed 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, a peer fill X=Y to the TIC 196 and / or third party cache 195 is completed.

[0044] As mentioned above, in some cases, the condenser 510 may not have a high-speed connection to the fixed core 159. For example, the condenser 510 may be configured in a relatively isolated location through which the mobile environments 150 are expected to pass (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 condenser 510 via the mobile edge 185, the high-speed network 161, and the fixed edge 184. In one embodiment, this is accomplished by the condenser 510 and the CDN node 119 exchanging messages identifying cached content that is stored in the CDN node 119 but not yet stored in the condenser 510. The condenser 510 may then request such content from the CDN node 119 in priority order, potentially based on a popularity, or "most frequently requested" value, associated with each item of content in the CDN node 119. In this manner, the various mobile environments 150 become a distribution network for the fixed edge 184, and vice versa. That is, each mobile environment 150 provides new data as it passes through the condenser 510, and the condenser 510 may provide content to mobile environments that do not currently have that particular 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) and the high speed network 161. When the high speed network 161 is established, the mobile edge 185 communicates back to the fixed core 159 to which it is connected and accessible. In one embodiment, this is accomplished by the network router 201 issuing Interior Gateway Protocol (IGP) updates to the router 200 directly associated with the fixed core 159. For example, the router 201 of the mobile environment can 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 the 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] 2, a content service provider 152 may be assigned a large pool of IP addresses 202, some of which may be assigned to various mobile environments 150 (e.g., trains, ships, buses, planes, etc.) As discussed above, this may be accomplished by defining a different sub-network for each mobile environment 150 and assigning all of the IP addresses within that sub-network to the mobile environment.

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

[0049] 3 highlights how IP addresses in mobile environment 150 establish routable connections to CSP 152 even when moving from first high speed network 161 to second high speed network 311. Specifically, IGP router 302 recognizes that high speed network 311 has been established and propagates its local subnetwork information to IGP router 301 in CSP network 152. CSP 152 may use the updated IGP router 301 to route packets to mobile environment 150. Note that prior to the establishment of high speed network 311 (e.g., while mobile environment 150 is moving), IP addresses may still be routed through low speed network 160.

[0050] FIG. 4 illustrates an example of content cache management in this environment. In this example, a particular third-party cache 410 is located within the mobile environment 150 and is part of the CSP subnetwork (i.e., has an IP address range assigned by the CSP). In one embodiment, the CSP 152 identifies a range of subnetwork addresses proximate to the third-party cache via a BGP peering link 203 back to the third-party content provider 401. The CSP 152 also deploys a third-party cache 402 within the CSP 152 to act 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 upon events such as scheduled or unscheduled peer fills.

[0051] In one embodiment, a request to access content from a user device in the mobile environment 150 may be initially routed to the content provider 401 over the low-speed network 160. As a result of the BGP peering connection 203 providing the content provider 401 with network connectivity information 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). Redirection by the content provider also requires that the user be authenticated with the content provider 401 to be 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) to look up an association between the user's IP address and the mobile cache 410 (which is in the same sub-network). Subsequent communications may then be directed to the mobile cache 410.

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

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

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

[0055] In an embodiment where the content of the ISP cache 402, 602 is trusted and may be hosted in a transparent cache (TIC) 610, the TIC 610 may have a complete representation of the ISP cache 402, 602. "Authorized peer fill" refers to the ability of the ISP cache 402, 602 to share its content with the TIC 610. The condenser 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 the mobile environment 150 requests content from a third party content provider 401, 601 (e.g., Netflix), a request is made to the content provider 401, 601 over the Internet 200. The content provider returns a reference to its ISP cache 402, 602, respectively, instead of the content physically located in the mobile environment 150. In this embodiment, IP addresses in the mobile environment 150 are not differentiated. The BGP peering connection 203 advertises to the Internet all of the addresses of the CSP 152, including the content providers 401, 601. Furthermore, the closest cache is the ISP cache 402, 602. Thus, when a user device attempts to connect to the ISP cache 402, 602, the transparent cache 610 needs to know only this destination address and can securely intercept the request, redirect it, and serve it from its local copy of the content.

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

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

[0058] 8 illustrates an embodiment in which a centralized cache management controller 850 managed by the CSP 152 makes decisions regarding the particular 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 as described above). In addition, the cache management controller 850 determines when and how to fill content for each of the condensers 510 based on a specified cache management policy 870. For example, the cache management policy 870 may indicate a particular rate at which the local cache 815 is filled and / or a particular period during which local cache filling occurs (e.g., in the middle of the night when bandwidth is available). The cache fill policy 870 may be specified by user requests and / or feedback from the content providers 401, 601 (e.g., Netflix). For example, if a particular video is frequently watched by users, 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 designated 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 in the various condensers 510 through communication with corresponding local cache managers 812. In one embodiment, each local cache manager 812 may implement its own local cache policy 870 to establish communication with the TIC administrators 822 of the different transport vessels / vehicles 820 to fill their respective TICs 825 with content. In one embodiment, the interfaces 828, 818 include high-speed wired or wireless links (as described above with respect to the high-speed network 161) that operate at full capacity (e.g., 30 GB / s, 100 GB / s, etc.) as soon as the transport vessels / vehicles 820 arrive at or pass through the condenser 510. By way of example, and not limitation, the fixed content distribution locations in which condensers 510 are configured may be train stations, bus terminals, cruise ship ports / terminals, or airport terminals / gates. Additionally, in certain embodiments described herein, condensers 510 are strategically positioned at locations along known routes that various transportation vessels / vehicles 820 may traverse.

[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 a content provider 401, 601, for example, by logging into Netflix and attempting to stream a particular movie. If a connection over the Internet 200 is available, the content provider 401, 601 receives the request, identifies the user device 827 as operating within the content service provider's 152 content delivery network (e.g., based on a dynamic network address assigned to the user device 827), and sends a redirect message instructing the user device 827 to connect to a CSP cache 710 (e.g., a Netflix OCA cache). Upon 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 cached locally in the TIC 810 and redirect the request to the TIC 810.

[0061] The user device 827 then streams the content from the TIC 810 over a local wireless connection provided by the connection manager 823 (e.g., a local WiFi connection). Thus, even if the passenger transport vessel / vehicle 820 is out of range of the Internet 200 (e.g., a cruise ship at sea, a train traveling through mountainous terrain, etc.), the user device 827 still has local access to authorized content. Alternatively, if an Internet connection 200 is available, content is streamed from the local TIC 810, although only the initial user request and / or user authentication may be sent over this link (a relatively low bandwidth transaction).

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

[0063] Some embodiments of the present invention include systems and devices for implementing 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 a different communication protocol and / or technology. D. Implementing high-speed links to the mobile environment

[0064] 9 illustrates a configuration in which multiple transparent caches (TICs) 610 configured in different types of transportation vessels / vehicles are periodically updated via a high-speed network link 161 established with multiple condensers 510. As described above, the content service provider 152 fills the cache in each of the condensers 510 according to a cache-fill policy 870. For example, the cache management controller 850 may deliver content in response to content usage data received from the content provider and / or from the 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 content for individual condenser locations and / or individual TICs.

[0065] As mentioned above, the content service provider 152 may deploy high speed networks and condensers 510 in multiple strategic locations for customers and / or specific industries. Each of the condensers 510 is updated from the centralized cache management controller 850 via the cache distribution network as described above. It is important that all of the associated condensers 510 have consistent data so that each vessel / vehicle 820 can consistently request data whenever it connects.

[0066] In one embodiment, the various TIC components described above are deployed on the transportation vessel / vehicle 820 as a network appliance with memory for storing program code and data, a processor for executing the program code and processing the data, and a mass storage device for implementing the TIC storage, such as one or more sets of hard drives. One or more other network interfaces may also be included and used while the vessel / vehicle 820 is in motion (e.g., satellite service, cellular service, long range WiFi, etc.). The appliances 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 (e.g., for 50 streaming sessions, $1000 per 30TB storage array may be sufficient, but for 1000 streaming sessions, $10,000 / 30TB storage array may be required).

[0067] In one embodiment, the appliance may be located in a single or multiple physical components. At one extreme, the appliance is a single server, and at another extreme, the appliance is a rack of servers. This is because the core functions of TIC can be differentiated as a) management functions, b) cache management, c) packet interception / redirection of packet flows, and d) providing services (through redirection) for video requests from clients. As a result, the entire functionality can be contained within a single server, or can be differentiated / scaled by one or more servers for each function. The underlying principles of the invention are not limited to any particular configuration.

[0068] Figure 10 provides an overview of an exemplary transaction through one embodiment of the Connection Manager 823 of the TIC 610. A promiscuous Terminal Access Point (TAP) 1010 monitors packets / flows on the network and after some analysis, a positive lookup in the cache triggers a redirect (1003). The client then requests the content again from the local redirect http server 1020, which provides the content from the local TIC 610. In one embodiment, the Connection Manager 823 monitors for out-of-band high speed connectivity via interface 828 and then downloads cache updates whenever and wherever possible.

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

[0070] Some example functions of the central management component 895 include software updates, network operation user and / or customer notifications, status monitoring including reporting functions for CPU, memory, storage, and network utilization, and LAN management tools to determine the number of devices in a stream and how the LAN is performing (e.g., to identify bottlenecks).

[0071] 10, one embodiment of the promiscuous TAP 1010 uses an Ethernet port running in promiscuous mode. In this embodiment, access is provided to an Ethernet LAN segment across which all traffic traverses. The promiscuous TAP 1010 listens to all traffic but passes through traffic that is not associated with an associated web request.

[0072] In one embodiment, the promiscuous TAP 1010 uses a Data Plane Development Kit (DPDK) library for managing packets to perform functions such as a 5-Tuple Hash that distinguishes flows, timestamps, and maintains packet order, and supports hardware assistance. In this embodiment, packets read from the promiscuous port are classified, timestamped, and dropped or scheduled in a FIFO for processing. A multi-threaded architecture may be used.

[0073] In one embodiment, once a hashed stream is identified, the URI is extracted and checked against the TIC database. If there is a match, both the source and destination points of the stream are reset with a FIN packet. But first the source of the request is sent an HTTP 1003 which 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 behind which multiple servers are load balanced.

[0074] In one embodiment, an efficient "cache information base" (CIB) is maintained that mirrors the actual TIC database to efficiently determine if a requested entry exists locally. Once the TIC is loaded into the appliance, various functions need to quickly look up content. In one embodiment, packets destined for the appliance (e.g., management and redirected cache hits) are forwarded to the management functions or to the TIC. They are essentially ignored by the promiscuous TAP 1010.

[0075] Assuming that wireless technology is used for the high speed link 161, a typical MIMO implementation with an 80Ghz band will achieve 655Mbps. 4XMIMO could achieve 2.4Gbps. 24Ghz and 60Ghz radios may also be considered. Products exist with radios at 2.4Gbps in the 24Ghz spectrum and 6-10Gbps in the 60Ghz band. In all cases, link aggregation may be used to aggregate multiple wireless connections (taking advantage of GPS synchronization, frequency spacing, and signal isolation) to increase this number. Conceivably, this could provide a throughput in the range of 10-50Gbps.

[0076] As shown in Figure 11, in one embodiment, each fixed content distribution location, such as a train station, airport terminal, bus depot, or cruise ship terminal, has multiple antennas 1101-1105 aligned with 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 transmit content from the local capacitor 815 simultaneously over multiple links, potentially achieving N times the bit rate of a single wireless link (where N is the number of antennas).

[0077] Although a train embodiment is shown in FIG. 11, similar configurations may be configured for ships, planes, and buses. A particular embodiment 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 stops at this location for a sufficient period of time. In either case, partial updates to the TIC may occur each time the vehicle / ship stops near or passes another capacitor (e.g., at each train station).

[0078] As shown in FIG. 12, an embodiment includes one or more distribution gateways 1200-1203, which are repositories of content that is pushed to condensers 1201-1203. Each distribution gateway (DG) 1200 may be located regionally (e.g., West Coast, East Coast, Midwest, etc.). When a condenser 1201-1203 initializes, it attempts to register with the DG closest to it (e.g., West DG if located in California). These regional DGs may be identified via DNS scoping (e.g., condenser 1201 may connect to a Vancouver-based DG versus a New York DG due to 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 is requested / pushed by the condensers 1201-1203. Given the size of the cache data set, efficiencies such as multicast can be used to stream content through the cache hierarchy.

[0080] In one embodiment, all condensers 1201-1203 on-site register with the DG 1200. When including some exchanged data set, they need to check for data that needs to be sent to a particular condenser 1201-1203. As new data is curated in the CSP cache 710, each DG 1200 initiates the transfer to its registered condensers 1201-1203. This may be implemented as a push or pull transaction (or both). Scheduling requirements for each condenser 1201-1203 may play a role in the particular push / pull configuration. In one embodiment, the condensers 1201-1203 are notified when new content is available and then need to request the data.

[0081] In one embodiment, each condenser 1201-1203 is a server with enough storage to hold multiple cache data sets (or a single master cache data set, from which near derived data sets may be created). The primary purpose of the condensers 1201-1203 is to have as much data as possible at the high speed network edge. It may receive requests from single or simultaneous CDN nodes 1220-1230 (and / or TICs) and can fill the available pipe.

[0082] When a CDN node 1220-1230 (and / or TIC) connects to a condenser 1201-1203, the CDN node identifies itself and requests the latest updates to the itinerary. The CDN node may identify itself based on, for example, vehicle / vessel, customer ID, etc. Based on this, the condenser 1201-1203 provides the CDN node 1220-1230 with the appropriate itinerary specific to the device. The CDN node then evaluates the itinerary and compares it to what is currently downloaded and what still needs to be downloaded. It then requests the specific elements from the condenser 1201-1203.

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

[0084] In one embodiment, each condenser 1201-1203 may declare its inventory assets, provisioning locations, etc., and request identities of all prospective customers and / or corresponding CDN nodes that may be in proximity to the condenser 1201-1203. For example, in one embodiment, the central management component 895 maintains an account database 1240 that identifies all CDN nodes / TICs and associated customers, and the associations of these CDN nodes / TICs / customers with one or more condensers 1201-1203.

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

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

[0087] Condensers 1201-1203 wait for registration requests from the high speed network (e.g., for an arriving ship, bus, train, or plane). Once a request is received and authenticated, a download service is initiated to the remote CDN node / TIC to download the new content. In essence, once authorized, the download may be performed in a manner similar to an FTP service. The structure of the cache data set should be considered as tuple sets and blocks of tuple sets. The CDN node / TIC knows what has been received elsewhere and is responsible for maintaining continuity between download sessions. The condensers 1201-1203 in this embodiment may simply be responsible for making tuple sets available to the CDN node / TIC.

[0088] Capacitors 1201-1203 should be able to handle more than one TIC at a time. Distinctly different capacitor configurations have different constraints in terms of concurrent download sessions. The main constraint is the available network capacity. In a scenario where many CDN nodes / TICs may make concurrent requests, a rack of servers may be used, with each server supporting two or three download sessions, all connected to a single storage array and high capacity switch. Overall, the rack can handle hundreds of sessions.

[0089] In one embodiment, a point-to-point / multipoint high speed network is used. Vehicles / vessels may connect to a point-to-point radio or a multipoint radio. The key difference between these is that large data sets are transmitted between two points. If more than one vehicle / vessel connects to the same access point, the total throughput is simply reduced. As with the example above, the maximum transfer speed is about 10 hours for 10TB. 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 in range, a wireless link is established. In one embodiment, the vehicle / ship station is configured as a DHCP client. The access point or a 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 / TIC 610 may constantly poll the capacitor 510 regardless of the state of the high speed link (e.g., if the capacitor 510 on a particular port can be polled, then it must be connected), or the TIC can make an API call to the station radio to determine if / when a link is present. The advantage of the latter solution is a more deterministic behavior vs. timeouts, which may be tied to a variety of reasons. The disadvantage is that a hardware abstraction layer may be required to deal with changing technology. Once a connection to the capacitor 510 is established, the TIC 610 proceeds with the cache update process described above. Of course, the underlying principles of the present invention are not limited to the particular way in which the connection between the capacitor and the TIC is made.

[0092] A point-to-point array high speed network exists because of an array of wireless connections that are link aggregated between the vessel / vehicle and the terminal where the capacitor 510 resides (as described above with respect to FIG. 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 creates a 25-50 Gbps high speed link. From a theoretical perspective, depending on the number of elements in the array, a 10 TB cached data set 725 can be transmitted in approximately 30-60 minutes, or a 30 TB cached data set 725 in 2-4 hours.

[0093] This solution would work particularly well on "long" vessels / vehicles such as ships and trains, as shorter vessels / vehicles may not provide sufficient separation between radio devices to allow multiple connections that do not interfere with each other at the radio level.

[0094] The array concept calls for a series of radios to be placed on the side of the ship / vehicle. Thus, in one embodiment, the radios are spaced at regular intervals at the terminal, so that when a train or ship docks, it will be vertically aligned with each corresponding radio. A 30-45 degree sector may be adequate to allow for some play (e.g., a stagger of a few tens of degrees is ideal, but may 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 another available SSID. This works fine if the vehicle / vessel is parked and then turns on its wireless device. However, if a wireless device is connected and the vehicle / vessel is stopped, it may result in a suboptimal wireless device maintaining a connection.

[0096] For example, if a ship has wireless devices s1, s2, s3, s4, and s5, and as the ship enters port, wireless device s1 establishes a connection to corresponding port wireless device p5. As it moves forward, it loses this association and connects to p4, p3, and p2. Finally, as it comes to rest, it may not shift to s1, resulting in suboptimal connections of s1-p2, s2-p3, s3-p4, and s4-p5. Neither s5 nor p1 will connect. One solution is for each wireless device to have a predefined 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 locate the capacitor 510. When the capacitor 510 is started, it registers itself with the management component 895, which in turn 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 condenser 510 via a management component 895, which may also provide various capabilities, monitor the attached high speed network, and perform other standard OAMP functions. The management component 895 identifies all known cached data sets suitable for the condenser 510. Additionally, the management component may set up a schedule for the condenser 510, which may be specified via the operator portal 740 and / or customer portal 741.

[0099] In one embodiment, the management component 895 is used to locate new CDN nodes / TICs 610. When a CDN node / TIC 610 starts up, it registers itself with the management component 895, which in turn adds the CDN node / TIC 610 to the database 640 and begins monitoring its status, cache contents, and connection state. The CDN node / TIC 610 may be provisioned to be in a monitoring mode or as an active cache. The management component 895 can push cache provisioning updates to the appropriate capacitors 510, which in turn triggers actions on the target CDN node / TIC 610 when it comes within range.

[0100] In one embodiment, CDN nodes / TICs 610 are configured to have their GPS locations reported periodically to management component 895. In one embodiment, the location of the CDN nodes / TICs can be tracked by a system operator and / or customer. 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 condenser 510.

[0101] New cache data sets may be generated periodically. At scheduled times, each customer cache update is scheduled and sent to the appropriate condenser 510. The mechanism for packaging the cache data sets is currently considered to be a single master cache data set with the itinerary associated with each customer / CDN node / TIC. Customers can log in via a web portal and enforce administrative policies 870 associated with their itinerary. For example, customers may select content specific to geography, language, or delivery stream.

[0102] As mentioned above, the trend cache is a special type of push operation that can be implemented over slow network links. This cache is automatically generated based on specifications, either from the customer or from other sources (e.g., the content provider itself). Constraints may be placed on the cache data set size. Scheduling data may also be required for its delivery and can be set by the customer via the customer portal. Latest news feeds need to be delivered in a timely manner. Directed to the TIC or globally via the condenser.

[0103] One embodiment includes an operator portal with a hierarchical GUI to display all currently active customers. When a single customer is selected, the GUI displays customer details; total number of condensers specific to the customer; status of that condenser; currently active cached datasets; number of CDN nodes / TICs currently connected, connected 1 hour ago, yesterday, last week, etc; error log for that condenser; high speed network, CDN node / TIC, etc; total number of cached dataset transfers to the condenser; and number of cached dataset transfers to the CDN node / TIC. Additional information that may be displayed hierarchically includes, but is not limited to: Total number of customer CDN nodes / TICs Location of each TIC Current status of TIC Total traffic generated by TIC Total cache misses by TIC Number of updates to cache data set 725 by TIC Average update time for cached data sets 725 Number of capacitors visited by TIC 510 Maximum number of devices connected to TIC Average number of devices connected to TIC statisCDN node / TIC related trip data Cached data set 725 / total number of trips Usage metrics for cached dataset 725 / itinerary. Efficiency of cache delivery (e.g., sending four cached data sets 725 for each download). The effectiveness of the cache dataset 725 relative to other customers / CDN nodes / TICs (e.g., 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 has an issue, they need to be able to see the history of requests they made. Where, what, when and what type of data. In some cases, have the ability to undo changes.

[0104] Thus, embodiments of the present invention contemplate placement of caches in mobile environments having various levels of connectivity, such as 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 cruise ships.

[0105] One embodiment of the system associates subnetworks of public addresses with different mobile environments (i.e., different ships / vehicles) and peers with content providers using BGP (or other protocols). The system associates the different subnetworks with deployed caches so that content providers can direct client devices to the local cache.

[0106] Client devices connect to content providers over any of the network links, and predictable connectivity is defined by time and location. In a particular location, where high-speed connections can be established for long periods of time, the connectivity is predictable if the mobile environment exists on a deterministic periodic schedule.

[0107] An embodiment of the system schedules cache fills by content providers during these scheduled periods so that connection speeds can be guaranteed to meet the content provider's requirements. While the diagram shows a single curated cache 155, an embodiment includes at least one cache per content provider to enable cache fills from which to peer. An embodiment provides connectivity to each high speed network back to the content caches used for peering.

[0108] Thus, embodiments of the present invention extend the concept of an ISP to include special connectivity to mobile environments that would not otherwise qualify as a) an ISP and b) a suitable connection location for cache fill. These embodiments also uniquely enable existing mechanisms to be localized to mobile environments by controlling IP addressing, distribution, and connectivity to content providers. Additionally, these embodiments uniquely define dual-homing connections to enable both en route and stationary connectivity, enabling unique aspects of the cache lifecycle.

[0109] As mentioned above, in some embodiments, the cache is also deployed 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 stop at several ports over the course of a few days, where cache fill may be performed. Since the duration of the stop at different locations may vary, it is difficult to complete the cache fill in one stop. Therefore, the cache may be incrementally updated at each stop, and the speed of the high-speed link from shore to the ship is set as high as possible to minimize the time required.

[0110] One embodiment uses condensers and CDN nodes to manage the non-deterministic nature of high speed networks. A condenser is a storage facility with one network connection used for cache distribution and one to a high speed connection used for forwarding content to the mobile environment. A CDN node is in the mobile environment and has one connection to the high speed network and one to the mobile environment. Its role is to fully receive cache updates from one or more condensers across one or more locations and over a discrete period of time. Once content is aggregated, the CDN node can perform scheduled cache fills with a local cache device. The local content cache believes it is operating on a consistent schedule despite several outages of the mobile environment to complete.

[0111] Many condensers are located in many locations and can provide cached content bit by bit over slower network connections for cost-effectiveness. Thus, there is a relationship of many mobile environments to many condenser locations. Transient connections drive updates of mobile environment caches. When a cache is updated, the address domain of the cache informs the content provider which cache serves which client.

[0112] Thus, embodiments of the present invention uniquely enable environments that cannot deterministically meet cache placement requirements by aggregating connectivity over time and space to shift update requirements to a local mobile environment. If enough connectivity events can be guaranteed between periodic cycles to aggregate content in the local environment, the local cache can meet its cache fill requirements without knowing that it does not have limited connectivity. Multiple caches from multiple content providers can be filled by these techniques.

[0113] One embodiment deploys CDN nodes / TICs that provide content caching in a highly scalable implementation. Based on the above implementation, deploying a large number of caches can start to become uneconomical because (1) existing caches target 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) that contains content from one or more content caches can address these issues. For example, a single transparent cache can utilize the high-speed network mechanisms described above to keep the cache up-to-date for multiple content providers. Furthermore, in an ISP model, a single addressable cache may be identified to handle the entire address domain of users. For example, thousands of end-user devices can all be associated with a single cache and logistics shared with the content provider via BGP. In the system described herein acting as an ISP, hundreds of transparent caches may be deployed that intercept traffic targeting the exposed cases (and thus intercept requests locally). These transparent caches then scale well beyond existing mechanisms. Additionally, because 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 particular content channel introduces content and security certificates. If Netflix is ​​permitted to deploy a transparent cache with content corresponding to the CPC, as reported, TLS encryption may be used for content delivery. As a result, a Netflix-signed certificate is required to intercept and serve requests. If the same content approved from Netflix is ​​used as with the upstream CPC, all requests to that CPC are valid cache hits. Each flow initiated to a known CPC may be intercepted and followed by a 303 redirect to the device to fulfill the request locally. The redirected request establishes a TLS session with the transparent cache, which is powered by the Netflix certificate, thereby providing Netflix a level of control over the delivery of its content. The 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 a number of constructs to ensure that the way the content is accessed is not outside of their explicit control.

[0116] In a pure transparent cache environment, where cache data is curated in one region and deployed in another, it is necessary to understand which requests are collectively the same. For example, there are over 6500 CPC caches deployed globally. In some cases, each transparent cache present in the mobile environment needs to consider all 6500 addressable locations to see if a request is for a locally stored content segment. One embodiment crawls the Internet for cache addresses and provides a list of addresses for comparison. Another embodiment applies contextual information of the transparent cache's location (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 system is the ISP of record, either explicitly or through an overlay network, the target cache addresses can be narrowed down to those cache addresses provided by the operator.

[0118] Given the above-mentioned nature of partly fast / permanently slow links, one embodiment of the present invention evaluates the urgency or importance of certain content and, in some cases, uses the slow links to fill the TIC. The portion of the TIC that contains this urgent / important content is referred to herein as the "trend cache."

[0119] One embodiment allocates a percentage of the low-speed bandwidth to the trend cache so that it is always filled with high-demand data, in some instances, all or a significant percentage of the low-speed bandwidth may be temporarily allocated to fill the cache with certain multimedia files that are frequently requested.

[0120] An embodiment uses a mobile environment to propagate content across the network. In the particular embodiment above, the condenser may be located in a remote location that does not necessarily have sufficient high-speed connectivity. For example, if a 100 Mbps link is the maximum that the remote port to the condenser can support, a 30 TB fill would take approximately 28 days. In contrast, a 15 Gbps link could be transferred in less than 5 hours. As a result, an embodiment establishes a high-speed connection with a passing ship / vehicle whenever it is possible to download the content from the temporary cache over the high-speed link. For example, a condenser may obtain content from a temporary cache on a ship that is traveling a day to another port. Then, a temporary cache on another ship traveling in the opposite direction can be updated more quickly from the remote condenser.

[0121] Thus, the Condenser includes two modes of operation: the Condenser always has a broadband connection, but <1G will be a maintenance connection and >=1G will be a cache-fill connection. If only a maintenance connection exists, the Condenser will be filled over the WAN. If a cache-fill connection exists, the Condenser will not be filled entirely over the WAN.

[0122] One embodiment of the Capacitor retrieves only data from a passing vessel / vehicle that is more up-to-date than the currently stored data. For example, if the Capacitor only needs image A, it will retrieve only image A from the passing vessel / vehicle. In contrast, a temporary cache on the vessel / vehicle may have old copies of images B and C, in which case it will retrieve these images from the Capacitor.

[0123] For example, the maintenance connection may be used to deliver metadata about the current cached data set. Images A, B, and C are considered up-to-date and the Condenser should have these images. When a CDN node connects with the local high speed network, the following protocol may be invoked: CDN Node - Do you have A, B, or C? Starts the download or continues the download from where the CDN node previously stopped filling. If the capacitor does not have A, B, or C, do nothing Capacitor - Do you have A, B, or C? If yes, the condenser starts the download or continues the download from the connected CDN node. If the capacitor already has A, B, or C, or if the CDN node has none, do nothing.

[0124] In one embodiment, a cache-fill connection is used for delivery of both the metadata and the actual data set. Depending on the speed of the link and / or availability of content, back-filling from a temporary cache on board the ship / vehicle may make sense.

[0125] On a 1Gbps connection, it would take 3 days to fill 30TB. If a vessel has a full link and 50% is downloaded over the WAN, it makes sense to calculate the percentage that can be downloaded over a 15Gbps link when it is available. One embodiment of the Condenser operates according to a set of rules / policies. For example, one requirement might be for the Condenser to download 1-50% over the WAN, while simultaneously downloading 51%-100% in reverse order over a high speed connection. It then determines when the entire cache has been completely downloaded.

[0126] Another embodiment may download some percentage (e.g., half) if a high-speed link is available. When complete, download the remaining half. When complete, download the half again (similar to a binary search algorithm). The cache in one embodiment is downloaded in segments, and any random point in time may result in loss of link. Thus, one embodiment includes checkpoint circuitry / logic to check the download (i.e., restart or continue as permitted).

[0127] One embodiment tracks all of the capacitors globally and all ships / vehicles that may cross these capacitors. Analysis can be done to determine how long it will take for all capacitors to be up to date. With a sufficient number of high speed network connections, all capacitors or all sizes can be refilled within 1-2 days.

[0128] Thus, using the above techniques, the vessel / vehicle becomes a mobile part of the network and is used to propagate updates to remote network components (i.e., remote condensers).

[0129] In existing ISP partner programs, cache providers such as Netflix and Google allow their own properties to be hosted by the ISP. The ISP can manipulate some of the logistical aspects of the deployment using various mechanisms, but ultimately, the only place the ISP can see the content is on the wire. The content is stored only on stationary over-the-top (OTT) provider devices.

[0130] For certain embodiments described herein to work, it is necessary that the OTT provider is willing to support pooling of content within the network (e.g., resting within the ISP infrastructure), e.g., within the condenser, CDN node, and CDN node / TIC. To make this arrangement 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 provided with the ability to track where their content is pooled. Furthermore, OTT providers are provided with the ability to delete pooled data and do not allow third parties to copy and / or extract pooled data.

[0132] With these prerequisites in mind, one embodiment of the present invention performs an additional layer of encryption on the content and provides a marker (e.g., a blockchain) within the data that verifies its authenticity. For example, each copy of the data may receive a unique blockchain entry and key, and decryption can only occur in the blockchain. If the data is deleted or removed, it becomes useless.

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

[0134] The above described embodiments of the present invention include caching techniques that operate in remote, potentially mobile environments such as airplanes, buses, trains, or ships. These techniques deliver large data sets to remote locations with predictable delivery times. By leveraging this mechanism, an effective caching solution can be provided that is compatible with the existing delivery mechanisms of Internet Service Providers and Media Service Providers.

[0135] Today, for example, Netflix and other providers use an ISP partnership model to distribute content across ISP networks to Content Provider Caches (CPCs), such as the Open Connect Appliances (OCA) deployed by Netflix. Although some embodiments described below focus on a particular media provider, such as Netflix, the underlying principles of the invention are not limited to any particular media provider architecture.

[0136] One embodiment of the present invention includes a micro-cache method and apparatus for mobile environments with variable connectivity. Particular implementations use a variety of techniques to deliver the Netflix cache to the mobile environment.

[0137] One embodiment of the present invention includes the following features: (1) an ISP (e.g., Netflix) hosts CPCs within and across their network; (2) the ISP communicates client IP addresses associated with deployed CPCs; (3) the ISP ensures that cache fills occur on a scheduled basis; and (4) if content is not available in the CPC cache, the ISP provides connectivity back to Netflix, where long-tail content is held.

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

[0139] 13 illustrates an embodiment in which the micro CPC cache system 1301 configured in the mobile environment 150 does not interface with the media provider 1310 as if it were in an ISP network. For example, rather than relying on a protocol such as BGP to distribute the current user's address to the media provider 1310, the on-board micro CPC system 1301 informs the media provider 1310 (e.g., Netflix) that (a) it has an on-board CPC cache that contains a particular data set, and (b) that cache is associated with an IP address pool 1320 that can then be associated with passengers (e.g., via a satellite or cellular network). In one embodiment, the address manager 1307 performs the IP address allocation in the micro CPC system. For example, if CSP 152 is associated with a particular range of IP addresses, such as 10.32.50.x to 10.32.63.x (where x designates any number allowed by the IP addressing scheme), then address manager 1307 may assign blocks of IP addresses, such as 10.32.50.0 to 10.32.50.800 or 10.32.50.x to 10.32.51.x, to mobile environment 150. In one embodiment, address manager 1307 dynamically assigns these address blocks to individual micro-CPC systems 1301, which then assign addresses within the allowed range to user devices 1321.

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

[0141] The micro-CPC cache 1460 may be filled directly from the media provider 1310 or may be filled through the CPC cache 1302 (e.g., where 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 implemented by the content service provider 152 and accepted / approved by the media provider 1310. A variety of different rules / policies for updating the micro-CPC cache 1460 are described above (e.g., as discussed with respect to the CDN node 520 and the transparent cache 610). Any of these techniques may be used to determine the particular set of media content to be placed in the micro-CPC cache 1460.

[0142] When a passenger contacts a media provider using the media provider's app, application, or browser (or other content channel) on the user device 827, the media provider 1310 searches for the nearest CPC cache 1302 as usual, but also searches for the nearest micro CPC 1460 if such device has registered itself. The media provider's app, application, or browser is then directed to the micro CPC cache 1460 (once credentials, DRM, Silverlight, etc. are all in place) instead of the CPC cache 1302 assigned to the CSP 152.

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

[0144] During operation, the user device 827 is dynamically assigned an IP address (e.g., using a media provider app) by the dynamic address assigner 1475. 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 the user device 827 is connected, it may access the Internet through a connection provided by a plane, train, ship, or bus. This may include, for example, a satellite connection, cellular service, and / or any other connection available in a mobile environment while on the move. When the user selects to access media content provided by the media provider 1310 (e.g., a Netflix show or movie), a request is sent to the media provider 1310 through the established Internet connection to authenticate the user device 827. The media provider 1310 may then use the IP address of the requesting device 827 or the connection manager 823 (which may be configured as an Internet router or gateway, for example) to identify a micro CPC cache 1460 in the same mobile environment. If the content is locally available in the micro CPC cache 1460, it then sends a redirect response to the user device 827 that includes the local IP address of the micro CPC cache 1460 (and / or the micro CPC manager 1470). If the content is not available locally, the response redirects the user device 827 to the CPC cache 1302 via an Internet link (or another CPC cache).

[0146] Thus, in the above embodiment, network fill operations from the 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 sent over a high speed network 161 that couples the mobile environments 150 to the CSP network via edge / router devices 1304, be they at train stations, docks, terminals, etc. Regardless of the technology used to fill the micro-CPC systems 1301, the media provider maintains full visibility and control of 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 fact, depending on the nature of the environment, the media provider may offer a constrained user portal that is limited to the content available in the micro-CPC cache 1460. Thus, in this example, passengers / customers do not request content that is not available on the cache.

[0148] In another embodiment, the same data set is populated into a transparent cache, such as the TIC 810 described above with respect to FIG. 8. Rather than directing clients to an on-board 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 CSP 152. The transparent cache intercepts media requests targeted to the CPC cache 1302, determines whether the media content is stored locally, and if so, serves the content locally. In this case, the IP range may be sent to the media provider 1310 via BGP (or other protocol). Note, however, that in contrast to the micro-CPC cache 1460, the media provider 1310 has no access or control over the transparent cache. The advantage, however, is that these transparent caches propagate media content much faster than the micro-CPC cache implementation. In a transparent cache model, a content service provider (CSP) 152 may inform a media provider 1310 that only certain IP addresses have access to CPC cached content, thus triggering 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 where a customer downloads a content catalog from a media provider 1310 that is aware of the content present on the micro-CPC cache 1460 or a transparent cache, or a distributed approach where a network-based authentication occurs but then commits the catalog to a local cache. Either mechanism essentially directs a media provider application running on the user device 827 to a subset of the media content locally available on the micro-CPC cache 1460. Note that the term "application" is used herein to include mobile device apps (e.g., iPhone apps), browser-based program code, and applications running on laptop computers). In short, any form of program code installed on the user device 827 that provides media streaming functionality may be configured to take advantage of the embodiments described herein.

[0150] There are numerous configurations that are suitable for various mobile environments. For example, a bus may only require enough streaming capacity to support 50-80 passengers, whereas 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. An existing CPC cache 1302 may be suitable for a cruise ship, but is unnecessarily large (e.g., in terms of price, power consumption, and capacity) for a bus.

[0151] However, a standard 30-100 TB cache may be specified as the standard baseline for all of the above embodiments. CSP 152 provides a form factor cache appliance that handles the delivery of cache updates when high speed connections are available and delivers sufficient media streaming capabilities for each mobile environment.

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

[0153] In one embodiment, the CSP 152 implements only a single "core" CPC cache 1302 and replicates the content to various micro-caches configured on different transport vehicles / vessels. By having an ISP relationship with the media provider 1310, the CSP 152 simply references the core CPC cache 1302 using BGP, and the media provider is provided with visibility of 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) on 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, knowing that these caches contain media content that is not greater than the same set of allowable media content on the CPC cache 1302. A temporary cache (TIC) configuration may be used for this embodiment. In another embodiment, each micro-CPC cache 1460 is individually registered 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-filling a pinned cache device

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

[0156] In one embodiment, the CPC cache 1302 sends different data to each of the FE caches, rather than providing the same media content from the CPC cache 1302 to all FE caches simultaneously. Figure 15 shows one particular example including three FE devices 1501-1503 with FE caches 1511-1513, respectively. This embodiment may split the content between each of the three FE caches 1511-1513, rather than streaming all of the same content from the CPC cache 1302. Thus, for example, if the bandwidth to each FE device 1501-1503 is the same, then 1 / 3 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 train station (i.e., the mobile environment 150 is a train), the micro CPC cache or temporary cache 1520 will receive 1 / 3 of the total content from each FE device 1501-1503 and will have all the content when it leaves the station with the FE device 1503. The advantage of this approach is that the total capacity for the 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 stations. In one embodiment, the reverse fill technique described above may also be implemented in this environment to send media content from the micro CPC cache or temporary cache 1520 to one or more of the FE devices 1501-1503 (e.g., if the network connection to the CPC cache 1302 degrades or is lost).

[0157] In one embodiment, the amount of media content sent to each FE device 1501-1503 is apportioned according to its link capacity to the CPC cache 1302. For example, if FE device 1501 has a 200 Mbps link, FE device 1502 has a 300 Mbps link, and FE device 1503 has a 500 Mbps link, then 2 / 10, 3 / 10, and 5 / 10 of the media content may be sent to these devices, respectively. Once the allocated portion of the media content has 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 left 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 the FE cache 1511 within the remaining time.

[0158] Additional optimizations may be applied to the above embodiment. Media content may be encoded into many small files, most of which have meaningless hash names. The core CPC cache 1302 may attempt to group these files together to ensure that a cohesive set of media content can be retrieved from each FE device 1501-1503. For example, 10 movies may be encoded into 100 files each, resulting in a total of 1000 files, and the utility of the media content is based on the particular grouping of files that can be retrieved by the user device. For example, a user may only start playing a movie if he or she has the correct set of files required for playback (e.g., files numbers 1-10 associated with movie number 1). If the media content of the above example is delivered as 33 files from each movie to each FE cache 1511-1513, then none of the FEs have the complete movie and the utility is zero.

[0159] To address this issue, one embodiment of the system determines the specific set of files associated with each movie and attempts to 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 to the end of the movie. Then, at least these movies can be viewed while waiting for the rest of the movie to reach the micro-CPC cache or temporary cache 1520.

[0160] In this embodiment, the media streaming analytics engine 1540 may monitor which files are sequential with respect to each other. For example, when a user watches movie number 1, the particular sequence of files streamed to the client may be tracked by the media streaming analytics engine 1540 and stored as a media file mapping 1530 (e.g., a table data structure that associates each media item with multiple files). Of course, 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, are implemented as proxy caches that request and store content from the upstream cache when the content is requested locally. One embodiment of the present invention utilizes components of this architecture, but intelligently requests upstream data based on cumulative requests distributed across all vehicles / vessels in the fleet.

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

[0163] Considering there are many vehicles / vessels on the scene (e.g., 100), cache misses will be somewhat distributed across different vehicles / vessels, but some may occur simultaneously (e.g., when breaking news). In one embodiment, cache miss requests generated within the mobile environment 150 are sent back to the core proxy cache 1605 over a slow network (e.g., cellular, satellite) 1350. If necessary, the core proxy cache 1605 calls the upstream 1600 to fetch the data and transmits it to the local cache 1620 in the requesting mobile environment 150. All other passengers within the mobile environment 150 who wish to view the media are served directly from the local cache 1620.

[0164] In this embodiment, the core proxy cache manager 1601 is aware of the cumulative activity from all mobile environments 1610, including all local cache misses provided by the upstream CDN server 1600 and stored in the core proxy cache 1605. As each individual mobile environment 150 arrives at the fixed edge 1610 using the high speed network 161, the core proxy cache will contain the latest content from the accumulated misses and these contents will be pushed to each mobile environment. In effect, for example, for 100 trains, the misses of the 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 seen to originate from multiple mobile environments (e.g., using a threshold of 10%, 15%, etc.), the requested content may be classified as a high demand item. As a result, this media item may be pushed to all mobile environments 150 over the slow network 1350 in the hopes that a very high percentage of passengers will want to access it.

[0166] In summary, a single core proxy cache 1605 serves the sum of requests from N mobile environments (e.g., N=50, 100, 400, or any other number). Requested content is pushed from the core proxy cache 1605 to all N mobile environments over the high speed network with a coarse grained frequency (e.g., daily), and for items determined to be in very high demand, pushed over the potentially slower network 1350 using a finer grained frequency (e.g., minutely).

[0167] Particular embodiments deploy a media cache at a remote location where the most important static content is managed and can be viewed locally. In this example, the distribution 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, rather than deploying a VOD system on a single ship / vehicle, the VOD system may be deployed on a public or private website, thus providing everyone who can reach the website with the same experience as the passengers on the ship / vehicle.

[0169] In one embodiment, public / private websites are mapped to a CDN as described in Figure 16 or any of the other examples above, and the entire website and CDN content is simultaneously and consistently replicated to each ship / vehicle. What a train passenger experiences, for example, is a visit to the public / private website, but instead the local cache 1620 is serving up the website data and media content as a cached instance.

[0170] As discussed above, one embodiment of the present invention comprises a system and method that analyzes content usage and mobile environmental data to prioritize and schedule content delivery. G. Prioritizing and Scheduling the Delivery of Learned Content

[0171] 17 illustrates 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 obtaining distributed content. An analytics engine 1710 evaluates data related to content and content usage to determine a demand value for each item of content. A 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 the evaluation performed by the demand engine 1715, the packager logic 1720 performs modifications of the particular content. For example, for very popular titles (e.g., identified by the analysis engine 1710 or the demand engine 1715), the packager 1720 may generate or obtain different bitrate versions of the content. Any transformations performed may be specified by the packager 1720 in customized manifest files 1750B-D and sent to each corresponding mobile environment 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 file specifies the different bitrates available for the associated content. In this embodiment, the manifest file 1750A is modified to generate customized manifest files 1750B-D for each mobile environment 150, so that the 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 transmitting various content items based on known or expected schedules of the mobile environments 150 and the expected demand for each content item in each mobile environment 150 .

[0174] Once scheduled, distribution logic 1730 manages the transmission to each of the mobile environments 150 and reports the results back to the scheduler 1725 and / or the content provider. Content may be distributed over 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 of FIG. 17 maximizes constrained connectivity to the mobile environment 150 by implementing one or more of: (1) multi-factor analysis to prioritize and determine title transmission order; (2) a multi-path delivery system; (3) real-time queue constraints; and (4) profile-based constraints.

[0176] With respect to multi-factor analysis, the demand engine 1715 may implement explicit prioritization and / or prioritization 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 content. For example, when a blockbuster movie is first released for streaming, it may be assigned a relatively high priority. Demand for the movie may then be tracked over time and the priority level adjusted accordingly. Learned demand is demand determined by monitoring usage of the content. In one embodiment, the priority is selected from one of several discrete priority values ​​(e.g., priority 1-5). Thus, learned demand may be adjusted for content based on exceeding a threshold (e.g., total number of requests, number of cache misses, etc.). Additionally, multi-factor analysis may involve explicit timed delivery. That is, a particular piece of content may be "monitored" at a particular time and delivered with a high priority, regardless of cache misses.

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

[0178] For real-time queues, the scheduler 1725 may take into account various constraints, which may include, for example, constraints on the amount of bandwidth that may be consumed at different times and constraints on the amount of data that may be utilized in a given time period.

[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, so content may be selectively targeted to different nodes based on available space vs. priority. Additionally, the demand engine 1715 may evaluate the profile data and other relevant data to adjust prioritization based on regional location (e.g., certain content may have different priority in different geographic regions). H. Implementation Examples 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. In particular, because different jurisdictions have different laws relating to the proper management of media content, these embodiments dynamically adjust how media content is managed as a transportation vehicle passes between jurisdictions.

[0181] In one embodiment, content availability needs to be tailored to the region the vehicle is in at any given time, so applications accessing the mobile cache need to know their region and access the cache information appropriately. Thus, in a mobile CDN environment, connections that remain anchored in the local transportation environment need to reflect the current geographic location.

[0182] 18, an embodiment is described in which a mobile environment 150 provides an example of traveling 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, a vehicle IP address in the mobile environment 150 passes through a NAT circuit 1820 to perform network address translation to the IP sub-network of the "home" region as previously described. The NAT circuit 1820 may be integral to a network router configured in the mobile environment 150.

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

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

[0185] An embodiment of the CDNE includes a multi-tier cache hierarchy with advanced content tracking, security, and visibility features. For example, an embodiment implements an immutable ledger to track and manage content distributed across multiple mobile environments and sourced from multiple content providers. Specifically, a blockchain-based immutable ledger may be used to track and verify where content is distributed 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 provable control of content titles across the network, these embodiments also provide secure and fully auditable tracking of each title from when it enters the CDN extender 110 network to when it is purged from the system. At any intermediate point where a title is cached, it is an encrypted blob that provides the content owner or provider with all the characteristics of an encrypted tunnel from its current large edge network to all cached instances of the content, including but not limited to content stored in the fixed edge 184, mobile edge 185, and micro-CPC cache 1460, to name a few.

[0186] 19, which illustrates a content origin service 1905A, such as Netflix, coupled 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 CDN core cache 1920 that establishes peer connections to one or more of the CPCs 1912 to receive peer-fill operations, and populates the cache with content from the CPCs 1911-1913.

[0187] In one embodiment, the CDNE core 1920 sits at the top of the CDNE 110 caching hierarchy, potentially caching all or a large subset of the 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 cores 1920 participate as peers in a direct network to the content owner's ISP.

[0188] A number of intermediate hub devices 1930-1932 receive content updates from the CDNE core 1920 over secure communication channels within the network of the CDNE extender 110 and pass the content updates to edge caches 1940-1942. In one embodiment, content is transmitted over encrypted communication channels 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 continually updates the content directory 1950 to reflect the propagation of content throughout the network of CDN extenders 110. For example, FIG. 19 shows the CDNE core 1920 generating entries that update the content directory upon receipt of a particular media content title, and the edge caches 1940-1942 updating the content directory 1950 upon receipt of media content from the hubs 1930-1932. In one embodiment, a new entry is added to the content directory 1950 for each content title received at each edge cache 1940-1942 and the CDNE core 1920. Each entry includes an identifier for its current location, a decryption key, an indication of the source (i.e., specifying the network component from which the content originated), and a timestamp (indicating the time of receipt of the content). Using appropriate authentication, the content owner / provider 1905A can thereby track the location of any of its content as it is distributed throughout the network of CDN extenders 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 a channel to each content owner carried over the CDNE 110 network. When a content title is received, a ledger entry is created in 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 the CDNE 110 uses this encryption key to encrypt and package the content for distribution. They CDNE 110 may receive the encryption key directly or via the shared ledger 2000. The encrypted title package is sent across the CDNE network, including to intermediate hub locations 1930-1932 where it is stored in encrypted form. When the content title reaches one of the edge caches 1940-1942, the encryption key is received from the content owner 1905A-B, which uses it to decrypt the package and load the underlying content into one or more available caches. The ledger entries record the event and are readily visible to the content owner / provider as a record of each new copy of the content. For example, a content title can be purged from an edge cache 1940-1942 to make room for newer / higher demand content.

[0192] The shared ledger 2000 is updated responsively to reflect changes and make them immediately visible to content owners. In one embodiment, content owners are provided with the option to issue "revoke" transactions (through or outside the shared ledger) that can be executed to purge content titles from each location (e.g., core, edge cache) in the CDNE.

[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, where each block includes a cryptographic hash of the previous block, a timestamp, and transaction data (commonly represented as a Merkle tree). In this example, each entry in the content directory 1950 includes a key that is a hash of the previous entry. This embodiment provides an immutable ledger for tracking and verifying the distribution of content within the CDNE 110.

[0194] Additionally, at any intermediate points, such as hub devices 1930-1932, the media content titles are stored as encrypted blobs, effectively creating an encrypted tunnel between the content provider edge, such as the CPC cache 1302, and the CDNE edge 1940-1942 and / or micro CPC 1460. J. Caching of aggregate content based on limited cache interactions

[0195] 21, one embodiment of the present invention uses data collected from various mobile environments to aggregate content across its cache 2105, thereby reducing bandwidth from various content channels 190. Specifically, the present embodiment builds the cache 2105 based on the aggregate input from strand networks 130A-B and contextual awareness of the particular data being cached.

[0196] Traditional content delivery networks cache content accessed by one user so that the next time the same content can be served to other users more quickly. However, in constrained mobile environments, this mechanism does not scale well enough to work. One embodiment turns this problem around. Specifically, in response to a particular event (e.g., a threshold number of misses in the local storage 142A-N of the local CDN extenders 135A-N), the trigger-based content collector 2110 attempts to retrieve all segments of all content titles from the strand networks 130A-N passing through the mobile environment 150. In one embodiment, the trigger-based content collector 2110 attempts to retrieve segments at all or a specified set of content bitrates.

[0197] In addition, as the CDN extender 110 passes through the strand networks 130A-N in a mobile environment, the trigger-based content collector 2110 progressively pushes segments that are not found on 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, on a regular schedule, it may scan content provider websites for new content titles and add each new network address to a search queue 2111. It may then process through 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 and the corresponding URL may be inferred to identify the complete content title. This title may be added to the collector's queue 2111. Eventually, the complete title is collected in the core cache 2105 of the CDN extender 119 and 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 delivery and storage. Specifically, this embodiment reduces the number of active flows in the manifest that constitute a title (reducing storage space) and performs progressive flow delivery to ensure faster delivery of a given title (e.g., by sending lowest bitrate content first, then medium bitrate content, then highest bitrate content).

[0201] As discussed above with respect to Figure 17, the manifest file 1750A informs the playback app on the end user device of the stream rates available for the title. Higher speed streams collected by the content collector 2110 are significantly larger than lower speed streams, which creates opportunities for optimizing delivery and / or storage.

[0202] To make the most of the real-time delivery channel, the packager 1720 generates a special package for the content title that removes the high-speed streams, modifies the manifest file 1750A associated with the content title, and removes one or more entries associated with the highest bit rate to generate one or more customized manifests 1750B-D. The smaller media files can then be sent via the real-time queue 1726A of the scheduler 1725 for immediate availability within the mobile environment 150. In contrast, the complete package (and complete manifest 1750A) containing all the 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 train station), the low bit rate version is replaced with the high bit rate version.

[0203] Additionally, one embodiment provides real-time cache misses. Specifically, this embodiment proactively creates and delivers special manifests for content that has not yet been delivered, but that specifically reference only low streaming rates. This leverages normal caching behavior to cache low rate segments as they stream. In one implementation, the number of simultaneous streams allowed is limited, and once the limit is reached, other streams are prevented from starting. K. Cache data distribution using mobile environments

[0204] One embodiment of the present invention leverages the mobile environment to distribute cached data using reverse fill, relying on a distribution protocol to enable rapid distribution of content across the diverse vessels of the mobile environment 150.

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

[0206] As new titles are collected, they may be "sprayed" across hub nodes 1930-1932. So, for example, content title 1 may go to hub 1930, content title 2 may go to hub 1931, etc. When edge 1940 reaches hub 1930, it picks up content title 1 and then travels to hub 1931. At hub 1931 it drops content title 1 and then picks up content title 2. Upon returning to hub 1930 it then drops content title 2. With more edges and hubs the process increases and utilization and costs associated with connecting to the content provider's network are greatly reduced.

[0207] 22 illustrates an embodiment in which fixed edges 2210-2212 are populated from both a core cache 2201 and mobile edges 2220-2222. A 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 a content delivery administrator via a dashboard graphical user interface (GUI) 2201. L. Walled Gardens with Mobile CDNs

[0208] One embodiment of the present invention implements a walled garden using a mobile content delivery network (CDN), which transforms the walled garden solution, where every mobile environment hosts its own footprint, into a solution where a single over-the-top (OTT) or intranet-based streaming solution is managed by the CDN extender 110.

[0209] Current walled garden solutions, also known as video-on-demand (VoD) systems, have limited adoption due to two significant challenges, including the fact that they are relatively static and require laborious updating of old content, plus access to the content requires either users to download a special app before boarding or a website hosted locally in each vehicle.

[0210] In one embodiment, the VoD system is deployed as a public or private website and then mapped as a content source in the mobile content delivery network described herein. The techniques described herein are then used to replicate the content across all of the mobile environments 150. End users in the mobile environments 150 then access the content like any other website, except that all of the data is provided by caches and therefore no outside connectivity is 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 their vehicles.

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

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

[0213] As described herein, instructions may refer to a particular configuration of hardware, such as an application specific integrated circuit (ASIC), configured to perform a certain operation or where a predetermined function or software instructions are stored in a memory embodied in a non-transitory computer readable medium. Thus, the techniques illustrated in the figures 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 use computer machine readable storage media, such as non-transitory computer machine readable storage media (e.g., magnetic disks, optical disks, random access memory, read only memory, flash memory devices, phase change memory), as well as transient computer machine readable communication media (e.g., electrical, optical, acoustic or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc.), to store and communicate (internally and / or with other electronic devices over a network) the code and data.

[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-transitory machine-readable storage media), user input / output devices (e.g., keyboards, touch screens, and / or displays), and network connections. The coupling between the set of processors and the other components is typically through one or more buses and bridges (also referred to as bus controllers). Each of the storage devices and 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 for execution on the set of one or more processors of that electronic device. Of course, one or more portions of the embodiments of the present invention may be implemented using different combinations of software, firmware, and / or hardware.

[0215] Throughout this detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. In certain instances, well-known structures and functions have not been described in detail to avoid obscuring the subject matter of the present invention. Therefore, the scope and spirit of the present invention should be judged in terms of the following claims.

Claims

1. 1. A system comprising: A plurality of micro-cache devices integrated within a corresponding plurality of mobile environments; an address manager that maintains an Internet Packet (IP) address pool according to IP address information received from a content provider, the address manager associating different portions of the address pool with different instances of the micro-cache device and corresponding mobile environments; a local network manager coupled to each microcache device in each mobile environment that provides network connectivity to client devices in each mobile environment, a first local network manager coupled to a first microcache device assigning IP addresses from a first portion of the address pool to requesting client devices in the first mobile environment, and a second local network manager coupled to a second microcache device assigning IP addresses from a second portion of the address pool to requesting client devices in the second mobile environment; The system, wherein the content provider is provided control over visibility of and access rights to each micro-cache by the client devices in each mobile environment.

2. 1. A system comprising: a plurality of mobile edge cache devices integrated within a corresponding plurality of mobile environments; a local network manager coupled to each edge cache device in each mobile environment that provides network connectivity to client devices in each mobile environment; a mobile high speed network interface in each mobile environment that establishes a high bandwidth link to one or more fixed high speed network interfaces when the mobile environment is within range; a multi-factor analysis engine that evaluates data related to content usage across the plurality of mobile edge caches to determine a priority for transmitting content titles to each mobile edge cache when the mobile environment is within range.

3. 1. A system comprising: a plurality of mobile edge cache devices integrated within a corresponding plurality of mobile environments; a local network manager coupled to each edge cache device in each mobile environment that provides network connectivity to client devices in each mobile environment; a mobile high speed network interface in each mobile environment that establishes a high bandwidth link to one or more fixed high speed network interfaces when the mobile environment is within range; a plurality of network access devices, each of which is coupled to one of the edge cache devices in a mobile environment to provide local network access to client devices in the mobile environment, each of which further performs network address translation on behalf of the client devices in the local network of the mobile environment; and regional configuration logic that, in response to an event indicating a first mobile environment has moved from a first geographic region to a second geographic region, modifies one or more configuration settings of a first network access device in the first mobile environment and / or a client device in the first mobile environment to tailor content availability from the edge cache to requirements of the second geographic region.

4. 1. A system comprising: a plurality of peer caches associated with a corresponding plurality of content owners; shared ledger logic having a channel for each content owner of a plurality of content owners, said shared ledger logic maintaining a shared ledger data structure; responsively recording a first ledger entry for the first content title that is visible to a first content owner that owns the first content title; receiving an encryption key from the content owner, the first content title including an encrypted content title encrypted with the key; storing the encrypted content titles on one or more network storage devices; and and shared ledger logic that performs the following operations when the encrypted content title reaches an edge cache: decrypt the encrypted content title using the key and update the first ledger entry to identify the edge cache.

5. 1. A system comprising: a plurality of mobile edge caches integrated within a corresponding plurality of mobile environments; a core cache managed by a content delivery network extender (CDNE) service, the core cache storing content titles from at least one content provider and selectively delivering the content titles to the mobile edge caches, each content title being encoded at a plurality of stream rates and including a plurality of title segments, each title segment being associated with a particular one of the stream rates and capable of being cached independently within the core cache and the plurality of mobile edge caches; A system comprising: a content collector coupled to the core cache, the content collector causing title segments to be collected and stored in the core cache, the content collector aggregating cache utilization data provided by the plurality of mobile edge caches, and identifying title segments to be collected and stored in the core cache based on an evaluation of the aggregated cache utilization data.

6. 1. A system comprising: a plurality of mobile edge caches integrated within a corresponding plurality of mobile environments; a local network manager coupled to each edge cache device in each mobile environment that provides network connectivity to client devices in each mobile environment; a mobile high speed network interface coupled to each mobile edge cache in each mobile environment that establishes a high bandwidth link to one or more fixed high speed network interfaces when the mobile environment is within range; a fixed core cache coupled to each fixed high speed network interface, the fixed core cache caching content titles delivered to the plurality of mobile edge caches, each content title including a manifest indicating a different stream rate at which the content title is encoded; a mobile low speed network interface coupled to each mobile edge that maintains a low bandwidth link when the mobile environment is out of range of the one or more fixed high speed network interfaces; a content delivery optimizer that reads an original manifest for a first content title and responsively generates a revised manifest by removing one or more indications of a highest stream rate included in the original manifest; In response to the mobile environment being out of range of the fixed high speed network interface, the content delivery optimizer provides the revised manifest to a content streaming app of a client device in the mobile environment in response to a request by the mobile streaming app for the first content title.

7. 1. A system comprising: a plurality of mobile edge caches integrated within a corresponding plurality of mobile environments; a local network manager coupled to each edge cache device in each mobile environment that provides network connectivity to client devices in each mobile environment; a mobile high speed network interface coupled to each mobile edge cache in each mobile environment that establishes a high bandwidth link to one or more fixed high speed network interfaces when the mobile environment is within range; a fixed core cache that stores content titles owned by a content provider, the content titles being distributed to the plurality of mobile edge caches, each content title including a plurality of title segments; a plurality of fixed edge caches coupled between the fixed core cache and the mobile edge cache; a content distribution manager that strategically spreads the title segments across the fixed edge caches, different fixed edge caches being initially provided with different sets of the title segments; and a first content aggregator coupled to a first fixed edge cache, the first content aggregator requesting title segments not stored in the first fixed edge cache from the plurality of mobile edge caches when the high bandwidth link becomes available to each of the mobile edge caches.

8. 1. A system comprising: a plurality of mobile edge caches integrated within a corresponding plurality of mobile environments; a local network manager coupled to each edge cache device in each mobile environment that provides network connectivity to client devices in each mobile environment; a mobile high speed network interface coupled to each mobile edge cache in each mobile environment that establishes a high bandwidth link to one or more fixed high speed network interfaces when the mobile environment is within range; a fixed core cache that stores content titles owned by a content provider, the content titles being distributed to the plurality of mobile edge caches, each content title including a plurality of title segments; a fixed core cache, the content provider maintaining a primary website to provide access to each content title by a streaming app installed on a client device, the streaming app executing on a first client device in the first mobile environment generating a request for a first content title in response to a user input, the request including a network address associated with the primary website; a request redirector that responsively redirects the request to a first mobile edge cache in the first mobile environment and / or the fixed core cache, wherein at least a portion of the title segment of the first content title is streamed from the first mobile edge cache to the streaming app.

Citation Information

Patent Citations

  • Mobile terminal equipment

    JP2008252376A

  • Management method for file cache, file cache device, and program

    JP2011191856A

  • Radio communication device, communication system, radio communication device control method, and program

    JP2014127798A

  • Dynamic cache allocation and network management

    US20150256639A1

  • Roaming content cache update and reporting system

    US9100089B1