Edge Computing in a Satellite-Connected Environment

Abstract

Various approaches for integrating and using edge computing operations in a satellite communications environment are described herein. For example, connectivity and computing approaches are described with reference to, among other things, identifying satellite coverage and computation operations available in low Earth orbit (LEO) satellites, establishing connection streams over a LEO satellite network, identifying and enforcing geofences for LEO satellites, coordinating and planning data transfers across devices temporarily connected to the satellites, service orchestration over LEO satellites based on data costs, and managing the delivery of computation and data operations and packet processing in a LEO satellite network.

Description

[Technical field]

[0001] Priority claim This application claims priority to U.S. Provisional Patent Application No. 63 / 077320, filed September 11, 2020, U.S. Provisional Patent Application No. 63 / 129355, filed December 22, 2020, U.S. Provisional Patent Application No. 63 / 124520, filed December 11, 2020, U.S. Provisional Patent Application No. 63 / 104344, filed October 22, 2020, U.S. Provisional Patent Application No. 63 / 065302, filed August 13, 2020, and U.S. Provisional Patent Application No. 63 / 018844, filed May 1, 2020, all of which are incorporated by reference in their entireties.

[0002] TECHNICAL FIELD The embodiments described herein relate generally to the terrestrial and non-terrestrial network infrastructure associated with satellite-based networks, such as data processing, network communication scenarios, and uses of low earth orbit satellite constellations. [Brief description of the drawings]

[0003] In the drawings, which are not necessarily drawn to scale, like numerals may describe like components in different views. Like numerals with different subscripts may represent different instances of like components. Some embodiments are described by way of example, and not by way of limitation, in the figures of the accompanying drawings, which are set forth below. [Figure 1] FIG. 1 illustrates network connectivity in a non-terrestrial (satellite) and terrestrial (eg, cellular network) setting according to one example. [Diagram 2] FIG. 2 illustrates a terrestrial and non-terrestrial edge connectivity architecture according to one example. [Diagram 3] FIG. 3 illustrates several types of satellite communication networks according to one example. [Figure 4] 4A and 4B show several types of satellite communications processing architectures according to one example. [Diagram 5]FIG. 5 illustrates details of ground communications and architecture in a geostationary satellite communications network according to one example. [Figure 6] 6A and 6B show details of ground communications and architecture in a low earth orbit (LEO) satellite communications network according to one example. [Figure 7] 7A and 7B show a network connectivity ecosystem implementing a LEO satellite communications network according to one example. [Figure 8] FIG. 8 illustrates an overview of ground-based LEO satellite-enabled edge processing according to one example. [Figure 9] FIG. 9 illustrates a geographic satellite connectivity scenario from a LEO satellite communications network according to one example. [Figure 10] 10A, 10B, and 10C show an example of a ground-based LEO satellite-enabled edge processing arrangement. [Figure 11] 11A, 11B, 11C and 11D show various arrangements of radio access network processing over a satellite communication network according to one example. [Figure 12] FIG. 12 illustrates a flowchart of a method for acquiring a satellite vehicle position according to an example. [Figure 13] FIG. 13 illustrates an edge computing network platform extended via satellite communications according to one example. [Figure 14] 14A and 14B show an appliance configuration of a connector module adapted for use in satellite communications according to one example. [Figure 15] FIG. 15 illustrates a flowchart of a method for using a satellite connector for collaboration with edge computing operations according to one example. [Figure 16] FIG. 16 illustrates a further architecture of a connector module adapted for use with satellite communications, according to one example. [Figure 17] FIG. 17 illustrates a further architecture of a connector module adapted for use with satellite communications, according to one example. [Figure 18] FIG. 18 illustrates a flowchart of a method for using a satellite connector for collaboration with edge computing operations according to one example. [Figure 19] FIG. 19 illustrates a further architecture of a connector module adapted for use with storage operations, according to one example. [Figure 20] 20A and 20B show a network platform extended via satellite communications for content and geofencing operations according to one example. [Figure 21] FIG. 21 illustrates an appliance configuration for satellite communications extended via satellite communications for content and geofencing operations according to one example. [Figure 22] FIG. 22 illustrates a flowchart of a method for using a satellite connector for satellite communication using geofencing operations according to one example. [Figure 23] FIG. 23 illustrates a system for coordination of satellite roaming activities according to an example. [Figure 24] FIG. 24 illustrates the configuration of a user edge context data structure for coordinating satellite roaming activity according to one example. [Diagram 25] FIG. 25 illustrates a flowchart of a method for using user edge context to coordinate satellite roaming activities according to one example. [Figure 26] Figure 26 shows the use of satellite communications in an Internet of Things (IoT) environment. [Figure 27] FIG. 27 illustrates a flowchart of a method for collecting and processing data using an IoT and satellite network deployment according to one example. [Figure 28] FIG. 28 illustrates an example satellite communication scenario with a plan for a temporarily connected device according to one example. [Figure 29] FIG. 29 illustrates a flowchart of a method for coordinating satellite communications with a temporarily connected device according to one example. [Diagram 30] FIG. 30 illustrates a satellite communication scenario with data cost considerations according to one example. [Diagram 31] FIG. 31 illustrates a satellite and terrestrial edge processing framework adapted for data cost functionality according to one example. [Diagram 32] FIG. 32 illustrates a flowchart of a method for service orchestration based on data costs according to one example. [Diagram 33] FIG. 33 illustrates an information-centric networking (ICN) network configuration according to one example. [Diagram 34] FIG. 34 illustrates a configuration of an ICN network node implementing Named Data Networking (NDN) technology according to one example. [Diagram 35] FIG. 35 illustrates an exemplary deployment of ICN and NDN technologies between satellite access nodes according to one example. [Diagram 36] FIG. 36 illustrates a satellite connection scenario for using NDN data handover according to one example. [Figure 37] FIG. 37 illustrates a satellite connection operation flow for coordinating NDN data operations according to one example. [Figure 38] FIG. 38 illustrates a flowchart of a method for handover of computing and data services to maintain service continuity in a satellite access system according to one example. [Figure 39] FIG. 39 illustrates a discovery and routing strategy performed in a satellite connectivity system according to one example. [Diagram 40] FIG. 40 illustrates a flowchart of an example method performed in a satellite access system to maintain service continuity for data services according to one example. [Diagram 41] 41A and 41B show an overview of terrestrial and satellite scenarios for packet processing according to one example. [Diagram 42] FIG. 42 illustrates a packet processing architecture used for edge computing according to one example. [Diagram 43] FIG. 43 illustrates a packet processing architecture used for edge computing according to one example. [Diagram 44] FIG. 44 illustrates template-based network packet processing according to one example. [Diagram 45] FIG. 45 illustrates template-based network packet processing according to one example. [Diagram 46] FIG. 46 illustrates network processing and use of command templates according to one example. [Figure 47] FIG. 47 illustrates a flowchart of an example packet processing method using command templates according to one example. [Figure 48] FIG. 48 illustrates an overview of an edge cloud configuration for edge computing according to one example. [Figure 49] FIG. 49 illustrates an overview of distributed computing layers deployed among an edge computing system according to one example. [Figure 50] FIG. 50 shows the operational layers between the endpoints, the edge cloud and the cloud computing environment. [Figure 51] FIG. 51 illustrates an example approach for networking and services in an edge computing system. [Figure 52A] FIG. 52A illustrates an overview of example components deployed in a compute node system according to one example. [Figure 52B] FIG. 52B illustrates a further overview of example components within a computing device according to one example. [Figure 53] FIG. 53 illustrates a software distribution platform for distributing software instructions and derivatives according to one example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] The following disclosure addresses various aspects of connectivity and edge computing as they relate to non-terrestrial networks (e.g., low earth orbit (LEO), medium earth orbit (MEO) or intermediate circular orbit (ICO) or very low earth orbit (VLEO) satellite constellations) networks. In various examples, this is provided through new approaches to terrestrial and satellite-enabled edge architectures, edge connectors for satellite architectures, quality of service management for satellite-based edge, satellite-based geofencing schemes, content caching architectures, Internet of Things (IoT) sensor and device architectures connected to satellite-based edge deployments, orchestration operations in satellite-based edge deployments, and other related improvements and designs.

[0005] One of the technical challenges addressed herein involves consideration of edge "multiple-access" connectivity, including many permutations of network connectivity provided between satellites, terrestrial wireless networks, and UEs (including UEs with direct satellite network access). For example, scenarios may involve coordination between different types of available satellite-UE connectivity, whether in the form of non-geostationary satellite systems (NGSO), medium or intermediate circular orbit satellite systems, geostationary satellite systems (GEO), terrestrial networks (e.g., 4G / 5G networks), and direct UE access, taking into account, among other things, propagation delays, frequency interference, exclusion zones, satellite beam landing rights, and terrestrial (or on-orbit) routing protocol capabilities. Similarly, such scenarios also involve consideration of multi-access satellite connectivity when performing discovery and routing, including how to route data over multi-access satellite links based on service level objectives (SLOs), security, regulations, etc.

[0006] Another technical challenge addressed herein involves the coordination between edge computational functions provided at non-terrestrial (satellite vehicles) and terrestrial (base stations, core networks) locations. From a simple perspective, this may include determining whether computational operations should be performed, for example, on the ground, on the satellite or connected user equipment devices, base stations, clouds or core networks connected to the satellite, or at remote locations. Computational operations range from establishing entire network routing paths between terrestrial and non-terrestrial network nodes (involving nearly all nodes in the network infrastructure) to performing updates of individual edges or nodes (which may involve only one node or satellite).

[0007] To make this determination, the system may evaluate what types of operations will occur and where to perform computational operations or obtain data, taking into account intermittent or interrupted satellite connections, the moving and variable beam footprints of individual satellite vehicles and satellite constellations, satellite interference or exclusion areas, limited transmission throughput, delays, costs, legal or geographic restrictions, Service Level Agreement (SLA) requirements, security, and other factors. As used herein, "exclusion zones" Or the term "excluded area" may include restrictions on satellite broadcasting or use, as defined in standards promulgated by the Alliance for Telecommunications Industry Solutions (ATIS) or other standards body or jurisdiction.

[0008] Relevant technical challenges addressed herein include edge computing operations provided over satellite connectivity and orchestration and quality of service for such satellite connectivity. Different considerations and priorities may apply applicable to cloud service providers (offering best-effort services) versus telcos / communication service providers (offering guaranteed services) while tailoring services and guaranteeing reliability based on considerations regarding latency, throughput capabilities and requirements, type of data, cost of satellite connectivity, among others. Evaluation of such factors may include consideration of risk, use cases of available services, use cases of satellite networks as a "bent pipe" of connectivity, conditions or restrictions on how and when data can be accessed and processed, various types of backhaul available over satellite data communications, and further aspects of tax, privacy and security that arise with satellite data communications in multiple jurisdictions.

[0009] Another technical challenge addressed herein relates to the adoption of edge computing and data services in a satellite-connected environment. One aspect of this includes the implementation of Software Defined Network (SDN) and Virtual Radio Access Network (RAN) concepts, including terrestrial and non-terrestrial network nodes connected to an orbiting satellite constellation. Another aspect includes how to align data processing with IoT architectures, including sensors monitoring environmental telemetry within terrestrial boundaries (e.g., ship containers, drones) with intermittent connectivity (e.g., last known state, connectivity via remote drones, etc.). Other aspects related to Content Data Networks (CDNs), geofencing and geographic restrictions, service orchestration, connectivity and data handover, communication paths and routing, security and privacy considerations are also addressed for various use cases.

[0010] In a diverse set of examples, satellite connectivity and coordination is provided through a novel approach to terrestrial and satellite-enabled edge architectures that involves the use of "edge connectors" and connectivity logic within computing systems. Such edge connectors are used to assemble and orchestrate communication streams over satellite networks and establish virtual channels to edge compute or remote service locations, despite the intermittent and unpredictable nature of LEO satellite network connectivity.

[0011] In a further example, in a satellite-based or satellite-assisted edge computing deployment, satellite connectivity and coordination is provided through quality of service and orchestration management operations. Such management operations may take into account the various types of delays and various congestion and resource usage conditions required for network backhaul over the satellite network. These management operations may enable effective integration of terrestrial-based and satellite-based edge computing operations with all of the resource properties associated with the associated network or computing service.

[0012] In a further example, connectivity and workload federation is provided for satellite-based edge computing nodes and terrestrial-based edge computing nodes that serve content to end users (e.g., from a content delivery network (CDN) or the like). This connectivity and workload federation may use a content caching architecture adapted for satellite communications to reduce latency and increase efficiency of content retrieval and delivery. Such connectivity and workload federation may also use satellite-based geofencing schemes to ensure compliance with content provider or geopolitical (often defined based on geographic region) regulations and requirements.

[0013] In a further example, the coordinated aspects of satellite connectivity and edge computing operations are provided through a handover system for computation and data services, providing for the transfer of services data and services within a satellite vehicle, allowing for service continuity and coordination within various satellite communication settings.

[0014] Additionally, in further examples, various aspects of discovery and routing are performed between satellite and terrestrial links. In a Named Data Network (NDN) environment, using name-based addressing, the satellite connectivity system can be configured to perform workload functions, data acquisition, and handoff between nodes. The satellite connectivity system can be configured to select as well as discover the optimal node / path to perform the service (routing and forwarding).

[0015] Satellite Connection Overview

[0016] FIG. 1 illustrates network connections in non-terrestrial (satellite) and terrestrial (e.g., cellular network) settings, according to one example. As shown, a satellite constellation 100 (disposed as shown in FIG. 1 at orbital locations 100A and 100B) may include multiple satellite vehicles (SVs) 101, 102 connected to each other and to one or more terrestrial networks. Each individual satellite (each SV) in the constellation 100 orbits the Earth at an orbital velocity that increases as the SV approaches the Earth. LEO constellations are generally considered to include SVs orbiting between altitudes of 160 km and 1000 km. At this altitude, each SV orbits the Earth approximately every 90 to 120 minutes.

[0017] Constellation 100 includes individual SVs 101, 102 (as well as multiple SVs not shown) and uses multiple SVs to provide communication coverage to a geographic region on the Earth. Constellation 100 may also interface with other satellite constellations (not shown) and ground-based networks to selectively provide connectivity and services for individual devices (user equipment) or terrestrial network systems (network equipment).

[0018] In this example, the satellite constellation 100 is connected to a backhaul network via satellite link 170, and the backhaul network 160 is connected to the 5G core network 140. The 5G core network 140 is used to support 5G communication operations with the satellite network and the terrestrial 5G radio access network (RAN) 130. For example, the 5G core network 140 may be located in a remote location and use the satellite constellation 100 as an exclusive mechanism to reach a wide area network and the Internet. In other scenarios, the 5G core network 140 may use the satellite constellation 100 as a redundant link to access the wide area network and the Internet. In yet another scenario, the 5G core network 140 may use the satellite constellation 100 as an alternative path to access the wide area network and the Internet (e.g., to communicate with a network on another continent).

[0019] FIG. 1 further illustrates the use of a terrestrial 5G RAN 130 to provide wireless connectivity to user equipment (UE), such as terrestrial user equipment 120 or vehicle 125, via a large MIMO antenna 150. It will be understood that for simplicity, various 5G and other network communication components and units are not illustrated in FIG. 1. In some examples, each UE 120 or 125 may also have its own satellite connectivity hardware (e.g., receiver circuitry and antennas) to directly connect to the satellite constellation 100 via a satellite link 180. In the following sections, a 5G network configuration is illustrated and described in detail, although it will be apparent that other variations of 3GPP, O-RAN and other network specifications may also be applicable.

[0020] Other permutations (not shown) may involve direct connection of the 5G RAN 130 to the satellite constellation 100 (e.g., with a 5G core network accessible via a satellite link), coordination with other wired (e.g., fiber), laser or optical, wireless links and backhaul, or substitution of multi-access wireless, terrestrial and non-terrestrial connections between the UE, the RAN and other UEs. Satellite network connections may be coordinated with 5G network equipment and user equipment based on satellite orbit coverage, available network services and equipment, cost and security, geographic or geopolitical considerations, etc. Considering these fundamental entities, and with varying configurations of mobile users and satellites in orbit, the following techniques describe how terrestrial and satellite networks can be extended for various edge computing scenarios.

[0021] Figure 2 shows the terrestrial and non-terrestrial edge connectivity architectures extended with the present technology. Edge cloud computing has already been established as one of the next evolutions in the context of distributed computing and the democratization of computing. Current edge deployments usually involve a set of devices 210 or users connected to data points 220A (base stations, small cells, wireless or wired connections) that provide access to a set of services (hosted locally at access points or other aggregation points) through various types of network functions 230A (e.g., virtual evolved packet core (vEPC), user plane function (UPF), virtual broadband network gateway (vBNG), control plane and user plane separation (CUPS), multi-protocol label switching (MPLS), Ethernet, etc.).

[0022] However, one of the limitations experienced by current edge computing architectures is that they rely on network infrastructure owned by the communications service provider or neutral carrier. Therefore, if a particular provider wants to offer a new service in a particular location, it needs to make an agreement with an operator to provide the necessary connectivity to the location where the service is hosted (a service provider owned or provided by the communications service provider). On the other hand, in many cases, such as rural edges or emerging economies, the infrastructure is not yet established. To overcome this limitation, some companies (Tier 1 and above) are considering satellite connectivity to remove these limitations.

[0023] Multiple satellite constellations acting as different entities need to cooperate, share resources, and provide features such as geographical exclusion zones, Quality of Service (QoS), low latency content and service delivery, etc. In this context, limitations such as reliability, QoS, resource sharing, and exclusion zones present important interrelated concerns, which are addressed by the edge computing architecture and processing approach described below.

[0024] In the architecture of FIG. 2, the device 210 is connected to a new kind of edge location of the base station 220B and performs access capabilities (such as wireless antenna network), network functions (e.g., vEPC with CUPS / UPF) and first level edge services (such as Content Delivery Network (CDN)). Traditionally, such services required a connection to the cloud 240A or a network core. Now, in a satellite connection setting, such content and computing operations can be coordinated with the base station 220B, which provides the RAN and distributed functions and services. The base station 220B can obtain content or offload processing to the cloud 240B or other services via satellite communication, via a backhaul connection 230B (e.g., in a scenario where the CDN located at the base station 220B needs to obtain content that is not cached). The RAN functions can be divided into wireless and wired processing, such as RAN distributed unit (DU) L1 / L2 processing and RAN centralized unit (CU) L3 and above processing.

[0025] One of the main challenges of any kind of edge computing architecture is how to overcome the high latency that occurs when a service requires a connection to a backhaul of the network. This challenge becomes more difficult when there are multiple types of backhauls (e.g., to different data centers in the cloud 240B) with different properties or different congestion levels. These and other kinds of complex scenarios are addressed during the operations below.

[0026] FIG. 3 illustrates several types of satellite communication networks, including a geosynchronous (GEO) satellite network 301 (described below with reference to FIG. 4), a low earth orbit (LEO) satellite network 302 (described below with reference to FIG. 6A), and a low earth orbit 5G (LEO 5G) satellite network 303 (described below with reference to FIG. 6B). In any of these cases, a remote edge RAN access point 311 connected to a 5G core network uses one or more of the satellite networks 301, 302, 303 to provide a backhaul connection to a larger communication network (e.g., the Internet). The use of satellite backhaul can include terrestrial backhaul to other 5G RAN wireless networks (e.g., peer-to-peer to wireless network 304) or control information communicated or obtained via a telemetry tracking and control (TTAC) network 305, in addition to other types of wired or wireless backhaul. For example, the TTAC network 305 may be used for operations and maintenance traffic, with a separate link for system control backhaul (eg, on a separate satellite communications band).

[0027] At the access point 311, various edge computing services 312 may be provided based on an edge computing architecture 320, such as those contained within servers or compute nodes. The edge computing architecture 320 may include one or more edge servers and satellite connectors hosted on the edge computing architecture 320 configured to provide UPF / vRAN functions, CDN, services, applications, and other use cases. The architecture 320 may be connected by a high-speed switching fabric. Additional details regarding the use of satellite connectors and the coordination of edge computing and connectivity operations for satellite configuration are described below.

[0028] 4A and 4B show further examples of edge computing architecture 320. For example, an example edge server 322 capable of LTE / 5G networking may involve various combinations of FPGAs, non-volatile memory (NVM) storage, processors, GPUs and dedicated processing units, storage and satellite communication circuitry. An example edge server 324 capable of operating applications may include artificial intelligence (AI) computing circuitry, NVM storage, processors and storage devices, etc. Similarly, services provided by such servers are shown in FIG. 4B with a first service stack 332 (e.g., running on edge server 322) and a second service stack 334 (e.g., running on edge server 324). Various use cases (e.g., banking, IoT, CDN) are also shown, but the use of the architecture is not limited thereto.

[0029] Figure 5 shows terrestrial communications and architecture details in a geostationary satellite communications network. Here, an example IoT device 511 uses 5G / LTE connectivity to a terrestrial RAN 512 that hosts an edge appliance 513 (e.g., for initial edge computing processing). The RAN 512 and edge appliance 513 are connected to a geostationary satellite 501 using a satellite link via a very small open-ended (vSAT) antenna. The geostationary satellite 501 may also provide direct connectivity to other satellite-connected devices such as device 514. The use of existing 5G and geostationary satellite technologies makes this solution easily deployable today.

[0030] In one example, in a geostationary satellite communications scenario, 5G connectivity is provided using a distributed UPF (e.g., connected via satellite) or a standalone core (e.g., at a satellite connectivity hub / ground station 515) or directly at the edge appliance 513. In either case, edge computing processing is performed and may be distributed between the edge appliance 513, the ground station 515, or a connected data center 516.

[0031] 6A and 6B show details of the ground communications and architecture in a low earth orbit satellite communications network provided by SVs 602A, 602B of a constellation 602. These figures show a device and edge system similar to that of FIG. 5, with an IoT device 611, an edge appliance 613 and a device 614. However, the provision of 5G RAN from SVs 602A, 602B and significantly reduced latency from the low earth orbit satellites enables much more robust use cases, including direct connectivity of the device (device 614) with a 5G satellite antenna at device 614 and communication between the edge appliance 613 and the satellite constellation 602 using a dedicated protocol.

[0032] For example, in some LEO configurations, one 5G LEO satellite can cover a 500 km radius for 8 minutes every 12 hours. The connection latency to the LEO satellite can be as low as 1 millisecond. Also, the connectivity between the satellite constellation and the device 614 or base station 612 depends on the number and capabilities of the satellite ground stations. In this example, the satellite 601 communicates with a ground station 618 that may host edge computing processing capabilities. For additional processing, the ground station 618 may be connected to a data center 616. With the low latency provided by 5G communications, data processing, computing, and storage can be located in any number of locations (at the edge, on the satellite, on the ground, in the core network, in a low-latency data center).

[0033] 6B includes the addition of an edge appliance 603 located at the SV 602A, where some edge computing operations may be performed directly using hardware located at the SV, reducing latency and transmission times that would otherwise be required to communicate with a ground station 618 or data center 616. Similarly, in these scenarios, edge computing may be performed or coordinated between specialized processing circuitry (e.g., FPGA) or general-purpose processing circuitry (e.g., x86 CPU) located in the satellite 601, the ground station 618, the devices 614 connected to the edge appliance 613, the edge appliance 613 itself, and combinations thereof.

[0034] Although not shown in Figures 6A-6B, other types of orbit-based connectivity and edge computing may be associated with these architectures. This includes connectivity and computation provided via balloons, drones, airships, and similar types of non-terrestrial elements. Such systems face similar time constraints and connectivity challenges (such as those faced by satellite orbits).

[0035] FIG. 7A illustrates a network connectivity ecosystem implementing a satellite communications network. Here, a satellite 701, which is part of a satellite constellation 700A, provides coverage to an “off-grid” wireless network 720 (e.g., a geographically isolated network without a wired backhaul). This wireless network 720 provides coverage to an individual user device 710. Various other connections can be made to broader networks and services via the satellite connection. These connections include connections via a satellite ground station 730 to a carrier 740 or cloud services 750, where various public or private services 760 can be hosted. Additionally, the deployment of an edge computing architecture can bring these services closer to the user device 710 based on the coordination of operations of the network 720, the satellite constellation 700, the ground station 730, or the carrier 740.

[0036] 7B further illustrates a network connectivity ecosystem where satellites 702 that are part of the satellite constellation 700B provide high-speed connectivity (e.g., one-way latency approaching 1 ms) using 5G network communications. Such high-speed connectivity enables satellite connectivity for multiple users 780 and multiple types of devices 790 at multiple locations 770. Such a configuration is particularly useful for connecting industrial IoT devices, mobility devices (robo-taxis, autonomous cars, etc.), and the overall concept of providing connectivity for "everyone" and "everything."

[0037] Satellite network coverage and coverage identification

[0038] One of the general challenges in satellite architectures is how and where to deploy compute and all of the necessary changes in the overall architecture. This approach addresses many aspects of where compute can be placed and how to combine satellite-based technology with edge computing in a unique way, where the goal is to embrace compute "everywhere" potentially (from device to edge, satellite to ground station).

[0039] Deploying and working with edge computing becomes very complicated because satellites will be orbiting in constellations. This leads to two major challenges. First, depending on the altitude and density of the constellation, edge locations are covered at different times. Similarly, latency and bandwidth may change over time. Second, the computing nodes themselves, including the satellites, are in orbit and move around. There is a need to consider using in-motion edge computing locations that are only accessible from geographic locations at different times.

[0040] 8 illustrates a simplified exemplary scenario of geographic satellite connectivity from multiple LEO satellite communications networks, showing associated LEO SV movement relative to a geographic region, where each satellite constellation orbit 811, 812 operates to provide network coverage in limited geographic regions 821, 822. In contrast, no access is provided in area 831. It will be appreciated that the geolocation of associated satellite coverage areas can play an important role in determining service characteristics, exclusion zones, and satellite ground processing coordination.

[0041] Figure 9 shows an overview of ground-based satellite-enabled edge processing. As shown, a ground-based satellite-enabled EDGE ground station (satellite Node B, sNB) 920 obtains coverage from a satellite constellation 900 and downloads a data set 930. The constellation 900 may coordinate to hand off the download using inter-satellite links (such as in scenarios where the data set 930 is streamed or cannot be fully downloaded before the satellite footprint moves).

[0042] The satellite download 925 is provided to the sNB 920 for processing, along with a cloud upload 915 to the server 910 (e.g., a CDN located at or near the sNB 920). Thus, once downloaded to the sNB 920 (and uploaded to the server 910), user devices located within the terrestrial coverage region (e.g., a 5G coverage area) of the sNB 920 may access the data from the server 910.

[0043] 10A shows a ground-based, satellite-enabled edge processing arrangement where routing is done "on the ground" and satellites are used as "bent pipes" between edge processing locations. In this context, "bent pipe" simply refers to using a satellite or satellite constellation as a connecting relay to communicate data from one ground location to another. As shown, a satellite 1000 of the constellation has an orbital path that travels from location 1001A to 1001B, providing separate coverage areas 1002 and 1003 for connection at each point in time.

[0044] Here, when a satellite-enabled edge computing node 1031 (sNB) is in the coverage area 1002, it gets a connection via a satellite 1000 (located at location 1001A) to communicate with a wider area network. In addition, this edge computing node sNB 1031 may be located at an edge ground station 1020 that further communicates with a data center 1010A to perform computing operations at a terrestrial location.

[0045] Similarly, when a satellite-enabled edge computing node 1032 (sNB) is in the coverage area 1003, it gets a connection via a satellite 1000 (at location 1001B) to communicate with a wider area network. Again, computing operations (e.g., services, applications, etc.) are processed at terrestrial locations such as edge ground stations 1030 and data centers 1010B.

[0046] Figure 10B illustrates another ground-based, satellite-enabled edge processing arrangement. Similar to the arrangement shown in Figure 10A, a satellite 1000 is shown in a constellation along an orbital path moving from position 1001A to 1001B, providing separate coverage areas 1002 and 1003 at each time. However, in this example, the satellite is used as a data center to perform edge computing operations (e.g., providing data, computing data, relaying data, etc.).

[0047] Specifically, edge computing hardware 1021 is located on the satellite vehicle to process data requests received from ground stations sNB 1031, 1032 within the computing or coverage area 1002, 1003. This may have the advantage of eliminating communication delays associated with other locations in the wide area network. However, processing and storage constraints may limit the amount of computing power on the satellite 1000, so some requests or operations may be offloaded to the ground stations 1031, 1032.

[0048] As will be appreciated, edge computing and edge network connectivity can include various aspects of RAN and software defined network processing. Specifically, in many of these scenarios, radio terminations can be moved between terrestrial and satellite depending on available processing resources. Also, in these scenarios, URLCC (Ultra Reliable Low Latency Connectivity) processing can be done on the ground or in the payload using packet processing approaches including via packet processing templates as further described herein and via vRAN-DU (Distributed Unit) processing and acceleration.

[0049] FIG. 10C shows a further comparison of ground-based and non-ground-based edge processing arrangements. Here, a satellite network 1005 provided by a LEO constellation is used. a) On the left, it provides connectivity and edge processing to up to millions of user devices 1041 (e.g., UEs, IoT sensors) that do not have a direct wired connection to the core network 1061. b) At the center, it provides connectivity and edge processing via a "bent pipe" edge server 1051 that has a direct wired connection to the core network 1061 and supports up to thousands of edge servers on the ground. c) On the right, it provides the use of an on-board edge server 1081 that may work in conjunction with a hybrid edge server 1071 to support up to hundreds of servers for on-orbit processing and hundreds of servers for the ground station. It will be appreciated that the servers 1051, 1071 and 1081 may be accessed for use by various UEs 1041 based on connectivity and service orchestration considerations such as those described further below.

[0050] Additional scenarios for network processing are shown in Figures 11A-11D. Figure 11A shows a satellite connection. First, we show an edge connectivity architecture with the terrestrial RAN side, using the 5G RAN (via satellite 1101) as the "bent pipe" and the vRAN-DU 1140 as the terrestrial edge. In this scenario, the satellite edge equipment 1120A communicates uplink and downlink via a 5G New Radio (NR) interface 1111 with the satellite 1101. The satellite also communicates uplink and downlink via a NR interface 1112 with a remote radio unit (RRU) 1130 that was connected to the vRAN-DU 1140. The network also includes a vRAN-CU (Central Unit) 1150 and a core network 1160.

[0051] Satellite edge equipment 1120A illustrates an example platform configuration configured to provide connectivity and edge processing for satellite connectivity. This equipment 1120A specifically includes an RF phased array antenna 1121, memory 1122, processor 1123, network interface 1124 (e.g., supporting Ethernet / Wi-Fi), GPS 1125, antenna steering motor 1126, and power components 1127. Other configurations and computer architectures of equipment 1120A for edge processing are further described herein.

[0052] 11B-11D show simplified versions of satellite access equipment 1120B used for network access. In the configuration of FIG. 11B, a similar bent pipe connection scenario is provided, with vRAN-DU 1140 located on the ground. In the configuration of FIG. 11C, vRAN-DU 1141 is located on board the SV, and an F1 interface 1113 is used to connect vRAN-CU 1150 and the terrestrial core network 1160. Finally, in the configuration of FIG. 11D, vRAN-DU 1141 and vRAN-CU 1151 are located on board the SV, and an N1-3 interface 1114 is used to connect with the terrestrial core network.

[0053] In a further example, the satellite and terrestrial connectivity networks identified above may be adapted for satellite and 5G ground station optimization using various artificial intelligence (AI) processing techniques. In one example, infrastructure optimization related to terrestrial 5G pole placement (uplink, downlink, latency) for optimal performance and satellite constellation coexistence may be analyzed to support improved network coverage.

[0054] Some satellite constellations have limited ground stations, so satellite connection latency can be affected if they are not located in line of sight with devices on the ground. As a result, service providers are expected to optimize their networks for 5G pole placement to avoid weather interference. Satellite imagery can be used as inference input to the AI ​​engine, allowing service providers to determine optimal routing and placement of 5G poles, leveraging factors such as geolocation, demand, latency, uplink, downlink requirements, and positive weather forecasts.

[0055] Satellite coverage coordination

[0056] The following techniques may be used to obtain a satellite coverage footprint for a LEO satellite network connection. The coverage footprint may be used to coordinate edge computing operations between terrestrial and non-terrestrial locations, in addition to determining when a satellite connection is available at a particular location (e.g., at a UE or satellite backhaul base station).

[0057] When considering satellite coverage from LEO, two main challenges are faced. First, depending on the altitude and density of the constellation, a particular edge location will be covered with network access (and computing access) for a different amount of time. The latency and bandwidth of the satellite connection may also change over time. Second, the satellites that host the computing resources are constantly moving around, coordinating computations with other satellites and ground systems. Therefore, the location and coverage capabilities of the satellite edge computing nodes are important considerations that must always be taken into account.

[0058] Provided below is a command mechanism that identifies the satellite coverage and location of individual SVs for the purposes of executing edge computing workloads or coordinating with the SVs to obtain content. Using this coverage and location information, individual edge endpoint devices can plan or coordinate their operations to make the best use of their LEO connections.

[0059] In one example, a command may be defined in the connectivity service to Get Satellite Vehicle future (fly-over) positions relative to ground positions. This may be provided by a "Get SV Footprint" command provided by the network or service provider. In the following, the ground (GND) reference may refer to the Ground Station Edge, Telemetry Tracking, UE or IoT Sensor Positions. The following parameters can be provided for this example "Get SV" footprint command:

[0060] [Table 1]

[0061] For example, the "direction" property can be used to obtain flyover telemetry.

[0062] Also for example, the "Get SV" footprint command may be defined to provide the following information in the response to the requestor:

[0063] [Table 2]

[0064] It will be appreciated that the availability property may be extended to information regarding available frequencies and inter-satellite links, or both, for routing decisions, including decisions related to locations of edge computing accessible on a satellite via bent pipe connections.

[0065] 12 illustrates a flowchart 1200 of a method for obtaining a satellite vehicle position in connection with an edge computing operation, according to one example. In operation 1210, a request is made to obtain a future flyover position of the satellite vehicle relative to a ground location. In one example, in addition to Table 1 above, the request includes an identification of the latitude, longitude, and altitude used for the satellite reception. Aspects of the request and command may also involve authentication (e.g., ensuring that the communication protocol is secure and that the data provided is trustworthy and not spoofed).

[0066] A response is obtained in operation 1220 indicating the future flyover position of the satellite vehicle relative to the ground position. For example, the "Get SV" footprint command and response described above may be used.

[0067] Based on this footprint information, an operation 1230 may be performed to identify network coverage and changes in coverage for the ground location. Edge computing operations may be adjusted or optimized at operation 1240 based on the identified network coverage and changes in coverage.

[0068] The following examples provide further variations of this and similar methods.

[0069] Example A1 includes a method performed by a terrestrial computing device for determining coverage of a satellite network from a low Earth orbit (LEO) satellite system, the method including: obtaining satellite coverage data for a latitude and longitude of a region on the ground, the satellite coverage data including an indication of a time and intensity of a beam footprint expected in the region on the ground; determining satellite coverage for connection with a satellite network using the LEO satellite system based on the satellite coverage data; and adjusting edge computing operations on the terrestrial computing device based on the satellite coverage data.

[0070] In Example A2, the subject matter of Example A1 optionally includes subject matter where the satellite coverage data includes identifying the latitude, longitude, and altitude used for satellite reception in an area on the earth.

[0071] In Example A3, the subject matter of Example A2 optionally includes subject matter where the satellite coverage data includes a radius of a predicted beam footprint, a minimum intensity at altitude of a predicted beam footprint over time at an altitude of a predicted beam footprint.

[0072] In Example A4, the subject matter of any one or more of Examples A1-A3 optionally includes subject matter where the satellite coverage data includes a central latitude point of the predicted beam footprint and a central longitude of the predicted beam footprint.

[0073] In Example A5, the subject matter of any one or more of Examples A1-A4 optionally includes subject matter where the satellite coverage data includes an identifier for a satellite vehicle or satellite constellation.

[0074] In Example A6, the subject matter of any one or more of Examples A1-A5 optionally includes subject matter where the request for satellite coverage data includes a time required to conduct a communication operation over the satellite network and the satellite coverage data includes a time available to conduct the communication operation over the satellite network.

[0075] In Example A7, the subject matter of Example A6 optionally includes subject matter where the satellite coverage data includes a satellite vehicle or satellite constellation identifier and name for performing communications operations over the satellite network.

[0076] In Example A8, the subject matter of any one or more of Examples A1-A7 optionally includes subject matter where coordinating edge computing operations includes performing the operations locally at a terrestrial edge computing location.

[0077] In Example A9, the subject matter of any one or more of Examples A1-A8 includes subject matter where coordinating edge computing operations includes offloading computing operations from a terrestrial computing location to a location accessible via a satellite network.

[0078] In Example A10, the subject matter of Example A9 includes subject matter where the locations accessible via the satellite network include edge computing nodes located within at least one of a satellite vehicle indicated by the satellite coverage data, a satellite constellation reachable via a connection indicated by the satellite coverage data, or a terrestrial edge processing location reachable via a connection indicated by the satellite coverage data.

[0079] In Example A11, the subject matter of any one or more of Examples A9-A10 optionally includes subject matter where the locations accessible via the satellite network include a cloud computing system accessible via a backhaul of the satellite network.

[0080] In Example A12, the subject matter of any one or more of Examples A1-A11 includes subject matter where coordinating edge computing operations includes offloading data content operations from a terrestrial computing location to a data content store location accessible via a satellite network.

[0081] In Example A13, the subject matter of any one or more of Examples A1-A12 optionally includes subject matter where adjusting the edge computing operation at the terrestrial computing device is further based on delay and service information calculated based on satellite coverage data.

[0082] In Example A14, the subject matter of any one or more of Examples A1-A13 optionally includes subject matter where obtaining the satellite coverage data includes sending a request for satellite coverage data to a service provider for a latitude and longitude at which satellite coverage occurs in the region on the ground.

[0083] In Example A15, the subject matter of any one or more of Examples A1-A14 optionally includes subject matter where coordinating the edge computing operations includes making calculations and routing decision calculations based on information indicative of available satellite network communication frequencies, inter-satellite links, and available satellite network communication strengths.

[0084] Connector Computing Architecture for Satellite Network Connectivity

[0085] As previously discussed with reference to FIG. 2, devices may be connected to satellite-connected edge locations implementing dual-type access such as radio access networks (e.g., 3GPP 4G / 5G, O-RAN Alliance standards, IEEE 802.11, or LoRa / LoRaWAN, providing network functions such as vEPC with CUPS / UPF) and first level edge services (e.g., CDN). In the following example, when these services require a connection to the cloud or the core of the network, a backhaul connection occurs via satellite communications. For example, if there is a miss in the CDN cache at the local edge CDN or the workload requires resources or hardware that are not available at the base station, the new connection obtains or provides this information via the satellite network backhaul.

[0086] One of the main challenges of such terrestrial-satellite architectures is how to overcome the higher latency that arises when a service requires a connection to the backhaul of the network. This challenge becomes more difficult when there are multiple types of backhaul connections (e.g., to different data centers) with different properties or congestion levels, and the associated resource sharing (e.g., bandwidth) limitations offered by such connections. Similarly, the challenge becomes more difficult given the small amount of time that a particular SV is in communication range to perform a computational operation or complete a data transfer to its source location.

[0087] The following approach provides a "satellite edge connector" mechanism for implementation within an edge computing node, appliance, device, or other computing platform. With this mechanism, telemetry and connection status is obtained from a satellite or satellite constellation that has a connection to a particular edge computing location, cloud, or data center, and this status information is used to implement smarter network traffic shaping from the original platform. In one example, the satellite edge connector can be implemented by extending a network platform module (e.g., a separate or integrated platform / package) that is responsible for handling communications for edge services. This can be provided at a base station, access point, gateway, or aggregation point that provides the network platform as a relay between an endpoint device (e.g., UE) and the satellite network. For example, the network platform module at the relay can also be adapted to dynamically handle the QoS and bandwidth associated with various data streams mapped to different services depending on the backhaul connection status available from the satellite to various endpoints.

[0088] Additionally, in various edge computing settings, each tenant or group of tenants may apply (or require) different security, QoS, and data dynamic privacy policies, including policies that depend on the tenant's geographic location or communications and computing hardware. In such settings, the edge computing platform may automatically configure such policies based on associated geolocation, especially when coordinating communications over ephemeral LEO satellite networks. Each tenant or group of tenants may also apply rules that determine how and when specific QoS, security, and data policies are used for a particular computational task or communications data.

[0089] FIG. 13 illustrates a network platform (similar to that shown in FIG. 2) extended with satellite communications for virtual channels. In this configuration, each endpoint (e.g., from a requesting edge device) is mapped to a satellite endpoint virtual channel (EPVC). One or more service streams targeted to a particular endpoint (e.g., cloud A 1340A or cloud B 1340B) are mapped to a satellite endpoint VC of a satellite 1330. Each of the service streams is mapped to a particular stream virtual channel (SVC) within that satellite endpoint VC, and multiple streams can be mapped to the same SVC. In one example, streams are also mapped to tenants and services using process address space IDs (PASIDs) or global process address IDs (PASIDs), as shown below:

[0090] In this configuration, using telemetry from the satellite 1330 (or satellite constellation) and the quality of service attached to each SVC, the network logic can dynamically move bandwidth between different EPVCs. The network logic provides active feedback to the software stack to apply platform QoS such as throttle-back services to one of the edge base stations 1320, satellite 1330 or clouds 1340A, 1340B that are mapped to EPVCs where constrained bandwidth or other conditions (e.g., power, memory, etc.) exist. Such network logic can be implemented in the base station 1320 using the following architectural configuration:

[0091] 14A and 14B show an architectural configuration of a computing system including a connector module adapted for use in satellite communications. In FIG. 14A, the architectural arrangement is provided for an appliance having a socket-based processor (FIG. 14A) or a ball grid array package-based processor as shown in FIG. 14B. In addition to the processors 1431, 1432, the architecture shows memory resources 1421, 1422, acceleration resources 1411, 1412, platform controllers 1441, 1442, and memory / storage resources 1451, 1452. Other computing architectures may also be adapted for use in the satellite connectivity module below. Although not shown, the architecture may be implemented in a variety of physical form factors (in the form of servers, boxes, sleds, racks, appliances, etc.).

[0092] In both architectural arrangements, Figures 14A and 14B identify an element (specifically, satellite 5G backhaul cards 1461, 1462) that provides the connection from the platform to the satellite as a connector. This element, called a "connector module," can be integrated into the platform or used separately as a device (e.g., PCIE, NVLink, CXL device).

[0093] In one example, the connector modules 1461, 1462 are exposed to a software stack and provide an interface similar to a network interface card and may include semantics for inputting and retrieving data from an endpoint (e.g., the next tier of services hosted in a data center after the satellite, such as those corresponding to the clouds 1340A, 1340B). The connector modules 1461, 1462 understand how local streams are mapped to one or more endpoint connectors after the satellite, and monitor the connections between the satellite and the endpoint connectors over time and the impact those connections have, and how much bandwidth is effectively available. This may be achieved by utilizing telemetry information provided by the satellite to the logic. Additional information regarding the connector modules is provided in Figures 16 and 17.

[0094] In addition, the connector modules 1461, 1462 may apply Quality of Service (QoS) policies to streams sharing the same endpoint and connection with different levels of QoS agreements (e.g., connections shared among different tenants). The connector modules 1461, 1462 may apply bandwidth load balancing to satellite communications between different streams mapped to different endpoints when backhaul changes are applied. The connector modules 1461, 1462 may also scale down resources to services bound to the network when telemetry from the satellite indicates that the service cannot achieve the desired performance.

[0095] 15 illustrates a flowchart 1500 of a method for using a satellite connector to coordinate edge computing operations. As previously discussed, such operations may occur at a base station (such as 1320), although other types of network gateways, access points, aggregation points, or connectivity systems may also be used.

[0096] At the ground station (e.g., at edge base station 1320), current or future streams are identified in operation 1510 and grouped into Virtual Channels (VCs) in operation 1520, for example, by using a hierarchical VC definition. Each endpoint is mapped to a Satellite Endpoint Virtual Channel (EPVC) based on the endpoint of the data stream. One or more service streams targeted to a particular endpoint are assigned to a Satellite Endpoint VC. (e.g., Cloud A 1340). Each service stream is mapped to a specific Stream Virtual Channel (SVC) within that satellite EPVC in operation 1530. Thus, an EPVC can contain multiple SVCs, and each SVC is mapped to multiple services as well as tenants that have associated EPVCs.

[0097] Using telemetry from the satellites and the quality of service attached to each SVC, the network logic dynamically moves bandwidth between different EPVCs in operation 1540. Additionally, in operation 1550, the network logic provides active feedback to the software stack to throttle back or adapt services mapped to bandwidth-constrained EPVCs (e.g., by adapting power, memory or other resources).

[0098] 16 illustrates the internal architecture of a connector module 1610 that may be implemented at a terrestrial location (e.g., a "terrestrial" edge computing system) adapted for use in satellite communications. As previously discussed, this architecture supports a particular method of grouping data streams into EPVC virtual channels (e.g., using hierarchical virtual channel definitions) to communicate efficiently over the satellite network.

[0099] The internal architecture of 1610 is applicable to an end-to-end system with fixed LEO satellites connected to ground-based edge appliances. Assuming that the ground-based edge appliances do not always have full connectivity and high bandwidth connectivity (e.g., due to remote locations), the following provides a useful approach for coordinating satellite backhaul data transmission and necessary processing operations.

[0100] In one example, the connector module 1610 is used to enable data transmission a) between satellites forming a cluster / federation / constellation (e.g., to minimize required data transmissions, including sending only summary information or preventing duplication of data transmissions where necessary) and b) between satellite clusters and terrestrial base stations (e.g., to determine when and which satellites communicate what data and enable handoff to the next terrestrial station). Planning and coordination are key to such transmissions, not only in terms of data management, resource allocation and management, but also processing ordering.

[0101] For example, in a logistics use case, consider a system that is coordinated from a ground-based management system and a satellite connectivity network to determine a joint plan for the movement and tracking of some physical resource, such as tracking the movement of cargo ships at sea. Here, the coordination involves identifying a) the relevant domain for the satellite connectivity (e.g., based on the geolocation of the cargo ships), b) what processing is required via the satellite system (e.g., image processing to detect the number of cargo ships), and c) how much bandwidth, resources, or processing is required to send back the data results via the satellite connectivity (e.g., returning only the number of cargo ships identified in the image data, rather than all images).

[0102] It will be appreciated that various conventional network deployments take into account quality of service and service level agreements. However, existing approaches fail to fully address satellite system architectures and connectivity considerations associated with such architectures. Furthermore, the concept of backhaul connectivity over satellite networks is not considered as part of existing architectures. As a result, the presently disclosed approach provides end-to-end QoS adaptation policies for the satellite edge and provides resource allocation based on mobility and multi-satellite telemetry.

[0103] With reference to the connector module architecture of Figure 16, the stream configuration logic 1611 of the ground edge connector module 1610 is used to map each endpoint of communication to a satellite endpoint virtual channel (EPVC). One or more service streams targeted to a particular endpoint are mapped to a satellite endpoint virtual channel (VC) (e.g., Cloud A) that performs processing (e.g., image detection processing). In one example, each service stream is also mapped to a particular stream virtual channel (SVC) from within that satellite endpoint VC.

[0104] The stream configuration logic 1611 also provides an interface to the system software stack to map identifiers of various streams (which may have the form of a Process Address Space Identifier (PASID), an application / service represented by a PASID+tenant identifier, or similar types of process or service identification) to corresponding EPVCs and SVCs. In one example, logic 1611 enables the system to provide or obtain an ID for the service, an identification of the EPVC and SVC associated with the PASID (note that various streams may share the same SVC), and an identification of the latency and bandwidth requirements associated with the stream. A detailed description of these properties and streams is provided below with reference to FIG. 17.

[0105] Using telemetry from the satellites and the quality of service attached to each SVC, network logic (e.g., logic 1612-1615 in conjunction with satellite communications logic 1616) dynamically moves bandwidth between different EPVCs and provides active feedback to the software stack via the platform RDT to apply platform QoS, for example to throttle back services mapped to EPVCs where there is bandwidth constrained (e.g., power, memory, etc.). Such logic may operate in addition to existing forms of satellite communications logic 1618 and platform resource director technology 1619.

[0106] At the edge connectors at the Satellite Edge 1620, satellite side functionality can be coordinated to complement the operations at the Terrestrial Edge 1610. Similarly, logic implemented at the Satellite Edge 1620 allows the satellite system to create SVCs with specific bandwidth and delay requirements.

[0107] At the satellite edge 1620, various components can be bound to the EPVCs and SVCs to enforce the E2E policies implied by the terrestrial edge 1610. Such satellite functions can include end-to-end QoS SVC mapping 1621, predictive route and QoS allocation planning 1622, end-to-end future resource reservation policies 1623 (supporting both local (satellite) and terrestrial policies), telemetry processing 1624 (supporting terrestrial telemetry and peer forwarding telemetry), local (satellite) telemetry and terrestrial edge zone and up-downlink agreement processing 1625.

[0108] FIG. 17 provides additional examples of processing logic used within the edge connector 1610 architecture at the ground edge, including example information maintained for streams and channels. In one example, the stream configuration logic 1611 provides an interface to a system software stack (not shown) to map various stream IDs (which may take the form of a PASID or any similar type of identification, including where a PASID maps to a tenant) to corresponding EPVCs and SVCs. For example, the stream configuration logic 1611 provides (1) an identifier for the service, (2) an EPVC and SVC identifier associated with the PASID (note that various streams may share the same SVC and multiple PASIDs are mapped to the same SVC), and (3) latency and bandwidth information (e.g., requirements) associated with the stream. With this information, the stream configuration logic 1611 enables the creation of an SVC with a particular bandwidth and latency requirement.

[0109] 18 illustrates a flowchart 1800 of a method for using a satellite connector for coordination with edge computing operations. Additional operations (not shown) may utilize other aspects of load balancing, QoS management, resource management, and stream aggregation consistent with the techniques described herein.

[0110] In operation 1810, the data streams are mapped to endpoints and virtual channels using the IDs mapped to the tenants. In one example, this is done by logic 1614 and 1615. Endpoint (EP) telemetry logic 1614 and endpoint (EP) projection logic 1615 are responsible for tracking and predicting (e.g., using LSTM neural networks) how the satellite to endpoint connections change over time. This mapping allows information to be collected for requirements related to the data streams in operation 1810 and telemetry related to data streams 1820. For example, this logic may collect data sets 1730 that track EPVCs, last known bandwidth, and last known delays. Such logic exposes a new interface to the satellite that allows for consideration of the current delay and bandwidth available at each endpoint.

[0111] In one example, the telemetry provided by the two aforementioned components is provided to the SVC and EPVC load balancing QoS logic as follows:

[0112] (1) In operation 1840, the SVC QoS load balancing logic 1612 is used to apply QoS and resource balancing across all streams mapped to a particular SVC according to their QoS requirements. In response to changes in the SVC allocation logic, this logic is responsible for distributing the existing bandwidth to different streams according to their requirements (e.g., distributing bandwidth according to priority).

[0113] (2) In operation 1850, the EPVC QoS load balancing logic 1613 is used to manage the bandwidth connection between the platform and the satellite according to the current or predicted bandwidth available to each endpoint. Each EPVC has a given priority associated with it. The bandwidth to the satellite is divided among the EPVCs in proportion to the priority. If a particular endpoint has less bandwidth available than was associated with the corresponding EPVC, the bandwidth is divided among the other EPVCs using the same priority criteria. When the bandwidth for a particular endpoint is changed (increased or decreased), the bandwidth associated with the EPVC is changed proportionally according to the priority of that particular endpoint. The increased or decreased bandwidth is provided to the other EPVCs as described above. Prediction logic may also be used to identify that less bandwidth will be available to a particular EP in the future and provide more bandwidth to the EPVC in advance. Thus, each EPVC may have an overall allocation (based on priority) that may be consumed ahead based on predictions.

[0114] As will be appreciated, EPVCs established from end-to-end may be re-routed to perform load balancing. For example, an EPVC involving Edge 1, Satellite 1, Satellite 2, Satellite 3, Terrestrial may be mapped to EPVCx, but Satellite 2 does not provide sufficient bandwidth given the required QoS. In response, the system may remap EPVCx to Satellite 1 -> Satellite X -> Satellite 3 -> Terrestrial.

[0115] (3) At operation 1860, the SVC QoS load balancing logic 1612 may provide telemetry to the platform resource director logic 1619 (e.g., implemented using resource director technology) to increase or decrease resources associated with a particular SVC depending on the allocated bandwidth. This logic may identify the bandwidth to meet the required resources for a particular identifier (e.g., PASID) using rules (e.g., mapping PASID ID, list of bandwidths {BW1,...BWn} with corresponding required resources (memory, CPU, power, etc.)).

[0116] Variations of this method and similar methods are provided by the following examples.

[0117] Example B1 is a method performed in a computing system for establishing a managed data stream connection using a satellite communications network, the method including: identifying a set of data streams to be carried out between the computing system and a set of endpoints via a satellite communications network; grouping a set of the data streams into an Endpoint Virtual Channel (EPVC), the grouping based on each of the endpoints; mapping each data stream of the EPVC to a Stream Virtual Channel (SVC) based on a service type associated with the each data stream; identifying changes to each data stream based on service requirements and telemetry associated with each data stream of the EPVC; and implementing the changes to each data stream based on the service type associated with the each data stream.

[0118] In Example B2, the subject matter of Example B1 optionally includes subject matter where said service requirements include Quality of Service (QoS) requirements.

[0119] In Example B3, the subject matter of any one or more of Examples B1-B2 optionally includes subject matter where the service requirements include compliance with at least one service level agreement (SLA).

[0120] In Example B4, the subject matter of any one or more of Examples B1-B3 optionally includes subject matter including a respective cloud data processing system accessible by the plurality of endpoints via the satellite communications network.

[0121] In Example B5, the subject matter of any one or more of Examples B1-B2 includes subject matter where the telemetry includes identifiable delay information based on EPVC and SVC.

[0122] In Example B6, the subject matter of any one or more of Examples B1-B5 optionally includes the subject matter of identifying changes to the respective data streams based on connection conditions associated with the satellite communications network.

[0123] In Example B7, the subject matter of any one or more of Examples B1-B6 optionally includes subject matter where the changes to the respective data streams are provided from changes to at least one of delay, bandwidth, service capability, power conditions, resource availability, load balancing, or security characteristics.

[0124] In Example B8, the subject matter of any one or more of Examples B1-B5 optionally includes the method further including collecting service requirements associated with the respective data streams and collecting telemetry associated with the respective data streams.

[0125] In Example B9, the subject matter of any one or more of Examples B1-B8 optionally includes subject matter including the changes to the respective data streams including moving at least one SVC from a first EPVC to a second EPVC to change use of at least one service from the first endpoint to the second endpoint.

[0126] In Example B10, the subject matter of any one or more of Examples B1-B8 optionally includes subject matter where implementing changes to the respective data streams includes applying QoS and resource balancing across the respective data streams.

[0127] In Example B11, the subject matter of any one or more of Examples B1-B10 optionally includes subject matter where implementing changes to the respective data streams includes applying load balancing to manage bandwidth across the respective data streams.

[0128] In Example B12, the subject matter of any one or more of Examples B1-B11 optionally includes the method further including providing feedback to a software stack of the computing system in response to identifying changes to the respective data streams.

[0129] In Example B13, the subject matter of Example B12 optionally includes the method further including adjusting usage of at least one resource associated with a corresponding service in the software stack based on the feedback.

[0130] In Example B14, the subject matter of any one or more of Examples B1-B13 optionally includes subject matter where the mapping of each data stream of an EPVC to an SVC is further based on identifying a tenant associated with the each data stream.

[0131] In Example B15, the subject matter of Example B14 optionally includes the method further including increasing or decreasing resources associated with at least one SVC based on the determining.

[0132] In Example B16, the subject matter of any one or more of Examples B1-B15 optionally includes subject matter in which the respective data streams are established between a client device and the multiple endpoints to obtain content from between the multiple endpoints.

[0133] In Example B17, the subject matter of Example B16 optionally includes subject matter wherein the computing system provides a content distribution service, and the content is retrieved between the multiple endpoints using the satellite communications network in response to a cache miss at the content distribution service.

[0134] In Example B18, the subject matter of any one or more of Examples B1-B15 optionally includes subject matter in which the respective data streams are established between a client device and the multiple endpoints for performing computing operations at the multiple endpoints.

[0135] In Example B19, the subject matter of Example B18 optionally includes subject matter wherein the computing system is further configured to provide a radio access network (RAN) to client devices with virtual network capabilities.

[0136] In Example B20, the subject matter of Example B18 optionally includes subject matter where the radio access network is provided in accordance with a standard from a 3GPP 5G family of standards.

[0137] In Example B21, the subject matter of any one or more of Examples B19-B20 optionally includes the subject matter where the radio access network is provided in accordance with a standard from an O-RAN Alliance family of standards.

[0138] In example B22, the subject matter of any one or more of examples B19-B21 optionally includes subject matter where the computing system is hosted at a base station for the RAN.

[0139] In Example B23, the subject matter of any one or more of Examples B1-B22 optionally includes the subject matter where the satellite communications network is a low earth orbit (LEO) satellite communications network including a plurality of satellites in at least one constellation.

[0140] In Example B24, the subject matter of any one or more of Examples B1-B23 optionally includes subject matter where the satellite communications network is used as a backhaul network between the computing system and the multiple endpoints.

[0141] In Example B25, the subject matter of any one or more of Examples B1-B24 optionally includes subject matter where the computing system includes a base station, access point, gateway, or aggregation point that provides a network platform as a relay between client devices and the satellite communications network to access the multiple endpoints.

[0142] Satellite network cache and storage processing

[0143] With the use of satellite communications, there are also a number of important challenges: (1) how to overcome the high latency and low bandwidth that arise when edge computing services require a connection to a backhaul network; (2) how to enforce geofencing data policies for data transmitted (and received) between edge devices, satellites, and endpoints; and (3) how to enforce end-to-end quality of service policies in a moving constellation of satellites, taking into account exclusion zones, geofencing, and various types of telemetry (from satellite peers in the constellation, from local processing systems, and from terrestrial actors).

[0144] These problems become more challenging, especially when there are multiple types of backhaul connections (e.g., to different data centers) with different properties, levels of congestion, edge base stations connected to the satellite mobile, and policies or service provider restrictions on content and services. In addition, as new methods of storing data in mobile edge systems are developed, using satellite exclusion zones and other unique characteristics will require new approaches in the form of rules, policies, and interfaces to implement autonomous, low latency, and dynamic data transformation and deletion in response to these approaches and metadata.

[0145] One approach expected to be used to solve the problem of authorization in the context of satellite communications involves the application of geofencing, for example, to make certain services or data available (or to prohibit or block such services or data or the use of such services or data) only based on geolocation. In the context of geofencing, three levels of geofencing may be required between any of three entities: end users / content providers, satellites and content / service providers. Geofencing may also be applied not only with respect to the ground (e.g., which countries are the satellites flying over), but also as a volumetric field within the domain of data transmission. For example, a certain volume or volume of space may be allocated, reserved or managed by a particular country or entity.

[0146] When considering content delivery over satellite communications, geofencing and restriction becomes very challenging due to the volume and expected volume of data in the content delivery communications, the different levels or service level agreements for delivering such data, the number of content providers, and the overall concerns regarding privacy, security, and data movement across such a dynamic environment. A caching and content delivery approach to address these challenges is provided below.

[0147] Figure 19 shows a network platform (similar to that shown in Figures 13 and 2) extended as a content catching architecture. Here, the architecture consists of a three-tiered terrestrial and satellite content delivery cache layer with quality of service and geofencing rules. In the context of this three-tiered cache architecture (base station 1920 responding to edge device requests 1910, satellite and end content providers 1930 and 1940), improvements are implemented in the following elements:

[0148] (a) Adaptive satellite content caching provided from multiple end locations to multiple sets of base stations distributed across multiple end locations, including QoS policies based on geographic area, subscriber and data provider served by the satellite. Additionally, new types of cache policies on the satellite are provided based on geofencing, satellite peer hints and terrestrial data access hits.

[0149] (b) Adaptive terrestrial data caching based on satellite data caching hints from the satellite, where the satellite provides each base station with information about content that should potentially be prefetched based on how base stations in the same geographic region access the content.

[0150] (c) Adaptive terrestrial content flows based on endpoint bandwidth availability: Here, the goal is to be able to implement adaptive throttling at the base station requesting content depending on the actual bandwidth availability between the satellite and the end content provider (e.g., for content missing in the satellite cache).

[0151] (d) Data geofencing (assuming not all locations are allowed) applied with two levels of fencing: (1) according to the geolocation of the consumers and producers of targeted ground data and (2) according to the xyz location of the satellite. Satellite data can be tagged with geofencing locations used as part of hit and miss policies. Data can be mapped to dynamic security and data privacy policies determined for tenants, groups of tenants, service providers and other participating entities.

[0152] Figures 20A and 20B show a network platform extended via satellite communication for geofencing and data caching operations. This platform is based on an extension of the features described in Figure 14. However, it will be appreciated that this architecture can be extended for other aspects of data caching related to specific data flows, caching policies, caching hints.

[0153] As shown in Figures 20A and 20B, an architecture arrangement is provided for an appliance having a socket-based processor (Figure 20A) or a ball grid array package-based processor (Figure 20B). In addition to processors 2031, 2032, the architecture shows memory resources 2021, 2022, acceleration resources 2011, 2012, a platform controller 2041, and memory / storage resources 2051, 2052.

[0154] In addition to the use of connector modules (e.g., satellite 5G backhaul cards 2061, 2062), the architecture may incorporate the use of a fast caching terrestrial logic component 2051. In one example, this component implements a two-tier caching logic responsible for determining how content should be cached between the two tiers (terrestrial and satellite tiers). For example, the terrestrial caching logic (e.g., implemented in component 2051) proactively increases or decreases the amount of content delivery to be prefetched based on:

[0155] (1) Telemetry from each EPVC bandwidth, so if there is more availability of EPVCs for a particular content provider, the amount of prefetching can be increased. The logic can utilize predictive data to prefetch more content in anticipation of higher saturation situations.

[0156] (2) Hints provided by satellite logic capable of analyzing requests from multiple terrestrial logics. The hints may provide a list of hot content tagged with the geolocation or region where the content is being absorbed, the endpoint or content delivery service to which the content is attached, or the time the content was last accessed.

[0157] In one example, the satellite logic (e.g., implemented in components 2061, 2062) (a) pre-caches content from multiple EP content sources and implements different types of caching policies depending on SLAs, data geofencing, data expiration dates, etc., and (b) pre-sends telemetry hints to ground caching logic 1611 provided as part of the ground edge 1610 shown in FIG. 21.

[0158] 21 more specifically illustrates an appliance configuration for satellite communications extended via satellite communications for content and geofencing operations according to one example. In accordance with the configuration example of FIG. 16, hygiene logic in the satellite edge computing system 2120 can implement a geo-aware caching policy for the storage system 2130 based on the following functional components:

[0159] Data Provider Rules 2121: Each content provider cached at the Satellite Edge 2120 has a certain level of SLA that translates into the amount of data cached for that provider at the satellite. For example, if the satellite's cache capacity is 100%, 6% may be allocated to streaming video providers.

[0160] Data Provider Geolocation Rules 2122: If there are different types of endpoint providers in different geolocations, the provider rules can be extended to specify different percentages for a given provider. Other aspects of data transformation for a provider or geolocation can also be defined.

[0161] Ground-based eviction (evictI / Ons) 2123: Each base station that provides content to edge devices provides hot and cold content to a satellite. Content for A and B that is cold is hosted on the satellite for N number of hours and then evicted or replaced with new content (e.g., prefetched content).

[0162] Data sharing between providers 2124. Different CDN providers may be allowed to share content or portions of content, each of which includes metadata that identifies other content providers sharing that data.

[0163] Satellite geolocation policy 2125. Depending on the target geolocation, terrestrial data may be missed or hit. Each data has a tag (area or list all) that identifies the geolocation where it can be accessed. If the edge base station does not meet these requirements, a miss occurs.

[0164] Satellite API and Data 2126. A flushing mechanism is provided that allows specific data to be flushed based on geolocation and based on content tag type for low latency flushing. Data needs to be tagged with meta keys (e.g., content provider, tenant, etc.) and the satellite can provide an interface (API) to control the availability of this data (e.g., flush data with specific meta keys when crossing X geographic region). Data is geotagged at the time of generation and can be enforced as part of the flushing API. Additionally, data transformation rules can be applied based on the use of the interface, such as automatically applying X (e.g., anonymize the data) when data with metadata or geotags is matched. This can ensure that violations do not occur in certain regions.

[0165] Additionally, data peer satellite hints may be implemented as part of the policy 2125. Content may be proactively evicted or demoted from hot to warm if there is feedback from satellite peers covering the peer's geolocation that the content is no longer hot. Content that was demoted to warm after X units of time may be evicted after Y units of time. Content may be made hot based on similar feedback from peer satellites.

[0166] It will be appreciated that CDN caches may incorporate more complex hit / miss logic that implements different combinations of the previous elements, and these variations may be considered for content delivery, geocaching, and other aspects of latency-sensitive applications.

[0167] The above defines a new kind of semantics for the storage and distribution of data at the satellite edge, however, it will be appreciated that other content storage, caching and eviction approaches may also be provided for the cooperation between the satellite edge and the computing systems.

[0168] FIG. 22 illustrates a flow chart of a method 2200 for searching for content using satellite communications based on a geofencing operation.

[0169] At operation 2210, content caching occurs at a satellite edge computing location involving some aspect of the satellite vehicle, constellation, or non-terrestrial coordinated storage. The interfaces described above can be used to define properties of such caching, data caching limitations, geographic details, etc.

[0170] At operation 2220, terrestrial data caching is performed based on satellite data caching hints received from the satellite network. As previously mentioned, such hints may relate to content relevance or demand, satellite network usage or policies, geographic restrictions, etc.

[0171] In operation 2230, content flows are established between terrestrial and satellite networks (and cache locations within such networks) based on resource availability. Such resource considerations may relate to bandwidth, storage, or content availability, as indicated by hints or predictions.

[0172] At operation 2240, one or more geofencing restrictions are identified and applied for particular content. For example, content may be added, unlocked, restricted, evicted, or controlled according to geographic region based on the geographic locations of satellite networks, data producers, data consumers, and regulations and policies associated with such locations.

[0173] At operation 2250, caching locations of content may be coordinated between satellite edge data stores and terrestrial edge data stores. Such coordination may be based on geofencing restrictions and rules, content flow, policies, and other considerations previously discussed.

[0174] Further variations of this method and similar methods are provided by the following examples.

[0175] Example C1 is a method for content distribution in a satellite communications network, comprising: caching data at a satellite computing node, the satellite computing node being accessible via the satellite communications network; applying restrictions to access to the cached data at the satellite computing node according to a location of the satellite computing node, a location associated with a source of the data, and a location of a receiver; and receiving a request for the cached data from a terrestrial computing node based on availability of resources at the terrestrial computing node, the request for data being based on satisfying the restrictions on access to the cached data.

[0176] In Example C2, the subject matter of Example C1 optionally includes subject matter where the terrestrial computing node is configured to cache at least a portion of the data, and the method further includes managing a cache of data between the satellite computing node and the terrestrial computing node.

[0177] In Example C3, the subject matter of Example C2 optionally includes subject matter where caching of data between the satellite computing node and the terrestrial computing node is based on geographic restrictions in restricting access to the cached data.

[0178] In Example C4, the subject matter of any one or more of Examples C2 to C3 optionally includes subject matter in which caching of data between the satellite computing node and the terrestrial computing node is performed based on bandwidth availability at the terrestrial computing node.

[0179] In Example C5, the subject matter of any one or more of Examples C2 to C4 optionally includes subject matter in which caching of data between the satellite computing node and the terrestrial computing node is performed based on hints provided from the satellite computing node to the terrestrial computing node.

[0180] In Example C6, the subject matter of any one or more of Examples C2 through C4 optionally includes subject matter in which caching of data between the satellite computing node and the terrestrial computing node is performed based on bandwidth used by a virtual channel established between the terrestrial computing node and another terrestrial computing node using a satellite network connection.

[0181] In Example C7, the subject matter of any one or more of Examples C1 through C6 optionally includes subject matter whereby restrictions on access to the data are based on a security or data privacy policy determined for at least one tenant, at least one tenant group, or at least one service provider associated with the terrestrial computing node.

[0182] In Example C8, the subject matter of any one or more of Examples C1 through C7 optionally includes managing the cached data at the satellite computing node based on a policy implemented within a satellite constellation or satellite that includes the satellite computing node.

[0183] In Example C9, the subject matter of Example C8 optionally includes evicting the cached data from the satellite computing node based on at least one of a geographic rule, a data provider rule, or a satellite network policy.

[0184] In Example C10, the subject matter of any one or more of Examples C1 to C9 optionally includes subject matter in which restricting access to the data defines a geofence, the geofence enabling access to the data upon co-location of the satellite computing node and the terrestrial computing node within the geofence.

[0185] In Example C11, the subject matter of any one or more of Examples C1-C10 optionally includes subject matter performed by processing circuitry in the satellite computing node hosted within a satellite vehicle.

[0186] In example C12, the subject matter of example C11 optionally includes subject matter where the satellite vehicle is a low earth orbit (LEO) satellite operating as a member of a satellite constellation.

[0187] Satellite Roaming Architecture

[0188] As will be appreciated, many of the previous scenarios involve the use of multiple LEO satellites, which may result in inter-operator roaming as different satellite constellations move in orbit and come within range of a user's geolocation. Similar to how today's mobile users move between networks with their user equipment and roam to other service provider networks, it is anticipated that satellite constellations will move in and out of location, providing an opportunity for users to roam between different service provider networks. In the context of edge computing, such satellite constellation roaming adds an additional level of complexity as it requires coordination of not only network connectivity, but also workloads and content.

[0189] Figure 23 illustrates system coordination of satellite roaming activity between satellite providers for roaming between different types of geopolitical jurisdictions and service areas. Specifically, the system illustrates how a subscriber user 2320 who has a contract for connectivity and service with a primary provider C 2312 also accesses networks from providers A, B, and C using an inter-LEO roaming agreement 2330. In this configuration, inter-operator roaming can be coordinated in space where LEO satellites in the same space orbit coordinate load balance using roaming agreements 2330 and achieve other useful resiliency / availability objectives.

[0190] Roaming agreements may follow patterns currently used where carriers in adjacent regions agree (through legal contracts) to route traffic to the peer carrier if a peer network is detected. SLAs for users 2320 reflect contractual arrangements made in advance. This may include alternative fees for similar services provided by peer carriers. In addition to traditional roaming agreement approaches, LEO satellite roaming may include various forms of load balancing, redundancy and resiliency strategies. Satellites of different carriers may have different host functions or optimizations, such as one for computing, one for storage, one for functional acceleration (FaaS), etc. Roaming agreements may detail these differences and the fees charged when used in a roaming configuration. The overall value to the user is the latency between nearby LEO satellites in space, which means the majority of the workload can be completed in space, avoiding round trips to edge hosting nodes on the ground.

[0191] In one example, roaming agreements are established to authorize cross-jurisdictional sharing of edge resources. This is provided through the use of a User Edge Context (UEC) data structure 2340. The UEC 2340 is associated with several contextual information that aids in establishing effective satellite access via roaming agreements that are physically co-located in space and may be over the airspace of any number of countries. Such locations of satellites may be determined based on space orbital coordinates, such as coordinate A 2350A and coordinate B 2350B.

[0192] Spatial coordinates are determined by three factors: (1) orbital trajectory, (2) altitude above sea level, and (3) speed. In general, these three are interrelated. Altitude determines the speed required to maintain altitude. Trajectory and speed determine possible points where collisions can occur. Carriers working to establish roaming agreements are expected to choose spatial coordinates that have the same factors and adjust them slightly to create buffers between them.

[0193] In a further example, autonomous inter-satellite navigation techniques can be used to detect roaming peers, if any, near or within a buffer where refinements to programmed spatial coordinates are dynamically and autonomously applied, so that inter-satellite roaming activity 2350A can also be tracked and evaluated using this framework.

[0194] In a further example, the UEC may be configured to capture premium use cases that follow certain SLA considerations, such as use in Ultra Reliable Low Latency Communication (URLLC) SLA. For example, the SLA part of the UEC may be adapted to understand priority factors to define the priority of available networks. If a UE (device) has line-of-sight connectivity and is allowed access to multiple terrestrial and non-terrestrial networks, a set of pre-configured factors helps the UE prioritize which network to select. For example, the terrestrial telecommunications network where the UE is located may be prioritized first, followed by licensed satellite network options. Some satellite subscribers may pay for premium services, whereas other users may have standard data rate plans connected to their UE. The UE SIM card has this priority information and coordinates with the UEC on SLA priorities. Similar examples may include premium users who want the best possible latency and pay for this access in the UE SIM connected to their UEC SLA.

[0195] 24 shows additional information about UEC data structures for coordinating satellite roaming activity, providing additional detail of the UEC 2340 described above. The following data fields or properties are provided for illustrative purposes, and additional or alternative data fields may also be used.

[0196] The UEC 2340 is depicted as storing information related to user context for edge computing, including user credentials 2431, orchestrator information 2432, SLA information 2433, service level objective (SLO) information 2434, workload information 2435, and user data pool information 2436. In one example, the SLA is related to roaming agreement information 2437, LEO access information 2438, LEO charging information 2439.

[0197] In further examples, roaming agreement information 2437 may also include or relate to user citizenship context 2441, trade agreement or treaty information 2442, political geofencing policy information 2443, and taxation information (e.g., related to value-added tax (VAT) or customs duties) 2444. Through implementation of UEC 2340, geofencing is logically applied to allow for the application of existing treaties and geopolitical policies.

[0198] The UEC is a data structure 2340 that exists independently of any currently executing workload. However, there is a binding phase 2420 that relies on the UEC 2340 to allocate or assign resources in preparation for the execution of a particular workload.

[0199] For example, consider a scenario where the associated SLA 2433 includes context regarding tax obligations of a given provider network. Roaming agreements provide additional context where international treaties or conventions may include VAT. UEC 2340 includes references to applicable geofencing and VAT context so that roaming agreements between LEO satellites from different provider networks can cooperate to provide a better (more available) user experience.

[0200] In a further example, UEC can add value within a single provider network, where the UEC 2340 can provide additional context for applying geofencing policies associated with country of origin, citizenship, trade agreements, tax rates, etc. The single provider network can provide workload statistics related to various aspects of workload execution to identify possible optimizations of compute, data, power, latency, etc. The provider can change the spatial coordinates of other LEO satellites in its network to rendezvous with peer satellites to better balance loads, improve availability and resiliency, or increase capacity.

[0201] In a further example, the SLA 2433 data of the UEC 2340 may be used to figure out the priority factors. For example, in a scenario where the UE (device) has line of sight and is allowed access to multiple terrestrial and non-terrestrial networks, the pre-determined factors may help the UE prioritize which network to select. The terrestrial telecommunications network where the UE is located may have first priority, and the licensed satellite network option may be second. Some of the satellite subscribers may pay for premium services, whereas others may only have standard data rate plans connected to their UE. The UE SIM card may provide this priority and collaborate with the UEC 2340 on the SLA priority. In such an example, the user context may be stored in the SIM rather than stored in a central database, and the edge node / orchestrator may directly access the SIM rather than opening a channel to a back-end repository to handle the workload.

[0202] As mentioned above, as another example, a premium user may want as little latency as possible over a satellite network, similar to or better than terrestrial fiber. The user pays for this access and indicates it in the UE SIM card connected to the UEC SLA. Since the expected speeds in space may be faster than some terrestrial networks and even fiber optic networks, the use of the UEC 2440 may provide the fastest low latency connection for point-to-point (e.g., when a data connection is established to a location on the other side of the Earth). For these and other scenarios, the SLA 2433 may be adapted to include a desired ranking of available networks.

[0203] 25 illustrates a flowchart 2500 of a method for using user edge context to coordinate satellite roaming activity, the operations of which may be performed by operations at end user devices, satellite constellations, service providers, and network orchestrators, consistent with the examples above.

[0204] In operation 2510, a user edge context is accessed (or newly defined) for use in a satellite communications network configuration. This user edge context may include the data features and properties described with reference to Figures 23 and 24. In operation 2520, this user edge context is communicated to a first service provider of the satellite network (e.g., a satellite constellation) so that an end user device can perform network operations consistent with the accessed or defined context.

[0205] In operation 2530, a roaming scenario is detected and identified, and information of service providers available for roaming is further identified. In one example, the roaming scenario is when a first satellite constellation moves out of range of a geographic region that includes the end user device and a second satellite constellation moves into range of the end user device. Roaming can also occur due to other scenarios, including service interruption, access to specific or premium services, preferences or SLA considerations.

[0206] At operation 2540, a second service provider (e.g., another satellite constellation) is selected for continuing satellite network operation in a roaming configuration based on the information of the user edge context. At operation 2550, the user edge context is communicated to the second service provider, and network operation is initiated or continued according to the information of the user edge context.

[0207] Internet of Things Drone-Satellite Communication Architecture

[0208] In certain use cases, end users may be interested in using devices to monitor remote locations for environmental changes or connecting to such devices to deploy status updates or software patches. The use of satellite connectivity allows for steadily improving the use of IoT devices and endpoints deployed in such remote settings.

[0209] FIG. 26 illustrates an exemplary use of satellite communications in an Internet of Things (IoT) environment. The figure shows an oil pipeline 2600 that stretches over long distances in a remote environment. The pipeline 2600 is equipped with several sensors (sensors S0-S5) to monitor its health. These can be physical sensors attached to the pipeline, cameras monitoring the environment, or a combination of sensor technologies. Often, these sensors are placed frequently on the pipeline. In addition, every few miles, an operator may decide to deploy more sophisticated monitoring stations. The sensors on the pipeline do not have a dedicated network connection, but constantly sample data. The sensors (or monitoring stations) can cache the data locally and also perform analytics that can predict when maintenance is needed.

[0210] FIG. 26 further illustrates the deployment of sensors S0-S5. In this setup, there is a 5G / 4G wireless access network 2610 where intelligence and analytics are performed on the sensor data using edge computing. Here, the data collected by the sensors is input into analytics that can detect and predict faults. For example, an algorithm to detect a pipeline fault can look at sensor data showing the flow of oil in the pipeline. However, in addition to the flow rate, other factors such as weather conditions are also important in predicting faults. Extreme weather conditions monitored in the past and predicted in the future can play an essential role in determining when the next maintenance is required.

[0211] In one example, a drone 2620, balloon 2625, or other unmanned aerial vehicle (UAV) can carry data obtained directly from a satellite 2630 (or satellite radio access network 2630 via radio access network 2610), such as a map with sensor locations highlighted. The drone 2620 or balloon 2625 can travel to collect data from sensors and retransmit it to the radio access network 2610 for processing. The satellite radio access network 2630 can also relay the information to other locations not shown.

[0212] In an example exemplary pipeline monitoring scenario, the data may include any or all of the following:

[0213] (a) Previous data collected by the sensor or other relevant sensors;

[0214] (b) Weather forecast data or data essential for analysis

[0215] (c) Updating algorithms as needed (e.g., allowing updates to algorithms capable of generating local predictions)

[0216] (d) Software updates, including security patches

[0217] (e) Data from other sensors collected by the drone along the way that may be relevant to the edge node.

[0218] Each sensor may be coupled to a local edge node (eg, located in the wireless access network 2610 (not shown)) that has the following roles:

[0219] (a) Collect data from a sensor or a group of sensors and cache it locally.

[0220] (b) performing analysis of data collected from the sensors to determine the health of the pipeline and future maintenance;

[0221] (c) Transmitting the analysis results to other sensors within its vicinity / connection range.

[0222] (d) Modifying our proprietary software from model updates to security patches.

[0223] Operators can use satellite communications to the radio access network 2610 to distribute software, collect data, and monitor insights generated at the edge. Additionally, further processing systems (e.g., in the cloud connected via backhaul to satellite 2630) can also predict when sensors will be out of range and dispatch drones with detailed mapping to optimize routes accordingly, delivering data (e.g., weather forecasts), software updates (e.g., model updates, security patches, etc.). Such information can be integrated with Information Centric Networking (ICN) or Named Data Networking (NDN) approaches as described further below.

[0224] The route used by the drone 2620 or balloon 2625 can be optimized to collect data from out-of-range sensors that have data essential to generate insights. For example, S2 is out of range of S0, but the data collected by S2 is a requirement of S0 to predict maintenance schedules. The drone 2620 then selects a route that allows it to communicate with S2 and collect data from its nodes and sensors. The drone then proceeds to S1 to provide the data collected from S2 and additional deliveries intended for S0. Each edge node (e.g., edge nodes of sensors S0-S4) obtains a dedicated storage reservation on the drone that is protected by policies and keys for authentication to determine which other edge nodes are allowed access for read / write.

[0225] For this use case, the analytics performed on the mobile node (e.g., a UAV such as a drone 2620 or balloon 2625) may focus on route selection and mapping, collecting and transmitting data. However, this mobile node may not have sufficient computational power to perform its own predictions and analytics. In this scenario, the UAV holds the algorithms to be run, collects data from edge nodes / sensors, executes the algorithms, generates insights, and transmits them to the cloud (e.g., via satellite 2630) where actions can be recommended and taken.

[0226] Or, in another example, the UAV may collect data for processing at an edge computing node located in the wireless access network 2610. For example, the UAV may use EPVC channels depending on the importance of the data, and may use ICN or NDN techniques in case the UAV does not know who can process the data. Other combinations of mobile, satellite, and edge computing resources may be distributed and coordinated based on the techniques described herein.

[0227] In a further example, rather than relying on state maintenance technology, the following predictive maintenance approaches can be coordinated through the collection of device and sensor data via satellite connectivity, so that despite the remote deployment of sensors, satellite connectivity (either direct or via a drone or access network) can be used to provide data to a predictive data analytics service, which can schedule service actions in advance.

[0228] The combination of satellite communication coordination and continuous data collection supports a new level of importance for real world things to be monitored on the ground. The collection of data may be coordinated by data aggregation devices, gateways, base stations or access points. Similarly, the type of satellite network may include one or more satellite constellations (and possibly one or more cloud service providers, services or platforms accessed via such constellations).

[0229] Also, in a further example, importance may be identified via the IoT monitoring data architecture. For example, important monitoring data values ​​may be identified and some action or further processing may need to occur. This importance may be correlated to the location or availability of the satellite network or constellation and what type of network access is available. Similarly, if some important action needs to be taken (e.g., communication of important data values), these actions may be prioritized for the next period when the relevant satellites are in coverage.

[0230] In further examples, UAVs and other related vehicles or mobile systems may also be linked in connection with predictive monitoring techniques. Because drones may provide connectivity in addition to computing capabilities, computer systems performing predictive analytics and predictive maintenance may be linked or operated on the drone. Similarly, the drones themselves may have direct satellite connectivity.

[0231] The connections between sensors, drones, base stations and satellites can be coordinated with multiple levels of processing and different forms of processing algorithms. For example, a sensor may identify that something is wrong, but may not have enough computing power or the correct algorithms to perform the next layer level of processing. The sensor may capture data using its own resources (such as a camera) and communicate this data to a central resource when the satellite can connect. All of these permutations of connections relate to the quality of service provided and managed within the satellite communication network. As a similar example, in response to a sensor malfunctioning, satellite communication may be used to deploy a new algorithm (so the new algorithm can tolerate the absence of a malfunctioning sensor, even if the new algorithm is not as highly accurate as the previous algorithm).

[0232] 27 illustrates a flowchart 2700 of a method for data collection and processing involving IoT and satellite network deployments, where a sequence of operations may be performed based on the type of computing operation, available network configurations, connectivity and latency considerations.

[0233] At operation 2710, operations are performed to collect, process, and disseminate data using edge computing hardware at an endpoint computing node (e.g., located at an IoT device). At operation 2720, operations are performed to collect, process, and disseminate data using edge computing hardware at a mobile computing node, e.g., with a drone deployed at an IoT device. At operation 2730, operations are performed to collect, process, and disseminate data using a terrestrial network and associated edge computing nodes in, e.g., 5GRAN, connected via a satellite backhaul.

[0234] At operation 2740, operations are performed to collect, process, and disseminate data using the satellite network and associated edge computing nodes, which may be either on the satellite or terrestrial edge computing nodes connected to the satellite link. At operation 2750, operations are performed to collect, process, and disseminate data using the wide area network and associated computing nodes (e.g., to a cloud computing system).

[0235] It will be appreciated that other hardware configurations and architectures may be used to achieve the operations described above. For example, some IoT devices (such as meter readers) operate on a best effort basis, whereas other IoT devices / sensors require reliable, low latency notification (e.g., humidity sensors on shipping containers monitored in real time to indicate theft). As such, other operations and processing may occur depending on the hardware and use case application.

[0236] Any of these operations may be coordinated using the EPVC channels and ICN / NDN network technologies described herein. In yet another aspect, the approach for IoT device computing may be coordinated over a satellite network connection using the following example implementation.

[0237] Example D1 is a method for collecting and processing sensor data using a satellite communications network, comprising: obtaining sensing data related to an observation condition from a sensor device, where the sensing data is provided to an intermediate entity using a terrestrial wireless communications network; having the intermediate entity transmit the sensing data to an edge computing location, where the sensing data is communicated to the edge computing location using a non-terrestrial satellite communications network; and obtaining a processing result of the sensing data from the edge computing location via the non-terrestrial satellite communications network.

[0238] In Example D2, the subject matter of Example D1 optionally includes subject matter in which the intermediate entity provides network connectivity to the sensor device via a terrestrial wireless communications network.

[0239] In example D3, the subject matter of example D2 optionally includes subject matter where the intermediate entity is a base station, an access point, or a network gateway, the intermediate entity providing a network function for operation of a terrestrial wireless communications network.

[0240] In example D4, the subject matter of any one or more of examples D2-D3 optionally includes subject matter in which the intermediate entity is a drone.

[0241] In Example D5, the subject matter of Example D4 optionally includes subject matter configured such that the drone is configured to provide network communications between a sensor device and an access point that accesses the satellite communications network.

[0242] In Example D6, the subject matter of any one or more of Examples D4-D5 optionally includes subject matter including communications circuitry for the drone to directly access and communicate with the satellite communications network.

[0243] In Example D7, the subject matter of any one or more of Examples D1-D6 optionally includes subject matter provided by a 4G Long Term Evolution (LTE) or 5G network, wherein the terrestrial wireless communications network operates according to 3GPP standards.

[0244] In Example D8, the subject matter of any one or more of Examples D1-D7 optionally includes subject matter where an edge computing location is identified for processing based on a delay in communication through the satellite communications network and a time required for processing at the edge computing location.

[0245] In example D9, the subject matter of any one or more of examples D1-D8 optionally includes the subject matter where the satellite communications network is a low Earth orbit (LEO) satellite communications network provided from a constellation of multiple LEO satellites.

[0246] In Example D10, the subject matter of Example D9 optionally includes subject matter where the edge computing location is provided using processing circuitry located on a LEO satellite vehicle of the constellation.

[0247] In Example D11, the subject matter of any one or more of Examples D9-D10 optionally includes subject matter where the edge computing locations are provided using respective processing circuitry located on a plurality of LEO satellite vehicles of the constellation.

[0248] In Example D12, the subject matter of any one or more of Examples D9-D11 optionally includes subject matter where the edge computing location is provided using processing services accessible via a LEO satellite communications network.

[0249] In Example D13, the subject matter of any one or more of Examples D1-D12 optionally includes subject matter in which processing the sensing data includes identifying anomalies in the data based on an operating condition of a system being monitored by the sensor device.

[0250] In Example D14, the subject matter of Example D13 optionally includes subject matter wherein the system is an industrial system and the monitored condition relates to at least one environmental or operating characteristic of the industrial system.

[0251] In Example D15, the subject matter of any one or more of Examples D13-D14 optionally includes transmitting a maintenance command for maintenance of the system in response to a result of processing the sensing data.

[0252] In Example D16, the subject matter of any one or more of Examples D1-D15 optionally includes subject matter in which the sensing data includes image data and results of processing the sensing data include non-image data generated at the edge computing location.

[0253] In Example D17, the subject matter of any one or more of Examples D1 to D16 optionally includes a subject matter in which the sensing data is obtained and cached from a sensor aggregation device, the sensor aggregation device being connected to a plurality of sensor devices including the sensor device.

[0254] In Example D18, the subject matter of Example D17 optionally includes subject matter where the sensed data is aggregated at the sensor aggregation device from raw data, the raw data being obtained from a plurality of sensor devices including the sensor device.

[0255] In Example D19, the subject matter of Example D18 optionally includes subject matter where the sensor aggregation device applies at least one algorithm to the raw data to generate the sensed data.

[0256] In Example D20, the subject matter of any one or more of Examples D1-D19 optionally includes subject matter where the method is performed by the intermediate entity.

[0257] Coordination and planning of data transfer over temporary satellite connections

[0258] One of the challenges of new generation moving satellite constellations is that the computational and data transfer capacity offered by such constellations depends on the geolocation they cover. Thus, end-to-end systems with many LEO satellites in orbit will always lack full connectivity and high bandwidth connections. As a result, two main types of data transfer and processing need to be coordinated a) between satellites forming a cluster / federation / constellation (to minimize the required data transfer and avoid data duplication, e.g. when summary information can be sent) and b) between a cluster of satellites and a ground station (to identify when and which satellite communicates what data) while considering the possibility of handover to another satellite or ground station.

[0259] In these scenarios, two different decisions can be considered for service continuity: (1) whether to perform some computations locally (which takes longer and uses scarce resources) or transfer the data to the ground and wait to "push" the computations while the satellite flies over the area, and (2) the optimal timing for transferring data from the satellite to the ground. Both decisions depend at least on the following aspects: the duration of connectivity coverage for a particular area, the expected uplinks and downlinks in that area, potential data or geographic constraints, and potential bandwidth dynamics depending on the connectivity provider.

[0260] In the following, we provide an adaptive smart mechanism that addresses the above points and provides a smart architecture to predict the actions to be taken. Furthermore, while individual satellite resources may have resource constraints (e.g., limited number of available GPUs, power budget, etc.), such resources can be weighed in creating an efficient overall plan. No current satellite connectivity approach fully considers the dynamic aspects of data transfer in geolocation coupled with robust quality of service. Furthermore, the tradeoff between imposition and local computation on moving satellites has not been thoroughly explored.

[0261] To address these aspects, it provides planning and coordination not only for data and connection management, resource allocation and management, but also in terms of processing sequencing. For example, consider the case where ground control and satellite processing systems generate a joint plan to determine a) where to look for data actions (e.g. cargo ship positioning), b) what processing to do (e.g. find number of cargo ships) and c) how much bandwidth / storage resources / processing is needed to send the data back (e.g. analyze imagery to find only number of cargo ships).

[0262] Figure 28 shows an example of an exemplary satellite communication scenario implementing a plan for temporarily connected devices, where plan 2801 defines a schedule of communication and processing actions between different satellites 2811, 2812, 2813. In this example scenario, the goal is to identify the capacity of each satellite 2811, 2812, 2813 orbit flying (at slightly different angles) observing a set of container ships in a port, process the images, and send back summary information (e.g. number of ships, whether any objects were identified, etc.). Each entity of the end-to-end system keeps track of the plan / schedule 2801 and its role in processing and data communication.

[0263] In one example, the plan / schedule 2801 can include what experiments or scenarios to perform (e.g., where to look based on the current orbit, which sensors (imagery, radar, etc.) to use), what data to process / store, what to forward to which other entities, etc. Plan boundary conditions can be shared between entities on a need-to-know basis. For example, satellites belonging to the same entity can share full plan details, anonymized descriptions can be shared with satellites or compute nodes from other service providers.

[0264] The use of plans and schedules supports the negotiation / sharing of constraints to obtain the most efficient and comprehensive plan (including in terms of resource usage, monetary cost, return on investment (ROI) or total cost of ownership (TCO)). As such, plans / schedules can be self-optimized or provided by entities such as ground stations / operators. Also, elements in the plan can have mixed importance, with some elements being immovable / non-negotiable and others being deployed on a best effort basis (e.g., "take action as much as possible"). It will be appreciated that negotiation between various system satellites, ground base stations, customers and other entities to develop plans and schedule the use of the plans provides a unique and robust approach that goes far beyond traditional techniques for planning. In particular, by considering multiple stakeholders, a comprehensive and optimal plan can be developed while sharing the minimum necessary information between systems and preserving privacy.

[0265] Example constraints of the plan / schedule 2801 related to satellite connectivity and operation may include:

[0266] a) Geolocation information to identify or limit which experiments and tasks are possible (or whether a task needs to wait until the next orbit).

[0267] b) Task Order

[0268] c) Hardware limitations (e.g. GPU limitations that mean it cannot handle two processing jobs simultaneously)

[0269] d) Limiting the number of tenants or different customers at the same time (e.g., for data privacy)

[0270] e) Deadline for data transfer

[0271] f) Connection conditions (cooperation between different types of LEO / GEO / terrestrial networks when up / downlink is not available)

[0272] g) Collaborative satellite or processing technology linkages (e.g. overlay radar (from GEO satellites) with thermal imagery (from LEO satellites)).

[0273] h) Resource limitations (e.g. power / storage / thermal / computational limitations)

[0274] i) Geofencing or geographic restriction

[0275] In a further example, a plan may be used to reserve computational or communication resources in the satellite in advance depending on anticipated usage, and such reservations may also depend on the costs charged by current reservations.

[0276] 29 illustrates a flowchart 2900 of a method for defining and planning satellite network computing operations in an on-orbit temporary satellite communications network deployment, where a sequence of operations may be performed based on the type of computing operation, available network configurations, connectivity and latency considerations.

[0277] At operation 2910, a plan and its plan constraints are defined (or obtained) to coordinate data transfer and processing among multiple entities. At operation 2920, a data experiment, action, or other scenario involving coordinated data transfer and processing is invoked. For example, this may be required to initiate some workload processing action.

[0278] At operation 2930, the data is transferred between entities of the satellite communications network based on the plan and the plan constraints. Similarly, at operation 2940, the data is processed at selected one or more entities using edge computing resources of the satellite communications network based on the plan and the plan constraints.

[0279] Flowchart 2900 concludes at operation 2950 by transmitting the data processing results between terrestrial entities or entities of the satellite communications network. Various aspects of handover, processing and data transfer coordination, and communication between satellites, constellations and terrestrial entities are not shown, but may also be involved in the operations of flowchart 2900.

[0280] In further aspects, the approach for scheduling and planning satellite network computing operations may be coordinated and executed using the following example implementations: Also, in further aspects, other aspects of resource expenditures not related to monetary considerations may be considered (such as battery life, memory, storage, processing resource constraints and usage, among others).

[0281] Example E1 is a method for coordinating computing operations in a satellite communications network, comprising: at a computing node of the satellite communications network, obtaining a coordination plan for performing computing and communications operations within the satellite communications network; performing a computing action on data within the satellite communications network based on the coordination plan, the computing action being to obtain a data processing result; performing a communications action on the data via the satellite communications network based on the coordination plan; and transmitting the data processing result from the satellite communications network to a terrestrial entity.

[0282] In example E2, the subject matter of example E1 is such that a collaborative plan for performing computing and communications operations includes a plurality of constraints, which optionally include subject matter relating to location information, task order, hardware restrictions, usage restrictions, usage deadlines, connection conditions, resource information, resource restrictions, or geographic restrictions.

[0283] In Example E3, the subject matter of any one or more of Examples E1-E2 optionally includes reserving computing resources at the computing nodes based on the federation plan.

[0284] In Example E4, the subject matter of any one or more of Examples E1-E3 optionally includes subject matter in which the coordinated plan for performing computing and communication operations within the satellite communications network causes the satellite communications network to reserve a plurality of computing resources within the satellite communications network for performing the computing actions using the data.

[0285] In Example E5, the subject matter of any one or more of Examples E1-E4 optionally includes subject matter where communicating the data includes communicating the data to a ground processing location and performing an action using the data includes obtaining the data processing results from the ground processing location.

[0286] In Example E6, the subject matter of any one or more of Examples E1-E5 optionally includes subject matter where communicating the data includes communicating the data to another node within the satellite communications network.

[0287] In example E7, the subject matter of any one or more of examples E1-E6 optionally includes determining when to perform the computing action based on the coordination plan.

[0288] In Example E8, the subject matter of Example E7 optionally includes subject matter where the timing of performing the computing actions is based on processing coordination among multiple satellite nodes in a constellation of the satellite communications network.

[0289] In Example E9, the subject matter of any one or more of Examples E1-E8 optionally includes determining a timing for transferring the data processing results from the satellite communications network to the terrestrial entity based on the coordination plan.

[0290] In Example E10, the subject matter of Example E9 optionally includes subject matter where the timing of transferring the data processing results is based on processing coordination among multiple satellite nodes in a constellation of the satellite communications network.

[0291] In example E11, the subject matter of any one or more of examples E1-E10 optionally includes subject matter where the timing of performing computing actions and the timing of transferring the data processing results are based on the orbital positions of one or more satellite vehicles of the satellite communications network.

[0292] In Example E12, the subject matter of any one or more of Examples E1-E11 optionally includes subject matter in which the coordination plan causes the satellite communications network to hand over processing of data from a first computing node accessible within the satellite communications network to a second computing node.

[0293] In example E13, the subject matter of any one or more of examples E1-E12 optionally includes subject matter where a computing action on the data is performed based on resource availability within the satellite communications network or a network connected to the satellite communications network.

[0294] In example E14, the subject matter of any one or more of examples E1-E13 optionally includes subject matter where the communication action is based on connection availability within the satellite communications network or a network connected to the satellite communications network.

[0295] In Example E15, the subject matter of any one or more of Examples E1-E14 optionally includes subject matter where the terrestrial entity is a client device, a terrestrial edge computing node, a terrestrial cloud computing node, another computing node of a constellation within the satellite communications network, or a computing node of another satellite constellation.

[0296] Orchestration of satellite and edge services based on data cost

[0297] The new Digital Services Tax (DST) proposed and implemented by the Organization for Economic Cooperation and Development (OECD) and the European Commission is defined as a tax on services that use data generated from user activity on digital platforms in a particular country and are subsequently used in other countries. For example, such a tax could be applied to data collected from users of a service in Italy (e.g. user engagement data) that helps to provide better recommendations (e.g. for video or music recommendations) to users with a similar profile in another country. This leads to an obvious problem in the context of satellite connectivity networks: each country has its own tax rate, so from an economic point of view it is important to be able to choose the one that best suits the services offered by satellite infrastructure, which has a larger geographical coverage than traditional static infrastructure.

[0298] Similarly, edge computing must increasingly address both the mobility of data creators and data consumers while also allowing for caching, securing, filtering, on-the-fly transformation of data, and dynamic refactoring of mobile producer resources and services. This is especially true for content and services hosted / cached on satellites in both LEO / NEO and GEO orbits. Thus, by using the techniques described below, data costs can be used as an additional variable while accelerating services over satellite connections.

[0299] For example, based on resource usage relative to monetary cost and considering that satellites are constantly moving through multiple geographic locations, a service scheme may be defined as using services with low taxes or service fees for each specific location. Services using a specific user data set are labeled with their location and cost to determine the optimal or most effective option when there are multiple services offering the same service. Thus, data consumers, users and service providers may evaluate tradeoffs between cost, service quality, etc. while complying with data taxation or other cost requirements.

[0300] In one example, new components are added to LEO satellites and ground stations (e.g., base stations) to implement a new kind of geo-aware orchestration policy. This includes configuring the system to include location and data cost as new tags as part of the metadata of the services to identify economically advantageous services running on LEO satellites, taking into account their geographic location. For example, a system orchestrator running on a ground station may use this configuration to select the best service, taking into account financial cost as a primary factor, but also factors required for satellite orchestration (e.g., telemetry, SLA, transmission time, visibility time, processing time). If a cheaper (e.g., lower tax) service is expected to be available on the next satellite (soon to be in range, e.g., in 5 minutes), and this next cheaper service meets the SLA, the orchestrator will wait to use the next satellite.

[0301] A simple example of a cost-selected service is a CDN service that provides data from a specific geographic origin associated with known data costs and tax rates. Other types of data workload processing services, cloud services and interactive data exchanges between data consumers and data providers can occur. This is illustrated in the exemplary satellite communication scenario of Figure 30, which involves a ground station GS1 3020 selecting and accessing one of the satellites L1 3011, L2 3012, L3 3013 for network connectivity, data content or data processing purposes.

[0302] In an example scenario, assume that GS1 3020 located in France requires the use of services A and B and has 5 minutes to realize the use of the services (to meet the SLA). The orchestrator (at the ground station or the controlling entity of the ground station) evaluates the satellites that are in range during the maximum availability time (5 minutes) as shown in the evaluation table 3030. In this situation, satellites L1 3011 and L2 3012 are the only satellites that are in range for the next 5 minutes and can also meet the service requirements.

[0303] Next, the following services and options are evaluated, taking into account costs:

[0304] Option 1: L1 Service A + L1 Service B: $20; Time: ~2 seconds

[0305] Option 2: L1 Service A + L2 Service B: $15; Time: ~3 minutes 49 seconds

[0306] Option 3: L2 Service A + L1 Service B: $30; Time: ~3 minutes 49 seconds

[0307] Option 4: L2 Service A + L2 Service B: $25; Time: ~3 minutes 49 seconds

[0308] From this evaluation, connectivity via Option 2 (L1 Service A and L2 Service B) was selected, providing the lowest cost across multiple satellites and services. (Note: in many cases taxes are levied on gross revenues, but for simplicity purposes in the table above they are expressed as per transaction amounts).

[0309] Catalog services operating at the satellite edge include new APIs to receive updates on the metadata of the service. Inter-satellite links may be used for such updates, as satellites advertise updates (deltas) so that ground stations can get this information before the satellites are in range. In addition, if allowed by SLAs, it may be possible to transfer or hand off processing actions to specific locations of ground stations, such as base stations, that have higher computing power and lower costs. Access to and results from such ground stations may be carried by any available LEO satellite passing over them.

[0310] FIG. 31 illustrates the framework of FIG. 16 extended for use in the presently disclosed cost evaluation. In one example, the terrestrial edge component 1610 is extended to include a service orchestrator 3111, a service planning component 3112, and a secure enclave 3121 element. In the service orchestrator 3111, each ground station 1610 continuously receives information from the satellites (e.g., service information maintained in a service catalog 3131, service usage information maintained in a service usage metrics data store 3132) necessary to orchestrate services and make decisions to identify optimal resource costs (e.g., monetary costs) to access the services. The service orchestrator 3111 may temporarily enable, disable, or adjust the usage of services depending on location and available capacity. The service planning component 3112 provides a helper module that generates the API gateway configurations necessary to provide a mapping of services per location (e.g., based on orchestrator analysis).

[0311] The secure enclave 3121 is configured to protect sensitive or private financial information. In one example, the secure enclave 3121 may not be managed by the software stack, but is only managed or accessed by authorized personnel.

[0312] In one example, the satellite edge component 1620 includes an API gateway 3124 that manages the execution of workloads 3125 and provides location-based service abstraction. The gateway receives location as an argument and returns a result of the service with reduced resource costs (e.g., monetary cost). This is done based on configurations provided by a service planning component 3112 that is called from the edge device. This module may be covered by a local API cache 3126. The satellite edge component 1620 also includes inter-satellite data sharing 3121 that is used to keep the service catalog 3122 up to date (such as via sending data delta changes) on each satellite and populate service usage metrics 3123.

[0313] 32 illustrates a flowchart 3200 of a method for performing computational operations in a satellite network deployment based on cost, where a series of operations may be coordinated with an in-orbit satellite based on considerations of the type of edge computing operation, the total end-to-end service cost, service usage restrictions or constraints, and service level objectives.

[0314] In operation 3210, various aspects of service demand and service usage are identified in relation to potential demand and use of satellite communications networks (e.g., by terrestrial user equipment devices). From such service demand and service usage conditions, operation 3220 includes identifying the availability of one or more satellite networks to provide services that satisfy the service usage conditions.

[0315] At operation 3230, costs associated with available services from available satellite networks are identified. As discussed above, this may include a breakdown of such costs based on geographic jurisdiction, time, service provider, service action to be taken, etc. At operation 3240, this information is used to calculate the cost to satisfy the service demand.

[0316] At operation 3250, one or more services are selected for use from one or more satellite networks based on the calculated costs and consideration of various constraints and conditions. Additional steps not shown for simplicity may include service orchestration, consideration of service usage metrics, invocation of service catalogs and APIs, etc.

[0317] In a further aspect, the following example implementations can be used to coordinate an approach for IoT device computing over a satellite network connection.

[0318] Example F1 is a method of coordinating computing operations in a satellite communications network based on resource expenditures, comprising: identifying a demand for a computing service; identifying conditions of use for the computing service that satisfy the demand; identifying a plurality of available computing services accessible via the satellite communications network, where the available computing services are identified to satisfy the conditions of use; calculating a resource expenditure for use of each of the available computing services; selecting one of the plurality of available computing services based on the resource expenditures; and performing a data operation with the selected computing service via the satellite communications network.

[0319] In Example F2, the subject matter of Example F1 optionally includes selecting a second computing service from the plurality of available computing services based on resource expenditures, and performing a data operation on the selected second computing service via the satellite communications network.

[0320] In example F3, the subject matter of any one or more of examples F1-F2 optionally includes subject matter relating to conditions under which the computational services are used that are required by a service level agreement.

[0321] In example F4, the subject matter of any one or more of examples F1-F3 optionally includes a subject matter where a condition of use of the computational service provides a maximum time of use of the computational service.

[0322] In example F5, the subject matter of example F4 optionally includes subject matter where the available computing services are identified based on satellite coverage at a geographic location within a maximum time period of use of the computing services.

[0323] In example F6, the subject matter of any one or more of examples F1-F3 optionally includes receiving information identifying the plurality of available computing services and identifying at least a portion of a resource expenditure for use of each of the services.

[0324] In example F7, the subject matter of any one or more of examples F1-F3 optionally includes subject matter where the plurality of available computing services are provided among a plurality of satellites.

[0325] In example F8, the subject matter of example F7 optionally includes subject matter operated among a plurality of satellite constellations, the plurality of satellites being provided among a plurality of satellite communications service providers.

[0326] In Example F9, the subject matter of any one or more of Examples F1-F8 optionally includes mapping the available computing services to respective geographic jurisdictions, wherein the resource expenditures are associated with monetary costs, the monetary costs being based on the respective geographic jurisdictions.

[0327] In Example F10, the subject matter of any one or more of Examples F1-F9 optionally includes subject matter in which the monetary cost is calculated based on at least one digital services tax associated with a geographic jurisdiction.

[0328] In example F11, the subject matter of any one or more of examples F1-F10 optionally includes a subject matter in which the computational services are content data network (CDN) services provided via the satellite communications network, and the resource expenditures are based on data obtained via the CDN services.

[0329] In example F12, the subject matter of any one or more of examples F1-F11 optionally includes the method being performed by an orchestrator, a base station, or a user device connected to a central satellite communications network.

[0330] Overview of Information-Centric Networking (ICN) and Named Data Networking (NDN)

[0331] FIG. 33 illustrates an exemplary ICN configuration according to one example. A network implemented in an ICN operates differently than a traditional host-based (e.g., address-based) communication network. ICN is a general term for a networking paradigm in which information and functions are named and requested from the network itself instead of the host (e.g., the machine that provides the information). In a host-based networking paradigm, such as that used in the Internet Protocol (IP), a device finds a host and requests content from the host. The network knows how to route (e.g., direct) the packet based on the address specified in the packet. In contrast, ICN does not include a request to a specific machine and does not use addresses. Instead, to obtain content, a device 3305 (e.g., a subscriber) requests named content from the network itself. The content request is called an interest and may be sent via an interest packet 3330. As the interest packet passes through network devices (e.g., network elements, routers, switches, hubs, etc.), such as network elements 3310, 3315, and 3320, a record of the interest is maintained, for example, in a pending interest table (PIT) of each network element. Thus, network element 3310 maintains an entry for interest packet 3330 in its PIT 3335, network element 3315 maintains an entry in its PIT, and network element 3320 maintains an entry in its PIT.

[0332] When a device, such as a publisher 3340, is found that has content matching the name in the interest packet 3330, that device 3340 may send a data packet 3345 in response to the interest packet 3330. Typically, the data packet 3345 is tracked back through the network to the source (e.g., device 3305) by following the trace of the interest packet 3330 left in the network element PIT. Thus, the PIT 3335 of each network element establishes a trail back to the subscriber 3305 for the data packet 3345 to follow.

[0333] When matching named data in an ICN implementation, several strategies may be followed. Generally, data is named hierarchically, for example using Universal Resource Identifiers (URIs). For example, a video may be named www.somedomain.com or videos or v8675309. Here, the hierarchy may be considered as publisher "www.somedomain.com," subcategory "videos" and canonical identity "v8675309." When an interest 3330 traverses an ICN, an ICN network element generally tries to maximally match the name. So, if an ICN element has cached items or routes for both "www.somedomain.com or videos" and "www.somedomain.com or videos or v8675309," the ICN element will match an interest packet 3330 specifying "www.somedomain.com or videos or v8675309" with the latter. In one example, an expression may be used in matching by an ICN device. For example, an interest packet may specify "www.somedomain.com or video or v8675*" (where "*" is a wildcard), so a cached item or route containing data other than the wildcard will be matched.

[0334] Item matching involves matching the Interest 3330 with data cached in an ICN element. So, for example, if the data 3345 named in the Interest 3330 is cached in the network element 3315, the network element 3315 returns the data 3345 to the subscriber device 3305 via the network element 3310. However, if the data 3345 is not cached in the network element 3315, the network element 3315 routes the Interest 3330 (e.g., to the network element 3320). To facilitate routing, the network element uses a forwarding information base 3325 (FIB) to match the named data to an interface (e.g., a physical port) for routing. So, the FIB 3325 operates like a routing table on a traditional network device.

[0335] In one example, additional metadata is attached to the interest packet 3330, cached data, or route (e.g., in the FIB 3325) to provide additional levels of matching. For example, not only is the data name specified as "www.somedomain.com or video or v8675309," but also includes a version number, or timestamp, time range, guarantee, etc. In this example, the interest packet 3330 identifies the desired name, version number, or version range. Matching may then search for routes or cached data that match the name, and perform additional comparisons of metadata, etc. to arrive at a final decision as to whether the data or route matches the interest packet 3330, for either responding to the interest packet 3330 with a data packet 3345 or forwarding the interest packet 3330, respectively.

[0336] In a further example, metadata in the ICN may indicate service terms or quality of service features, as employed by the considerations of service with the satellite communications network described herein. For example, such metadata may indicate the geolocation where the content was generated, whether the content is mapped to an exclusion zone, whether the content is valid at the current or specific geolocation. Using this metadata, various properties may be mapped to the geographic exclusions and quality of service of the satellite communications network, such as using the techniques described herein. Also, depending on the QoS required in the PIT, the ICN network may select a particular satellite communications provider (or select another provider entirely).

[0337] ICN has an advantage over host-based networking because data segments are individually named, which allows for aggressive caching throughout the network, since a network element may provide a data packet 3330 in response to an Interest 3330 just as easily as the original creator 3340. Thus, the same segment of the network is less likely to send duplicate transmissions of the same data requested by different devices.

[0338] Fine-grained encryption is another feature of many ICN networks. A typical data packet 3345 contains the name of the data that matches the name in the interest packet 3330. The data packet 3345 also contains the requested data and may contain additional information (e.g., creation time, expiration date, version, etc.) to filter data with similar names. To deal with malicious entities providing false information with the same name, the data packet 3345 may encrypt its contents with a publisher key or provide a cryptographic hash of the data and name. Thus, by knowing the key (e.g., from the expected publisher's 3340 certificate), the recipient can verify whether the data is from that publisher 3340. This technique also encourages aggressive caching of data packets 3345 throughout the network, since each data packet 3345 is self-contained and secure. In contrast, many host-based networks encrypt the connection between two hosts to secure the communication. This increases the delay while the connection is established and discourages data caching by hiding the data from network elements.

[0339] In a further example, different ICN domains may be separated such that different domains are mapped to different types of tenants, service providers, or other entities. Such separation of domains may enable forms of software-defined networks (e.g., SD-WANs) using ICNs, including satellite communication environments as described herein. Additionally, the ICN topology, including which nodes are exposed from a particular service provider, tenant, etc., may be altered based on geolocation, which is particularly relevant in satellite communication environments.

[0340] Exemplary ICN networks include the Content-Centric Network (CCN) defined in the Internet Engineering Task Force (IETF) draft specifications for CCNx0.x and CCN1.x, and the Named Data Network (NDN) defined in NDN technical report DND-0001.

[0341] NDN is a feature of ICN that brings new opportunities to provide better user experience in scenarios that are challenging for current IP-based architectures. Instead of relying on host-based connections, like ICN, NDN uses Interest packets to directly request specific data (including the function to be performed on that particular data). Nodes that have the data send it back in response to the Interest packet.

[0342] Figure 34 shows the configuration of an ICN network node implementing the NDN technology. NDN is an ICN implementation that provides name-based routing and provides a design and reference implementation that enables a pull-based content search and propagation mechanism. Each node or device in the network that consumes data (e.g., content, the result of a computation or function) or some function to be performed sends an interest packet to a neighboring node that is connected through a physical interface (e.g., a face), which may be wired or wireless. A neighboring node that receives a data request (e.g., an interest packet) experiences the sequence shown in Figure 34 (top), where the node first searches its local content store 3405 (e.g., a cache) for a match with the name in the interest packet. If successful, the content is returned to the requesting node. If a neighboring node does not have the requested content in its content store 3405, it adds an entry to its Pending Interest Table (PIT) 3410 that includes the name from the interest packet and the face that received the interest packet, and waits for the content to arrive. In one example, if an entry for the face and name already exists in the PIT 3410, the new entry may overwrite the current entry or the current entry is used and no new entry is created.

[0343] When a PIT entry is created, a lookup occurs in the Forwarding Information Base (FIB) table 3415 to obtain information about the next hop (e.g., a neighboring node face) to forward the Interest packet. If no FIB entry is found, the request is sent to all available faces except the one that received the Interest packet, or the request is dropped and a route NACK (negative acknowledgement) message is returned to the requester. On the other hand, if a neighboring node has an entry for the requested information in its FIB table 3415, it forwards the Interest packet further out of the network (e.g., to another NDN processing node 3420) and creates an entry in its Pending Interest Table (PIT).

[0344] When a data packet arrives in response to an Interest, the node sends the information back to the subscriber (via an entry in the PIT 3425) following the Interest Path (while caching the data in the Content Store 3430) as shown in the bottom part of Figure 34. Typically, a PIT entry is updated in the PIT 3425 after the data packet has been forwarded. Will be removed from 3425.

[0345] FIG. 35 illustrates an example deployment of ICN (e.g., NDN or NFN) technology between satellite access nodes, where an endpoint node 3505 uses a radio access network 3510 to request data or functionality from an ICN. The ICN data request is first processed at a base station edge node 3515, which checks the content store of the base station edge node 3515 to determine whether the requested data is available locally. If the data is not available locally, the data request is recorded in a PIT 3514 and propagated through the network to the satellite communications network according to the FIB 3512, such as via an uplink 3525A, to check a data source 3530 (e.g., a content store of the satellite 3502) at the satellite 3502. In the scenario illustrated in FIG. 35, the data 3540 is further available at node 3540 (or at a further data node in the network, such as a terrestrial location 3550) in the satellite network. The NDN operates to transmit data 3542 using the downlink 3525B from the satellite 3501 back to the base station edge node 3515 and then back to the endpoint node 3505. The NDN can identify and apply properties of the satellite communications network using domains, metadata and other features communicated via the NDN.

[0346] Satellite Handover for Computational Workload Processing

[0347] As mentioned above, with many satellites orbiting the Earth and many nodes on the ground connected to the satellite constellations, various connectivity use cases are possible. Some LEO satellites are expected to provide computational and data services to the ground nodes in addition to pure connectivity, with the added challenge that the LEO satellites are intermittently visible to the ground nodes. In such a scenario, if a satellite loses visibility to the ground node in the middle of providing a service, the service will be interrupted and intermediate results computed by the first satellite may be lost. This interruption can be mitigated or eliminated with the handover techniques described below to coordinate data transfer and operations.

[0348] FIG. 36 illustrates a satellite connectivity scenario enhanced by the use of ICN data handover. In this scenario, a number of devices 3630 (e.g., IoT devices) are connected via a wireless network to a base station 3620 having an edge appliance 3622 for computation or data processing. The devices 3630 request performance of some edge computing function for a data workload that cannot be processed locally at the appliance 3622 (e.g., the appliance 3622 has limited resources, the processing model is not available, etc.). In response, the base station 3620 coordinates communication with a satellite 3602 of the LEO satellite communications network and uses connection 3611A to request processing of the workload further down the network (e.g., at the satellite 3602, at the ground station 3650, at the data center 3660). However, in this scenario, due to the ephemeral nature of the orbiting LEO satellites, the satellite 3602 is unable to fulfill the data request before moving out of range.

[0349] As further illustration of such a scenario, consider a use case where satellite 3602 loses coverage for a communicating terrestrial node 3622 while transmitting data to the terrestrial node 3622 or performing a computational service. At some point, a new satellite 3601 comes into view of the terrestrial node 3622. However, the new satellite 3601 may not have the data required by the terrestrial node 3622. Also, in the case of a computational service, all the state and partial computations that the old satellite has are not present in the new system.

[0350] Estimating when a satellite is in or out of coverage and coordinating such coverage requests among different satellites requires significant overhead. Therefore, we propose a scheme below that allows a new satellite coming into view to pick up where the old satellite left off with minimal overhead.

[0351] In what follows, a name-based scheme is used, similar to other ICN activities, where a user (e.g., a client) requests a computation based on the name of a function (e.g., a software function) and the data that needs to be processed. In some implementations, this may be referred to as Named Function Networking (NFN) or Named Data Networking (NDN). Because the requests are name-based, the name is not associated with a particular node or location. In this case, when a first satellite moves and a second satellite comes into range, the computation request is simply forwarded to the second satellite. However, rather than recomputing all the data, when a LEO satellite receives the first computation request from the new location, it requests a data migration (e.g., a "core dump" or container migration) of all relevant computation information from the old satellite.

[0352] The following provides a simple and scalable solution for performing computational services on satellites. The handover technique does not require the overhead of anticipating loss of coverage. Rather, the system is triggered upon receipt of the first computational interest packet. The following also provides the development of a new type of interest packet that requests all material related to the computational service. This is not done by default, since if a new satellite does not receive a computational request, it does not request previous computational information. Additional security and other constraints can also be linked to which satellites can obtain previous computational information and perform computations.

[0353] 37 illustrates an example connection flow for handoff between a user computing device 3702, a terrestrial node 3704, and LEOs 3706, 3708 in a satellite data processing scenario. Although not shown, this connection flow can be extended for retrieval or processing of data at other locations in the network, such as terrestrial locations accessible via the satellite communications network.

[0354] In the flow of Figure 37, a user provides an initial computational service request (e.g., an interest packet) for a computational action, function, or data named in the service request in operation (1). Ground node 3704 forwards this to LEO1 3706 for processing. In operation (2), LEO1 3706 returns intermediate or partial results (e.g., data packets with names that can match names from the target packet).

[0355] At time 3712, LEO1 3706 moves out of range, followed by LEO2 3708 coming into range. Based on this transition, the first computation request is forwarded to LEO2 3708 at time 3714.

[0356] The user provides a second computational service request for a computational action, function or data in operation (3), which the ground node 3704 forwards to LEO2 3708 for processing. LEO2 3708 provides a request to LEO1 3706 for a dump of computational information for a period of time or other specification (e.g., last minute) and obtains such information from LEO 3706. LEO2 3708 then sends the remaining results back to the user 3702 in operation (4).

[0357] In a further example, the selection of the LEO 3708 can be based on existing routing and capacity planning rules. For example, if LEO1 3706 has multiple options for what LEO2 3708 can choose from, it can use (1) how much power capability is provided, (2) what QoS capabilities are provided, and (3) whether the EPVC channel can be re-established according to the SLA. These factors can be included in the FIB of the LEO 3708 to help determine the interface over which the request is sent.

[0358] In contrast to the handover approach shown in Figure 37, existing technologies do not provide for "reactive" handover of services in a satellite framework, and session-based services such as TCP / IP are based on fixed endpoints and cannot support such functionality.

[0359] Other extensions to the handover technique shown in Figure 37 may also be implemented. For example, this may involve end-to-end QoS coordination, such as an extended QoS approach to ICN (e.g., NDN or NFN) networks. It may also involve key performance indicator (KPI) considerations and other complex, multi-constrained QoS considerations. Other aspects may consider reliability as part of the coordination and processing selection. For example, reliability requirements or information may be used as part of the NDN / ICN request and considered in the resource and route mapping.

[0360] In addition, considering that satellite technology is planned as one of the radio access technologies beyond 5G, other network information (e.g., cellular network control plane information, etc.) can be used for handover processing. Here, terrestrial nodes (e.g., terrestrial node 3704) are considered to be part of the cellular network and connect cellular base stations either via wired (e.g., Xn interface) or wireless interface. As the satellite moves, the terrestrial node detects the movement and exchanges information with the base station that can smartly forward the consumer request to the new satellite via the new terrestrial node. Thus, cooperation can also be used to handle the movement of data consumers or users.

[0361] 38 illustrates a flowchart 3800 of an example method performed in a satellite connectivity system for handing over computation and data services to maintain service continuity using the NDN / ICN architecture and service requirements. Aspects of the method may be performed by a user device (e.g., user equipment) directly or indirectly connected to the satellite communications network, a terrestrial node (e.g., edge base station) connected or indirectly connected to the satellite communications network, a low earth satellite of the satellite communications network, or other orchestrator, gateway, or communications device (including intermediate devices involved in NDN / ICN operations).

[0362] At operation 3810, a computational service request is received (or provided) at a first satellite node via the NDN / ICN architecture. The service request may involve a request for at least one of a computational operation, a functional performance, or a data acquisition operation via the NDN / ICN architecture.

[0363] In operation 3820, intermediate or partial results of the service request are provided to the user / consumer from the first satellite node (or are received from such node). For example, as previously described with reference to FIG. 37, the initial response to the service request may include partial results of the service request. These results may be delivered as a result of the first satellite node detecting or predicting that it will move out of the optimal geographical space (square, circle, hexagon, ...) region for the terrestrial user. For example, in an NDN / ICN setting, the first satellite node pre-identifies a second satellite node that will enter its geographical space and transitions its PIT and FIB entries (including those that are partially serviced).

[0364] In operation 3830, an updated (second) service request is obtained (or communicated) at the second satellite node in response to a change in user or satellite coverage. As previously mentioned, this handover from, for example, a first satellite to a second satellite of the constellation may occur automatically within the satellite network based on geographic coverage information or the state of the user connection.

[0365] In operation 3840, an updated service request is received at the second satellite node via the NDN architecture for initial or remaining processing results, where the second satellite node completes the partially serviced request using the context of the transferred first satellite node. In some examples, the operation of performing the handoff remains transparent to the end user, since the terrestrial user is unaware of the handoff to the second satellite node.

[0366] In operation 3850, the second satellite node operates (based on the intermediate results, service requirements, or other information from the first satellite node) to obtain computational or data processing results for the service request.

[0367] In operation 3860, the remaining results of the service request (if applicable) are generated, accessed or otherwise obtained and then communicated from the first satellite node to the end user / consumer.

[0368] In a further example, a terrestrial node is involved to request, communicate or provide data as part of the service request and NDN operation. For example, a terrestrial node may be involved as the first hop in the NDN architecture and forward a service request to the satellite communication network if the data or function result cannot be provided from the terrestrial node.

[0369] Example G1 is a method for coordinated data handover in a satellite communications network, including sending a service request for a Named Data Networking (NDN) architecture to a satellite communications network implementing an NDN architecture, receiving an initial response to the service request from a first satellite of the satellite communications network, sending an updated service request for the NDN architecture to the satellite communications network in response to the first satellite moving out of communication range, and receiving an updated response to the updated service request from the second satellite of the satellite communications network based on a handover of the service request from the first satellite to the second satellite.

[0370] In Example G2, the subject matter of Example G1 optionally includes subject matter in which the service request is a request for at least one of a computational operation, a functional performance, or a data acquisition operation via an NDN architecture.

[0371] In example G3, the subject matter of any one or more of examples G1-G2 optionally includes subject matter where a first response to the service request includes partial results of the service request and an updated response to the updated service request includes remaining results of the service request.

[0372] In Example G4, the subject matter of any one or more of Examples G1-G3 optionally includes subject matter in which handover of the service request is coordinated between the first satellite and the second satellite based on forwarding the service request from the first satellite to the second satellite and based on the second satellite obtaining data from the first satellite related to a first response to the service request.

[0373] In example G5, the subject matter of any one or more of examples G1-G4 optionally includes subject matter where actions are performed by user equipment directly connected to the satellite communications network.

[0374] In Example G6, the subject matter of any one or more of Examples G1-G5 optionally includes subject matter in which operations are performed by a terrestrial node connected to the satellite communications network, the terrestrial node communicating data of the service request and data of the response to a connected user.

[0375] In Example G7, the subject matter of Example G6 optionally includes the subject matter of the terrestrial node invoking the service request in response to the terrestrial node being unable to fulfill the service request.

[0376] In example G8, the subject matter of any one or more of examples G1-G7 optionally includes the subject matter where the handover of the service request includes coordination of computation results communicated from the first satellite to the second satellite.

[0377] In Example G8, the subject matter of Example G8 optionally includes subject matter where the calculations include data performed on the first satellite over a predetermined period of time.

[0378] In Example G10, the subject matter of any one or more of Examples G1-G9 optionally includes subject matter in which the service request includes an NDN request based on a name of a function and a dataset for operating the function.

[0379] In Example G11, the subject matter of any one or more of Examples G1-G10 optionally includes subject matter in which the first satellite or the second satellite is configured to satisfy the service request based on additional computational nodes accessible from the satellite communications network.

[0380] In Example G12, the subject matter of any one or more of Examples G1-G11 optionally includes subject matter where the first satellite and the second satellite are part of a low Earth orbit (LEO) satellite constellation.

[0381] In Example G13, the subject matter of any one or more of Examples G1-G12 optionally includes subject matter where selection of the first satellite or the second satellite to satisfy the service request is based on network routing or capacity rules.

[0382] In Example G14, the subject matter of Example G13 optionally includes the subject matter where the selection of the first satellite or the second satellite to satisfy the service request is further based on a quality of service and a service level requirement.

[0383] In Example G15, the subject matter of any one or more of Examples G1-G14 optionally includes the subject matter where the updated service request is further coordinated based on a movement of a mobile device from which the service request originates.

[0384] Satellite and terrestrial link discovery and routing algorithms

[0385] As shown in the previous example, a terrestrial infrastructure node is connected to (i) a LEO satellite, (ii) a client device via a wireless link, (iii) a client device via a wired link, and (iv) other infrastructure devices via wired and / or wireless links. Each of these links has a different latency and bandwidth. For a data request, the decision of which link to use is simpler; the closest node with the shortest latency will be the appropriate choice. However, if it is a computation request, then decisions also need to be made about the type of computing hardware available on the device, QoS requirements, security requirements, etc.

[0386] Leveraging name-based addressing in ICN, below we provide enhancements that allow the system to select, in addition to discover, the optimal node / path for performing services (routing and forwarding). In the satellite edge framework, different nodes have different computing capabilities and resources (hardware, software, storage, etc.), applications have different QoS requirements and priorities, and there may be additional policies enforced by governments or other entities.

[0387] To provide an example, some satellites may implement security functions while others do not. For example, some of them may have secure enclave / trusted execution environment capabilities while others do not. As a result, when an interest packet arrives at the base station, the base station must decide whether to forward it to the satellite link. Despite the high latency to the satellite, the satellite has much larger computing resources and can facilitate a situation where it is a better choice to run a service compared to a terrestrial node that is closer (and also has higher bandwidth).

[0388] In the following, we propose a multi-layered solution that decides where to forward computation requests and how to configure services with resources. This is applicable to the use of ICN or NDN since forwarding decisions are needed in addition to routing. The discovery mechanism we disclose helps to populate the routing table or Forwarding Information Base (FIB) and creates a map of links to available resources along with delay, bandwidth, etc.

[0389] Since forwarding in ICN is hop-by-hop, each time an Interest packet arrives at a node, the node must decide where to forward the packet. If the FIB indicates, for example, three locations or links where a function can be performed, the forwarding strategy must decide which of these three is the best option.

[0390] FIG. 39 illustrates a discovery and routing strategy implemented in a satellite connectivity system, providing a two-tier hierarchy of decision factors used in the selection and use of computational resources. Here, the first tier is the application providing its requirements and priorities as application parameters 3910. The application may include this information in the “Application Parameters” field of the interest packet. For example, if security is the highest priority, the ground / base station will not forward packets to the satellite if it has the fastest computational capabilities but does not have security capabilities. The interest packet may also indicate which parameters it has or does not have leeway in. For example, if a client specifies that all requirements must be met, the base station will not forward the packet (it may send a NACK depending on the implementation) if it believes that there is no node that meets all constraints.

[0391] At the first tier, there is also resource discovery information 3920 obtained from identifying relevant computational, storage or data resources. Information about such resources and resource capabilities may be discovered and identified as part of an ICN / NDN network as described above.

[0392] In addition, the first layer may need to apply other local policies that are not dynamically changed, which is the top layer policy information 3930.

[0393] The forwarding strategy layer 3950 uses input from all three sources 3910, 3920, 3930 to determine the optimal path for subsequently forwarding the interest packet. At the strategy layer, policies override application requirements.

[0394] Once the forwarding strategy layer 3950 has determined where to forward the interest packet, it also forwards it to other nodes. There is an option to provide "forwarding hints". For example, if a certain group of routes should be avoided, that can be indicated in the forwarding hints. So, even though in ICN / NDN forwarding is hop-by-hop, the source node can provide guidance on routing for all nodes coming from it.

[0395] In a further example, satellite area geofencing and QoS / service level considerations (as described throughout this application) may be integrated as part of the forwarding strategy, such that routing can include considerations regarding geographic location interests and restrictions as well as SLAs.

[0396] The use of this approach provides a comprehensive solution for discovery and routing, as well as enforcement of QoS, policies, security, etc. The approach can support dynamic discovery of critical resources at the satellite edge. The approach enables the use of secured as well as unsecured satellite nodes and other computational resources. The approach comprehensively considers radio delay and bandwidth, along with other parameters, to make routing and forwarding decisions. In contrast, existing orchestration solutions mostly rely on static routing and resource frameworks.

[0397] LEO based routing can be adapted to construct paths that provide end-to-end SLAs that include factors including ground-based nodes, dynamic satellite-based nodes, hop-to-hop propagation delays, which hops are safe, which inter-satellite links are on / off, and where to perform routing algorithm calculations, etc. Ground-based algorithm calculations of such routes can be more computationally intensive than on-orbit calculations, so depending on how quickly the constellation needs to be updated, which hops are safe or which hops get the best results with compression can be important factors.

[0398] So even ground-based routing calculations can evaluate the wide view and hop characteristics (secure / compressed, etc.) of space-based networks to guarantee SLA results. Ground-based routes can also be considered as part of the potential routes to achieve SLA results (e.g., using terrestrial fiber optic networks and dedicated links that provide high bandwidth and low latency). As an example, one route choice can be Sat1→Sat2→Sat3→Sat4, while another route choice can be Sat1→Sat2→Earth route→Sat4.

[0399] In a further example, overlays can be created for different tenants and exclusion zones, for example having different organizations or tenants with different levels of trust in different types of routers or network providers. Also, using credentials, trust levels can be established for various routers (e.g., associated with different interest packets). Similarly, in a further example, the concept of trusted routing can be applied.

[0400] 40 shows a flowchart 4000 of an example method for implementing a discovery and routing approach. This method can be implemented and applied in the ICN (e.g., NDN or NFN) architecture described above. However, this method can also be implemented as part of other routing calculations for a satellite communication network.

[0401] A request for data routing, including a data connection through a satellite communications network, is received at operation 4010. The request may be received in the following procedures by a ground-based infrastructure node connected to the satellite communications network, by a user equipment directly or indirectly connected to the satellite communications network, or by the satellite communications node itself.

[0402] At operation 4020, one or more application parameters (including application preferences) are identified and applied, such application parameters defining priorities among requirements for the data connection.

[0403] In operation 4030, one or more resource capabilities are identified and applied, which relate to the resources of the node that will be used to satisfy the data connection.

[0404] At operation 4040, one or more policies are identified and applied, each such policy defining one or more restrictions on the use of the data connection.

[0405] At operation 4050, a routing strategy (and routing path) is identified based on preferences, capabilities, and policies. For example, this may be based on prioritization between priorities defined by application parameters, resource capabilities provided by the nodes, and satisfaction of identified policies.

[0406] In operation 4060, a routing strategy is applied (e.g., in an ICN implementation) that includes generating a next hop for the interest packet or setting up a FIB table using the identified routing path. Other applications and modifications can be applied to use this technique in non-ICN network architectures.

[0407] Example H1 is a method for data routing using a satellite communications network, comprising: receiving a request for data routing using a data connection via the satellite communications network; identifying at least one application parameter for using the data connection, the application parameter defining a priority among requirements for the data connection; identifying at least one resource capability for using the data connection, the resource capability relating to resources at a node used to satisfy the data connection; identifying at least one policy for use of the data connection, the policy defining at least one restriction for use of the data connection; determining at least one routing path through at least one node of the satellite communications network based on a prioritization among the priority defined by the application parameter, the resource capability provided by the at least one node and satisfaction of the identified policy by the at least one node; and indicating the routing path for use with the data connection on the satellite communications network.

[0408] In Example H2, the subject matter of Example H1 optionally includes subject matter used for data communications in which routing paths are provided within a Named Data Networking (NDN) architecture.

[0409] In Example H3, the subject matter of Example H2 optionally includes subject matter in which a routing path is used to generate a next hop for an interest packet used in an NDN architecture.

[0410] In example H4, the subject matter of any one or more of examples H2-H3 optionally includes subject matter in which the routing path is used to input data into a forwarding information base (FIB) of the NDN architecture.

[0411] In Example H5, the subject matter of any one or more of Examples H1-H4 optionally includes subject matter where the requirements for the data connection provided by the application parameters relate to at least one of security, delay, quality of service, or service provider location.

[0412] In example H6, the subject matter of any one or more of examples H1-H5 optionally includes subject matter where the resource capabilities provided by at least one node relate to security, trust, hardware, software, or data content.

[0413] In example H7, the subject matter of any one or more of examples H1-H6 may include determining resource capabilities including discovering resource capabilities at a plurality of nodes, and the resource capabilities optionally include security and trust related subject matter.

[0414] In Example H8, the subject matter of Example H7 optionally includes subject matter where the resource capabilities at the plurality of nodes further relate to service resources provided by at least one of computing, storage, or data content resources.

[0415] In Example H9, the subject matter of any one or more of Examples H1-H8 optionally includes subject matter where at least one restriction of the policy relates to a satellite exclusion zone, a satellite network restriction, or a device communication restriction.

[0416] In Example H10, the subject matter of any one or more of Examples H1-H9 optionally includes the subject matter where the routing path includes a terrestrial network connection.

[0417] In Example H11, the subject matter of any one or more of Examples H1-H10 optionally includes subject matter where determining a routing path includes determining a plurality of routing paths that satisfy the identified policies and selecting a path based on application parameters and resource capabilities.

[0418] In Example H12, the subject matter of Example H11 optionally includes determining a preference among multiple routing paths and providing forwarding hints for use of the multiple routing paths.

[0419] In Example H13, the subject matter of any one or more of Examples H1-H12 optionally includes subject matter where the method is performed by a ground-based infrastructure node connected to a satellite communications network.

[0420] In Example H14, the subject matter of any one or more of Examples H1-H13 optionally includes subject matter where the method is performed by a user device directly or indirectly connected to a satellite communications network.

[0421] In Example H15, the subject matter of any one or more of Examples H1-H14 optionally includes subject matter where the operations are performed by a satellite communications node and the satellite communications network includes paths between multiple satellite constellations operated by multiple service providers.

[0422] In Example H16, the subject matter of any one or more of Examples H1-H15 optionally includes subject matter where the satellite communications network includes potential paths between multiple inter-satellite links.

[0423] Improved satellite network packet processing

[0424] The following disclosure addresses various aspects of connectivity and network data processing associated with various network communication settings. In particular, some of the techniques described herein relate to simplified hardware packet processing in temporary non-terrestrial networks (e.g., Low Earth Orbit (LEO) or Very Low Earth Orbit (VLEO) satellite constellations) networks. Other techniques described herein relate to packet processing in terrestrial networks, such as the use of network processing hardware at various network termination points.

[0425] In the context of many network deployments, service providers are embracing the use of Internet Protocol Security (IPSec) to secure the path of infrastructure traffic from the edge to the core. IPSec requires packet modification for each session flow that necessitates the use of packet processing engines that add latency between IPSec termination points, impacting the ability of service providers to meet 5G's <1 ms latency.

[0426] Network applications such as IPSec, Datagram Transport Layer Security (DTLS), etc., require packets to be modified (e.g., add or remove headers, add or remove fields, encrypt or decrypt, authenticate) before they are sent or after they are received. To achieve the high throughput required by modern network applications, multiple dedicated network processing engines are required to operate in parallel. The following system and method significantly improves latency, power and die area constraints by utilizing a command template-based mechanism that eliminates multiple network processing engines from processing and modifying such packets.

[0427] Below, we provide an approach to reduce the latency introduced to serve 5G edge-to-core traffic by using a single engine with predefined packet templates rather than multiple packet engines. Reducing the number of packet engines reduces the design complexity of network processes by using fewer arithmetic logic units (ALUs), reduces circuit area, reduces power, and ultimately enables service providers to meet 5G latency requirements at the edge. In one implementation, the ALU count is reduced by 64 while still enabling the same packet operation performance.

[0428] Figures 41A and 41B show example terrestrial and satellite scenarios for packet processing. Specifically, Figure 41A shows IPSec aggregation points 100A-D used in typical 4G / LTE and 5G networks, and Figure 41B shows example routing points 150A-D used in a typical satellite communications network. The following approach reduces the overall complexity of handling the required dynamic packet modifications while templating standard modifications. This feature can be used in smart NICs, network processors and FPGA implementations, providing significant advantages for use in satellite network processing.

[0429] In the context of Figure 41A, not using the template packet modifier results in higher latency. This higher latency is due to multiple unique packet processing engines (e.g., up to 32 ALUs) and the time it takes for each packet processing engine to perform its respective operation. So, for IPSec used in 5G edge-to-core, there can be about 64 modifications for about 30 flows. The use of the template PKT modifier below reduces latency by using a single packet engine with an alternate template, which requires only the use of one common engine (e.g., one ALU).

[0430] Similarly, a delay-sensitive environment is shown in Figure 41B. In satellite constellations, the LEO:FSA algorithm is used in conjunction with the Explicit Load Balancing (ELB) algorithm to determine the maximum efficiency of the inter-satellite links. A finite-state automaton (FSO) is used to allow neighboring satellite entities to exchange information, where the LEO satellite network may also provide priority adaptive routing (e.g., using a grid for network shortest paths).

[0431] Different templates may be used depending on the location or type of routing to be performed. For example, templates may include templates for extreme latency and minimal processing power, such as those used in non-terrestrial on-orbit hardware processing with limited hardware capabilities or network borders, network access, or other limited hardware located on orbit. Without template packet modifiers, latency is high, especially for on-orbit routing protocols. In contrast, the use of the following template packet modifiers results in lower latency and fewer hardware components through the use of a single packet engine. The use of a single packet engine with alternative templates uses one common engine that is applicable to location-based routing, whether on a terrestrial or satellite network.

[0432] 42 and 43 show a packet processing architecture that is embedded for edge computing according to one example. FIG. 42 shows a conventional network processor 4200 used to perform operations on packets for network applications such as IPsec or DTLS. The network processor 4200 includes an ALU 202 with a special purpose instruction set. The ALU 4202 prepares commands at run time based on parameters obtained from an input packet 4206 and a specific protocol configuration 4204. The ALU 4202 provides commands to a modifier circuit 4208 to modify the packet. A typical packet goes through such multi-stage processing, with each stage performing a different function on the packet before reaching the end of the processing pipeline.

[0433] To achieve high throughput, multiple packets are processed in parallel substantially simultaneously, with each pipeline requiring its own dedicated processing engine. The use of network processors arranged in parallel to perform such operations on packets is shown in FIG. 43. Multiple ALUs 4202A-4202M operate on the input packets. The packets are processed sequentially by modification circuits 4208A1-AN, 4208B1-BN, . . . , 4208B1-BN. This requirement for multiple network processing elements, with each ALU 4202 generating commands at run time, results in significant power consumption and silicon area in a typical system.

[0434] To overcome the drawbacks of each ALU generating commands at run time in the above-mentioned network processing system, a command template based (CTB) network processor 4400 is provided in Fig. 44. The sophisticated ALU of Fig. 43 which generates commands for the modification circuit 208 at run time is replaced by a simple "parameter substitution" circuit 4400 of Fig. 44, where the commands for the parameter substitution circuit 4402 are obtained from a command template block 4404 with some parameter modification at run time.

[0435] The network processor 4400 of FIG. 44 implements a command template-based network processing method that replaces pre-prepared commands with run-time parameters to efficiently process packets in network applications. This allows multiple packet processing engines (e.g., the modification circuit 4208) to be replaced by a single engine (e.g., the CTB network processor 4400). Such a solution is highly optimized in terms of delay performance, power, and area.

[0436] The command template block 4404, loaded during initialization, stores a set of command templates containing pre-prepared commands. Each command template contains two command sets: a network command set (NCS) and a substitution command set (SCS). The network command set contains commands used by the modifier 4406 in the CTB network processor 4400 to modify packets. The substitution command set contains commands used by the parameter substitution block 4402 to modify the network command set before it is sent to the modifier 4406 to modify the packet.

[0437] Based on the protocol, the command template based network processor 4400 selects one template from the command template block 4404, and the parameter substitution block 4402 substitutes some fields in the network command set with input parameters using a substitution command set from the selected template. The input parameters are received from the ALU 4408. The network command set is then sent to the modifier 4406, which makes changes to the packet.

[0438] The parameters provided to the network processors 4400 are in a fixed format, similar to the templates. Thus, the parameter substitution block 4402 simply operates to copy parameters to the network command set based on the substitution command set. The command template block 4404 is shared by all network processors 4400. The parameters are prepared by the ALU 4408 at run time for each packet and become part of the packet metadata that is passed from stage to stage.

[0439] Figure 45 shows a typical system with multiple command template based processors arranged to process input packets in parallel. At each stage, a template is used to provide a replacement command set, which is used to modify the network command set based on ALU parameters. The ALU parameters are fed into the pipeline and are available at each stage. One template is passed along and used at each stage. Alternatively, templates may be provided per stage by the command template block 4404. Templates may be designed for a particular stage.

[0440] Figure 46 provides a further network processing example to give an idea of ​​the command template based network processing mechanism. In this example, a 16 byte field called "IV" needs to be inserted into a packet at location offset 52. A set of parameters 4600 are provided by the ALU. Parameters 4600 contain 16 bytes of IV data, measured in IV length bytes (i.e., 16), with the IV location within the packet at offset 52. These values ​​for the IV field are found in parameters 4600 at addresses 20, 80, and 90, respectively.

[0441] The template includes a network command 4602. Network command 4602 has an insert command that inserts the IV located at offset 10 into the network command set 4602. The insert command has four fields, each one byte long, except for the pkt offset field, which is 4 bytes long. The insert command is followed by 32 bytes, which are used to store up to 32 bytes of data. cmd_len is the length of the current command, in this case 40 bytes. valid_len is the actual IV length. valid_len is updated by the replace command with IV_len=16. In the insert command, pkt_offset is the position in the packet where the IV value is to be inserted, which is updated by the replace command with a value of 52 (the value of pkt_IV_offset in parameters 4600).

[0442] The format of the substitution commands is simple: copy, source offset, destination offset, length. So, as shown in Figure 46, the first copy command is "COPY 80, 11, 1", which instructs the parameter substitution circuit to copy the parameter at offset 80 from the parameters to offset 11 in the network command portion of the template, where the field size (or length) is 1 byte. Similarly, the copy command "COPY 90, 12, 4" copies the contents of the parameter at offset 90 to offset 12 in the network command, copying 4 bytes of data to that location in the network command.

[0443] The resulting network command is used by the modifier, in this case to insert 16 bytes of data at packet offset 52 and proceed to the next command 40 bytes away.

[0444] Therefore, this command template-based network processing mechanism effectively replaces pre-prepared commands with run-time parameters to efficiently process packets in high-performance network applications. This eliminates the need for multiple network processing engines and only requires one common engine, which can result in much fewer ALUs and faster processing times.

[0445] Similar to the above-described approach for IPsec, this packet processing technique can be applied to a variety of other routing protocols, including those used in satellite communication networks. LEO satellite network routing can be done "offline" on the ground and used to set up paths between satellites and terrestrial nodes. However, constellation nodes dynamically change over time due to orbital shifts, offline nodes, and exclusion zone services. Depending on how a provider approaches these issues, different protocols or inter-satellite communication techniques (e.g., radio or laser) may be used, for example, to support the use of inter-satellite links (ISLs) or to provide services (e.g., Ultra Reliable Low Latency Connectivity (URLCC)) to premium subscribers. As a result, when processing is transferred to orbit, latency, power, and simple processing become important considerations that are addressed in the command template-based network processor described above.

[0446] Additionally, the use of minimal memory data changes (to avoid corruption from space radiation) highlights the value of command template processing. This is particularly beneficial for protocols such as Asynchronous Transfer Mode (ATM) where virtual nodes can be configured and dynamically adjusted to be the shortest path. Thus, by using our packet processing techniques, dynamic network processing changes can be handled on-orbit, approximating actual path rerouting.

[0447] Additionally, the packet processing template reference architecture described herein may also be extended as part of an improved 5G network, as part of a "Regenerative Satellite-Enabled NR-RAN with Distributed gNB." Here, the gNB-DU (Distributed Unit) may be hosted on the satellite, so that parts of the NR protocol are processed on-board the satellite, with the DU on orbit. In contrast, existing deployments of vRAN-DU are terrestrially located. Consider an example where the satellite needs to reroute when there is a sudden change in traffic load that causes congestion, and there is no time to wait for ground-based (offline) routing to occur, so the satellite needs to step in. In this situation, current packet template processing techniques in satellite communications hardware can provide low latency, limited processing power, and immediate response.

[0448] Figure 47 provides a flowchart 4700 of a template based packet processing technique. The flowchart begins at operation 4710 with the initial step of configuring and obtaining a template for data processing (optional in subsequent steps), as described above with reference to command template block 4404. The flowchart continues at operation 4720 with receiving one or more packets from the packet stream for processing by the CTB network processor 4400 as follows.

[0449] The ALU 4408 operates to generate and provide parameters for modification of one or more packets at operation 4730. The template obtained from the command template block 4404 is then provided at operation 4740 for use for initial parameter substitution, such as by the parameter substitution block 4402. The initial parameter substitution at operation 4740 provides replacement commands that can be used to modify the particular type of packet being processed.

[0450] At operation 4750, substitution commands are applied to modify one or more of the processed packets based on substitution parameters provided in the template. This operation may be performed by modifier 4406 as described above. Such substitution commands may be performed repeatedly to modify the packets in multiple stages, as shown in Figure 45. Finally, at operation 4760, the modified packets are output from the network processor so that they may be communicated or further used in a network scenario.

[0451] Further example implementations include the following device configurations and methods performed by the following configurations and similar network processing devices:

[0452] Example I1 is a network packet processing device including a network interface that receives a stream of packets, an arithmetic logic unit (ALU), a command template store, and circuitry including a plurality of processing components connected to the ALU and the command template store, the plurality of processing components arranged in parallel groups of serial pipelines, each pipeline including a first stage and a second stage, the processing component of the first stage receiving parameters from the ALU and using the parameters to modify commands in a template received from the command template store, the modified commands being used to modify packets in the stream of packets.

[0453] In Example I2, the subject matter of Example I1 optionally includes subject matter where the template received from the command template store includes a network command and a corresponding replacement command, the replacement command using parameters received from the ALU to modify the network command.

[0454] In Example I3, the subject matter of Example I2 optionally includes subject matter where the network command is a generalized command structure.

[0455] In Example I4, the subject matter of any one or more of Examples I2-I3 optionally includes subject matter related to the type of packet in which the network command is being processed from the stream of packets.

[0456] In Example I5, the subject matter of any one or more of Examples I1-I4 optionally includes subject matter where the ALU is the only ALU of the network packet processing device.

[0457] In Example I6, the subject matter of any one or more of Examples I1-I5 optionally includes subject matter in which a first stage processing component outputs a modified packet based on commands in a template, and a second stage processing component receives the modified packet and further modifies it based on the template.

[0458] In Example I7, the subject matter of any one or more of Examples I1-I6 optionally includes subject matter where a first stage processing component outputs a modified packet based on commands in the template, and a second stage processing component receives the modified packet and further modifies it based on a second template received from the template store.

[0459] In Example I8, the subject matter of any one or more of Examples I1-I7 optionally includes subject matter where each of the first stage processing components operates on the same type of packets provided according to the network communications protocol.

[0460] In Example I9, the subject matter of any one or more of Examples I1-I8 optionally includes subject matter where the network packet processing device is deployed in network processing hardware of a low Earth orbit satellite vehicle.

[0461] In Example I10, the subject matter of any one or more of Examples I1-I2 optionally includes subject matter where the stream of packets is of a first type of network communication protocol, and the multiple processing components are used to convert the stream of packets to a second type of network communication protocol.

[0462] In Example I11, the subject matter of any one or more of Examples I1-I10 optionally includes subject matter where the command template store provides one or more templates for a given routing protocol used in satellite-based networking.

[0463] In Example I12, the subject matter of any one or more of Examples I1-I11 optionally includes subject matter where the circuitry is provided by an application specific integrated circuit (ASIC).

[0464] In Example I13, the subject matter of any one or more of Examples I1-I12 optionally includes subject matter where the multiple processing components include multiple network processors.

[0465] Implementation in edge computing scenarios

[0466] It will be appreciated that the present terrestrial and non-terrestrial network configurations can be integrated with many aspects of edge computing strategies and deployments. At a general level, edge computing refers to the migration of computing and storage resources closer to endpoint devices (e.g., consumer computing devices, user equipment, etc.) to optimize total cost of ownership, reduce application latency, improve service capabilities, and improve compliance with security or data privacy requirements. In some scenarios, edge computing can provide cloud-like distributed services that provide orchestration and management of applications across many types of storage and computing resources. As a result, some implementations of edge computing are referred to as "edge cloud" or "fog" because powerful computing resources that were previously only available in large remote data centers are now moved closer to the endpoints and available to consumers at the "edge" of the network.

[0467] In the context of satellite communications networks, as discussed above, edge computing operations can occur by moving workloads to computing equipment on the satellite vehicles, using satellite connectivity to provide backup or (redundant) links and connections to low latency services, coordinating workload processing operations at terrestrial access points or base stations, providing data and content over the satellite network, etc. Thus, many of the same edge computing scenarios described below for mobile networks and mobile client devices are equally applicable when using non-terrestrial networks.

[0468] 48 is a block diagram 4800 outlining an edge computing configuration, including a layer of processing referred to in many of the current examples as the “edge cloud.” This network topology, which may include many traditional network layers (including those not shown herein), may be extended through the use of satellite and non-terrestrial network communication arrangements as described herein.

[0469] As shown, the edge cloud 4810 may include multiple entities, devices, and equipment instances as they are co-located at edge locations, such as satellite vehicles 4841, base stations 4842, local processing hubs 4850, or central offices 4820. The edge cloud 4810 is located much closer to the endpoint (consumer and producer) data sources 4860 (e.g., autonomous vehicles 4861, user equipment 4862, business industrial equipment 4863, video capture devices 4864, drones 4865, smart city and building devices 4866, sensors and IoT devices 4867, etc.) than the cloud data center 4830. The computation, memory, and storage resources provided at the edge of the edge cloud 4810 are critical because they provide ultra-low latency or improved response times for the services and functions used by the endpoint data sources 4860, as well as reduce network backhaul traffic from the edge cloud 4810 to the cloud data center 4830, improving energy consumption and overall network usage, among other benefits.

[0470] Computation, memory and storage are scarce resources and are generally reduced by edge locations (e.g., fewer processing resources available at a consumer endpoint device than at a base station or central office). However, the closer the edge location is to the endpoint (e.g., UE), the more space and power are constrained. Therefore, as a general design principle, edge computing attempts to minimize the amount of resources required for network services by distributing more resources located closer together, both geographically and in network access time. In non-terrestrial network scenarios, distances and latencies to satellites may be farther away, but data processing may be better realized in edge computing hardware on the satellite vehicle rather than requiring additional data connections and network backhaul to the cloud.

[0471] In one example, edge cloud architectures may be extended beyond typical deployment limits to address constraints that some network operators or service providers have in their own infrastructure, including variations in configuration based on edge location (as performance may be more constrained at the base station level, for example), configuration based on edge locations, hierarchies of locations, resources of types such as compute, memory, storage, fabric, acceleration, etc. available at groups of locations, services, security, management and orchestration capabilities, and related objectives to enable usability and performance of end services.

[0472] Edge Computing is an evolving paradigm where computing is done at or near the "edge" of the network through the use of computational platforms, typically implemented in base stations, gateways, network routers, or other devices much closer to the endpoint devices that generate and consume data. For example, an edge gateway server may comprise a pool of memory and storage resources to perform computations in real time for low-latency use cases (e.g., autonomous driving or video surveillance) for connected client devices. Or, as an example, a base station may be extended with computational and acceleration resources to directly process service workloads for connected user equipment without further communicating data over a backhaul network. Or, as another example, central office network management hardware may be replaced with computational hardware that performs virtualized network functions and provides computational resources to execute services and consumer functions for connected devices. Similarly, within an edge computing deployment, there may be scenarios in which data is "moved" to computational resources in addition to scenarios in which computational resources are "moved" to data in services. Or, as an example, base station (or satellite vehicle) computation, acceleration and network resources can be tailored to workload demands as needed by enabling dormant capacity (subscription, capacity on demand) to manage corner cases, emergency situations or provide longevity for deployed resources over a significantly longer implementation lifecycle.

[0473] In contrast to the network architecture of FIG. 48, traditional endpoint (e.g., UE, Vehicle-to-Vehicle (V2V), Vehicle-to-Everything (V2X), etc.) applications rely on local device or remote cloud data storage and processing for communication and collaboration. Cloud data placement allows for long-term data collection and storage, but is not optimal for time-varying data such as collisions, signal changes, etc., and may fail to address latency issues. Extending satellite capabilities within an edge computing network offers further possible permutations for management of compute, data, bandwidth, resources, service levels, etc.

[0474] Depending on the real-time requirements in the communication context, a hierarchy of data processing and storage nodes may be defined in an edge computing deployment with satellite connectivity. For example, such a deployment may include local ultra-low latency processing, regional storage and processing, as well as remote cloud data center based storage and processing. Key performance indicators (KPIs) may be used to identify where the sensor data is optimally forwarded and where it is processed or stored. This typically depends on the ISO layer dependency of the data. For example, data at lower layers (PHY, MAC, routing, etc.) typically changes quickly and is better processed locally to meet latency requirements. Higher layer data, such as application layer data, is typically less time critical and may be stored and processed in a remote cloud data center.

[0475] FIG. 49 illustrates operational layers between endpoints, edge clouds, and cloud computing environments. Specifically, FIG. 49 illustrates an example compute use case 4905 that utilizes edge cloud 4810 between multiple example layers of network computing. The layers start with endpoints (devices and things) layer 4900, which access edge cloud 4810 for data creation, analysis, and data consumption activities. Edge cloud 4810 can span multiple network layers, such as edge device layer 4910 with gateways, on-premise servers or network equipment (nodes 4915) located in physically proximate edge systems, network access layer 4920 including base stations, wireless processing units, network hubs, regional data centers (DCs) or local network equipment (equipment 4925), and equipment, devices or nodes located in between (in layer 4912, not shown in detail). Network communication within edge cloud 4810 and between various layers can occur via any number of wired or wireless media, including connection architectures and technologies not shown.

[0476] Examples of latencies in terrestrial networks resulting from network communication distance and processing time constraints are sub-milliseconds (ms) between endpoint layer 4900, sub-5 ms at edge device layer 4910, and in the range of 10-40 ms when communicating with nodes at network access layer 4920 (variations in these latencies are expected with the use of non-terrestrial networks). Beyond edge cloud 4810 are core network 4930 and cloud data center 4940 layers, each with increased latencies (e.g., 50-60 ms at core network layer 4930, and 100 ms or more at cloud data center layer). As a result, operation at core network data center 4935 or cloud data center 4945 with latencies of at least 50-100 ms or more would not be able to achieve many of the time-critical functions of use case 4905. Each of these latency values ​​is provided for purposes of illustration and comparison. It will be appreciated that the use of other access network mediums and technologies may result in even lower latencies. In some examples, each portion of the network may be classified as a "close edge", "local edge", "near edge", "middle edge" or "far edge" tier based on the source and destination of the network. For example, from the perspective of the core network data center 4935 or cloud data center 4945, a central office or content data network may be considered to be located in a tier (high latency values ​​when communicating with the devices and endpoints of use case 4905, "close" to the cloud), whereas an access point, base station, on-premise server or network gateway may be considered to be located in a tier (low latency values ​​when communicating with the devices and endpoints of use case 4905, "far" from the cloud). It will be appreciated that other classifications of a particular network tier that constitutes a "close", "local", "near", "middle" or "far" edge may be based on latency, distance, number of network hops or other measurable characteristics measured from a source in any of the network tiers 4900-4940.

[0477] Various use cases 4905 may access resources under usage pressure from incoming streams by multiple services utilizing the edge cloud. To achieve results with low latency, services running within the edge cloud 4810 balance various requirements in terms of (a) priority (throughput or latency) and quality of service (QoS) (e.g., autonomous vehicle traffic may have a higher priority than temperature sensors in terms of response time requirements or depending on the application, there may be performance sensitivities / bottlenecks in compute / accelerators, memory, storage or network resources), (b) reliability and resiliency (e.g., some input streams need to be serviced and traffic routed with mission-critical reliability, while other input streams may tolerate occasional failures depending on the application), and (c) physical constraints (e.g., power, cooling and form factor).

[0478] The end-to-end service view for these use cases involves the notion of service flow and is related to transactions. Transactions detail services in relation to resources, workloads, workflows, business function level and business level requirements in addition to the overall service requirements of the entities consuming the services. Services that execute on the described "conditions" can be managed at each layer such that real-time and compliance with the run-time contract for the transaction during the service lifecycle are guaranteed. If a component within a transaction lacks its agreed upon SLA, the overall system (components within the transaction) can provide the ability to (1) understand the impact of the SLA violation, (2) augment other components in the system to resume the overall transaction SLA, and (3) implement procedures to remediate.

[0479] Thus, in view of these variations and service features, edge computing in edge cloud 4810 can provide real-time or near real-time service and corresponding capabilities for multiple applications of use cases 4905 (e.g., object tracking, video surveillance, connected cars, etc.) and meet the ultra-low latency requirements of multiple applications. These advantages enable entirely new classes of applications (e.g., virtual network functions (VNFs), function as a service (FaaS), Edge as a Service (EaaS), etc.) that cannot leverage traditional cloud computing due to latency or other limitations. This is particularly relevant for applications that require connectivity via satellite and the additional latency required for a satellite trip to the cloud.

[0480] However, the benefits of edge computing come with a caveat: Devices located at the edge are often resource constrained, putting pressure on edge resource usage. This is typically addressed by pooling memory and storage resources for use by multiple users (tenants) and devices. The edge may be power and cooling constrained, so the most power hungry applications must consider power consumption. These pooled memory resources may have inherent power performance tradeoffs, as many are likely to use new memory technologies that require more power for greater memory bandwidth. Similarly, improved security of hardware and trusted root of trust capabilities are also required, as edge locations may be unmanned and may even require authorized access (e.g., if stored at a third party location). Such issues are especially magnified in edge clouds 4810 in multi-tenant, multi-owner or multi-access settings where services and applications are required by many users, as network usage fluctuates dynamically and the composition of multiple stakeholders, use cases and services changes.

[0481] At a more general level, an edge computing system may be described as including any number of deployments in the aforementioned layers, operating at an edge cloud 4810 (network layers 4900-4940) providing collaboration from clients and distributed computing devices. One or more edge gateway nodes, one or more edge aggregation nodes, and one or more core data centers may be distributed across the layers of the network to provide implementations of the edge computing system by or on behalf of a communications service provider ("telco" or "TSP"), an Internet of Things service provider, a cloud service provider (CSP), an enterprise entity, or any other number of entities. Various implementations and configurations of the edge computing system may be dynamically provided, such as when tailored to meet service objectives.

[0482] Consistent with the examples provided herein, a client computing node may be embodied as any type of endpoint component, circuit, device, appliance, or other thing capable of communicating as a producer or consumer of data. Additionally, the use of "node" or "device" in an edge computing system does not necessarily imply that such node or device operates in a client or agent / minion / follower role. Rather, a node or device in an edge computing system refers to an individual entity, node, or subsystem that includes separate or connected hardware or software configurations to facilitate or use the edge cloud 4810.

[0483] Thus, the edge cloud 4810 is formed from the network components and functional features operated within and by edge gateway nodes, edge aggregation nodes, or other edge computing nodes between the network layers 4910-4930. Thus, the edge cloud 4810 may be embodied as any type of network that provides edge computing and / or storage resources located in proximity to radio access network (RAN)-enabled endpoint devices (e.g., mobile computing devices, IoT devices, smart devices, etc.) as described herein. That is, the edge cloud 4810 may be envisioned as an "edge" that connects endpoint devices to traditional network access points that serve as on-ramp to service provider core networks, including mobile carrier networks (e.g., Global System for Mobile Communications (GSM) networks, Long Term Evolution (LTE) networks, 5G / 6G networks, etc.), while also providing storage and / or computational capabilities. Other types and forms of network access (e.g., wired networks including Wi-Fi, long-range wireless, and optical networks) may also be utilized in place of or in combination with such 3GPP carrier networks.

[0484] The network components of the edge cloud 4810 may be servers, multi-tenant servers, appliance computing devices, and / or other types of computing devices. For example, the nodes of the edge cloud 4810 may include appliance computing devices, which are self-contained electronic devices including a housing, chassis, case, or shell. In some circumstances, the housing may have dimensions for portability such that it can be carried and / or transported by a person. An example housing may include a material forming one or more exterior surfaces that partially or completely protect the contents of the appliance, which may include weather protection, hazardous environment protection (e.g., EMI, vibration, extreme temperature), and / or submersibility. An example housing may include power circuitry for powering stationary and / or portable implementations, such as AC power inputs, DC power inputs, AC / DC or DC / AC converters, power conditioners, transformers, charging circuits, batteries, wired inputs, and / or wireless power inputs. The example housing and / or its surface may include or be attached to mounting hardware to allow for attachment to structures such as buildings, telecommunication structures (e.g., poles, antenna structures, etc.) and / or racks (e.g., server racks, blade mounts, etc.). The example housing and / or its surface may support one or more sensors (e.g., temperature sensors, vibration sensors, light sensors, acoustic sensors, capacitive sensors, proximity sensors, etc.). One or more such sensors may be included in, carried by, or otherwise embedded in or attached to the surface of the appliance. The example housing and / or its surface may support mechanical connections such as propulsion hardware (e.g., wheels, propellers, etc.) and / or articulation hardware (e.g., robotic arms, pivotable appendages, etc.). In some situations, the sensors may include any type of input device such as user interface hardware (e.g., buttons, switches, dials, sliders, etc.). In some situations, the example housing includes an output device included in, carried by, embedded in, and / or attached to the housing.Output devices may include displays, touch screens, lights, LEDs, speakers, I / O ports (e.g., USB), and the like. In some situations, an edge device is a device that is presented in a network for a specific purpose (e.g., traffic lights), but may have processing and / or other capacity that may be utilized for other purposes. Such an edge device may be independent of other network devices and may have a housing with a form factor suitable for its primary purpose, but may also be utilized for other computational tasks that do not interfere with its primary task. Edge devices include Internet of Things devices. An appliance computing device may include hardware and software components for managing local issues such as device temperature, vibration, resource utilization, updates, power issues, physical and network security, and the like. Exemplary hardware for implementing an appliance computing device is described in connection with FIG. 52B. The edge cloud 4810 may also include one or more servers and / or one or more multi-tenant servers. Such servers may include an operating system and implement a virtual computing environment. The virtual computing environment may include a hypervisor that manages (e.g., creates, deploys, destroys, and the like) one or more virtual machines, one or more containers, and the like. Such a virtual computing environment provides an execution environment in which one or more applications, software, code or scripts may be executed in isolation from one or more other applications, software, code or scripts.

[0485] In FIG. 50, various client endpoints 5010 (in the form of mobile devices, computers, autonomous vehicles, business computing equipment, industrial processing equipment) exchange requests and responses specific to the type of endpoint network aggregation. For example, the client endpoints 5010 may obtain network access via a wired broadband network by exchanging requests and responses 5022 via an on-premise network system 5032. Some client endpoints 5010, such as mobile computing devices, may obtain network access via a wireless broadband network by exchanging requests and responses 5024 via an access point (e.g., a cellular network tower) 5034. Some client endpoints 5010, such as autonomous vehicles, may obtain network access for requests and responses 5026 via a wireless vehicular network through a road-based network system 5036. However, regardless of the type of network access, the TSP may deploy aggregation points 5042, 5044 in the edge cloud 4810 to aggregate traffic and requests. Thus, within the edge cloud 4810, the TSP may deploy various computational and storage resources, for example, in edge aggregation nodes 5040 (including those located in satellite vehicles) to provide the requested content. The edge aggregation nodes 5040 and other systems of the edge cloud 4810 are connected to a cloud or data center 5060 using a backhaul network 5050 (such as a satellite backhaul) to meet the higher latency requirements from the cloud / data center of websites, applications, database servers, etc. Additional or integrated instances of edge aggregation nodes 5040 and aggregation points 5042, 5044, including those deployed in a single server framework, may also exist within the edge cloud 4810 or other areas of the TSP infrastructure.

[0486] At a more general level, an edge computing system may be described as including any number of deployments operating on an edge cloud 4810 that provide collaboration from clients and distributed computing devices. For purposes of explanation, FIG. 49 provides a further abstracted overview of the distributed computing tiers deployed across an edge computing environment.

[0487] 51 generally illustrates an edge computing system for providing edge services and applications to multiple stakeholder entities distributed across multiple tiers of a network, including one or more client compute nodes 5102, one or more edge gateway nodes 5112, one or more edge aggregation nodes 5122, one or more core data centers 5132, and a global network cloud 5142. An implementation of the edge computing system may be provided at or on behalf of a telecommunications service provider ("telco" or "TSP"), an Internet of Things service provider, a cloud service provider (CSP), an enterprise entity, or any other number of entities.

[0488] Each node or device of the edge computing system is located in a particular layer corresponding to layers 4900, 4910, 4920, 4930, 4940. For example, each of the client computing nodes 5102 is located in the endpoint layer 4900, while each of the edge gateway nodes 5112 is located in the edge device layer 4910 (local level) of the edge computing system. In addition, the edge aggregation nodes 5122 (and / or fog devices 5124 when deployed or operated with or among fog network configurations 5126) are located in the network access layer 4920 (middle level). Fog computing (or "fogging") generally refers to the extension of cloud computing to the edge of an enterprise network, usually in a cooperative distributed or multi-node network. Some forms of fog computing provide the deployment of computing, storage and networking services between end devices and cloud computing data centers on behalf of cloud computing locations. Such forms of fog computing provide operations consistent with edge computing described herein. Many aspects of edge computing described herein are applicable to fog networks, fogging, and fog configurations, and aspects of edge computing systems described herein may be configured as fog or fog aspects may be integrated into edge computing architectures.

[0489] The core data center 5132 is located at the core network tier 4930 (e.g., at a regional or geographic central level), while the global network cloud 5142 is located at the cloud data center tier 4940 (e.g., at a national or global tier). The use of "core" is provided as a term to refer to a centralized network location deeper in the network that is accessible from multiple edge nodes or components, but "core" does not necessarily indicate the "center" or innermost part of the network. Thus, the core data center 5132 may be located in, at, or near the edge cloud 4810.

[0490] While FIG. 51 shows an example number of client computing nodes 5102, edge gateway nodes 5112, edge aggregation nodes 5122, core data centers 5132, and global network clouds 5142, it should be appreciated that an edge computing system may include more or fewer devices or systems at each tier. In addition, as shown in FIG. 51, the number of components at each tier 4900, 4910, 4920, 4930, 4940 generally increases with each lower tier (i.e., closer to the endpoints). Thus, one edge gateway node 5112 may serve multiple client computing nodes 5102, and one edge aggregation node 5122 may serve multiple edge gateway nodes 5112.

[0491] Consistent with the examples provided herein, each client computing node 5102 may be embodied as any type of endpoint component, device, appliance, or "thing" capable of communicating as a producer or consumer of data. Additionally, the labels "node" or "device" used in an edge computing system do not necessarily imply that such node or device operates in a client or agent / minion / follower role. Rather, a node or device in an edge computing system refers to an individual entity, node, or subsystem that includes separate or connected hardware or software configurations for facilitating or using the edge cloud 4810.

[0492] As such, the edge cloud 4810 is formed from the network components and functional features operating by and within the edge gateway nodes 5112 and edge aggregation nodes 5122 of layers 4920, 4930, respectively. The edge cloud 4810 may be embodied as any type of network that provides edge computing and / or storage resources located in proximity to radio access network (RAN) enabled endpoint devices (e.g., mobile computing devices, IoT devices, smart devices, etc.), shown in FIG. 49 as client compute nodes 5102. That is, the edge cloud 4810 may be envisioned as an "edge" that connects endpoint devices with traditional mobile network access points that serve as on-ramp to service provider core networks, including carrier networks (e.g., Global System for Mobile Communications (GSM) networks, Long Term Evolution (LTE) networks, 5G networks, etc.), while also providing storage and / or computing capabilities. Other types and forms of network access (e.g., Wi-Fi, long-range wireless networks) may also be utilized in place of or in combination with such 3GPP carrier networks.

[0493] In some examples, the edge cloud 4810 may form part of or provide an entry point to or across a fog networking configuration 5126 (e.g., a network of fog devices 5124, not shown in detail), which may be embodied as a system-level horizontally distributed architecture that distributes resources and services to perform specific functions. For example, a federated and distributed network of fog devices 5124 may perform computing, storage, control, or networking aspects in the context of an IoT system arrangement. There may be other networked, aggregated, and distributed functions present in the edge cloud 4810 between the cloud data center layer 4940 and the client endpoints (e.g., client compute nodes 5102). Some of these are described in the following section in the context of network function or service virtualization, including the use of virtual edges and virtual services coordinated for multiple stakeholders.

[0494] The edge gateway nodes 5112 and edge aggregation nodes 5122 cooperate to provide various edge services and security to the client computing nodes 5102. Additionally, since each client computing node 5102 may be fixed or mobile, each edge gateway node 5112 may cooperate with other edge gateway devices to propagate currently provided edge services and security as the corresponding client computing node 5102 moves within the domain. To accomplish this, each of the edge gateway nodes 5112 and / or edge aggregation nodes 5122 may support multi-tenant and multi-stakeholder configurations where services from (or hosted by) multiple service providers and multiple consumers may be supported and coordinated across a single or multiple computing devices.

[0495] In a further example, any of the computing nodes or devices described with reference to the present computing systems and environments may be implemented based on the components illustrated in Figures 52A and 52B. Each computing node may be embodied as a type of device, appliance, computer, or other "thing" capable of communicating with other edge, networking, or endpoint components.

[0496] In the simplified example shown in FIG. 52A, an edge computing node 5200 includes a computational engine (also referred to herein as "computational circuitry") 5202, an input / output (I / O) subsystem 5208, data storage 5210, a communication circuitry subsystem 5212, and optionally one or more peripheral devices 5214. In other examples, each computing device may include other or additional components (e.g., displays, peripherals, etc.), such as those used in personal or server computing systems. Additionally, in some examples, one or more of the illustrated components may be incorporated into or form part of another component.

[0497] The computational node 5200 may be embodied as any type of engine, device, or collection of devices capable of performing various computational functions. In some examples, the computational node 5200 may be embodied as a single device, such as an integrated circuit, embedded system, field programmable gate array (FPGA), system on chip (SOC), or other integrated system or device. In an illustrative example, the computational node 5200 includes or is embodied as a processor 5204 and memory 5206. The processor 5204 may be embodied as any type of processor capable of performing the functions described herein (e.g., executing an application). For example, the processor 5204 may be embodied as a multi-core processor, a microcontroller, or other processor or processing / control circuitry. In some examples, the processor 5204 may be embodied as, include, or be coupled to an FPGA, an application specific integrated circuit (ASIC), reconfigurable hardware or hardware circuitry, or other specialized hardware that facilitates performance of the functions described herein.

[0498] The main memory 5206 may be embodied as any type of volatile (e.g., dynamic random access memory (DRAM), etc.) or non-volatile memory or data storage capable of performing the functions described herein. Volatile memory may be a storage medium that requires power to maintain the state of data stored by the medium. Non-limiting examples of volatile memory may include various types of random access memory (RAM), such as DRAM or static random access memory (SRAM). One particular type of DRAM that may be used in the memory module is synchronous dynamic random access memory (SDRAM).

[0499] In one example, the memory device is a block addressable memory device, such as one based on NAND or NOR technology. The memory device may be a three dimensional cross point memory device (e.g., Intel 3D XPoint TMThe memory device may include a 3D cross-point memory (e.g., Intel 3D XPoint memory, other storage class memory) or other byte-addressable write-in-place non-volatile memory device. The memory device may refer to the die itself and / or the packaged memory product. In some examples, the 3D cross-point memory (e.g., Intel 3D XPoint memory, other storage class memory) or other byte-addressable write-in-place non-volatile memory device. TM The main memory 5206 may include a transistor-free, stackable, cross-point architecture in which memory cells are located at the intersections of word lines and bit lines and are individually addressable, with bit storage based on changes in bulk resistance. In some examples, all or a portion of the main memory 5206 may be integrated into the processor 5204. The main memory 5206 may store various software and data used during operation, such as one or more applications, data manipulated by the applications, libraries, and drivers.

[0500] The computing circuit 5202 is communicatively coupled to other components of the computing node 5200 via an I / O subsystem 5208, which may be embodied as circuits and / or components for facilitating input / output operations with the computing circuit 5202 (e.g., the processor 5204 and / or the main memory 5206) and other components of the computing circuit 5202. For example, the I / O subsystem 5208 may be embodied as or otherwise include a memory controller hub, an input / output control hub, an integrated sensor hub, firmware devices, communications links (e.g., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and / or other components and subsystems for facilitating input / output operations. In some examples, the I / O subsystem 5208 may form part of a system-on-chip (SoC) and be integrated into the computing circuit 5202 along with one or more of the processor 5204, the main memory 5206, and other components of the computing circuit 5202.

[0501] The one or more example data storage devices 5210 may be embodied as any type of device configured for short-term or long-term storage of data, such as, for example, memory devices and circuitry, memory cards, hard disk drives, solid state drives, or other data storage devices. Each data storage device 5210 may include a system partition that stores data and firmware code for the data storage device 5210. Each data storage device 5210 may also include one or more operating system partitions that store data files and executable files for the operating system, depending on, for example, the type of compute node 5200.

[0502] The communications circuitry 5212 may be embodied as any communications circuit, device, or collection thereof that enables communications over a network between the computing circuitry 5202 and another computing device (e.g., an edge gateway node 5112 of an edge computing system). The communications circuitry 5212 may be configured to use any one or more communications technologies (e.g., wired or wireless communications) and associated protocols (e.g., cellular networking protocols such as 3GPP's 4G or 5G standards, wireless local area network protocols such as IEEE 802.11 / Wi-Fi®, wireless wide area network protocols, Ethernet, Bluetooth®, etc.) to effectuate such communications.

[0503] The exemplary communications circuitry 5212 includes a network interface controller (NIC) 5220, which may also be referred to as a host fabric interface (HFI). The NIC 5220 may be embodied as one or more add-in boards, daughter cards, network interface cards, controller chips, chipsets, or other devices that may be used by the compute node 5200 to connect with another computing device (e.g., the edge gateway node 5112). In some examples, the NIC 5220 may be embodied as part of a system-on-chip (SoC) that includes one or more processors or may be included in a multi-chip package that includes one or more processors. In some examples, the NIC 5220 may include a local processor (not shown) and / or local memory (not shown) local to the NIC 5220. In such examples, the local processor of the NIC 5220 may be capable of performing one or more of the functions of the compute circuitry 5202 described herein. Additionally or alternatively, in such examples, the local memory of the NIC 5220 may be integrated into one or more components of the client compute node at the board level, socket level, chip level, and / or other levels.

[0504] Additionally, in some examples, each computing node 5200 may include one or more peripherals 5214. Such peripherals 5214 may include any type of peripheral found on a computing device or server, such as audio input devices, displays, other input / output devices, interface devices, and / or other peripherals, depending on the particular type of computing node 5200. In further examples, the computing nodes 5200 may be embodied by an edge computing system (e.g., client computing node 5102, edge gateway node 5112, edge aggregation node 5122) or a respective edge computing node in the form of an appliance, computer, subsystem, circuit, or other component.

[0505] In a more detailed example, FIG. 52B illustrates a block diagram of example components that may be present in an edge computing node 5250 to implement the techniques (e.g., operations, processes, methods, and methodologies, etc.) described herein. The edge computing node 5250 may include any combination of the components mentioned above and may include any device usable in an edge communication network or combination of such networks. The components may be implemented as ICs adapted in the edge computing node 5250, parts thereof, separate electronic devices or other modules, logic, hardware, software, firmware, or combinations thereof, or as components embedded within the chassis of a larger system. Also, to support the security examples provided herein, a hardware RoT (e.g., provided according to the DICE architecture) may be implemented in each IP block of the edge computing node 5250 such that any IP block can be booted in a mode that allows it to generate a RoT ID that can prove its identity and its currently booted firmware to another IP block or an external entity.

[0506] The edge computing node 5250 may include processing circuitry in the form of a processor 5252, which may be a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, or other known processing element. The processor 5252 may be part of a system-on-chip (SoC) in which the processor 5252 and other components are formed on a single integrated circuit, or may be part of an Edison SoC manufactured by Intel Corporation of Santa Clara, Calif. TM or GaliLEO TM The processor 5252 may be a single package such as a SoC board. TM , Atom TM , Xeon TM Intel® Architecture Core™, such as i3, i5, i7, i9 or MCU class processors TMThe processor may include an Intel®-based processor or another such processor available from Intel®. However, any number of other processors may be used, such as those available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, Calif., MIPS-based designs available from MIPS Technologies, Inc. of Sunnyvale, Calif., ARM-based designs licensed from ARM Holdings, Inc. or its customers or their licensors or adopters. Processors may include the A5-A13 processors from Apple®, the Snapdragon from Qualcomm® Technologies, Inc. TM Processor: Texas Instruments OMAP TM It may include units such as a processor.

[0507] The processor 5252 may communicate with the system memory 5254 via an interconnect 5256 (e.g., a bus). Any number of memory devices may be used to provide a given amount of system memory. As one example, the memory may be random access memory (RAM) according to a Joint Electron Devices Committee (JEDEC) design, such as a DDR or mobile DDR standard (e.g., LPDDR, LPDDR2, LPDDR3, LPDDR4). In a particular example, the memory components may conform to DRAM standards promulgated by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for low power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR4. Such standards (and similar standards) may be referred to as DDR-based standards, and the communication interface of a storage device implementing such standards may be referred to as a DDR-based interface. In various implementations, the individual memory devices may be in any number of different package types, such as a single die package (SDP), a dual die package (DDP), or a quad die package (Q17P). In some examples, these devices may be soldered directly to a motherboard to provide a low-profile solution, while in other examples, the devices are configured as one or more memory modules and coupled to the motherboard by a predefined connector. Any number of other memory implementations may be used, such as other types of memory modules, for example, different types of dual in-line memory modules (DIMMs), including, but not limited to, micro-DIMMs or mini-DIMMs.

[0508] Storage 5258 may be coupled to processor 5252 via interconnect 5256 to provide persistent storage of information, such as data, applications, the operating system, etc. In one example, storage 5258 may be implemented via a solid-state disk drive (SSDD). Other devices that may be used for storage 5258 include flash memory cards, such as SD cards, micro SD cards, XD picture cards, and USB flash drives. In one example, the memory device may be or may include a memory device using chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), antiferroelectric memory, magnetoresistive random access memory (MRAM) memory incorporating memristor technology, resistive memory including metal oxide based, oxygen vacancy based and conductive bridge random access memory (CB-RAM) or spin transfer torque (STT)-MRAM, spintronic magnetic junction memory based devices, magnetic tunnel junction (MTJ) based devices, DW (domain wall) and SOT (spin orbit transfer) based devices, thyristor based memory devices or any combination of the above or other memories.

[0509] In low power implementations, storage 5258 may be on-die memory or registers associated with processor 5252. However, in some examples, storage 5258 may be implemented using a micro hard disk drive (HDD). Also, storage 5258 may use any number of new technologies in addition to or instead of the technologies described, such as resistive memory, phase change memory, holographic memory, or chemical memory, among others.

[0510] The components may communicate through an interconnect 5256. The interconnect 5256 may include an Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), NVLink, or any number of other technologies. The interconnect 5256 may be a proprietary bus used in SoC-based systems, for example. Other bus systems may be included, such as an I2C interface, an SPI interface, a point-to-point interface, a power bus, among others.

[0511] The interconnect 5256 may couple the processor 5252 to a transceiver 5266 for communicating with connected edge devices 5262. The transceiver 5266 may use any number of frequencies and protocols, such as 2.4 gigahertz (GHz) transmissions based on the IEEE 802.15.4 standard, in particular using the Bluetooth Low Energy (BLE) standard defined by the Bluetooth SIG or the ZigBee standard. The connection to the connected edge devices 5262 may use any number of radios configured for a particular wireless communication protocol. For example, Wi-Fi communication may be implemented according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard using a wireless local area network (WLAN) unit. In addition, wireless wide area communication, for example according to cellular or other wireless wide area protocols, may occur via a wireless wide area network (WWAN) unit.

[0512] The wireless network transceiver 5266 (or multiple transceivers) may communicate using multiple standards or radios for communication at different ranges. For example, the edge computing node 5250 may communicate with nearby devices, for example within about 10 meters, using a local transceiver based on BLE or another low power radio to conserve power. Connected edge devices 5262 that are farther away, for example within about 50 meters, may be reached via ZigBee or other medium power radio. Both communication techniques may be done via a single radio at different power levels or via separate transceivers, for example a local transceiver using BLE and another mesh transceiver using ZigBee.

[0513] A wireless network transceiver 5266 (e.g., a radio transceiver) may be included to communicate with devices or services in the edge cloud 5290 via local or wide area network protocols. The wireless network transceiver 5266 may be an LPWA transceiver conforming to the IEEE 802.15.4 or IEEE 802.15.4g standards, among others. The edge computing node 5250 may be a LoRaWAN transceiver conforming to the LoRa standard developed by Semtech and the LoRa Alliance. TM (Long Range Wide Area Network). The techniques described herein are not limited to these techniques and may be used with any number of other cloud transceivers implementing long distance, low bandwidth communications, such as Sigfox or other techniques. Other communication techniques may also be used, such as time slotted channel hopping as described in the IEEE 802.15.4e specification.

[0514] In addition to the systems mentioned for the wireless network transceiver 5266 as described herein, any number of other wireless communications and protocols may be used. For example, the transceiver 5266 may include a cellular transceiver using spread spectrum (SPA / SAS) communications to perform high speed communications. Also, any number of other protocols may be used, such as a Wi-Fi network, to provide medium speed and network communications. The transceiver 5266 may include radios compatible with any number of 3GPP (3rd Generation Partnership Project) specifications, such as Long Term Evolution (LTE) and 5th Generation (5G) communications systems, which are described in more detail at the end of this disclosure. A network interface controller (NIC) 5268 may be included to provide wired communications to other devices, such as nodes of the edge cloud 5290 or connected edge devices 5262 (e.g., operating in a mesh). The wired communication may provide an Ethernet connection or may be based on other types of networks such as a Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS or PROFINET Direct, among others. To enable connection to a second network, additional NICs 5268 may be included, for example a first NIC 5268 providing communication to the cloud via Ethernet and a second NIC 5268 providing communication to other devices via another type of network.

[0515] Considering various types of applicable communications from the device to another component or network, applicable communications circuitry used by the device may include or be embodied by any one or more of components 5264, 5266, 5268, or 5270. Thus, in various examples, applicable means for communicating (e.g., receiving, transmitting, etc.) may be embodied by such communications circuitry.

[0516] The edge computing node 5250 may include or be coupled to acceleration circuitry 5264, which may be embodied by one or more AI accelerators, neural compute sticks, neuromorphic hardware, FPGAs, an arrangement of GPUs, one or more SoCs, one or more CPUs, one or more digital signal processors, dedicated ASICs, or other forms of specialized processors or circuits designed to accomplish one or more specialized tasks. These tasks may include AI processing (including machine learning, training, inference, and classification operations), vision data processing, network data processing, object detection, rules analysis, etc. Thus, in various examples, the applicable acceleration means may be embodied by such acceleration circuitry.

[0517] The interconnect 5256 may link the processor 5252 to a sensor hub or external interface 5270 used to connect additional devices or subsystems. The devices may include sensors 5272, such as accelerometers, level sensors, flow sensors, light sensors, camera sensors, temperature sensors, Global Positioning System (GPS) sensors, pressure sensors, barometric pressure sensors, etc. The hub or interface 5270 may be used to connect the edge computing node 5250 to actuators 5274, such as power switches, valve actuators, sound generators, visual warning devices, etc.

[0518] In some optional examples, various input / output (I / O) devices may be present in or connected to the edge computing node 5250. For example, a display or other output device 5284 may be included to show information such as sensor readings or actuator positions. An input device 5286 such as a touch screen or keypad may be included to accept input. The output device 5284 may include any number of forms of audio or visual indication, including simple visual outputs such as binary status indicators (e.g., LEDs) and visual outputs of multiple characters or more complex outputs such as a display screen (e.g., LCD screen) where output such as text, graphics, multimedia objects, etc. are generated or created from the operation of the edge computing node 5250.

[0519] The battery 5276 may power the edge computing node 5250, or in instances where the edge computing node 5250 is mounted in a fixed location, may have a power source tied to a power grid. The battery 5276 may be a lithium ion battery or may be a metal air battery, such as a zinc air battery, an aluminum air battery, a lithium air battery, etc.

[0520] A battery monitor / charger 5278 may be included in the edge computing node 5250 to track the state of charge (SoCh) of the battery 5276. The battery monitor / charger 5278 may be used to monitor other parameters of the battery 5276 to provide failure predictions such as state of health (SoH) and state of function (SoF) of the battery 5276. The battery monitor / charger 5278 may include a battery monitoring integrated circuit such as the LTC4020 or LTC2990 from Linear Technologies, Inc., the ADT7488A from ON Semiconductor, Phoenix, Arizona, or an IC from the UCD90xxx family from Texas Instruments, Dallas, Texas. The battery monitor / charger 5278 may communicate battery 5276 information to the processor 5252 via the interconnect 5256. The battery monitor / charger 5278 may also include an analog-to-digital (ADC) converter that allows the processor 5252 to directly monitor the voltage of the battery 5276 or the current flow from the battery 5276. The battery parameters may be used to determine actions that the edge computing node 5250 may take, such as transmission frequency, mesh network operation, sensing frequency, etc.

[0521] A power block 5280 or other power source coupled to the grid may be coupled to a battery monitor / charger 5278 to charge the battery 5276. In some examples, the power block 5280 may be replaced with a wireless power receiver to receive power wirelessly, for example, via a loop antenna of the edge computing node 5250. The battery monitor / charger 5278 may include, among other things, a wireless battery charging circuit such as an LTC4020 chip manufactured by Linear Technologies, Inc., Milpitas, Calif. The particular charging circuit may be selected based on the size of the battery 5276, and thus the current required. Charging may be performed using, among other things, the AirFuel standard promulgated by the AirFuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power.

[0522] Storage 5258 may include instructions 5282 in the format of software, firmware, or hardware commands for implementing the techniques described herein. Such instructions 5282 are illustrated as code blocks contained in memory 5254 and storage 5258, although any of the code blocks may be implemented in, for example, an application specific integrated circuit (ACI). It will be appreciated that the present invention may be substituted with hard-wired circuitry, such as that incorporated in an ASIC.

[0523] In one example, the instructions 5282 provided via the memory 5254, storage 5258, or processor 5252 may be embodied as a non-transitory machine-readable medium 5260 including code that instructs the processor 5252 to perform electronic operations at the edge computing node 5250. The processor 5252 may access the non-transitory machine-readable medium 5260 via the interconnect 5256. For example, the non-transitory machine-readable medium 5260 may be embodied by a device described for the storage 5258 or may include a specific storage unit such as an optical disk, a flash drive, or any number of other hardware devices. The non-transitory machine-readable medium 5260 may include instructions that instruct the processor 5252 to perform a particular sequence or flow of operations, such as those described with respect to the flowcharts and block diagrams of the operations and functions described above. As used herein, the term "machine-readable medium" is synonymous with "computer-readable medium."

[0524] In a further example, a machine-readable medium may also include tangible media capable of storing, encoding, or carrying instructions that are executed by a machine and cause the machine to perform any one or more of the methodologies of the present disclosure, or data structures used by or associated with such instructions. Thus, a "machine-readable medium" may include, but is not limited to, solid-state memory, optical, and magnetic media. Specific examples of machine-readable media include, by way of example and not limitation, non-volatile memory including semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. Instructions embodied by a machine-readable medium may further be transmitted and received over a communications network using a transmission medium via a network interface device utilizing any one of a number of transfer protocols (e.g., HTTP).

[0525] The machine-readable medium may be provided by a storage device or other apparatus capable of hosting data in a non-transitory format. In one example, information stored or otherwise provided on the machine-readable medium may represent instructions, such as the instructions themselves or a format from which the instructions are derived. This format from which the instructions are derived may include source code (e.g., in a compressed or encrypted format), encoded instructions, packaged instructions (e.g., divided into multiple packages), and the like. The information representing the instructions in the machine-readable medium may be processed by a processing circuit to process into instructions to perform any of the operations described herein. For example, deriving instructions from information (e.g., by processing by a processing circuit) may include compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamic or static linking), encoding, decoding, encrypting, decrypting, packaging, unpackaging, or manipulating the information into instructions.

[0526] In one example, deriving the instructions may include assembling, compiling, or interpreting the information (e.g., by a processing circuit) to create the instructions from an intermediate or pre-processed form provided by a machine-readable medium. If the information is provided in multiple parts, it may be combined, expanded, and modified to create the instructions. For example, the information may be in multiple compressed source code packages (or object code, binary executable code, etc.) on one or more remote servers. The source code packages may be encrypted when transferred over a network, decrypted, decompressed, assembled (e.g., linked), compiled or interpreted on the local machine (e.g., into a library, a standalone executable, etc.), and executed by the local machine.

[0527] Each block diagram of Figures 52A and 52B is intended to illustrate a high-level view of components of a device, subsystem, or arrangement of an edge computing node, however, it will be understood that some of the illustrated components may be omitted, additional components may be present, or different arrangements of the illustrated components may occur in other implementations.

[0528] FIG. 5310 illustrates an example software distribution platform 5305 that distributes software, such as the example computer readable instructions 5282 of FIG. 52B, to one or more devices, such as the example processor platform 5310 and / or other example connected edge devices or systems described herein. The example software distribution platform 5305 may be implemented by any computer server, data facility, cloud service, etc. that can store and transmit software to other computing devices. The example connected edge devices may be customers, clients, management devices (e.g., servers), third parties (e.g., customers of an entity that owns and / or operates the software distribution platform 5305), etc. The example connected edge devices may operate in commercial and / or home automation environments. In some examples, the third parties are developers, sellers, and / or licensors of software, such as the computer readable instructions 5282 of FIG. 52B. The third parties may be consumers, users, retailers, OEMs, etc. that purchase and / or license the software for use and / or resale and / or sublicense. In some examples, the distributed software causes the display of one or more user interfaces (UIs) and / or graphical user interfaces (GUIs) to identify one or more devices (e.g., connected edge devices) that are geographically and / or logically separated from one another (e.g., physically separated IoT devices responsible for water distribution control (e.g., pumps), power distribution control (e.g., relays), etc.).

[0529] In the illustrated example of FIG. 53, the software distribution platform 5305 includes one or more servers and one or more storage devices that store computer readable instructions 5282. The one or more servers of the example software distribution platform 5305 communicate with a network 5315, which may correspond to the Internet and / or one or more of any of the example networks described above. In some examples, the one or more servers respond to requests to transmit software to a requester as part of a commercial transaction. Payment for distribution, sale, and / or license of the software may be handled by one or more servers of the software distribution platform and / or through a third party payment entity. These servers enable purchasers and / or licensors to download the computer readable instructions 5282 from the software distribution platform 5305. For example, software corresponding to the example computer readable instructions may be downloaded to an example processor platform that executes the computer readable instructions 5282. In some examples, the one or more servers of the software distribution platform 5305 are communicatively connected to one or more security domains and / or security devices through which transmissions and requests of the example computer readable instructions 5282 must pass. In some examples, one or more servers of the software distribution platform 5305 periodically provide, transmit, and / or force updates to the software (e.g., the example computer-readable instructions 5282 of FIG. 52B) so that improvements, patches, updates, etc. are distributed and applied to the software on end-user devices.

[0530] In the example illustrated in FIG. 53, the computer readable instructions 5282 are stored in a particular format in a storage device of the software distribution platform 5305. The format of the computer readable instructions includes, but is not limited to, a particular code language (e.g., Java, JavaScript, Python, C, C#, SQL, HTML, etc.) and / or a particular code state (e.g., non-compiled code (e.g., ASCII), interpreted code, link code, executable code (e.g., binary), etc.). In some examples, the computer readable instructions 5282 stored in the software distribution platform 5305 are in a first format when transmitted to the example processor platform 5310. In some examples, the first format is an executable binary executable by a particular type of processor platform 5310. However, in some examples, the first format is non-compiled code that requires one or more preparatory tasks to convert from the first format to a second format to enable execution on the example processor platform 5310. For example, the receiving processor platform 5300 may need to compile the computer readable instructions 5282 in a first format to generate executable code in a second format that is executable on the processor platform 5310. In yet another example, the first format is interpretive code that, upon reaching the processor platform 5310, is interpreted by an interpreter to facilitate execution of the instructions.

[0531] Additional implementation examples and notes

[0532] An example implementation is a method performed by an edge computing node, the edge computing node being connected to a satellite communications network, the method including receiving a request for a computational process from an endpoint device; identifying a location for the computational process, the location being selected from among computational resources provided locally at the edge computing node or computational resources provided at a remote service accessible via the satellite network; and causing use of the computational process at the identified location in accordance with service requirements for the computational process, the satellite network being intermittently available, and usage of the computational process being coordinated based on availability of the satellite network.

[0533] A further example implementation is a method performed by the edge computing node, wherein the satellite network is a low Earth orbit (LEO) satellite network providing coverage to the edge computing node from among a plurality of satellite vehicles based on the orbital positions of the satellite vehicles.

[0534] A further example implementation is a method performed by the edge computing node, wherein the LEO satellite network includes a plurality of constellations, each of the plurality of constellations providing a respective plurality of satellite vehicles, and network coverage to the edge computing node is based on a location of the plurality of constellations.

[0535] A further example implementation is a method performed by the edge computing node, the edge computing node being provided in a base station, the base station providing wireless network connectivity to the endpoint device.

[0536] A further example implementation is a method performed by the edge computing node, wherein the wireless network connection is provided by a 4G Long Term Evolution (LTE) or 5G network operating in accordance with 3GPP standards or a RAN operating in accordance with O-RAN Alliance standards.

[0537] A further example implementation is a method performed by the edge computing node, where a location for the computation is identified based on a delay in communication through the satellite network and a time for processing on the computational resource.

[0538] A further example implementation is a method performed by the edge computing node, where a location for the computation is identified based on a service level agreement associated with a request for the computation.

[0539] A further example implementation is a method performed by the edge computing node, where a location for the computation is identified based on instructions from a network orchestrator, which provides orchestration of multiple edge computing locations including the edge computing node.

[0540] A further example implementation is a method performed by the edge computing node, comprising returning results of the computational processing to the endpoint device, the computational processing comprising processing a workload.

[0541] A further example implementation is a method performed by the edge computing node, where the location for the computational processing is identified based on (i) the type of workload and (ii) the availability of the computational resources at the edge computing node for locally processing the type of workload.

[0542] Another example implementation is a method performed by an endpoint client device, the endpoint client device capable of network connectivity with a first satellite network and a second terrestrial network, the method including identifying a workload for computational processing; determining a location for the computational processing of the workload, the location being selected from among computational resources provided at an edge computing node accessible via the second terrestrial network or computational resources provided at a remote service accessible via the first satellite network; and communicating the workload to the identified location, wherein network connectivity with the satellite network is provided intermittently based on availability of the satellite network.

[0543] A further example implementation is a method performed by the endpoint client device, wherein the satellite network is a low Earth orbit (LEO) satellite network that provides coverage to the endpoint client device based on the orbital positions of the satellite vehicles from among a plurality of satellite vehicles.

[0544] A further example implementation is a method performed by the endpoint client device, wherein the LEO satellite network includes a plurality of constellations, each of the plurality of constellations providing a respective plurality of satellite vehicles, and network coverage to the endpoint client device is based on a location of the plurality of constellations.

[0545] A further example implementation is a method performed by the endpoint client device, wherein the edge computing node is provided at a base station of the second terrestrial network, the base station providing a wireless network connection to the endpoint client device.

[0546] A further exemplary implementation is a method performed by the endpoint client device, wherein the wireless network connection is provided by a 4G Long Term Evolution (LTE) or 5G network operating in accordance with 3GPP standards or a RAN operating in accordance with O-RAN Alliance standards.

[0547] A further example implementation is a method performed by the endpoint client device, where a location for the computational processing is determined based on a delay in communication through the first satellite network and a time for processing on the computational resource.

[0548] A further example implementation is a method performed by the endpoint client device, where a location for the computing process is identified based on a service level agreement associated with the workload.

[0549] A further example implementation is a method performed by the endpoint client device, where a location for the computation is identified based on instructions from a network orchestrator, which provides orchestration of multiple edge computing locations including the edge computing node.

[0550] A further example implementation is a method performed by the endpoint client device that includes receiving results of computation of the workload.

[0551] A further example implementation is a method performed by the endpoint client device, wherein the location for the computational processing is identified based on (i) the type of workload and (ii) the availability of the computational resources at the edge computing node for locally processing the type of workload.

[0552] An example implementation is an edge computing system provided via a low Earth orbit satellite connection that includes respective edge processing devices and nodes for invoking or performing operations of examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0553] Another example implementation is a client endpoint node operable to invoke or perform the operations of examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein using a low Earth orbit satellite connection or directly or via another wireless network.

[0554] Another example implementation is an aggregation node, network hub node, gateway node or core data processing node communicating via a low Earth orbit satellite connection and located or coupled within an edge computing system and operable to invoke or perform operations of examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13 or other subject matter described herein.

[0555] Another example implementation is an access point, base station, roadside unit, wayside unit or premise unit communicating via a low earth orbit satellite connection and located or coupled within an edge computing system and operable to invoke or perform operations of Examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0556] Another example implementation is an edge node accessible via a low Earth orbit satellite connection, operating as an edge provisioning node, application orchestration node, or multi-tenant management node, located or coupled within an edge computing system and operable to invoke or perform operations of Examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0557] Another example implementation is an edge node accessible via a low Earth orbit satellite connection, operating as an edge provisioning node, application or service orchestration node, virtual machine deployment, container deployment, function deployment and computation management, located or coupled within an edge computing system, and operable to invoke or perform operations of Examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0558] Another example implementation is an edge computing system provided via a low Earth orbit satellite connection, including aspects of network functionality, acceleration functionality, acceleration hardware, storage hardware, or computational hardware resources, operable to invoke or perform use cases described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0559] Another example implementation is an edge computing system provided via a low Earth orbit satellite connection adapted to support client mobility, vehicle-to-vehicle (V2V), vehicle-to-everything (V2X) or vehicle-to-infrastructure (V2I) scenarios, optionally operating in accordance with ETSI MEC standards, and operable to invoke or perform use cases described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0560] Another example implementation is an edge computing system provided via a low Earth orbit satellite connection, coupled to equipment providing mobile wireless communications in accordance with 3GPP 4G / LTE or 5G network capabilities, and operable to invoke or perform the use cases described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0561] Another example implementation is an edge computing system provided via a low Earth orbit satellite connection, coupled to equipment providing mobile wireless communications in accordance with O-RAN alliance network capabilities, and operable to invoke or perform the use cases described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0562] Another example implementation is an edge computing node operable at a layer of an edge computing network or edge computing system provided via a low earth orbit satellite connection, the edge computing node operable as an aggregation node, network hub node, gateway node or core data processing node, operable at a close edge, local edge, enterprise edge, on-premise edge, near edge, middle edge or far edge network layer or a set of nodes having common delay, timing or distance characteristics, and operable to invoke or perform the use cases described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13 or other subject matter described herein.

[0563] Another example implementation is networking hardware, acceleration hardware, storage hardware or computation hardware in which functions are implemented that is operable in an edge computing system provided via a low Earth orbit satellite connection and is operable to invoke or perform the use cases described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13 or other subject matter described herein.

[0564] Another example implementation is an apparatus for an edge computing system provided via a low Earth orbit satellite connection, including one or more processors and one or more computer-readable media containing instructions that, when executed by the one or more processors, cause the one or more processors to invoke or perform a use case described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0565] Another example implementation is one or more computer-readable storage media operable in an edge computing system provided via a low Earth orbit satellite connection, the computer-readable storage media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to invoke or perform a use case described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0566] Another example implementation is an apparatus for an edge computing system provided via a low Earth orbit satellite connection that includes means, logic, modules, or circuitry for invoking or performing the use cases described herein using examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0567] Another example implementation is an edge computing system provided via a low Earth orbit satellite connection and configured to perform use cases provided by one or more of computational offloading, data caching, video processing, network function visualization, radio access network management, augmented reality, virtual reality, industrial automation, retail services, manufacturing operations, smart buildings, energy management, autonomous driving, vehicle assistance, vehicle communications, Internet of Things, object detection, voice recognition, healthcare applications, gaming applications, or accelerated content processing using Examples A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, or other subject matter described herein.

[0568] In the above examples, reference has been made extensively to low earth orbit (LEO) satellites and constellations. However, it will be appreciated that the above examples also relate to many forms of medium earth orbit satellites and constellations, geostationary orbit satellites and constellations, and other high altitude communication platforms such as balloons. Thus, it will be appreciated that the techniques described for a LEO network configuration are also applicable to many other network configurations.

[0569] Although these implementations have been described with reference to certain exemplary aspects, it will be apparent that various modifications and changes may be made thereto without departing from the broader scope of the present disclosure. Many of the arrangements and processes described herein can be used in combination or parallel implementations, including terrestrial network connections (where available), to increase network bandwidth / throughput and support additional edge services. Accordingly, the specification and drawings are to be considered in an illustrative and not a limiting sense. The accompanying drawings, which form a part hereof, show by way of example, and not by way of limitation, specific aspects in which the subject matter may be practiced. The illustrated aspects are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived, such that structural and logical substitutions and changes can be made without departing from the scope of the present disclosure. Accordingly, this detailed description is not to be taken in a limiting sense, and the scope of the various aspects is defined only by the appended claims, along with the full scope of equivalents to which such claims are entitled.

[0570] Such aspects of the inventive subject matter may be referred to individually and / or collectively, where more than one aspect is actually disclosed, for convenience only, without any intention to limit the scope of the present application to any single aspect or inventive concept. Thus, although specific aspects have been illustrated and described herein, it should be recognized that any arrangement calculated to achieve the same purpose may be substituted for the specific aspects shown. The present disclosure is intended to cover any adaptations or variations of the various aspects. Combinations of the above aspects with other aspects not described herein will be apparent to one of skill in the art upon reviewing the above description.

Claims

1. 1. A method, performed on a computing system, for establishing a managed data stream connection using a satellite communications network, comprising: identifying a plurality of data streams running between the computing system and a plurality of endpoints over the satellite communications network; grouping the set of data streams into an endpoint virtual channel (EPVC), the grouping being based on a respective endpoint of the plurality of endpoints; mapping each data stream of the EPVC to a Stream Virtual Channel (SVC) based on a service type associated with the each data stream; determining changes to be applied to each of the data streams of the EPVC based on service requirements and telemetry associated with each of the data streams; applying the identified changes to each of the data streams based on a type of service associated with each of the data streams; and Including, The method, wherein the changes to be applied to the respective data streams include moving at least one of the SVCs from a first EPVC to a second EPVC to change the use of at least one service from a first endpoint to a second endpoint.

2. The method of claim 1 , wherein the service requirements include quality of service (QoS) requirements.

3. The method of claim 1 , wherein the service requirements include compliance with at least one service level agreement (SLA).

4. The method of claim 1 , wherein the plurality of endpoints comprises respective cloud data processing systems accessible via the satellite communications network.

5. The method of claim 1 , wherein the telemetry includes delay information identifiable based on the EPVCs and the SVCs.

6. The method of claim 1 , wherein identifying changes to apply to each of the data streams is based on connection conditions associated with the satellite communications network.

7. The method of claim 1 , wherein the changes to be applied to each data stream include changes to at least one of delay, bandwidth, service capabilities, power requirements, resource availability, load balancing, or security features.

8. The method comprises: collecting said service requirements associated with each of said data streams; collecting the telemetry associated with each of the data streams; The method of claim 1 further comprising:

9. The method of claim 1, wherein applying the identified changes to the respective data streams includes applying QoS and resource balancing across the respective data streams.

10. The method of claim 1, wherein applying the identified changes to the respective data streams includes applying load balancing to manage bandwidth across the respective data streams.

11. The method comprises: providing feedback to a software stack of the computing system in response to identifying changes to be applied to the respective data streams; The method of claim 1 further comprising:

12. The method comprises: adjusting, based on the feedback, within the software stack, usage of at least one resource associated with a corresponding service; The method of claim 11 further comprising:

13. The method of claim 1 , wherein the mapping of the respective data streams of the EPVC to the SVCs is further based on an identification of a tenant associated with the respective data stream.

14. The method comprises: increasing or decreasing resources associated with at least one SVC based on said determining; The method of claim 13 further comprising:

15. The method of claim 1 , wherein the respective data streams are established between a client device and the plurality of endpoints for obtaining content from any of the plurality of endpoints.

16. 16. The method of claim 15, wherein the computing system provides a content distribution service, and the content is retrieved from among the plurality of endpoints using the satellite communications network in response to a cache miss at the content distribution service.

17. The method of claim 1 , wherein the respective data streams are established between a client device and the multiple endpoints for performing computational operations at the multiple endpoints.

18. 20. The method of claim 17, wherein the computing system is further configured to provide a radio access network (RAN) to the client device with virtual network capabilities.

19. 20. The method of claim 18, wherein the radio access network is provided in accordance with a standard from the 3GPP 5G or O-RAN Alliance family of standards.

20. The method of claim 18 , wherein the computing system is hosted at a base station for the RAN.

21. 21. The method of any one of claims 1 to 20, wherein the satellite communications network is a Low Earth Orbit (LEO) satellite communications network including a plurality of satellites in at least one constellation.

22. 21. The method of claim 1, wherein the satellite communications network is used as a backhaul network between the computing system and the plurality of endpoints, and the computing system includes a base station, access point, gateway or aggregation point that provides a network platform as a relay between client devices and the satellite communications network to access the plurality of endpoints.

23. A processing circuit; a memory device containing instructions; An apparatus comprising:

23. Apparatus, the instructions embodied on the memory device, the instructions, when executed by the processing circuitry, configuring the processing circuitry to perform the method of any one of claims 1 to 22.

24. 23. A machine-readable storage medium containing instructions which, when executed by a processing circuitry of a machine, cause the processing circuitry to perform a method according to any one of claims 1 to 22.

Images