Method, system, kit and apparatus for providing end-to-end secure dedicated fifth generation telecommunications

Abstract

To provide a method and a system for enabling a fifth generation (5G) communication network and a computing platform to provide secure and private end-to-end communication.SOLUTION: The method includes software defined networking (SDN) decoupling a dataplane from a control plane of a 5G network, executing the decoupled control plane across a low earth orbit (LEO) system between edge networks and core networks of the 5G network such that the LEO system exclusively directs or uses the control plane, and determining and generating, by the LEO system exclusively using the control plane, routes for the dataplane.SELECTED DRAWING: Figure 23

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 888,742, filed August 19, 2019, and U.S. Provisional Patent Application No. 62 / 937,601, filed November 19, 2019. Each of the above applications is incorporated herein by reference in its entirety as if fully set forth herein.

[0002] The present disclosure relates to methods and systems for enabling fifth generation (5G) communication networks and computing platforms to provide secure and dedicated end-to-end communications. [Background technology]

[0003] Fifth-generation technology, more commonly known as 5G, is expected to transform many everyday activities. Advances in autonomous vehicles, complex surgery, global logistics, and artificial intelligence will be made possible by 5G, as it provides the right infrastructure for product improvements and refinements that can transform the digital experience for both consumers and businesses. This infrastructural change offers the opportunity to significantly improve current systems and services and fundamentally transform many computing processes by providing higher data rates, lower latency, and increased mobility. 5G uses radio waves to transmit and receive voice and data and incorporates several foundational technologies, including network slicing, network function virtualization, software-defined networking, and multi-access edge computing. 5G shifts computing, data, and application intelligence to the network, transforming it from a transactional transport pipe into a robust, dynamic computing platform. On a 4G network, it can take six minutes to download a movie. With 5G, that download time could be reduced to three seconds. While 4G networks can only support 4,000 devices per square kilometer, 5G could potentially support up to 1 million.

[0004] The 5G network core will be based on open standards, addressing all aspects of signaling, session, access, subscriber, data, and radio access management, as well as all aspects of multimedia and 5G application services. The 5G core could easily contain tens of millions of lines of code, including millions of lines of open source code developed by third-party companies and developers. Policing and checking the security implications of open source, which expands exponentially every day, is often difficult. Many open source standards typically encapsulate third-party libraries that contain other functions and services, which may never be exercised, thereby increasing the overall malware attack surface. Even if a particular release of software is secure, this does not guarantee that future versions will be free of security holes. Within the 5G network core, access and session management functions may involve many microservices, potentially executing large numbers of calls on sensitive virtual machines (VMs) that hold both network and user data and have many entry points for operations, authentication, authorization, subscriber management, and home services functions, exposing them to security breaches. In 5G, packet gateways process data packets for control information and data transmission, which may contain or carry malware. These gateways also support application-level control and may be more accessible than in past networks. These factors combine to create additional security vulnerabilities in the installation, maintenance, and operation of home serving systems, authentication, authorization, session management, and packet gateways, particularly in the management and orchestration aspects. Policy control functions, such as charging, may include charging data, and exploitable gaps may exist, particularly as part of the data collection and storage process. The applicant recognizes the significant need to develop secure and purpose-built 5G architectures, as current vulnerabilities expose critical infrastructure and data to increased attacks.

[0005] A typical 5G core network is a mobile core platform that handles device-to-network, network-to-device, and network-to-network requests for paging, signaling, control, data processing / handling, and media services without complete assurance of message source or destination, and without sufficient protection against spoofing, message modification, fake base stations, and inaccurate or intentionally altered inter-carrier and inter-exchange information. These attacks may be amplified given new 5G technologies, such as network slicing, large-scale IoT, network function virtualization, and software-defined networking. Example attack vectors include authentication attacks, such as forgery, verification impersonation, partial message collision attacks, and password compromise; integrity attacks, such as message blocking, spam, message and data cloning, message modification, message insertion, and message tampering; and availability attacks, such as man-in-the-middle attacks, impersonation, spoofing, eavesdropping, replay, and session impersonation.

[0006] Many of the key changes introduced in 5G networks contribute to the architectural approach for these platforms, including: (A) Approximately 1 millisecond response time between edge devices and the network. 4G typically has a response time of 50 milliseconds. Near-real-time response times could enable a wealth of new applications and services on 5G networks. (B) 5G is one of the first network architectures designed specifically with the Internet of Things in mind. This could potentially improve connection density, needed to support the rapidly growing number of IoT devices, by 10 times compared to 4G. (C) 5G will be 10 to 100 times faster than current 4G networks. (D) Network slicing provides the ability to divide network bandwidth into multiple logical networks, enabling the use of private networks on 5G networks. (E) Support for mesh networking allows 5G networks and related services to scale over different radio environments, such as Wi-Fi and Bluetooth, potentially increasing coverage, range, and addressing peak capacity issues. (F) Intelligent networking capabilities. The core of 5G networks can leverage the latest advances in expert systems to understand what is happening on the network and identify potential issues and requirements.

[0007] Some telecommunications networks utilize satellite technology. An exemplary satellite technology uses low Earth orbit (LEO) satellites, which are typically deployed as constellations, because a single LEO satellite provides a relatively small coverage area that moves as the satellite moves at the high angular velocity required to maintain its orbit. Therefore, multiple LEO satellites are typically required to provide continuous coverage. On the other hand, geostationary satellites move at the same angular velocity as the Earth's rotation and can provide continuous coverage over a relatively large area. Furthermore, the ground-to-satellite latency for LEO satellites is relatively short, approximately 125 milliseconds for geostationary satellites, compared to approximately 1-4 milliseconds.

[0008] LEO satellites have generally been used with telecommunications networks that do not have a separation between the control plane and the data plane. LEO satellites typically treat all communications as belonging to the data plane. Many LEO systems are primarily used for backhaul. For example, LEO satellites typically do not include a telephone processing system in the backhaul because no processing occurs on the LEO satellite.

[0009] With regard to 5G technology, LEO satellites are expected to use the same communications architecture paths that geostationary satellites (e.g., geocommercial satellites) also use. Therefore, current and near-future LEO satellites cannot handle specific traffic types or specific applications. Rather, LEO satellites, like existing geostationary satellites, function as pathways or conduits to move bandwidth (e.g., moving bandwidth from one location to another). Like existing geostationary satellites, LEO satellites can transport bandwidth for television, internet access, Wi-Fi to airplanes, maritime traffic, 5G traffic, and more. For example, with 5G traffic, all data will be transported together along the control plane and data plane. This is because these LEO satellites are designed to be transparent regardless of the type of traffic or whether the communication is 5G, 4G, television streaming, Wi-Fi, or some other form of communication. Summary of the Invention

[0010] In embodiments, methods, systems, kits, and apparatuses may include improving data security of platform data in a dedicated 5G telecommunications platform. In embodiments, the method may include separating platform data into three separate object structures: data, metadata, and actions. The method may include defining data of a first object structure by its Abstract Syntax Notation (ASN); converting the data of the first object structure into a data object based on the ASN of the data; converting metadata of a second object structure into a metadata object; and converting actions of a third object structure into an action object. The method may include separating the data object, metadata object, and action object while the platform data is at rest; and reconstructing the data object, metadata object, and action object while the platform data is being accessed.

[0011] In embodiments, data objects and metadata objects may be related by inheritance. In embodiments, data objects and metadata objects may be related by a strict parent-child relationship. In embodiments, data objects and metadata objects may be related by association. In embodiments, data objects and metadata objects may be related by a pointer relationship. In embodiments, data objects and metadata objects may be related to each other through operations based on the code they execute, which code is held in a separate object related to the metadata object by inheritance. In embodiments, data objects and metadata objects may be related to each other through operations based on the code they execute, which code is held in a separate object related to the metadata object by association. In embodiments, data objects, metadata objects, and operation objects may be held in one of separate databases, separate data stores, and separate clouds.

[0012] In one example implementation, a computer-implemented method for configuring a fifth-generation (5G) network may include, but is not limited to, utilizing software-defined networking (SDN) to separate a data plane from a control plane of the 5G network. The separated control plane may be implemented across a low-Earth orbit (LEO) system between an edge network and a core network of the 5G network, such that the LEO system exclusively directs the control plane. Paths for the data plane may be determined and generated by the LEO system exclusively using the control plane.

[0013] One or more of the following example features may be included: The LEO system may be configured to provide sole control and management of the routing of data on the data plane based on a control plane running on the LEO system. The LEO system may be software running on one or more LEO satellites. In one example, data may be blocked from being forwarded along the control plane based on the type of data being forwarded across the data plane. At least a control portion of one or more applications may be executed on the LEO system by utilizing SDN.

[0014] In another exemplary implementation, a computer-implemented method for providing low Earth orbit (LEO)-oriented fifth-generation (5G) telecommunications may include, but is not limited to, receiving a service request from a first location via a 5G network to transmit data from the first location to a second location. Software-defined networking (SDN) control of a control plane of the 5G network may be established exclusively on the LEO system based on the service request. A path for a data plane from the first location to the second location may be determined and generated based on the service request and the control of the control plane on the LEO system. Data may be transmitted from the first location to the second location based on the generated data plane path.

[0015] One or more of the following example features may be included: The LEO system may be software running on one or more LEO satellites; Session Initiation Protocol (SIP) may be utilized to secure communications in the signaling and control plane; Session Description Protocol (SDP) may be utilized to provide at least one of originating call model information, adapting the call model in real time, and adding services during a call; In one example, a mid-trigger event may be initiated during a call between a first user equipment at a first location and a second user equipment at a second user location, such that Session Initiation Protocol (SIP) and Session Description Protocol (SDP) may be utilized to provide security against mid-trigger events (e.g., conferencing, add-ons, mid-call invites, etc., as described in this disclosure in connection with call selection and processing for 5G call setup); The route may be determined based on at least one of a whitelist of approved terrestrial network VIAs and a blacklist of unauthorized (e.g., unauthorized) terrestrial network VIAs. For example, the whitelist may include at least one of a Common Language Facility Identifier (CLFI), a Common Location Language Identifier (CLLI), a LEO satellite identifier, and / or a terrestrial network equipment identifier. Data transmitted from the first location to the second location may be encrypted.

[0016] In another exemplary implementation, a computer-implemented method for providing fifth-generation (5G) telecommunications using backhaul on one or more satellites may include, but is not limited to, receiving a service request via a 5G network. Software-defined networking (SDN) control may be established to deploy virtual network functions based on the service request. Encrypted data may be communicated via a data plane between one or more satellites supported by the virtual network functions based on the service request. The control plane may be configured based on the service request with one or more cores providing compute residing on one or more satellites independent of the one or more satellites used to communicate the encrypted data via the data plane.

[0017] One or more of the following example features may be included: A path for the data plane may be determined and generated for the data plane from a first location to a second location based on the service request and control of the control plane by one or more satellites. The control plane may use an SDN controller to establish SDN control for deploying virtual network functions based on the service request.

[0018] In another exemplary implementation, a low Earth orbit (LEO) system for providing fifth-generation (5G) telecommunications may include, but is not limited to, one or more control plane nodes connected by free space optical links that form a control plane of a 5G network across one or more control nodes. The LEO system may also include a software-defined networking (SDN) controller used by the one or more control plane nodes to direct the control plane in selecting one or more data plane nodes that form the data plane of the 5G network across one or more selected data plane nodes. The one or more control plane nodes may use the SDN controller to determine and generate routes for data across the one or more selected data plane nodes.

[0019] One or more of the following example features may be included: The one or more control plane nodes may be one or more LEO satellites. The one or more selected data plane nodes may include at least one of a LEO satellite, a terrestrial network device, and a combination thereof. The SDN controller may utilize network functions virtualization (NFV) to employ the control plane. The LEO system may further include at least one database related to routing, such that user identification information in the at least one database can be used to eliminate a handshaking process. The LEO system may further include one or more encryption keys for decrypting information related to user device communications and transactions.

[0020] In another exemplary implementation, a system for configuring a fifth-generation (5G) network may include, but is not limited to, a low-earth orbit (LEO) system that utilizes software-defined networking (SDN) to separate a data plane from a control plane of the 5G network; and an edge network connected to the LEO system via a control plane, such that the LEO system directs the control plane exclusively between the edge network and a core network of the 5G network. The LEO system may use the control plane to determine and generate routes for the data plane.

[0021] One or more of the following example features may be included: The LEO system may be software operating on one or more LEO satellites, and at least a control portion of one or more applications may utilize SDN on the LEO system to execute the one or more applications in connection with directing the control plane.

[0022] In another exemplary implementation, a system for providing low Earth orbit (LEO)-oriented fifth-generation (5G) telecommunications may include, but is not limited to: a first user device transmitting a service request from a first location over a 5G network to transmit data from the first location to a second user device at a second location; and a LEO system establishing software-defined networking (SDN) exclusive control of a control plane of the 5G network based on the service request. The LEO system may determine and generate a path for a data plane from the first location to the second location based on the service request and the control of the control plane on the LEO system. Data may be transmitted from the user device at the first location to the user device at the second location based on the generated path of the data plane.

[0023] One or more of the following example features may be included: The LEO system may be software operating on one or more LEO satellites. In an embodiment, the system may further include home serving information for a categorized group of users for activating one or more services. A first user of a first user device and a second user of a second user device may be part of a categorized group of users such that one or more services are activated when the first user device connects with the second user device. The LEO system may include a Session Initiation Protocol (SIP) virtual server and a Session Description Protocol (SDP) virtual server for providing security for transmissions between the first and second user devices and other transmissions. The LEO system may be configured to execute at least a control portion of one or more applications by using SDN exclusive control. Data transmitted from a user device at a first location to a user device at a second location may be encrypted.

[0024] A more complete understanding of the present disclosure will be apparent from the following description and accompanying drawings, and the appended claims. [Brief explanation of the drawings]

[0025] The accompanying drawings, which are included to provide a better understanding of the present disclosure, illustrate embodiment(s) of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

[0026] [Figure 1] FIG. 1 is a schematic diagram illustrating an extension of a platform to include mobile network-as-a-service platform capabilities, zero trust mobile network capabilities, and portions of a unified edge computing platform, in accordance with one or more example implementations of the present disclosure. [Figure 2]FIG. 1 is a schematic diagram illustrating an extension of a platform to include mobile network-as-a-service platform capabilities, zero trust mobile network capabilities, and portions of a unified edge computing platform, in accordance with one or more example implementations of the present disclosure. [Figure 3] FIG. 1 is a schematic diagram illustrating an extension of a platform to include mobile network-as-a-service platform capabilities, zero trust mobile network capabilities, and portions of a unified edge computing platform, in accordance with one or more example implementations of the present disclosure. [Figure 4] FIG. 1 is a schematic diagram illustrating an extension of a platform to include mobile network-as-a-service platform capabilities, zero trust mobile network capabilities, and portions of a unified edge computing platform, in accordance with one or more example implementations of the present disclosure.

[0027] [Figure 5] FIG. 1 is a prior art schematic diagram of a data structure depicting typical data layers.

[0028] [Figure 6] FIG. 1 is a schematic diagram of a data structure with a layer of policy-based key distribution that can ensure that keys required to decrypt data are distributed only to authorized systems or users, in accordance with one or more example implementations of the present disclosure.

[0029] [Figure 7] FIG. 1 is a perspective view illustrating a further example of a standalone and secure fifth-generation technology (5G) architecture of a network and computing platform in accordance with one or more exemplary implementations of the present disclosure.

[0030] [Figure 8] FIG. 10 is a schematic diagram illustrating further examples of successively increasing levels of data protection employed on a platform, in accordance with one or more exemplary embodiments of the present disclosure.

[0031] [Figure 9]FIG. 10 is a schematic diagram illustrating a further example of a dedicated and secure 5G core network and cloud architecture employed by a platform in accordance with one or more example implementations of the present disclosure.

[0032] [Figure 10] FIG. 10 is a schematic diagram illustrating a further example of a dedicated and secure 5G cloud and secure domain architecture employed by a platform in accordance with one or more example implementations of the present disclosure.

[0033] [Figure 11] FIG. 10 is a schematic diagram illustrating a further example of a dedicated and secure layer of a trusted network employed by a platform in accordance with one or more example implementations of the present disclosure.

[0034] [Figure 12] FIG. 10 is a schematic diagram illustrating further examples of the platform's dedicated, securely owned and operated components and systems to provide further enhanced security in accordance with one or more exemplary implementations of the present disclosure.

[0035] [Figure 13] FIG. 1 is a schematic diagram illustrating an example of a dedicated and secure low Earth orbit (LEO) constellation backhaul network, in accordance with one or more example implementations of the present disclosure.

[0036] [Figure 14] FIG. 1 is a schematic diagram illustrating an example architecture of a dedicated, secure sandbox employed by a platform to actively manage and quarantine processes contained in the sandbox, in accordance with one or more exemplary implementations of the present disclosure.

[0037] [Figure 15]FIG. 1 is a schematic diagram illustrating an example architecture of a dedicated, secure sandbox with a keyed layer of checkpoints employed by a platform to actively manage and quarantine processes contained in the sandbox, in accordance with one or more exemplary implementations of the present disclosure.

[0038] [Figure 16] FIG. 1 is a schematic diagram illustrating an example of a dedicated and secure data security architecture employed by a platform in accordance with one or more exemplary implementations of the present disclosure.

[0039] [Figure 17] FIG. 1 is a schematic diagram illustrating an example of a dedicated and secure data structure employed by a platform that uses object identifiers to facilitate the isolation, reconstruction, and secure keeping of data, metadata, and the context and behavior around that data and metadata, in accordance with one or more exemplary implementations of the present disclosure.

[0040] [Figure 18] FIG. 1 is a schematic diagram illustrating an example of a dedicated and secure data system employed by a platform to extract, load, and transfer data, metadata, and the context and behavior around that data and metadata to isolate and reconstruct them, in accordance with one or more exemplary implementations of the present disclosure.

[0041] [Figure 19] FIG. 1 is a schematic diagram illustrating an example of a dedicated, secure data system employing a secure micro-data center architecture with a platform including platform edge devices and one or more network cores residing in a platform secure domain, in accordance with one or more example implementations of the present disclosure.

[0042] [Figure 20]FIG. 1 is a schematic diagram illustrating an example of a dedicated, secure data system employing a secure micro data center architecture and sandbox protection with a platform including platform edge devices, transiting via a platform LEO constellation, fiber, microwave, etc., in accordance with one or more example implementations of the present disclosure.

[0043] [Figure 21] FIG. 1 is an example schematic diagram of a LEO system communicating with edge and core networks across a 5G network, in accordance with one or more example implementations of the present disclosure.

[0044] [Figure 22] FIG. 22 is an exemplary schematic diagram of a control plane operating in conjunction with the LEO system of FIG. 21 to interact with the application plane and data plane of a 5G network in accordance with one or more exemplary implementations of the present disclosure.

[0045] [Figure 23] 1 is an example flowchart of a 5G configuration process, in accordance with one or more example implementations of the present disclosure.

[0046] [Figure 24] 1 is an example flowchart of a LEO-directed 5G telecommunications process in accordance with one or more example implementations of the present disclosure.

[0047] Like reference numbers in the various drawings indicate like elements. DETAILED DESCRIPTION OF THE INVENTION

[0048] In various methods and systems, the disclosed network and computing platform can provide a highly secure, standalone, dedicated fifth-generation technology (5G) telecommunications network and computing platform with significantly reduced surface vulnerabilities and significantly enhanced end-to-end security. In embodiments, the disclosed 5G telecommunications network and computing platform can incorporate a distributed data model using a differentiated approach to creating a reliable and resilient network by securing the entire technology stack, from applications, services, and data to physical infrastructure. In embodiments, the platform may offer various features, functionality, components, and user and business experiences to defense, government, and enterprise customers where security and reliability are paramount. In embodiments, the platform provides connectivity for rural areas of one or more countries, for areas with poor connectivity and poor lines, and the like.

[0049] In embodiments, the 5G telecommunications network and computing platform incorporates one or more combinations of a standalone 5G architecture, a converged network and cloud architecture, a minimized surface attack architecture, an architecture that intentionally drives pervasive security at all levels, etc. In embodiments, the network and computing platform may be architected in a standalone architecture configuration, as opposed to the many non-standalone architectures adopted by many U.S. operators. In embodiments, the network and computing platform may provide an end-to-end secure 5G network, including a new radio access network, transport network, 5G mobile core, edge network, etc. In these examples, the platform's standalone architecture may be a fully virtualized, cloud-native architecture with efficient ways to develop, deploy, and manage services.

[0050] In embodiments, a 5G telecommunications network and computing platform may provide an integrated network and cloud. In these examples, edge computing may be deployed at or near the devices to be controlled. In embodiments, the platform architecture may integrate a seamless, distributed, and secure cloud at the network edge. In examples where coverage for wireless or edge computing may not be available in locations deemed necessary by a customer, a customer of the platform may seamlessly provision and integrate a mobile edge that combines wireless, compute, and network and backhaul to the computer platform all in one. In many examples, the platform may be deployed with an edge computing and network architecture that may be statically or dynamically provisioned or auto-provisioned and operated by the platform without manual intervention. In many examples, the platform may be deployed with an edge computing and network architecture that may be controlled (in whole or in part) by one or more customers of the platform.

[0051] In embodiments, the methods and systems of the present disclosure may include a 5G-enabled connectivity platform that deploys native defense-grade security, which may be purpose-built to handle critical communications and data by addressing what applicant assesses to be significant security and architectural issues inherent in existing telecommunications infrastructure and software.

[0052] The platform can be well-suited for a range of applications and use cases worldwide to fully realize the benefits of 5G technology. In embodiments, platform features may include being designed from the ground up with enterprise virtual private cloud (VPC) architectural principles. The platform may also include Mobile Network as a Service (MNaaS) capabilities, providing full control over the entire mobile network lifecycle and enabling multiple mobile networks dynamically on a pay-per-use, subscription-based, or combination thereof. The platform may also include Zero Trust Mobile Network (ZTMN) capabilities, built on an architecture that supports significant security enhancements not typically possible with traditional 3GPP-only networks. If needed, each application or use case can be configured with its own highly customizable network architecture to meet its specific needs, resulting in significant improvements in timelines, accuracy, security, and operations.

[0053] In embodiments, the platform may also include a cloud-native, standalone 5G architecture that may provide improved scalability, fault isolation, and efficient use of resources while improving total cost of ownership; dynamic extension of enterprise security to mobile assets and the mobile core; and the use of agile, open frameworks and advanced development, security, and operations (DevSecOps) paradigms that result in a rapid innovation environment and faster delivery of capabilities.

[0054] In embodiments, the platform may provide Zero Trust Mobile Network (ZTMN) capabilities for its customers seeking defense-grade security in private 5G networks. ZTMN and its capabilities may be developed based on virtual private cloud (VPC) principles and offered as part of its cloud-based MNaaS platform with integrated edge capabilities. In embodiments, the platform MNaaS and ZTMN may provide significant security and architectural enhancements that can extend the capabilities of traditional 3GPP 5G networks. Architectural enhancements may include being built from the ground up on proven enterprise VPC principles; multi-tenancy capabilities that can provide any number of discrete, secure, and highly customizable private 5G networks; and trust verification and encryption between all network functions and network elements. Further, architectural enhancements may include encryption of metadata, subscription data, and log data with customer-generated keys to ensure maximum security by dynamically extending enterprise perimeter security to mobile assets and the core; multi-factor authentication and authorization for all mobile assets; and facilitating missions for supply chain reengineering and supply chain risk mitigation for various entities.

[0055] In embodiments, the platform may include the ability to create any number of 5G networks that can be individually created and customized according to the exact needs of, for example, augmented reality / virtual reality (AR / VR) and other applications requiring a 5G network. The platform may include a cloud-native implementation that enables scalability, resilience, and efficient resource usage. The platform may include a Zero Trust Mobile Network (ZTMN) built on an architecture that offers major improvements in the areas of security and service level guarantees far beyond standard 3GPP 5G networks. In accordance with these examples, the platform may dynamically provision edge computing into the ZTMN on a per-application basis that may adhere to the application's security model and customized mobile network.

[0056] Applicant appreciates that the enterprise mobile network market is rapidly evolving as government allocations of unlicensed mobile spectrum enable large enterprises to transition from traditional carrier-controlled public networks built for consumers to private networks that they control and maintain. In light of this disclosure, it will be appreciated that enterprise mobile networking can be thought of as deploying hybrid mobile networks consisting of private 5G radio infrastructure in areas controlled by the enterprise and public LTE / 5G networks that can provide roaming coverage where private networks are not available.

[0057] Applicant recognizes that there may be significant security issues that must be addressed in any 5G network architecture designed to support critical data or communications, such as significant existing LTE vulnerabilities when 5G networks are deployed in non-standalone (NSA) network configurations; an expanded (and growing) attack surface due to the use of microservices-based architectures; companies lacking visibility and control of security policies in centrally managed and / or operator-controlled 5G networks; and all 5G network slices that may share a control plane, potentially exposing organizations using a network slice to any breaches or issues occurring in other slices.

[0058] In embodiments, the platform may provide a new class of wireless network services that seeks to foster innovation by extending the cloud model of dynamically provisioned and controlled computing and network resources to the mobile network itself. The platform may address numerous architectural deficiencies and security gaps inherent in 5G standards, some of which are detailed herein and may be system requirements for defense and enterprise customers, while maintaining compatibility and interoperability with their networks. In embodiments, the platform may extend and enhance the basic 5G network by providing several enhanced features. In embodiments, the 5G network may be enhanced with platform MNaaS capabilities. In embodiments, the MNaaS capabilities may integrate with RAN networks that may be deployed as part of a 5G testbed and extend it with the ability to create any number of highly customized “tenant” mobile networks (potentially one per application), which may be similar to the virtual private cloud concept. Each “tenant” mobile network created on the MNaaS may be a highly secure ZTMN. In embodiments, the ZTMN may be a 3GPP Release 16 compatible private 5G network that can follow a zero trust security architecture to extend enterprise security controls onto mobile networks. In embodiments, the edge computing platform may be part of the ZTMN that can be protected with the same security paradigms and configurations established to protect the ZTMN.

[0059] Exemplary embodiments may provide a low Earth orbit (LEO) method and system that can address security concerns while maintaining and possibly improving network speeds. In some examples, the LEO system may be part of a platform, while in other examples, the LEO system may be a system separate from the platform. In examples where the LEO system may be integrated with a platform, for example, integrating the LEO system into the platform's data governance, network management, and security envelope, it is understood in light of the disclosure that the LEO system may become an integrated part of the overall platform. This may be achieved by uniquely designing LEO satellites (i.e., the LEO system) to operate as dedicated components of the platform, rather than employing traditional LEO communications satellites that may be intended to fulfill various missions. While some LEO satellites may operate generically with all traffic from different types of networks, the proposed LEO system may be configured specifically to work with 5G networks. For example, the LEO system may be specific to 5G networks by being technically capable of carrying primarily 5G traffic through operation of a 5G interface. The LEO system may be implemented on one or more LEO satellites. In some examples, one or more satellites may be part of only one constellation of satellites, and in other examples, one or more satellites may be part of one or more constellations of satellites. In some examples, each satellite may provide the functionality of a LEO system as described in this disclosure. In other examples, multiple satellites may be used together to provide the functionality of a LEO system as described in this disclosure.

[0060] The proposed LEO system may provide for the separation of the control plane from the data plane of a 5G network, such that the control plane can be moved to the LEO system (e.g., on one or more LEO satellites). By moving the control plane to the LEO system (e.g., on one or more LEO satellites), security risks associated with control plane management may be addressed. These management security risks are related to the security of the typical control plane, which runs across terrestrial systems and devices with little oversight in most communications networks. Specifically, security risks exist due to multiple enterprises or multiple applications within an enterprise sharing a single control plane. Also, because there is little oversight of the control plane, there is limited or no control over data plane routing. By moving the control plane to the LEO system, these security risks may be addressed and resolved by having control plane management exclusive to the LEO system (e.g., exclusive LEO satellite control), which allows control of data plane routing. This may eliminate some of these security risks and reduce the exposure of the entire network. The control plane on the LEO system can also provide versatility by allowing the development of software applications that direct the control plane on the LEO system. For example, the control plane on the LEO system offers new opportunities for the development of various software applications (e.g., interactive voice response applications and broadcast applications). For example, international broadcasting is difficult to achieve via the ground (e.g., from New York to Tokyo). However, using the control plane on the LEO system, it is possible to direct a LEO satellite (e.g., via an application) over Tokyo or over New York to broadcast data.

[0061] In an exemplary embodiment, the LEO system may utilize software-defined networking (SDN) to provide desired functionality, such as separating the control plane from the data plane. SDN may enable dynamic and efficient network configuration for network performance improvement and monitoring (e.g., similar to cloud computing). SDN may separate the network packet forwarding process (e.g., sometimes referred to as the data plane) from the routing process (e.g., sometimes referred to as the control plane). The control plane may include one or more SDN controllers to use or direct the control plane with respect to the data plane (e.g., use or direct the control plane to route the data plane). In general, the use of SDN may involve an evolving, continuously updated set of protocols, procedures, and algorithms. For example, programming updates may allow the LEO system to remain current and not be fixed in terms of what is implemented. For example, the LEO system may be updated and kept current with core SDN functions, protocols, and other software dedicated to specific applications of 5G traffic types.

[0062] Most existing LEO satellite systems may focus on moving user communications traffic through communication pipes or nailed-up channels to establish a path for data from one location to another. As a result, local computation may be minimized to enjoy maximized throughput. The movement of communications traffic (e.g., streaming content) may be commoditized. However, with the advent of 5G, more attack vectors may emerge, potentially creating new security vulnerabilities. 5G network capabilities may provide integrated resources supporting the control and data planes when operating satellite backhaul, potentially exposing organizations to compromises and issues that could compromise the security of the control plane. An insecure control plane may be at risk of man-in-the-middle attacks and security risks that could compromise the delivery of encrypted data across the data plane. The proposed LEO system therefore provides a platform capable of separating and isolating the control plane from the data plane (or user plane) on the 5G network, and can support the control plane with dedicated computation resident on the satellite that does not provide encrypted data communications across the data plane. Separating and isolating the control plane allows applications to control all aspects of the virtual infrastructure, including supporting development and operations (DevOps) processes and functional capabilities.

[0063] (MNaaS features) In embodiments, the platform and virtualization infrastructure may go beyond simply operating as a single, static network by enabling multiple, customizable instances of that network (e.g., potentially one per application), as well as the integration of edge computing platforms and the ability to add platform functionality as needs evolve. FIG. 1 illustrates platform enhancements at 100, including examples of an MNaaS platform, ZTMN, and integrated edge computing platform that may operate within the security configuration of a ZTMN. In embodiments, the MNaaS functionality provides full programmable control of the network, allowing defense, sovereign, and municipal forces to rapidly create custom networks to test different applications and technologies with different requirements.

[0064] In embodiments, the platform may provide the ability to create highly customizable 5G mobile network instances (or tenants) per application, similar to the virtual private cloud architecture of a cloud platform. Tenants may be very broad-based (e.g., a single-tenant network for a global enterprise) or very narrowly focused on a single application (e.g., a custom mobile network for just a smart warehousing application).

[0065] In embodiments, the platform may provide the ability to decouple the physical layer (e.g., radio network, spectrum, compute, storage) from the network that consumes the physical layer resources and may dynamically change them without impacting network operations. In embodiments, the platform may provide a cloud-native implementation that provides scalability, better fault isolation, and efficient resource usage resulting in lower operational costs. In embodiments, the platform may provide an agile framework and utilize advanced development, security, and operations (DevSecOps) paradigms, which may be shown to result in a rapid innovation environment and faster delivery of features.

[0066] In embodiments, the platform may provide a stateless service architecture and built-in geographic redundancy that may enable the respawning and replacement of failed services with new infrastructure or new locations, which may be shown to result in high availability of services.

[0067] In embodiments, the platform may provide a flexible architecture that may enable interoperability with 4G networks without compromising security to support scenarios requiring backward compatibility. Through these examples, uncompromising security may shield applications and networks from various forms of espionage, such as foreign eavesdropping, man-in-the-middle attacks, and spoofing attacks.

[0068] In embodiments, the platform may provide a relatively future-proof cloud-based platform that integrates security, privacy, and scalability. In embodiments, the platform may deploy a physical infrastructure that is decoupled from the virtualized infrastructure used by the applications.

[0069] In embodiments, the platform may separate the control plane and data plane and provide applications with control over all aspects of the virtual infrastructure, including supporting development and operations (DevOps) processes and functional capabilities. In embodiments, the platform may integrate security practices with development and operations practices (DevSecOps) to provide secure new capabilities within an agile framework.

[0070] In embodiments, each tenant network may be a ZTMN, and each ZTMN may be an entire private 5G network with its own private 5G packet core. This may be shown to eliminate the security risks of multiple enterprises or multiple applications within an enterprise sharing a single control plane by reducing the exposure of all networks to a single control plane. In embodiments, a zero trust security architecture may apply principles such as asset microsegmentation, least privilege access, encryption, analytics, and strong authentication for maximum security. This zero trust architecture may drive the design and operation of the ZTMN. In addition to designing the ZTMN itself based on zero trust policies, the ZTMN architecture may also enable an enterprise to extend its own zero trust security policies to each tenant network, including the entire private version of the 5G packet core and all mobile assets connected to it. In embodiments, this may enable an enterprise to have complete visibility and control over the security of its mobile network. With these examples, the ZTMN may be designed to dramatically minimize the impact of any security breach. In an embodiment, the ZTMN architecture deployed on the platform can extend and enhance the concept of the platform's MNaaS (Mobile Network as a Service) capabilities.

[0071] (Secure edge computing function) In embodiments, the MNaaS functionality may enable customers to create edge computing clouds, connect the edge computing clouds to the ZTMN's data plane, and extend the security of the ZTMN to similarly protect the edge computing clouds.

[0072] In embodiments, the platform may offer its customers the ability to install their own radios and radio area networks (RANs) in the coverage areas required to create "virtual private mobile networks" or "tenants" that are highly customizable to the customer's needs.

[0073] In embodiments, the platform may offer not only a "public" platform offered as a service from a public cloud (e.g., AWS / Azure GovCloud, milCloud 2.0, or JEDI), but also a "private" version for those customers (such as for sovereign or municipal militaries) that may require more physical control over their infrastructure and would like to deploy the platform in their own private cloud or data center.

[0074] In embodiments, the platform may provide a network modeling interface with the ability to model, create, modify, and tear down "tenant" mobile networks that can be deployed in real time for one or more IoT applications, for example. In embodiments, the platform may provide access to a methodology used to create and manage one or more tenant networks on a physical infrastructure, similar to how a virtual private cloud can be created on a public cloud. In embodiments, the platform may provide each tenant mobile network with its own entire virtual network compatible with 3GPP's 5G (or 4G, if the customer prefers) standards, and its own private packet core and shared RAN infrastructure across a designated set of physical RANs deployed for one or more of the customers.

[0075] These examples may show that each tenant network can maintain its own private control and data plane, resulting in exceptional control, privacy, data sovereignty, and customizability for application owners. This architecture may be shown to have distinct advantages, such as: complete control over the specification and customization of infrastructure to suit the specific needs of the application; application control over its own network compared to centralized command and control; custom security profiles that may include different classification levels and various encryption algorithms; the ability to provide access to operate and manage the network only to authorized and vetted personnel; and the ability for custom service level agreements. When compared to other standard 5G services, the platform's MNaaS capabilities may offer significant architectural, scalability, security, and operational advantages, which are described in more detail herein.

[0076] Applicant recognizes that a standard 5G service-based architecture may provide a statically created network with predefined consumption of network resources and a single control plane with different statically configured shared data planes for each consumption type.

[0077] In embodiments, each application in the platform can have its own "tenant" mobile network with a private control and data plane customized for each of the application's many needs. In embodiments, modules in the platform can virtualize and oversee the entire physical infrastructure to create a fully orchestrated mobile network environment. In embodiments, the platform mobile network may be operated more like a software object, allowing it to become an orchestrated part of application processes. In embodiments, platform applications can integrate network creation with "infrastructure as code" DevOps scripts to achieve full control and automation.

[0078] In embodiments, the platform may be purposefully configured so that it no longer has a "one size fits all" approach to network architecture. In this way, control may be shifted from the carrier to the application owner. For example, physical resources may be saved because development and testing phases are created only for the duration of test execution. During deployment, version-controlled networks may be created and "rolled back" along with the application if an error occurs in production. This allows for a focus on developing innovative applications that take advantage of the flexibility offered by mobile networks, similar to some examples deployed in public / hybrid cloud models.

[0079] In evolving from legacy architectures, applicants recognize that OEMs have carried forward legacy code and design flaws while evolving NSA core software to 5G, now wrapped in an SBA interface.

[0080] In embodiments, the platform may encompass a de novo development effort with no legacy code and, in many instances, may be based on modern Go programming language similar to Kubernetes. In doing so, the platform may eliminate legacy architectures and known security issues and may be developed from the beginning with cloud-native scalability in mind. Applicant recognizes that if 4G backward compatibility is required, current 3GPP deployments may introduce issues with legacy implementations and LTE security flaws.

[0081] (Sandboxed LTE Interoperability) In embodiments, the platform may deploy and create standalone 5G and 4G tenants when 4G is needed. In these examples, the 4G tenants may interoperate with the 5G tenants based on a secure "home-root" architecture. In this way, the platform may deploy cleanly separated 5G security, such that the 4G tenants may run in their own isolated and sandboxed environments.

[0082] Applicant recognizes that new 5G network functions may be created to be "cloud-native" microservices, however, some implementations may use decades-old code, defeating the purpose of the cloud-native concept.

[0083] (True Cloud Native) In embodiments, all applicable components of the platform may be cloud-native. In these examples, all code may be "born in the cloud," thereby being microservices that may run in any public, private, or hybrid cloud environment. Furthermore, cloud-native horizontal scalability and the ability to "scale out" rather than scale up may prove to result in lower operational costs. In embodiments, the platform may also be deployed with the ability to dynamically and instantly scale out to maintain operations during peak demand periods. It is understood in light of this disclosure that scalability is built for web applications and legacy architectures that may be designed to scale up to millions of subscribers.

[0084] (IoT scale) Applicant recognizes that there is tremendous scalability in the world of connected devices, especially when deployed as a fully stateless scale-out architecture. In these examples, each microservice may be started and stopped independently to scale up to incoming demand. In some examples, a non-SQL horizontally scalable database may be deployed.

[0085] The IoT also offers opportunities for clean horizontal scalability to handle traffic without bottlenecks, scalability limited only by the availability of physical resources. In these examples, components, including their virtual versions, can be scaled out (e.g., adding more components rather than replacing them with larger ones) as needs grow without impacting service availability.

[0086] (Microservices architecture built into the 5G core) In embodiments, the platform may be deployed in a 5G microservices architecture, intended as an internal scaling mechanism to benefit operators looking to optimize their services.

[0087] (Declarative Network Model) In embodiments, the platform architecture may be configured to expose network services external to the application. In these instances, applicant recognizes that the application and its support may determine and drive the network requirements, and the interface may be based on a "declarative network model."

[0088] Applications, rather than a central command and control infrastructure, may determine the classification level control security of each network. In this way, a model-driven paradigm can lead to consistent network design and performance.

[0089] Applicant recognizes that some 5G focus is on consumers creating static "services" to sell to customers and having a more substantial service creation infrastructure, and within this, there may be a "small number" of sizes that fit all models of network services.

[0090] In embodiments, the platform is deployed without static "service definitions," and a declarative model can drive custom tenant networks. These capabilities may mean rapid integration with enterprise applications without the need for large-scale, typical infrastructure overhead from regular telecommunications players. These capabilities can provide the ability to drive rapid innovation similar to cloud business models; a lightweight, flexible architecture; and customized tenant networks that can be configured and expanded to fit any need. This allows customers, rather than carriers, to have complete visibility and control of their own wireless infrastructure and security.

[0091] (Network Slicing) Applicant recognizes that in many instances, network slicing may be the only customizable concept in the 5G specifications, and this customization may be deployed with service level agreements to meet industry or specific customer needs, and may then be centrally provisioned and managed by the carrier.

[0092] (private network) In embodiments, the example private network can support standards-based network slicing, with each tenant accessing its own customizable private network. The private tenant network operates similarly to an enterprise wide area network, yet integrates with existing enterprise policies, providing: a flexible platform for innovation; greater customizability over network slice capabilities and control; no central command and control; and federated accountability.

[0093] (User control based on world-class security) In embodiments, platform functionality may be focused on security with sovereign military applications and use cases in mind; control, data, and management planes may be separated for each tenant network; security policies may be configurable per tenant, and PKI and encryption algorithms may be customized for each tenant network (i.e., allowing NC3 networks as needed); tenant mobile networks may be managed, controlled, and secured using corporate LAN / WAN policies with signed binaries; and open source components may be updated to fix security holes.

[0094] Tenant-based private networks offer significantly higher levels of security that may be built into the network architecture itself. Such networks may include distributed control of granular network security policies and the ability to create separate networks for each application and each classification level for complete separation of traffic and management / security responsibilities.

[0095] (Network reliability built in) In embodiments, the network architecture may be configured to respawn failed services with new infrastructure or locations to ensure reliable service; support geographic redundancy via CouchDB for reliability of stateless infrastructure; improve reliability built into the architecture itself; increase reliability in highly available applications; avoid requiring the overhead of engineering reliability as part of deployment; provide highly reliable individual tenant networks; and provide faster innovation by freeing developers from reliability engineering.

[0096] (Zero Trust Security Architecture) Applicant recognizes that a control plane common to all customers and networks can be subject to significant security risks. In embodiments, zero trust security architecture, currently recognized as cutting edge security principles, may drive the platform's ZTMN architecture. In this case, the control plane, user plane (sometimes referred to throughout this disclosure as the "data plane"), and management plane may be separated per tenant. Each tenant network may be based on micro-segmentation (e.g., segmentation of the control plane, user plane, and management plane), least privilege access, analytics and artificial intelligence, strong biometric authentication, and hardware-based authentication.

[0097] (Extending Customer Zero Trust Policies to Protect Mobile Networks) Applicant understands that central command and control of typical networks does not provide enterprise visibility into security, nor does it provide enterprise control of mobile network security. In embodiments, the platform can provide enterprise-wide visibility and control over tenant network security. As such, customer zero trust policies can be seamlessly extended to the mobile network. Customer data can be encrypted with customer-owned keys. Mobile assets can be micro-segmented and enterprise perimeter security applied to the mobile network. The platform can employ strong authentication and integrate enterprise security information and event management and logging. User plane functions are protected by dynamically provisioned enterprise security policies, and edge computing platforms that can connect to user plane functions can be within the enterprise security perimeter.

[0098] The platform may be configured to adhere to customer-controlled corporate security policies, giving corporate security personnel visibility and control over the security of tenant networks.

[0099] (Minimizing the impact of security breaches) Applicant understands that a breach of a network operator's security could result in the complete exposure of the network, including all customers, their subscriber data, metadata, and usage data. In embodiments, the platform tenant architecture may be configured to isolate and protect the exposure of all tenants. Protection may be against exfiltration of user data, attack propagation, and spoofing.

[0100] In embodiments, the platform may provide enhancements to provide a platform-oriented architecture for highly secure 5G networks and edge computing 5G environments that may enable tens of billions of always-on connected devices. Thus, the convergence of traditional network design with cloud computing may require new approaches that may enable rapid advancement of cutting-edge capabilities in 5G technology.

[0101] In embodiments, the platform may incorporate two beneficial standards. The first is a platform-level enhancement that brings virtual private clouds to mobile networks and provides MNaaS. Additionally, the secure mobile networks that customers can create on the MNaaS platform may all be ZTMNs, providing a zero trust architecture for the platform.

[0102] In embodiments, the platform's MNaaS capabilities may be capable of providing a 5G zero trust mobile network and edge computing platform configured on-demand per tenant network. In examples, the MNaaS platform may be expanded to offer a variety of additional services to meet future needs. An example would be an NB-IoT or LTE-M capable LTE network that can interoperate with the platform ZTMN for identity, authentication, secure data plane, and policy control. Another example would be a mobile network with a custom DoD radio access technology (RAT) rather than just the LTE or 5G RAT. In these examples, the cloud platform's PaaS architecture may be expanded to add capabilities as application needs evolve. Platform ZTMN can apply the following core principles of zero trust network architecture to secure mobile networks: microsegmentation of assets, networks, and segment users and machines that need access to each microsegment; zero trust security policies that enforce the least amount of access a user needs to perform a task; multi-factor authentication, which can reduce authentication vulnerabilities and ensure there is always another way to allow a user onto the network; continuous authentication rather than "front door" security that verifies a user's identity when they first connect to the network; device security, which deploys agents on devices that control and monitor the activity of each device connected to the network; encryption and data loss prevention to protect both data at rest and data in motion; and analytics and machine learning models that can constantly monitor the network to detect anomalies that may indicate a security breach.

[0103] In embodiments, the MNaaS functionality may comprise components that can decouple the physical layer (e.g., RAN, spectrum, servers, network, storage, etc.) of a 5G network from the network that consumes it, virtualizing the physical layer (e.g., spectrum, RAN, compute, storage, networking, etc.). An example of such a collection of components and functionality may be included in the platform's Televisor technology. The MNaaS functionality provides the functionality to model zero trust mobile networks using a declarative paradigm and create these managed virtual mobile networks on the physical layer. In embodiments, applications may use the MNaaS functionality to create, manage, and tear down one or more zero trust mobile networks based on their needs, as shown at 200 in FIG. 2. A physical infrastructure process may be implemented as shown in FIG. 2. This process may include a platform that deploys RAN infrastructure at base stations, the platform may provide IP connectivity from the RAN to the cloud, commercial applications (e.g., smart warehouses) and enterprise applications (e.g., drones) may be deployed, each application may create a virtual mobile network with a security level based on enterprise policies, and the platform, including some televisor functionality, may dynamically allocate additional resources from the physical infrastructure (spectrum, bands, etc.) as needed by the application without impacting application performance.

[0104] In embodiments, each ZTMN created with MNaaS functionality may be its own self-contained mobile network to which various security enhancements can be applied. In an example, it may have its own dedicated Release 16 packet core or, if desired (Release 15), its own user and management planes, along with a network configuration that integrates the mobile network into the enterprise's own wide area network (WAN) architecture. Each ZTMN may use enterprise private IP addresses within its dedicated software-defined network, thereby connecting to the enterprise network and the enterprise's zero trust network architecture.

[0105] In embodiments, the platform's MNaaS capabilities may also enable applications to model and provision their own edge cloud, connect it to the user plane of a tenant ZTMN, and wrap the edge cloud in the same security blanket that protects the ZTMN.

[0106] The following subsections provide exemplary technical details of the platform architecture, including the physical infrastructure. The solution enables multiple mobile networks aligned with the requirements of each application, thereby providing testing and validation for a variety of applications.

[0107] In an embodiment, the architecture of the MNaaS platform may include layers shown in FIG. 3 as 300.

[0108] (Physical Layer Architecture) 5G Radio Access Network (RAN) such that 5G radio access network sites can be interconnected to the edge cloud. 5G RAN and radios may be used as part of these enhancements.

[0109] In embodiments, the platform may include an edge infrastructure that may use servers for user plane functions to accelerate user plane Internet Protocol (IP) traffic, handle software-defined networking (SDN) processing, and execute components of monitoring functions. In examples, such components and monitoring functions may be included in the platform's Televisor technology.

[0110] In embodiments, the MNaaS infrastructure and the 5G Core for each tenant network may be located in a public cloud (e.g., AWS Government Cloud, Joint Enterprise Defense Infrastructure), a private cloud (e.g., milCloud), or a private data center. Each of the 5G Cores may be orchestrated within the cloud using Kubernetes technology. In many examples, multiple instances of the Core may be instantiated per tenant across any cloud that may provide geographic redundancy and scalability.

[0111] In an embodiment, the platform may include management and network operations (MANO) in that a management layer may be used to expand, contract, modify, and monitor the physical layer. Components of the management layer may be distributed across all other elements of the physical layer (e.g., RAN, core, edge, etc.). In an embodiment, an exemplary architecture for deploying MNaaS functionality on a platform may include layers shown in FIG. 3 at 300.

[0112] (Platform layer) In embodiments, applications on the platform can use a declarative model to specify customized network configurations. In an example, the platform may create one or more "tenants" of virtual mobile networks on a physical infrastructure. In embodiments, the platform may include a software layer that can run in both the core and edge clouds. The software layer's functions may include maintaining a complete inventory of physical and virtual resources; providing orchestration capabilities for all virtual mobile networks; creating a virtual infrastructure layer during tenant creation and installing an instance of a private 5G core with full customization and control plane isolation; performing lifecycle management for each tenant; and providing management and monitoring capabilities for the platform layer and all virtual networks and instantiated services.

[0113] (Application Programming Interface (API) and Management Layer) In embodiments, the platform may include an API layer that provides network orchestration capabilities based on a declarative model as well as RESTFUL APIs for managing tenant networks. The platform may include a platform and physical layer and a UI-driven management layer for tenant networks. In embodiments, the platform may include access for multi-layered APIs and management layers to support various levels of access control.

[0114] In embodiments, the features and benefits of the MNaaS platform are detailed herein, and the platform can provide MNaaS and ZTMN capabilities to enable many different advanced applications.

[0115] In embodiments, the platform's MNaaS capabilities may provide the ability to create customized mobile networks per application, enabling the decoupling of physical infrastructure from the mobile networks consumed by the applications. The platform's capabilities may also provide distributed control of network configuration; self-reliance within each application instead of centralized command and control; and reduced time to launch new applications.

[0116] In embodiments, the platform may automate the network lifecycle; integrate with DevOps and DevSecOps processes; avoid the need to write code for automation; avoid human error; reduce time to deployment and lower total cost of ownership; and facilitate automation; and include declarative model-driven provisioning and lifecycle management.

[0117] In embodiments, the platform may include a cloud-native, modern architecture for scalability, reliability, and geographic redundancy that may provide ease of resource management; the ability to quickly scale up / down to meet customer demands; reduced need for management of hardware lifecycles; and economical and rapid geographic redundancy.

[0118] In embodiments, the platform may be Docker container-based, providing portability, performance, agility, isolation, faster deployment, and an open source architecture, resulting in platform independence, efficient use of resources, and self-contained applications for quick and easy deployment.

[0119] In embodiments, the platform may include Kubernetes microservices that can be deployed as loosely coupled systems that are highly maintainable and testable, independently scalable, better fault-isolated, open source, and configured to reduce service interdependencies. Microservices allow different services to be scaled up and down independently, while individual services are easier to maintain and test.

[0120] In embodiments, the platform may include modern programming languages ​​such as Go, which reduce language complexity, provide native concurrency support, and may be compiled to native code rather than to a Java Virtual Machine. As such, these languages ​​may offer a smaller footprint, improved programming efficiency, faster execution capabilities, and less memory usage.

[0121] In embodiments, the platform may include a stateless network function (NF) that provides separation of logic and data so that failed functions can be restarted anywhere for continuity of service. Stateless NF performance can scale linearly and provide sessionless load balancing and relatively easy to implement fault tolerance.

[0122] In embodiments, the platform may include a horizontally or vertically scalable No-SQL database with an open source architecture that utilizes a dynamic schema and Restful APIs. In embodiments, the use of a No-SQL database makes data model changes relatively inexpensive and provides a tamper-proof binary distribution to protect data in transit.

[0123] The following subsections provide technical details of the ZTMN architecture, showing how these three design principles make the ZTMN extremely secure: Zero Trust policies drive the design of the ZTMN; the customer's own Zero Trust policies are extended to secure the mobile network; and the impact of a breach is minimized.

[0124] (Zero Trust Mobile Network Microsegmentation Designed on Zero Trust Architecture Principles) In embodiments, because the ZTMN is run and managed on a per-tenant basis and includes several microservices, the platform can dramatically reduce the attack surface using certain techniques. By these examples, the control, data, and management planes of the network may be segmented and isolated from each other with clear authentication and privilege boundaries.

[0125] To the extent that customer applications require access to LTE devices (e.g., NB-IoT or LTE / M devices), the platform's MNaaS functionality may allow the applications to run separate tenant networks to minimize exposure to the 5G network given LTE-specific vulnerabilities. These examples allow for the configuration of home routing policies between the LTE core and 5G packet core, which may ensure isolation of less secure LTE networks while running the LTE core and unifying identity and policy functions within the 5G core with superior security capabilities. In an embodiment, an example architecture for such a deployment is shown in FIG. 4 at 400.

[0126] In embodiments, the platform provides improved security by providing separate tenant networks for LTE and 5G, with home routing to the 5G core.

[0127] (Zero Trust Policy) In embodiments, all authorized operators managing tenants may be given specific access based on zero trust policies. In embodiments, operators are given access only to the micro-segmented tenants they can manage, rather than blanket access to the network management system. In embodiments, platform management and orchestration operates at two levels: an infrastructure level, fully managed by the platform, and a tenant level, performed with APIs and systems that provide enterprise-level control.

[0128] (Infrastructure Security) In embodiments, each system that connects with other systems may be issued a PKI certificate, etc. Before any system can connect to another system, its identity may be verified. All control traffic between all network functions within the ZTMN may be encrypted, for example, using AES-256 or a customer-swappable algorithm. PKI management may be provided as part of the ZTMN, and the certificate authority service component (i.e., certificate generation) may be provided through commercial contractual agreements and methodologies with the platform's certificate authority partners.

[0129] (SDN Security) In embodiments, data forwarding statistics may be applied to monitor short transition events, retransmissions, resets, reroutes, etc. In these examples, pattern recognition algorithms and artificial intelligence may then be used to detect network anomalies. If an anomaly is detected, the application may instruct a software-defined networking (SDN) controller on how to reprogram the data plane to mitigate the anomaly.

[0130] (Microservices Security) Using the 3GPP architecture, all network functions may be defined as microservices, without full control over the definition of how these microservices may be implemented. Implementations of many of these microservices may use Docker containers. 3GPP does not require isolation between microservices serving multiple customers, and some or all microservices in a typical 5G network may often share the same virtual machine. Applicant understands that if a virtual machine, a microservice, or a shared data store between microservices is compromised, kernel-level data may be exposed, potentially exposing all other microservices hosted within the same kernel.

[0131] In embodiments, the platform's ZTMN architecture can isolate microservices serving various mobile networks. In embodiments, virtual machines may be spawned on a per-tenant basis, controlling data traffic that is not only isolated at the container level (which is less secure), but also at the virtual machine level for a higher level of security.

[0132] (Encryption and Data Ownership) In embodiments, all data in motion may be encrypted within the network using AES-256 or a similar level of protection. In examples, the encryption algorithm may be swapped out for a customer-defined algorithm. In embodiments, all data at rest, including the subscriber database (UDR) and call logs, may be encrypted using customer-owned keys. In these examples, the platform's network operator may not have access to these keys. As such, data within these systems may only be read and interpreted by network functions and management software granted access to the data. This may in turn provide customers with an extremely high level of data security and sovereignty.

[0133] (Sandboxed system) In embodiments, each or all servers may run in a behavior-monitoring sandbox. In these examples, monitored behavior includes various trackable and recognizable attributes of user and device interactions with the network and core, including data flows, applications, and services. In embodiments, the sandbox may be either a container or a virtual machine, and the behavior of each system may be modeled and monitored. According to these examples, anomalous behavior may alert an administrator or isolate the sandbox from the rest of the system based on the severity of the incident. In this manner, each anomaly may be triaged and remediated to ensure that fixes are delivered consistently and atomically across all potentially vulnerable systems.

[0134] (Strong authentication management network) In embodiments, ZTMNs may deploy risk-based multi-factor authentication mechanisms in which an artificial intelligence system monitors user access patterns and calculates the risk of user activity based on platform parameters such as system logs, location, IP, and address. Through these examples, anomalous or high-risk activity can immediately trigger stronger authentication requirements of different factors to confirm a user's identity. In this way, the system can continuously learn and adapt to changing behavior and vulnerability profiles.

[0135] (Roaming Protection) In embodiments, the ZTMN architecture may allow a mobile asset from a ZTMN to roam to other carrier networks. While the mobile asset is roaming on another network, the mobile asset may still be protected with all the security controls configured and provided in its home ZTMN without compromising the latency requirements of the 5G network. With these examples, the user plane may be instantiated under the control of the enterprise, using its network and using its security profile.

[0136] (Extending customer zero trust policies to secure mobile networks) Applicant recognizes that a virtual private cloud within a public cloud allows an enterprise to protect its assets within the public cloud using enterprise-controlled software-defined perimeters and zero trust policies. An enterprise may deploy its own security software within the VPC to control and monitor data flowing in and out of the VPC, or it may alternatively use a suite of security services consumable from the public cloud provider to achieve a similar result.

[0137] (Dynamic provisioning of security boundaries around the UPF) In embodiments, the platform's ZTMN architecture enables enterprises to define and operate a software-defined perimeter around each tenant of their zero trust mobile network, including elements such as advanced firewalls, intrusion prevention and detection systems, secure socket layer offload, and data loss prevention, and dynamically adjust the security perimeter to encapsulate where mobile devices connect to the enterprise and ensure their protection. Through these examples, a software-defined perimeter can be dynamically provisioned around user plane functions to protect them from any attacks originating not only from the operator network but also from the public networks to which they connect.

[0138] (Log integration with enterprise SIEM) In embodiments, the platform can expose its logs for all relevant ZTMN functionality and logs for all user device activity to the enterprise through its API layer. According to these examples, these logs may be imported into an enterprise's security information and event management system for integration with analytics for the Zero Trust Mobile Network.

[0139] (Strong Device Authentication) In embodiments, a ZTMN may enable devices with an embedded SIM (eSIM) or embedded universal integrated circuit card (eUICC) to be provisioned or reprogrammed as needed to add or modify restrictions or permissions. This can be important for enterprise applications, including machine-to-machine (M2M) or IoT applications, to minimize the use of physical SIM cards while demonstrating improved reliability and security.

[0140] Apart from strong device identity authentication, enterprises can also deploy enterprise-managed secondary authentication and authorization, which may be managed and verified against the enterprise's own identity and access management systems. These systems may, for example, be secondary biometric authentication performed to connect to the network, or any other form of multi-factor authentication to which authorization to connect to the network is subject. For connected devices where biometric authentication is not possible, ZTMN can provide a mechanism to integrate a Trusted Platform Module (TPM) into client devices and use the TPM for secondary authentication and software validation.

[0141] (Minimizing the impact of compromise) To the extent security is compromised, applicant understands that typical activities of an attacker include exfiltrating critical data, modifying critical data to change system behavior, spreading vulnerabilities between systems, and performing activities while assuming the identity of another. In the unlikely event that an attacker is able to penetrate the minimized attack surface of the ZTMN disclosed herein, the platform may be configured to limit any potential damage as a result of a breach. In these examples, the platform may be protected from data exfiltration in that data within the platform may be stored in a manner that makes data exfiltration very difficult. All data (e.g., control, user, metadata, service data, etc.) may be encrypted using keys that belong to the tenant network and are distributed by a customer-controlled key management server.

[0142] Some typical layered data security, specifically data structures as typical data layers, are shown in Figure 5 at 500. Data is inherently insecure and is surrounded by layers of security to protect it. A breach of any layer is sufficient for a data breach.

[0143] In embodiments, the key management server may employ another layer of policy-based key distribution (e.g., as shown at 600 in FIG. 6 ), which may ensure that the keys required to decrypt the data can only be distributed to authorized systems or users. The data may be encrypted with a customer-owned key. As shown at 600 in FIG. 6 , the data may be protected by a zero-trust policy, which may require two levels of breach for data compromise. For systems accessing this data, such as a core 5G system accessing HSS data, the identity of the requesting system may be verified using a certificate. For users accessing the data, risk-based multi-factor authentication may be used to confirm the user's identity. Without these identification and authentication systems, data exfiltration alone may result in unusable encrypted data.

[0144] In embodiments, data may be encrypted with customer-owned keys and protected by zero trust policies.

[0145] (Protection from network data leakage) To the extent that an attacker has access to the network, Applicant understands that such an attacker may attempt to exfiltrate customer network data (e.g., data in motion). In embodiments, all user plane data transferred over the platform may be encrypted to prevent exfiltration of data in motion.

[0146] (Protection from attack propagation) To protect against malware propagation within the network, a smart sandbox can be used across the platform. In embodiments, all assets may be deployed in a smart sandbox to monitor for anomalous connection patterns and the propagation of any software between nodes. If such activity is detected, the anomalous server may be immediately quarantined and a new server may be restarted. Administrators can be immediately alerted to triage and remediate the issue.

[0147] (Protection against spoofing) Applicant recognizes that another common tactic of intrusion can be spoofing. In embodiments, strong user and device authentication employed by network administrators on the platform and devices and users connecting to platform tenant networks can protect against user and device spoofing.

[0148] The distinctive benefits of ZTMNs, as described in the disclosure below, can include enhanced security and the following features:

[0149] (Microsegmentation) In embodiments, the platform can be configured to isolate subsystems for security and reduce attack surface exposure. By these examples, customer data, metadata, and logs can be encrypted using customer keys, and data encryption at the tenant level can use customer-owned keys, providing control to the customer. Additionally, there can be no data exposure to the network operator or carrier network; verifiable metadata sources; centralized customer control of key management for enhanced security; threshold actions for data exposure or vulnerability; carrier network security reductions configured to avoid exposing customer data; one or more mechanisms to prevent metadata injection vulnerabilities; and the use of customer encryption keys to further protect exfiltrated data.

[0150] (Zero Trust Policy) These policies can improve access security to operations and data, reducing privileges and increasing security.

[0151] (Trust verification and encryption between network functions) In embodiments, all communications between network functions on the platform may be trusted using customer-controlled CA-issued certificates, and data may be encrypted in transit. These examples may demonstrate that these functions avoid "man-in-the-middle" attacks and data exposure through network eavesdropping.

[0152] (DNSSEC instead of DNS) In an embodiment, the Domain Name System Security Extensions (DNSSEC) may be more secure than the regular Domain Name System (DNS), which has some issues such as cache poisoning or registrar hijacking, providing better security and avoiding man-in-the-middle attacks.

[0153] (Tenant network level SDN security) In embodiments, software-defined networking (SDN) security can be configured according to the needs of individual tenant applications. Multiple levels of security classification may be supported; for example, an NC3 mobile network may be customized to use special encryption algorithms. These examples may demonstrate that automating network security configuration reduces human error and lowers operational costs.

[0154] In embodiments, an AI monitoring sandbox may be used for each microservice and process, and each microservice and all call processing may be monitored using machine learning models that baseline behavior and look for anomalies. In this way, the platform may be shown to provide better security to detect and flag anomalies, and dynamic quarantine, which may enable better forensics to understand the root cause of potential breaches.

[0155] (Risk-based continuous multi-factor authentication) In embodiments, the platform may provide access to network management and control only after multi-factor authentication. Through these examples, continuous authentication may ensure zero trust security practices, and artificial intelligence may detect high-risk behavior while improving authentication, authorization, and accounting (AAA) posture and security.

[0156] It can neutralize phishing, the most common method of breaching passwords.

[0157] (Secure Roaming Architecture) The ZTMN can support a secure roaming architecture using a home routing approach that can be immune to security compromises of visited networks.

[0158] (Log integration with enterprise SIEM) In embodiments, the platform provides the ability to integrate network logs into an enterprise's SIEM, providing a global view of enterprise security, allowing for correlation of mobile events with network events and better understanding of potential threats and attacks, resulting in a more secure network.

[0159] (Unified Performance Optimization and Organization-Controlled Security Configuration for Mobile Networks) The platform's MNaaS capabilities enable dynamic provisioning of user plane functions near wireless area networks to which user equipment may connect. In these examples, these user plane functions may be provisioned by an organization's controlled security perimeter and may be an extension of the organization's zero trust policy for mobile networks. In embodiments, the user plane always runs on an organization-owned private IP address and can traverse the organization's NAT and security perimeter before connecting to the Internet. In these examples, the data plane may never be exposed to external networks. In embodiments, the platform provides the ability to run mobile network devices within an enterprise's security perimeter while providing a unified security profile to the enterprise's mobile users.

[0160] (Customer provided firewall for UPF) In embodiments, the platform provides superior protection over traditional firewalls because SSL offloading can decrypt data for deeper malware inspection in attachments. SSL offloading can enable the deployment of data loss prevention. These features can be shown to provide a reduced likelihood of malware, a reduced likelihood of network intrusion, and a reduced likelihood of data exfiltration.

[0161] (API-driven automated provisioning framework) In embodiments, applications requiring a mobile network can directly provision these frameworks on demand, thus requiring human intervention in provisioning. In these examples, automated provisioning can reduce the number of people requiring administrative access to the mobile network, thus reducing security, exposure, and errors.

[0162] (Strong Device Authentication) In embodiments, the platform may require the smartphone to pass biometric authentication or have MFA provisions in enterprise authentication, authorization, and accounting for better security controls.

[0163] (Enhance security by securing IoT devices with enterprise-managed, pre-provisioned passwords) In embodiments, the platform may use pre-provisioned passwords to provide an alternative to carrier-controlled SIM-based authentication. According to these examples, the platform may have the ability to use enterprise-managed authentication methods.

[0164] In embodiments, the platform may be a standalone cloud-native solution compatible with 3GPP standards and built on commercial off-the-shelf (COTS) hardware and open-source software platforms. The baseline core network may be 3GPP Release 16.0, and PKI functionality may be based on Classified Commercial Solutions for Computing (CSfC) standards. All cloud and edge server systems may follow the Kubernetes architecture and APIs. The gNR radio units may be provided by COTS suppliers supporting 5G standalone architectures and interfaces.

[0165] (Potential end-item applications of the proposed new technology) In embodiments, 5G network enhancements may enable enterprises to automatically provision and deploy customized, highly secure networks based on application requirements to test and deploy next-generation applications that require ultra-low latency and reliability (ULLR) and high bandwidth. Examples of such end-user applications are detailed below.

[0166] Applicant understands that multiple applications with varying security requirements may require 5G network coverage within a base. By way of example, training applications that may use drones to capture video, as well as fixed-position full-motion video cameras, may require high bandwidth and edge networking to store the video locally. Further examples include tracking applications that need to track personnel location; low-bandwidth applications that do not require edge computing; immersive simulation applications that use AR / VR and may require high bandwidth; and edge storage and computing capabilities.

[0167] In embodiments, the platform can share the physical infrastructure within the base across all three applications without sacrificing security or service levels for each application. In these examples, each application may create a separate tenant network for itself, limiting coverage to specific areas within the base according to each application's needs. Furthermore, access to each network can be configured accordingly. For training and simulation applications, the platform may specify in its IP configuration a high bandwidth allocation and access to the local edge computing infrastructure. For tracking applications, the platform may specify low bandwidth needs and no IP access to the edge computing infrastructure.

[0168] (Network isolation for each application) In embodiments, the platform may be deployed with customized network policies that may distribute control to those with the most knowledge of the needs and operations. The platform may have a low total cost of ownership due to a shared infrastructure, and in examples, RAN access may be limited to the coverage area of ​​each tenant network.

[0169] (Performance Improvements and Metrics) In embodiments, the platform's core network can support system scaling to millions of busy hour call attempts (BHCA). The platform system may be based on a Kubernetes server cluster, and all functions may be relocatable to a cloud architecture for scaling. Platform metrics may include processor load and Erlangs as a function of CPU load; signaling load, SIP, SMS, and MMS processing as a function of CPU load; user plane load as a function of CPU load; user data management (e.g., read / write throughput rate) as a function of CPU load; cloud-RAN scalability; access and mobility management function (AMF) load per BTS as a function of CPU load; and management and orchestration (MANO) load as a function of CPU load.

[0170] As detailed herein, there are additional metrics that are particularly relevant to hardening the security of ZTMNs.

[0171] (ZTMN provisioning and misconfiguration events) In embodiments, ZTMN includes management, application, and SIEM support for reducing cross-site scripting (XSS) and cross-site request forgery (CSRF) events. The platform may also be configured to reduce vulnerabilities due to malicious application events, missing access control events, insecure object reference events, remote code execution, server-side request forgery events, data exfiltration prevention, authentication and authorization events, data privacy, protection, and metadata vulnerability events, and redirect and forward events.

[0172] (User data storage and management) In an embodiment, the platform may reduce sensitive data exposure events.

[0173] (Device spoofing) In embodiments, the platform may reduce multi-factor authentication events; secondary authentication events; and 3GPP authentication and key agreement events.

[0174] (Availability Attack) In an embodiment, the platform may reduce geographic redundancy.

[0175] In embodiments, the platform can provide a Mobile Network as a Service (MNaaS)-based platform tailored to the nuclear command, control, and communications (NC3) security requirements of various defense customers. In embodiments, the flexible cloud-based architecture can seamlessly integrate with any number of public or private cloud deployments, radio technologies, and other wireless operator infrastructures. The platform provides customers with the ability to plan and deploy radios and antennas to meet their coverage needs, rapidly creating a secure, powerful, and scalable 5G network that is launched via one-click provisioning. In embodiments, the platform can handle any number of customers using its auto-scaling capabilities, dramatically lowering the barrier to entry for managing and deploying a secure network for critical communications.

[0176] (strengthened) In embodiments, the platform may offer its ZTMN architecture, which may also support enterprise trust options, enterprise security transparency, and extensive options for virtual private cloud and multitenancy operations. In embodiments, the platform may use a DevSecOps development approach and continue to upgrade its core with additional enhancements. Such enhancements may include: low Earth orbit (LEO)-based backhaul to provide redundancy and remote connectivity; reconfigurable FPGA-based accelerator cards on every server; hardware-based security and application acceleration capabilities directly in the network; physical security across the non-deterministic computing platform; tamper resistance necessary to prevent system breaches; two-person control of critical network functions to prevent insider threats; a personnel integrity program to ensure network operators operate with the highest integrity; extreme vetting to ensure employees are of the highest caliber; network-wide behavioral analysis to monitor insider threats; a counterintelligence program to ensure all elements of the supply chain are verifiably secure; combat-grade system redundancy; and EMP hardening.

[0177] In embodiments, the 5G telecommunications network and computing platform may provide a 5G wireless network based on a C-RAN architecture and integrated fronthaul. In embodiments, the platform may provide integrated connectivity to the 5G backbone using either wireline, fixed wireless, or LEO-based backhaul. In embodiments, the platform may provide an edge computing cloud supporting various architectures, such as container and edge architectures supported by all public clouds. In embodiments, the platform may provide connectivity to one or more customer or user data centers through one or more virtual or public clouds via a secure and encrypted software-defined networking (SDN) layer. In embodiments, the platform may provide an encrypted storage platform that may be secured using a customer key server. In embodiments, the platform may provide a rapid provisioning infrastructure capable of launching an entire micro-data center by securely authenticating itself and connecting one or more edge devices to the 5G communications network and computing platform of the present disclosure.

[0178] In embodiments, a 5G communications network and computing platform may provide a dynamic spectrum management (DSM) system for spectrum harvesting through allocation and aggregation of contiguous and non-contiguous licensed, unlicensed, and shared spectrum bands. In embodiments, the platform may be configured to provide one or more kits to facilitate on-the-fly delivery of secure, dedicated 5G capabilities to the platform integrated into one combined solution with automated remote provisioning.

[0179] In embodiments, 5G communications networks and computing platforms may be configured to minimize the attack surface of the platform by employing one or more of the following:

[0180] (Purpose-based segment system) In embodiments, 5G communications networks and computing platforms may be purposefully segmented into management plane systems, network plane systems, operational systems, and IT systems. In these examples, each system may be separated with distinct authentication and authorization boundaries. If one system is compromised, the risk is contained to that system and not propagated to other systems.

[0181] (Unified Architecture) In embodiments, the 5G telecommunications network and computing platform may include a unified, dedicated, and secure architecture for managing and administering users, servers, endpoints, and software for all segmented systems.

[0182] (Smart Sandbox) In embodiments, 5G telecommunications networks and computing platforms may deploy managed "smart" sandboxes in that each server may run in a behavior-monitored sandbox. In embodiments, the behavior-monitored sandboxes may function as containers or virtual machines, and the behavior of each sandbox may be modeled using machine learning techniques for anomalous behavior. By these examples, anomalous behavior may also be monitored so that alerts can be sent to administrators, etc. In embodiments, detection of anomalous behavior may trigger the platform to isolate the sandbox from the rest of the platform based on the severity of the incident. By these examples, the anomaly may be triaged and remediated, and fixes may be applied across all potentially vulnerable systems.

[0183] In embodiments, the platform may be configured to provide a standalone 5G networking and computing platform with a significantly reduced attack surface and end-to-end security. This platform may deploy a secure standalone architecture 5G network for defense, government, and commercial customers where security and reliability are paramount. This platform may be configured for nationwide deployments and for deployment in other segments focused on rural connectivity and strengthening secure facilities around military bases. As described herein, this compute platform can address security vulnerabilities inherent in many network and computing architectures by building security into the network itself.

[0184] In an embodiment, the platform may be configured with a standalone 5G architecture that provides an end-to-end secure standalone (SA) 5G network optimized for critical next generation applications, which in an embodiment includes a standalone radio access network, a hybrid transport network, a 5G mobile core, and various edge computing sites.

[0185] In embodiments, the platform may comprise a unified network, cloud, and edge by providing a secure distributed edge network with integrated RAN, cloud, and LEO backhaul with a customer experience that includes a seamless provisioning awareness. These systems and methods may enable next-generation low-latency applications and have the ability to set up 5G networks on the fly for remote operation.

[0186] In embodiments, a platform with minimized attack surface can be configured such that systems and networks are purposefully segmented into management plane systems, network plane systems, operational systems, and IT systems, each of which may be separated by distinct authentication and authorization boundaries and protected by smart sandboxing technology, secure DNS, and encrypted I / O.

[0187] In embodiments, the platform may be configured with pervasive security at all levels by deploying context-based, multi-factor security protocols powered by artificial intelligence and machine learning for threat protection and detection. In a further example, electromagnetic pulse (EMP) shielding may be used to protect cell sites. Additionally, redundancy and resilience can be built into all elements in the network, including redundant backhaul links via LEO satellites.

[0188] In embodiments, the platform may be configured to minimize the impact of security breaches by adopting a data protection paradigm where data is isolated from the broader application context and all stored data may be parametrically distributed with multi-level encryption.

[0189] In embodiments, the platform may be configured with an improved data governance paradigm, with an approach to data governance focused on driving actionable insights for the military and end users. In many examples, the platform may deploy a policy of not monetizing data or sharing it with any third parties. In many examples, the platform can deploy full autonomy and control of data for users, including a default opt-out policy, automatic clearance of data tracking, and privacy-controlled containers.

[0190] In embodiments, the platform consists of secure devices to enhance the security of existing devices and endpoints through proactive efforts such as virtualization, feature hardening, forced updates, and vendor restrictions. Through these examples, a variety of fully secure devices such as smartphones and wearables may be deployed with cloud-based code, centralized updates, registration, and limited on-device storage.

[0191] In embodiments, the platform may be configured with secure supply chain capabilities that enable engagement with trusted entities to build a strong and widespread ecosystem for 5G technology.

[0192] In embodiments, 5G communications networks and computing platforms may be configured to provide pervasive security at all levels by employing one or more of the following:

[0193] (User Security) In embodiments, 5G telecommunications networks and computing platforms may employ context-based security and identity management for all users, such as employees, administrators, and subscribers. In embodiments, the platform may provide a risk-based multi-factor authentication mechanism in which an artificial intelligence (AI) system monitors a user's access patterns and calculates the risk of their activities based on parameters such as system logs, location, IP, and address. In these examples, unusual or high-risk activity can immediately trigger stronger authentication requests of different factors to verify the user's identity. In embodiments, 5G telecommunications networks and computing platforms may continuously learn and adapt to changing behavior and vulnerability profiles. In embodiments, the platform may protect user identities based on a layered approach to establishing a root of trust. In these examples, a first layer of protection may be to define anti-tamper mechanisms for all subscribers. In many examples, standards such as Common Criteria and FIPS 140-2 may be adopted. In embodiments, a second layer of protection may be configured to protect subscriber identities. In embodiments, subscribers may be identified using eSim devices. In embodiments, the platform may require context-based identity management, including substantial data pooling, use of graph databases, and cloud extensions.

[0194] (Infrastructure Security) In embodiments, 5G communications networks and computing platforms may provide infrastructure security in that all servers associated with the platform may deploy standard security measures, such as encrypted disks and images, locked BIOS, etc. In embodiments, many systems of the platform may be deployed and run within a smart sandbox where behavior can be monitored. In embodiments, the platform may first deploy software changes to servers, which may be verified in a shadow system and signed with a certificate issued by the platform, before any server accepts the software and patches. In embodiments, the platform may include a constellation of servers that can connect exclusively to other trusted servers with authenticated credentials.

[0195] (Network Security) In embodiments, 5G communications networks and computing platforms may deploy improved network security in that all segments of the platform may be protected using standard network security infrastructure, such as next-generation firewalls, intrusion detection and prevention systems, etc. In embodiments, the platform may deploy advanced security systems that can utilize unsupervised learning with advanced network traffic analysis that can be used to protect the platform's network.

[0196] (Application Protection) In embodiments, 5G communications networks and computing platforms may provide application protection in that all applications, including vendor applications and internally created applications, may be deployed in a managed "smart" sandbox whose behavior may be monitored by the platform. The managed sandbox may model the behavior of each application server and detect anomalies. In embodiments, identified open source components and software of the platform may undergo separate security validation and certification, and may do so in the managed sandbox. In embodiments, all applications may be recompiled using secure versions of open source software.

[0197] (Premises Protection) In embodiments, 5G communications networks and computing platforms may deploy premises protection at data centers and employee locations associated with the platforms and may employ rigorous security protocols such as facial recognition, biometric authentication, and other next-generation identity management solutions.

[0198] (Advanced Threat Detection and Response) In embodiments, 5G telecommunications networks and computing platforms may include AI / ML-based advanced threat detection and automated response systems that may monitor activity across users, infrastructure, networks, and applications. Through these examples, potential threats may be triaged, and automated responses may trigger learned responses to contain and manage the threat.

[0199] (Minimizing the impact of information leakage) If an attacker does compromise the platform, the platform may be configured to limit the damage and protect the integrity of the network, systems, and data from the following vulnerabilities:

[0200] (User data leakage) In embodiments, 5G communication networks and computing platforms may be configured to have all disks within the platform encrypted, and where feasible, stored data may be split into multiple components and encrypted with different keys, thereby protecting against user data exfiltration. In these examples, key management servers may employ policy-based key distribution systems that ensure the necessary keys are only available to decrypt data distributed to authorized systems or users. Without authentication, data exfiltration may result in unusable encrypted data.

[0201] (Network data leakage) In embodiments, 5G telecommunications networks and computing platforms may be protected from network data exfiltration in that the platforms may be configured so that all data passing through the platforms is seamlessly encrypted at the network ingress node and decrypted at the network egress node. In many examples, automatic virtual private network (VPN) tunnels may be established. In examples where traffic is detected between two secured devices, an end-to-end VPN tunnel may be set up between these devices, allowing for routing of not only data but also voice traffic. In examples where traffic is between a secured device and another device, the secured device may establish a VPN between itself and the furthest network node that the data traverses on the platform before entering a network not associated with the platform. In examples where traffic is between a secured device and a server endpoint associated with the platform, a VPN tunnel may be established between them to protect the network traffic. In examples where traffic is between a secured device and another server associated with the platform, optional VPN software may be made publicly available. In this example, the VPN software (or a portion thereof) may be downloaded and installed on any server. If this is done, the secured device may detect the presence of such a VPN endpoint and automatically create a VPN tunnel between them.

[0202] (Attack propagation) In embodiments, 5G communications networks and computing platforms may be configured to minimize attack propagation by using platform-wide, managed "smart" sandboxes to protect against propagation and malware by monitoring anomalous connection patterns and transaction behavior between nodes. When activity is detected, for example, an errant server may be immediately quarantined and a new server restarted. These examples allow administrators to be immediately alerted to triage and remediate the problem.

[0203] (Impersonation) In embodiments, 5G telecommunications networks and computing platforms can be configured to reduce the effectiveness of spoofing by implementing multi-factor user authentication based on context and biometrics for both users and employees associated with the platform, making spoofing nearly impossible.

[0204] In embodiments, 5G communication networks and computing platforms can deploy data governance methods and systems, recognizing that today's user data can be collected constantly by multiple entities and at various levels.

[0205] In embodiments, 5G communications networks and computing platforms may adopt an approach to data governance through the protection of user data by maintaining a position regarding the security and visibility of user data that may be stored within or associated with the platform, as well as the protection, prioritization, and autonomy of personal and behavioral user data. In these examples, a distributed data management approach enables data insight, availability, and protection, allowing many users to maintain full control over both their information and infrastructure as IT environments modernize and transform. Once data is visible, agencies can determine who owns the data, who has access to it, and how it is classified by value and risk. Policies regarding access to data can be assigned for user approval, access time requirements, retention, and disposal, and enforced to comply with security and governance requirements.

[0206] (Governance of stored user data) In embodiments, 5G telecommunications networks and computing platforms may deploy governance of stored user data in that the platform may store various information about users on its servers for basic network usage. By way of example, this data may reflect general information about the user, such as demographic information, information about the multiple devices and networks the user accesses on the platform from the user's connection, location, and communication (voice, text, and data) history, connection times, volume, etc.

[0207] In embodiments, user data associated with the platform may be stored and used solely to verify network usage by users for billing and user experience purposes. In embodiments, the platform may provide a portal for users to inspect data stored about them on the platform and may allow users to request deletion of such data beyond that required to be stored by the platform for billing and operational purposes.

[0208] In embodiments, all access to user data by people or representatives associated with the platform may be conditional and governed by robust access control and governance mechanisms. In many instances, all personally identifiable information (PII) may be stored encrypted and masked before leaving the platform.

[0209] (Corporate Governance and User Autonomy) In embodiments, 5G telecommunications networks and computing platforms may be deployed with enterprise governance and user autonomy in sharing user data, such as critical components of user data, which may include application data, site data, and location data, among other data sources. In embodiments, the platforms may be configured to allow users to control how their data may be used by doing two things: (i) increasing awareness of what information may be collected by sources and providing mechanisms for users to become more involved in managing or limiting data collection; and (ii) providing mechanisms by which users can limit the extent to which information may be shared with websites, applications, and the like.

[0210] (User control of data sharing) Modern data collection activities by digital services can be difficult to restrict because use of the services occurs across networks and may be independent of the platform. Nevertheless, platforms may need immediate and long-term measures to help manage the inherent risks associated with data sharing.

[0211] (default opt-out) In embodiments, 5G communications networks and computing platforms may provide one immediate solution in that data flow between non-Google Android manufacturers and smartphones may be blocked unless the user opts in. Only OS updates may be allowed to be downloaded by the smartphone.

[0212] (Automatic Clearance of Data Tracking) In embodiments, 5G communication networks and computing platforms may offer a longer-term solution in that browser applications may provide users with the ability to manage cookie and data sharing permissions for digital services. For unauthorized data, the platform may automatically clear any data tracked for that user. In embodiments, the platform may deploy machine learning methodologies to provide users with meaningful insights for informed data sharing management.

[0213] (Privacy-Managed Container) In embodiments, 5G communication networks and computing platforms may be configured with a privacy-controlled container on top of a base smartphone OS to run services and applications. In these examples, this container may mask user data from websites to maintain site functionality while ensuring user privacy.

[0214] (Privacy protection) In embodiments, 5G telecommunications networks and computing platforms can identify and provide users with social and legislative opportunities to promote cyber privacy and informed data sharing initiatives.

[0215] In embodiments, the 5G communications network and computing platform may be configured to provide device security in a series of steps that enhance device security, including enhancing the security of existing Android® devices and deploying platform-specific devices with enhanced security features.

[0216] (Enhancing security for existing Android devices) (Virtualization) In embodiments, 5G communications networks and computing platforms can enhance the security of existing Android devices by virtualizing core functions such as telephony and messaging and running these applications on a Type 1 hypervisor with its own real-time operating system (RTOS). By limiting the Android operating system's ability to extract and monitor such applications, the security of the platform devices may be further enhanced, which in turn may significantly limit the number of available attack surfaces.

[0217] (Feature enhancements) In embodiments, the 5G communications network and computing platform may provide feature enhancements by understanding that, on average, each Android release may include 2,500-3,000 changes within Android, ranging from kernel and BSP updates to entirely new APIs, along with a certain amount of virgin code inserted into the system that may be untested and unhardened. In embodiments, the platform may facilitate extending the existing Android testing framework with customer test suites so that penetration testing vulnerabilities can be identified early and addressed before new devices are released.

[0218] (Forced update) In embodiments, 5G communication networks and computing platforms may be deployed with policies that establish mandatory updates to ensure devices remain up to date and that security patches can be applied within a minimum window, such as within 24 hours. In these examples, mandatory update policies can reduce user prompts that could delay or prevent important security updates.

[0219] (Vendor Restrictions) In embodiments, 5G communications networks and computing platforms may be deployed with vendor restrictions, such as limiting Google's ability to offload data from devices associated with the platform to prevent sensitive information from being inadvertently shared with third parties. By way of these examples, multiple approaches may be implemented on the platform to limit this ability, from deep pack inspections to modifying the Radio Interface Layer (RIL) stack to removing certain features or applications.

[0220] In embodiments, the 5G communications network and computing platform may include endpoint devices such as mobile phones and wearables. In embodiments, the platform may provide a standalone secure 5G network that may provide a dedicated real-time network slice, allowing the platform to host most of its operating system in a secure cloud environment.

[0221] In embodiments, 5G communications networks and computing platforms may be associated with and cooperate with secure endpoint devices that may run on a basic RTOS with minimal functionality. In embodiments, the endpoint devices may incorporate predictive artificial intelligence that may be configured to learn and predict user behavior in order to manage and prioritize network requirements and OS functionality. In embodiments, the endpoint devices may provide some of the following advantages:

[0222] (Cloud-based code) In embodiments, 5G telecommunications networks and computing platforms may be configured to minimize software running directly on the hardware without network interaction to reduce the number of attack vectors that hackers can seek and exploit. In embodiments, entities supplying platform-related devices may minimize the need to invest in long-term development and validation of functionality. When functionality is ultimately needed, it may be implemented when invoked by a user.

[0223] (Centralized updates) In embodiments, 5G communications networks and computing platforms may provide centralized updates so that updates made to core cloud-based OS components may be immediately available to all devices, unlike current mobile devices where core OS updates and security patches often take 4-6 months to be applied by users.

[0224] (Device Registration) In embodiments, 5G telecommunications networks and computing platforms may be associated with devices that can register with their respective network slices, providing an opportunity for verification that occurs each time a slice may be accessed to prevent compromised network access.

[0225] (limited device storage) In embodiments, 5G telecommunications networks and computing platforms can be configured so that if a device is lost or compromised, the amount of information it contains and its usefulness to another person is minimized.

[0226] (Reducing development burden) In embodiments, 5G communication networks and computing platforms may be configured with cloud-managed OS components, significantly reducing the demand for hardware and software development. These examples allow the development of new devices to decouple hardware capability development from software, allowing the software to inherently respond to hardware features and functionality. Such platform-associated devices may reduce time-to-market for new hardware and maximize effectiveness in maintaining the overall end-to-end security of the network. In embodiments, platform-associated devices may be smartphones and wearable technologies, including fully automated wearable devices with significantly less manual involvement. In embodiments, wearable electronic devices may track daily fitness, activity, calorie expenditure, sleep quality, heart rate, various vital parameters, and the like, to provide insight into the user's overall health. These devices may use non-invasive biosensors, such as optical, motion (e.g., accelerometers, gyroscopes, and magnetometers), galvanic skin activity sensors, body hydration, heart rate, and the like.

[0227] In embodiments, 5G telecommunications networks and computing platforms and associated devices may be configured to connect to various communication layers of the platform, making collected data easily accessible to remote nodes within the network. In embodiments, this data integration may allow for the inclusion of new biosensors to provide increasingly comprehensive assessments of overall health. New physiological biosensors may include blood glucose levels, blood pressure, blood oxygen saturation, etc.

[0228] In embodiments, many examples may include military use cases. Military personnel experience significant physical and mental stress daily, often under extreme environmental conditions, with a high risk of injury. Through these examples, the platform may be configured with a condensed view of both the individual and larger units to better equip leadership with information to proactively address overall health.

[0229] (Architecture Overview) In an embodiment, a 5G communications network and computing platform deploys a standalone 5G architecture to provide secure, dedicated, end-to-end communications and computing. In an embodiment, a platform such as that depicted in FIG. 7 may deploy pervasive security across all of its components, as shown at 700. For its users at 720, the platform may deploy multi-factor, context-aware authentication, including biometrics. For platform devices at 722, the platform may deploy endpoint network isolation technology with secure user factors monitored by an expert system managed by an artificial intelligence module. For the radio access network deployed by the platform at 724, the platform may deploy protected, automated, secure, tamper-proof sites that can be protected against electromagnetic pulse and similar forms of attack. At 724, the platform may also deploy defense-grade micro data centers with an integrated, centralized or cloud-based radio access network (C-RAN). At 724, the platform may also deploy ultra-low latency encrypted transport for fronthaul and backhaul. For one or more cores of the platform 730, the platform may deploy a virtualized environment with a security-first encryption design, secure virtual network functions, a highly secure cloud platform architecture, secure integrated network service orchestration, etc. If desired, the platform may access various internet destinations external to the platform at 740.

[0230] In embodiments, 5G communications networks and computing platforms may deploy layers of protection across the platform, as depicted at 800 in FIG. 8 . In embodiments, the platform may deploy process-level protection at 860, from which the platform may build and layer protection. According to these examples, the process-level protection at 860 may be deployed by the platform and may include sandboxing. According to these examples, the platform may also be configured to protect key processes with hardened sandboxes that may operate below the virtual machine level to protect against virtual machine attacks and vulnerabilities in the operating system itself. In embodiments, the platform's process-level protection may also include containers, which may ensure that key processes are isolated and immune to spoofing, malware intrusion, data exfiltration, and the like. In embodiments, the platform's process-level protection may also include monitoring the behavior of key processes to ensure they comply with expected ranges of processor load, input / output access, call model flow, and the like. In embodiments, the platform's process-level protection may also include recording data upon detecting an attack, so that the platform can record and report attack information. In embodiments, the platform's process-level protection may include a clean slate reset after isolating and logging an intrusion, where the platform may be configured to purge the intruding or malicious process and return to a predetermined original state, a "clean slate."

[0231] In embodiments, a 5G communications network and computing platform may deploy layers of protection across the platform, as depicted at 800 in FIG. 8 . In embodiments, the platform may deploy a data protection level of protection at 870, from which the platform may continue to build and layer protections. By way of these examples, the data protection level at 870 may be deployed by the platform to protect against exfiltration, malware, and the like. In embodiments, the data protection level at 870 may include data model protection, which may mandate logical and physical separation of data, metadata, and service function data. In doing so, requirements for logical and physical separation of data, metadata, and service function data may impact compile-time data structures and runtime data access. In embodiments, the data protection level at 870 may also include data distribution protection, in that data, metadata, and function data may be maintained in a distributed manner (i.e., across multiple stores and multiple clouds) or may be maintained in a chaotic state at rest (i.e., encrypted). In an embodiment, the data protection level at 870 may also include data access protection in that the enhanced data object storage hardware technology and access software technology may not be based on x86 hardware or a processor may be used simultaneously to access data, metadata, and functional data in real time.

[0232] In embodiments, a 5G communications network and computing platform may deploy layers of protection throughout the platform, as depicted at 800 in FIG. 8 . In embodiments, the platform may deploy I / O process and communication level protection at 880, from which the platform may continue to build and layer protection. By way of these examples, I / O process and communication level protection at 880 may be deployed by the platform to ensure that all 5G core network packet layer and radio access network (RAN) communications with the internet, the RAN, and one or more cores can be protected from attack, copying, or spoofing. In embodiments, I / O process and communication level protection at 880 may include hardened I / O hardware and technology that may not be based on x86 hardware, operating systems, or software to eliminate currently known fileless, file-based, polymorphic, and other malware attack vectors. In embodiments, I / O process and communication level protection at 880 may include encryption / decryption algorithms with the ability to add class 6 and 7 key technology, including quantum keys, to protect against unauthorized access. In embodiments, the I / O process and communication level protection at 880 may include link-level optical communications with quantum-level technology to secure long-distance links over fiber between the RAN and one or more cores for backhaul between the platform's core and Internet destinations outside the platform, or between the platform's core and edge network devices also associated with the platform. In these examples, any attempt to "listen" on the link will result in the channel dying. In embodiments, the I / O process and communication level protection at 880 may include micro data centers, and all cloud extensions through the platform's micro data centers may use the new link-level protection and secure I / O protection.

[0233] In embodiments, a 5G telecommunications network and computing platform may deploy layers of protection across the platform, as depicted at 890 in FIG. 8 . In embodiments, the platform may deploy protections for user devices and activities at 890, from which the platform may continue to build and layer protections. By these examples, the protections for user devices and activities at 890 may be deployed by the platform with little impact to current device hardware or firmware performance, and such that all users of the platform are unaware of the protections being put in place to improve prevention of any endpoint attacks and vulnerabilities. In embodiments, the protections for user devices and activities at 890 may include automatic virtual private networking, in which when two users are connected on the platform, all users and their devices are automatically protected by a virtual private network (VPN) when making calls, sending messages, receiving or sending data, etc., without any additional steps by the users. In embodiments, protection for user devices and behavior at 890 may include behavioral monitoring, where all users on the platform (and those outside the platform but connected to it) may be evaluated via endpoint and "man-in-the-middle" behavioral systems to ensure that individual call models are in accordance with their predetermined behavior. In these instances, any anomalous behavior may be caught and the endpoint reset.

[0234] In an embodiment, protection for user devices and actions at 890 can include network isolation using endpoint isolation software and methodologies to prevent users from uploading any malware that could affect one or more cores of the platform and the entire network.

[0235] In embodiments, 5G telecommunications networks and computing platforms may deploy layers of protection throughout the platform, as depicted at 810 in FIG. 8. In embodiments, the platform may deploy cloud and Domain Name System (DNS) level security at 810, from which the platform may continue to build and layer protection. By way of these examples, cloud and DNS level security at 810 may be deployed by the platform to ensure all user and device level communications can be protected at the signaling and control plane level, as well as at the data and user plane level, with the platform's core. In embodiments, cloud and DNS level security at 810 may include the deployment of a secure domain, in that the cloud in which the platform resides may be a secure domain cloud, which ensures that requests for all sub-domains, client-side devices and websites, signaling requests, and services may be architecturally cleared by one or more cores of the platform at the top-level DNS to ensure signaling cannot be spoofed or altered, as may be more common when routing requests over other networks. In embodiments, cloud and DNS level security at 810 may include a session border controller. In these examples, the platform may maintain its own session border controller (SBC) as part of the secure domain with or without a top-level domain to ensure control over which Internet federations the platform may support and to ensure that all inter-communication links may be subject to behavioral modeling as described herein.In embodiments, cloud and DNS level security at 890 may include behavioral modeling in that users on the platform and users off the platform but connected to it may be evaluated via a "man-in-the-middle" behavioral system to ensure that individual call patterns follow their predetermined behavior. In these instances, any anomalous behavior may be caught, the communication cleared, and the automatic VPN terminated.

[0236] In embodiments, 5G telecommunications networks and computing platforms may deploy layers of SIP security protection to ensure that all communications can be protected in the signaling and control planes. In embodiments, SIP may include deployment of enhanced protocols to ensure that SIP resolvers and proxies have not been compromised by rogue serving networks or by rogue SIP resolvers, such as by maintaining lists of trusted and secure proxies for SIP resolvers, maintaining grey and black lists of suspect or completely isolated proxies to protect against rogue proxies, using "callback" techniques to mitigate against grey and black listed proxies, performing outbound authentication using trusted proxies and routes, etc. In embodiments, the enhanced SIP security protocols may be maintained as part of the SBC, as part of the secure domain, as part of the top-level domain, or as part of the Session Mgmt function in the core network.

[0237] In embodiments, 5G communications networks and computing platforms may deploy a layer of SIP security protection to ensure all communications can be protected in the signaling and control planes. In embodiments, enhanced SIP security protocols and SIP resolvers may be deployed in LEO constellations where the 5G core network may use its own space-borne proxies and earth station gateways, or may use bilateral communications with specific trusted terrestrial service networks or SIP resolvers that bypass unknown, unverified greylist or blacklist proxies, or where source identity may not be verified using the enhanced SIP security protocols. In embodiments, 5G communications networks and computing platforms may provide a secure, dedicated 5G cloud to enhance data communications security. At the platform security layer, the platform may be configured with the ability to logically "firewall" one or more cores of the platform within a secure domain and secure all bearer traffic, as depicted at 900 in FIG. 9 . According to these examples, the secure domain may allow one or more cores of the platform to resolve and control all DNS queries in the secure domain from its global directory. Furthermore, the secure domain of the platform may act as a logical partition and firewall within the global directory that prevents higher-level DNS servers from controlling all aspects of the actual bearer traffic once a call path is established through the platform, e.g., at 902. In embodiments, the secure domain may automatically provision a VPN to platform endpoints, e.g., at 910 and 912, without requiring explicit VPN configuration at the platform endpoints, provided the platform endpoints remain authorized and authenticated on one or more cores of the platform 920.In doing so, this automatic VPN functionality can be controlled by the platform. Referring to FIG. 9 , the platform secure domain may automatically provision a VPN to the platform endpoints, e.g., at 910 and 912. The local peer may then see a software-defined network service request from the local peer in response to a connection request from the remote peer. In embodiments, the local peer may also connect to the remote peer via an encrypted connection to an optional relay service. In these examples, the platform with its secure domain may be configured such that the platform's session border controller and SIP translations can be processed without involving clouds and session initiation protocol resolvers unrelated to the platform. In these examples, the platform with its secure domain may also be configured to provide automatic VPN protection through an architecture with a DNS server within the secure domain, which may be dedicated and exclusive to the platform.

[0238] In embodiments, 5G telecommunications networks and computing platforms can provide public security and reliability using network infrastructure that allows additional measures to prevent the porting of non-owned and operated networks without user consent. In doing so, the platform can ensure highly secure and trusted private networks to reduce or eliminate fraud in critical markets, such as defense, utilities, banking, logistics, and healthcare. Through these examples, the platform may provide increasing levels of security and reliability, as depicted in FIG. 10 at 1000. At a first level, at 1060, all virtual applications may require a "trusted network" on the platform, automatically instantiating new layers of security and encryption. In doing so, virtual applications may be configured to protect clients and servers by requiring creation and provisioning to run only on the platform. At an intermediate level, at 1070, the platform may offer only "owned and operated" domains, in that the platform establishes a trusted network boundary to allow other operators to support more trusted applications. In this arrangement, the platform may require transaction fees. At the highest level, 1080, the platform can provide managed network security, with the internal servers and software being "owned and operated" by the platform, providing significant security that is fully managed by the platform. In this arrangement and at this highest level of security at 1080, the platform may be configured to reject authentication-handoffs for signaling and routing to networks outside of the designated home network.

[0239] In embodiments, a 5G communications network and computing platform may provide enhanced security to enterprise clients, as depicted at 1100 in FIG. 11. The platform may use virtual customer premises equipment, network function virtualization, and other virtualization of network functions at 1110 to provide secure and dedicated connectivity to users with, for example, distribution centers. In embodiments, secure domain server technology may be deployed to run only on operator-owned networks. In these examples, an "owned and operated" secure network running the secure domain in a physically secure data center location can increase enterprise confidence in the use of secure domain technology.

[0240] In embodiments, a 5G telecommunications network and computing platform may provide protection for all inputs and outputs to and from one or more cores of the platform for all control of user plane traffic. In embodiments, the platform may protect query transactions between components of one or more core elements of the platform, such as subscriber data access, device validation, and authentication data access. In embodiments, the platform may integrate field programmable gate arrays (FPGAs), such as DirectStream FPGAs, into one or more cores of the platform in the platform packet gateway for the user plane and the signaling gateway for the control plane interface. In embodiments, the platform may integrate FPGAs, such as DirectStream FPGAs, for input / output between one or more core components of the platform, such as policy data access, home subscriber server subscriber data access, and authentication data access. In embodiments, the platform may implement support for automatic VPN client integration in the secure domain. In embodiments, the platform may implement Session Initiation Protocol messaging on the FPGA for the signaling gateway. In embodiments, the platform may implement instant messaging service messaging on the FPGA to support multimedia transport for the packet gateway.

[0241] In embodiments, the platform may employ secure domain server technology that may only operate on an operator-owned network. In these examples, an owned and operated secure network that operates a secure domain registry and servers in a physically secure data center location may improve enterprise confidence in the use of secure domain technology and increase the level of security and reliability. In embodiments, data at rest may be secure because the data center where the secure domain registry / server resides may be in an owned and operated facility with physical and local IT security controls. In embodiments, data in flight may be secure because payloads are carried on owned and operated network infrastructure without cross-connections to foreign facilities or networks. In embodiments, the platform may protect certificate and key exchanges by restricting operations to the owned and operated network. In embodiments, the platform may employ authentication gateways, core routers, session border controllers (SBCs) / session initiation protocol (SIP) resolution servers, and route reflectors that follow the same secure domain DNS as on the owned and operated network. Additionally, the platform may function as a secure domain SIP resolver.

[0242] Referring now to the example of FIG. 12, a platform's dedicated, secure, owned and operated components and systems are shown at 1200 that may offer further enhanced security for Session Initiation Protocol (SIP). As described further in this disclosure, FIG. 12 illustrates a dotted line referencing an example "callback" SIP resolution path that bypasses blacklisted proxy servers, compared to a dotted line referencing the original SIP path. The network in FIG. 12 illustrates a two-party trusted interface where data may be transmitted via SIP resolver interconnection carriers (IXCs) a, m, n, and x across a terrestrial SIP proxy. For the original SIP path, transmission may be from a first user device through SIP resolvers IXC a, m, n, and x and through a secure domain (e.g., between SIP resolver IXC n and SIP resolver IXC x) to a second user device. A LEO SIP proxy may also be included to provide at least a bypass path. In an example "call-back" SIP resolution path, transmission can occur from a first user device through SIP resolvers IXC a, m, and x, through a secure domain (e.g., between SIP resolver IXC m and at least one LEO SIP proxy) to a second user device, bypassing blacklisted proxy servers. At least one LEO SIP proxy may be located between the secure domain and SIP resolver IXC x such that transmissions from the secure domain are directed to the second user device through at least one LEO SIP proxy and SIP resolver IXC x.

[0243] With a secure domain registry / server on an owned and operated network, the carrier can non-intrusively implement multi-level security and provide additional checks and authentication services between hosts and clients, and between clients. After installing a secure domain registry / server in an owned and operated data center on an owned and operated network on owned and operated equipment, the platform can implement multi-level security by transparently opening different types of tunnels / VPNs between platform endpoints based on client resolution and / or host resolution and applying various security applications. In embodiments, security applications can include monitoring for anomalous activity, such as tracking and reporting calls / data transfers to unauthorized networks on a separate dedicated tunnel that implements one or more historically based "tracking" algorithms. In embodiments, security applications may include monitoring user behavior (e.g., identity checks based on keystrokes, typing cadence, password exchanges, etc.) on a separate dedicated tunnel that implements "behavioral" algorithms based on past user activity. In embodiments, security applications may include periodically and transparently updating certificates without the client's knowledge, using a separate dedicated tunnel for dynamic key exchange. In these instances, keys may be updated multiple times during the call and the VPN may be transparently re-established. In embodiments, the security application may include tracking network statistics for different traffic types on separate dedicated tunnels running "management" algorithms.

[0244] Having a secure domain registry / server on an owned and operated network allows carriers to add automatic IoT security to sensor networks that use secure domain registration. After installing a secure domain registry / server in an owned and operated data center on an owned and operated network on an owned and operated facility, the provider may provide security to Internet of Things devices that bind to the secure domain as clients. IoT clients may also utilize open spectrum provided by a spectrum access system or spectrum in unlicensed bands, but by registering with the secure domain, they are protected by a VPN automatically provided by secure domain registration.

[0245] In embodiments, the platform may enable IoT devices, such as those used in sensor networks, connected car applications, infrastructure projects, consumer applications, and business applications, to be protected via Secure Domain registration, where the Secure Domain may recognize that an IoT client is registered for a service. When an IoT client is registered for a service, the client may automatically instantiate end-to-end VPN, SSL protection, custom manufacturer private key protection, etc. In embodiments, the client may automatically instantiate IPv6 encoding and mapping, meaning that product (e.g., sensor) suppliers may pre-register IoT devices using a Secure Domain authentication procedure with pre-agreed manufacturer-specific security protocols.

[0246] In embodiments, the platform may deploy and use owned and operated networks and network facilities to operate secure domain servers for secure communications such as automatic VPNs. In embodiments, the platform may operate a secure domain registry / name server product embodied in a telecommunications network, where the secure domain registry / server, network, and network facilities may include a data center hosting the secure domain registry / server, which may be physically owned and operated by a single service provider entity. In embodiments, the platform may operate a secure domain registry / name server product embodied in a telecommunications network to prevent data vulnerability to secure domain hacking, spoofing, and stored data. In embodiments, the platform may operate a secure domain registry / name server product embodied in a telecommunications network, where secure communications over the secure domain may be required for host, device, client, or user in-flight authentication, authorization, or key exchange activities.

[0247] In embodiments, a network provider can implement multi-level security by transparently opening different types of tunnels / VPNs between endpoints based on client and / or host resolution, and apply various security applications. In embodiments, security applications may include monitoring for anomalous activity, such as tracking and reporting calls / data transfers to unauthorized networks. In embodiments, security applications may include monitoring user behavior (identity checks may be based on keystrokes, typing cadence, password exchanges, etc.). In embodiments, security applications may include periodically and transparently updating certificates without the client's knowledge. In embodiments, security applications may include tracking network statistics for different traffic types. In embodiments, security applications may include independently running SSL for secure connections. In embodiments, security applications may include running a TCP / IP offload engine for secure connections.

[0248] In embodiments, the network provider may support IoT manufacturer-specific security protocols, including automatic VPN establishment upon secure domain registration. In embodiments, the security protocols may include factory-based pre-registration for devices prior to field shipment and deployment, including the addition of secure keys and IPv6 encoding. In embodiments, manufacturer-specific security protocols may be provided for field device registration.

[0249] (Platform LEO Backhaul Architecture) In embodiments, a 5G communications network and computing platform may provide a secure and dedicated 5G low Earth orbit (LEO) backhaul architecture system and method for employing and integrating software-defined networking (SDN) to control and route content on the platform, as depicted at 1300 in FIG. 13. In many cases, an example secure and dedicated 5G LEO backhaul architecture may be shown to provide protection for the backhaul and demonstrate backhaul redundancy between the fiber deployed on the platform and the LEO satellites to maintain sufficient performance, security, and operation while operating a secure and dedicated 5G LEO backhaul system (which may also be referred to as a “LEO system” or “LEO systems” throughout this disclosure) 1302. In embodiments, the LEO backhaul system 1302 may provide continuous network monitoring using link hardware interface monitoring. In embodiments, the LEO backhaul system 1302 may deploy switches that employ backup links to employ early detection and rapid changeover to pre-planned backup paths when conditions warrant a detour. In an embodiment, the LEO backhaul system 1302 may deploy software-defined networking (SDN) to reroute when network updates indicate that a faster network topology may be appropriate. In an embodiment, the LEO backhaul system 1302 may be deployed for high availability in that the platform may employ a native forwarding plane (which may also be referred to as a data plane or user plane) via an SDN controller that can provide data transfer capabilities aligned with the ground-to-air-to-ground and air-to-air connections of the LEO satellites, and robust network security capable of providing rapid topology changes and movements with robust failover capabilities (e.g., hot standby), and a network designed for security and automatic establishment of virtual private network tunnels.

[0250] In embodiments, the LEO backhaul system 1302 may be configured to create unified operations and control for an Earth-satellite-Earth SDN wide area network. In embodiments, the LEO backhaul system 1302 may be configured to use a VPN to secure a terrestrial path for a VPN over a low Earth orbit (LEO) satellite constellation. In embodiments, the LEO backhaul system 1302 may be configured to perform near real-time backhaul (simulation) for terrestrial and LEO satellite constellations using SDN. In embodiments, the LEO backhaul system 1302 may be configured to provide VPN for the terrestrial and satellite portions of the LEO backhaul. In embodiments, the LEO backhaul system 1302 may be configured to integrate SDN management capabilities for the terrestrial and satellite constellations, including configuration of forwarding plane information and control. In embodiments, the LEO backhaul system 1302 may be configured to provide backhaul using an SDN-based transport layer from platform edge devices to platform cloud components, such as from micro data centers to core platform network components and from the Radio Access Network (RAN) to core platform network components, using both optical fiber and operational LEO satellites. In embodiments, the LEO backhaul system 1302 may be configured to use SDN for both fiber and operational LEO satellite transport for backhaul seamlessly integrated with an SDN controller. In embodiments, the LEO backhaul system 1302 may be configured to implement forwarding plane functions for routing SDN flows from platform edge components to platform cloud assets with integrated operational control and management. In these examples, the platform may integrate a terrestrial SDN controller with an earth station gateway.In an embodiment, the platform may operate an earth station gateway with transfer plane satellite operations capabilities fully integrated with a LEO satellite constellation.

[0251] (5G LEO Backhaul with Software-Defined Networking (SDN) Integration) In an embodiment, the platform may be configured to exhibit seamless LEO backhaul operation with integrated software-defined networking control and traffic routing and integrated security management. In an embodiment, the following security attributes of the platform LEO backhaul may be deployed with the following capabilities:

[0252] In embodiments, LEO backhaul may be deployed with a non-shared, dedicated satellite communications link at either Layer 1 (physical medium) or Layer 2 (data link); with onboard processing and routing of traffic (i.e., a "data center in the sky"), which may include integrated software-defined networking (SDN) control and traffic routing; and with an envelope of protocols and encryption over the LEO backhaul. Furthermore, inter-satellite links can keep all backhaul traffic separated in space between the base transceiver station (BTS) and the core network, regardless of distance (e.g., from Afghanistan to Washington, D.C.). LEO satellites or key payload elements may be manufactured by trusted aerospace companies with software from trusted sources that adheres to established software security standards. Command, control, and telemetry of LEO satellites and their backhaul functions may include encryption approved by trusted security organizations.

[0253] It will be appreciated in light of this disclosure that integrating LEO backhaul into the data governance, network management, and security envelope of a platform allows LEO backhaul to become an integrated part of the overall platform, by uniquely designing and operating LEO satellites as dedicated components of the platform, rather than supporting a variety of missions as traditional LEO communications satellites do.

[0254] (Platform Core Security - Sandbox) In embodiments, 5G telecommunications networks and computing platforms may provide security in the form of sandboxing around core functions 1400, as depicted in Figures 14 and 15. Referring to Figure 14, the 5G telecommunications networks and computing platforms may provide security such that the Authentication Server Function (AUSF) 1410, an operational module that may "blueprint" authorized access between a User Data Repository or Module (UDM) and a Home Serving System (HSS) 1412, is sandboxed. Each instance of the AUSF 1410, whether it uses a full hypervisor or not, may run within a sandbox 1420. If malware attempts to exfiltrate data using unauthorized vectors, in many instances, the process may be suspended, an audit trail may be established, and then a clean slate reset may be performed on the process instance or the entire function. In many instances, the methodologies described herein may be applied to any instantiable process, including session management, policy management, and all mobility management functions, as in 1422. In many embodiments, the extent to which this sandboxing can be achieved depends largely on the platform's ability to separate its traffic flows and management data flows from traffic and bearer traffic flows from other carriers. In embodiments, the platform may be configured to sandbox many of the platform core processes, or in some embodiments, the entire platform core.

[0255] In further examples of sandboxing, the platform may be configured such that sandboxes 1420 may be layered around layers of processes, as depicted in FIG. 15 and reference numeral 1500. In these examples, all of the checkpoints may be related to standard-mandated call behavior and may be characterized during system testing. For example, for call type 1, the sandbox may be configured such that the call information must pass through checkpoints in the following order: CHK1 → CHK2 → CHK3. Similarly, for call type 2, the sandbox may be configured such that the call information must pass through checkpoints in the following order: CHK1 → CHK4 → CHK5. In further examples, a checkpoint module may be added to each of the call models (e.g., as determined during testing). In these examples, this is a compile-time change. If a particular call fails to checkpoint in the correct order, in these examples, it may be determined that something went wrong. At that point, the platform may quarantine the process, record what happened, and report it before resetting it to a clean slate.

[0256] (Data Security Architecture) In embodiments, 5G communications networks and computing platforms may employ high levels of data security for data at rest and in flight, providing a data security architecture to protect against data breaches at various locations on the platform. In embodiments, the platform may employ user data separation from its underlying metadata. It will be understood in light of this disclosure that data itself has no context without rules about how it is interpreted, manipulated, and processed, and therefore only has value when it can be combined with metadata, which has the behavior and context in which the data and metadata should be used. In embodiments, the platform may separate data and metadata from its broader application context, such as service functions that may be responsible for performing actual services based on changes to the data or changes to the context, or for retrieval and storage of data, and for stateful data processing. In embodiments, the platform may employ data separation techniques to prevent important subscriber and management data from being spoofed, leaked, destroyed, or stolen without capturing all three contexts (e.g., data, metadata, and the context / behavior in which the data and metadata exist). In embodiments, the platform may employ techniques that may be applied to various systems of the platform, such as those depicted in Figure 14, such as HSS and / or UDR 1412, authentication functions 1410, policy and session management functions 1422, data repositories and data flows, etc. These functions may be used during call setup and may not be in the latency critical path for when a connection is established, and therefore may be candidates for additional levels of security, such as sandboxing.

[0257] In embodiments, 5G telecommunications networks and computing platforms may provide an enhanced security architecture for data in that data can be reassembled into secure, unreachable subcomponents, as depicted at 1600 in FIG. 16 . According to these examples, the secure, unreachable subcomponents of data may be further protected by one or more containerized cores of the platform, along with additional layers of security. In embodiments, 5G telecommunications networks and computing platforms may deploy cellular network security that can be built outside-in, such that endpoint security can be provided at the origination or termination point but not in the network itself. According to these examples, the platform may use new security technologies to protect data-at-rest and data-in-flight. This data-at-rest or data-in-flight may be subscriber data, device data, or communications data (e.g., IP addresses, etc.). In embodiments, the platform may deploy another element of an inside-out strategy by securing all intra- and inter-traffic using proprietary technologies such as contextual security, data-centric identity management, encryption / decryption, etc.

[0258] In embodiments, FIG. 17 depicts an example of a purpose-built, secure data structure employed by a platform at 1700 that can be used to separate and secure data, metadata, and the context and behavior surrounding that data and metadata, and reassemble the three for delivery. In embodiments, 5G telecommunications networks and computing platforms may employ data structures that may utilize abstract syntax notation to protect a layer of data's DNA. In these examples, abstract syntax notation may be used by the platform to describe data structures and variables and further define the values ​​and ranges the data may hold. In this structure, metadata may become a proteome of the data, in that it may provide how data described in abstract syntax notation should be interpreted and the logic between data elements. In these examples, metadata may also detail how data values ​​relate to each other. To fully understand the data, it is necessary to integrate the abstract syntax notation description and metadata with the data's behavior and context. In these examples, the data's behavior and context may be actual code, possibly associated with specific object types and detailed in object diagrams and UML.

[0259] FIG. 17 illustrates examples of dedicated secure data structures employed by a platform that use object identifiers to facilitate the separation and reassembly of data, metadata, and the context and behavior around that data and metadata, while keeping it secure. It is understood in light of this disclosure that by separating object-level associations of data based on its ASN 1710, metadata 1712, and behavior 1714, the data itself may lose meaning unless all three elements are known. In these examples, this means that separation of object information into multiple databases, code fragments, and the creation of atomic objects may be indicated to protect data from theft and misuse. In embodiments, the platform may employ objects that may be further decomposed into atomic objects, and inheritance for those objects may be maintained in a top-level or secure database, management information tree, or the like. In these examples, metadata may be maintained in its own object, which may be a federated object and therefore maintained in its own data store and encrypted. Additionally, behavior and context (one of the three elements) may also be code objects, and may be maintained inline within the code module or in a further relational database. In these examples, applications on the platform may only execute when all objects (all three elements) are brought together, which may occur at runtime. In an embodiment, as shown in FIG. 18, the platform may deploy an infrastructure-less data store that employs near real-time extract, transform, and load (ETL) processing at 1800 to combine data, metadata, and context / behavior objects (e.g., service functions) together prior to application processing.In embodiments, the platform may deploy an object database or a relational database with object wrappers to extract data, metadata, and context / behavior objects together prior to application processing, or a relational database employing in-memory, real-time, or front-end processing. In embodiments, the platform may include an application programming interface (API) for implementing data dissemination, as depicted at 1800 in FIG.

[0260] It is understood in light of this disclosure that starting with ASN.1 may not allow for a direct connection to behavior and context. In such cases, it may be better to deploy SysML, since it inherently includes support for parametric modeling, which may enable connection to models defined elsewhere and / or in different tools. In embodiments, the platform may use a Functional Mockup Interface (FMI). In these examples, the FMI may enable the use of co-simulation between diverse systems or facilitate the import and export of FMI components to and from systems. In embodiments, the platform may employ a UML / SysML version of ASN.1 (i.e., in generating ASN.1), where class definitions may be modernized for the extra requirements in SysML, and behavior definitions can be mapped to actual code using co-simulation, parametric modeling, keeping the definitions in a separate location, etc. From there, you choose how to glue your system together, either within UML or with options outside of UML.

[0261] In embodiments, 5G communications networks and computing platforms may employ top-level objects that can be broken down into atomic-level objects. In these examples, the object atomic level may be as small as an individual ASN value and type. According to these examples, objects may be kept in separate data stores, which may prevent the entire object from being retrieved without inheritance (i.e., an object roadmap) and related information (i.e., interrelationships). In embodiments, platform data stores may be logically or physically separate, or may reside in different clouds. According to these examples, objects may be retrieved together at runtime, such as for big data analysis and processing where a data lake is secure but off-platform. Even in these cases, real-time access can be maintained by using inheritance and associations to separate and reassemble information as needed.

[0262] In embodiments, 5G communication networks and computing platforms may employ data / metadata separation and further separate code from data / metadata through service objects. It will be appreciated in light of the present disclosure that object-oriented analysis and design (OOA / OOD) may provide options that enable separation of data and metadata into separate object structures, where data may be defined by its Abstract Syntax Notation (ASN) definition. In these examples, ASN data types may be encapsulated in data objects. Metadata may be encapsulated in another object, a metadata object. Data objects and metadata objects may be related by inheritance, such as a strict parent-child relationship or a link relationship, such as a pointer relationship. In these examples, data objects and metadata objects may be related to each other through code operations, where executable code is held in another object, such as a service object, which may be related to the metadata object by various examples of inheritance or association.

[0263] In embodiments, applications on the platform can reconfigure object information, metadata, and behavioral execution at runtime using inheritance and / or association relationships. In embodiments, objects on the platform may be maintained in separate databases and data stores or may reside in different clouds. It will be appreciated in light of the present disclosure that object-oriented design and analysis (OOD / A) may provide options that allow programmers, code designers, developers, and the like to automatically decompose and separate objects into atomic subobjects. In these examples, this may be done when a single execution object (e.g., a service object) requires all configuration data objects, metadata objects, and any and all atomic subobjects associated therewith to be reconfigured at runtime in order for the single execution object (e.g., service object) to perform its required execution. In these examples, new inheritance and association structures may be created, enabling real-time configuration at runtime. In embodiments, new association rules may allow runtime interrelationships between heterogeneous objects and atomic subobjects. In embodiments, the platform may allow object-level data and atomic subobject information to be maintained in separate databases and cloud systems, which in turn may allow for object / atomic object encryption.

[0264] In embodiments, objects may be held inline in the code, for example as compiled-time constructs. In embodiments, objects may be held inline in binary code objects held in a local or remote database. In embodiments, objects may be resolved at runtime through conventional symbol table and runtime library reference resolution techniques and methodologies.

[0265] In embodiments, commercially available tools may be extended or enhanced to enable the creation of separation of object types, provide enhanced functionality for compile-time and run-time reference resolution of inheritance and association relationships, support data object, metadata object, and service object separation techniques, and support parametric programming concepts and strategies.

[0266] FIG. 19 illustrates, at 1900, an example of a dedicated, secure data system employing a secure micro data center architecture with a platform including platform edge devices and one or more network cores residing in the platform's top-level domain. FIG. 20 illustrates, at 2000, an example of a dedicated, secure data system employing a secure micro data center architecture with a platform including platform edge devices and sandbox protection over the platform's LEO constellation, fiber, microwave, etc. For example, FIG. 20 illustrates, at 2010, a backhaul demonstration including microwave, fiber, and LEO-based solutions. In embodiments, the platform may provide a secure micro data center in a form that can be "drop-shipped" with a converged centralized or cloud-connected radio access network (C-RAN) that can link to a 5G core network that can reside in a secure cloud or domain or top-level domain (TLD), or any combination thereof. In embodiments, the platform may protect cloud and edge components. In these examples, the platform may be deployed with one or more micro data centers (MDCs) that can integrate a scalable cloud that can reside in the platform's secure domain. In an embodiment, the MDC may be a drop-shipped, fully contained baseband unit (e.g., a BBU hotel) with C-RAN connectivity, with options for fronthaul fiber or microwave interconnection. In an embodiment, the fronthaul may be a Common Public Radio Interface (CPRI) running over fiber or microwave to the baseband unit processing elements. In an embodiment, the MDC may be firewalled and may include C-RAN input / output interfaces and baseband unit processing elements that, together with the tower and remote radio heads, provide a radio access network.

[0267] In embodiments, the MDC may also provide network slicing support for relocatable functions such as session management, signaling, and bearer functions. These functions may allow signaling and data setup to occur, and bearer paths to be set up for Internet-wide or local application processing. In these examples, policy control, authentication, and auto-VPN may remain at the secure domain level and not be remote by design. In embodiments, the MDC may also provide C-RAN interface integration, auto-configuration and bring-up with one or more cores within the platform secure domain, zero-touch bring-up, LEO backhaul, etc.

[0268] In embodiments, a 5G communications network and computing platform may provide complete 5G protection across the entire platform, providing office applications for voice, video, and data to all device types authorized to run on one or more of the platform's cores, which may reside in a top-level or secure domain. In embodiments, the platform may employ a platform secure domain, which may be logically firewalled from the Internet, and all critical processes in the core may be sandboxed. In embodiments, the platform may employ custom containers for all sandboxed processes, which may be configured to prevent any type of unsolicited data exfiltration and clean slate processes that violate predetermined behavioral profiles. In embodiments, the platform may employ secure DNS and secure SIP processing, which may reside in the platform secure domain. Given this, there may be no authority above the secure domain level, and thus this structure can cut off any spoofing at the session initiation protocol or data level. In embodiments, the platform may include all devices within automatically provisioned VPN tunnels, and all critical data, such as subscriber information, authentication information, and authorization information, may be distributed. In embodiments, the platform may deploy an MDC that may be linked to the platform's secure domain for all policy, authentication, and subscriber data. In embodiments, the MDC may be a standalone C-RAN and integration processing hub.

[0269] In embodiments, 5G communication networks and computing platforms may facilitate the protection of data at rest to ensure that data belonging to a user or enterprise can be authorized before being used for routing and internet purposes. In these examples, data may be separated into data, metadata, and service data. As such, any access to the entire data may be subject to authorization control. In embodiments, the control may include atomic-level permissions, in that the actual owner of the data must provide access permission. In embodiments, the control may be configured such that a general level of meaning may be available to anyone, and a priority level of meaning may be open to the organization housing the data and available for internal use by the organization, for example, for data checking or authentication purposes.

[0270] (Secure 5G core network and cloud) In embodiments, the platform may be configured to logically "firewall" the 5G core network within a secure domain, securing all signaling and bearer traffic. By way of example, this may prevent higher-level DNS servers from controlling any aspect of the control plane, allowing the platform to maintain full control over the establishment of signaling or bearer traffic paths within the platform network or across inter-carrier networks.

[0271] In embodiments, the platform may be configured to automate VPN setup to endpoints without requiring an explicit VPN client or solicited setup at the endpoint. Additionally, a new secure I / O packet gateway based on a field-programmable gate array (FPGA) specifically designed for 5G packet processing may be integrated into the platform's 5G secure core network to support control plane and user plane (e.g., also referred to as the "data plane," which may be the data path) functions. In many examples, this may include all logical and physical links, such as I / O between core components, such as the radio access network and the 5G core network, for policy data access, HSS subscriber data access, multimedia service support, etc.

[0272] (5G Micro Data Center (MDC) and Edge Network) In embodiments, the platform may be configured to demonstrate a secure, distributed, and integrated edge computing platform that can be deployed and remotely provisioned in real time. This differentiating feature of the platform may prove particularly useful in scenarios where specific military needs may require on-the-fly 5G network setup for special and temporary operations and other mission-critical activities.

[0273] In embodiments, a micro data center (MDC) can integrate radio access networks (RANs), fronthaul, core networks, secure low Earth orbit (LEO) satellite backhaul, and cloud facilities into one scalable network. According to these examples, an MDC may be drop-shipped with a fully contained baseband unit (BBU) with integrated cloud-radio access network (C-RAN) connectivity with options for fronthaul fiber or microwave interconnection and low Earth orbit (LEO) backhaul. Additionally, an MDC can also provide network slicing support for relocatable functions such as access and session management, signaling, and bearer functions. According to these examples, these functions may enable signaling and data setup, set up bearer paths across the Internet, or support local processing and processing of applications sensitive to local delays.

[0274] In embodiments, the MDC can support a fully virtualized multi-tenant infrastructure, including compute, networking, and storage. In these examples, the virtualization layer can provide several important security features. First, it can provide a sandbox environment to isolate customer applications from the physical infrastructure. Second, it can provide a security barrier between customers. Third, it can control resource usage to prevent one customer from using up all of the MDC's resources, for example, starving other customers. In addition to the infrastructure, the MDC can also provide common security services to customer applications, such as data storage encryption.

[0275] (5G process, data and infrastructure security) In embodiments, the platform may be configured to protect processes responsible for 5G secure core network operations, applications, and signaling, and can provide a relatively high level of data security protection for data at rest, data in flight, and both.

[0276] In embodiments, the platform may be configured to enforce all process-level interactions through subsystem isolation, process sandboxing, and the application of machine learning operations to key processes. These examples allow capabilities to be developed with machine learning operations that can design allowable patterns of access to and from key data sources and 5G secure core network resources, such as the User Data Repository (UDR) and Home Serving System (HSS). Each process instance, whether configured to use a full hypervisor or not, can run in a sandbox. If malware attempts to exfiltrate data using unauthorized vectors, the process can be terminated, an audit trail established, and a clean slate reset can then be performed based on operator command or pre-established rules. In embodiments, isolation and machine learning methods may be applied to key instantiable processes of the 5G secure core network, including sessions, authentication, databases, policies, all mobility management functions, etc.

[0277] In embodiments, the platform may be configured to deploy a new data protection paradigm in which all stored data can be distributed in a parametric manner and encrypted with different keys. Furthermore, data may be further separated from its broader application context, e.g., from service functions that may be responsible for performing actual services based on data changes or context changes. In embodiments, these new data distribution and encryption techniques may ensure that critical subscriber and management data is impossible (or more difficult) to spoof, exfiltrate, destroy, or steal without all subcontexts being available or derived together. By way of example, these techniques may be initially applied to the HSS, UDR, user data management processes and data repositories, and key inter-process data flows.

[0278] (5G Management and Network Operations (MANO)) In embodiments, the platform may be configured to provide end-to-end MANO capabilities and may define services that may be provided. By way of example, these services may be definable bundles of various components, such as 5G voice, 5G data, machine connectivity, bandwidth and backhaul capabilities, access to a standard edge for custom edge or edge application deployment, etc.

[0279] In embodiments, the MANO technology may be Open Network Automation Platform (ONAP) compliant, enabling a plug-and-play operational support system. The platform may support best-of-breed, vetted vendor operational systems, such as general ledger systems, as it may provide a 5G secure core network with integrated provisioning, performance management, and management and accounting capabilities. Additionally, the system may provide big data APIs and machine learning capabilities for value-added and custom application development.

[0280] In embodiments, the platform may be configured to secure and authenticate all control and user plane messaging and operations before, during, and after call processing begins using secure DNS, secure signaling, and secure I / O.

[0281] These examples allow the platform to logically firewall the 5G core network inside a secure domain, securing all signaling and bearer traffic. In embodiments, the secure domain allows the platform 5G secure core network to resolve and control all data paths, signaling, and DNS queries, preventing malicious DNS servers, SIP proxies, or serving networks from managing any aspect of the platform's user or control plane. In this way, the platform can maintain complete security control over signaling or bearer traffic channels hosted by the platform or across inter-carrier networks.

[0282] In embodiments, the platform can be configured to automate VPN setup between the endpoints it serves, as long as the endpoints are authorized and authenticated. The VPN may be provided through encryption techniques handled by the core network in the platform's data plane, or may be part of SIP / SIP extensions and secure SIP implemented by the platform in the control plane. In embodiments, secure SIP may be based on the concept of zero trust networking, where SIP proxies are not trusted by default until they are verified and switched to a trusted state.

[0283] In an embodiment, the secure I / O packet gateway may be explicitly configured to integrate data packet processing into the platform's 5G secure core network to support user plane functions.

[0284] (Exemplary facility) In embodiments, the platform may be configured in an exemplary facility with an operational core network and RAN (e.g., initially based on 4G LTE). According to these examples, the platform may provide an operational support interface, including element and network management functions, to enable the launch, administration, and management of the core network and RAN with C-RAN.

[0285] In an embodiment, the 4G / 5G core network may be a 4G NSA core. In a further example, the core network may be a 5G SA core. For a 4G LTE RAN, the supported spectrum bands may be those currently supported by 4G LTE CONUS (Continental United States).

[0286] Additionally, the 4G LTE SIM (Subscriber Interface Module) card may be initialized with databases such as home serving system, policy controlled resource functions, etc.

[0287] In a further example, test equipment for signal attenuation and test equipment for simulating SIP and IMS can be installed to simulate intrusions such as attackers, man-in-the-middle hacking, etc. These simulations can be achieved using standard Ixia-type traffic boxes or by inline patch scripts. Similarly, on the RAN side, platform facilities may simulate replay attacks, UE spoofing, etc. In this case, the platform may use standard equipment from Keysight-type companies or may use inline patches in the client UA registration or invitation process. These options may be predetermined based on the effectiveness requirements of the security test.

[0288] (Secure DNS Enhancement) It will be understood in light of the disclosure that secure DNS refers to the Domain Name System Security Extensions (DNSSEC) defined by the Internet Engineering Task Force (IETF) to secure the Domain Name System (DNS) used in Internet Protocol (IP) multimedia networks. This allows DNS clients (resolvers) to perform origin authentication of DNS data, authenticated denial of existence, and data integrity. This may be achieved by verifying digitally signed data associated with queries that the DNS resolver can verify is identical (i.e., unaltered and complete) to the information published by the zone owner. It will be understood in light of the disclosure that Requests for Comments (RFCs) related to secure DNS may also address key rotation and refresh, error and exception handling, and different types of signing authorities and resolvers. In many instances, RFCs that ensure DNS resolution functions may be secured as per the Secure DNS RFCs include: RFC 2535 Domain Name System Security Extensions; RFC 3833 Threat Analysis of the Domain Name System; RFC 4033 DNS Security Implementation and Requirements (DNSSEC-bis); RFC 4034 Resource Records for DNS Security Extensions (DNSSEC-bis); RFC 4035 Protocol Modifications for DNS Security Extensions (DNSSEC-bis); RFC 4398 Storage of Certificates in the Domain Name System (DNS); RFC 4470 Minimal NSEC Records and DNSSEC Online Signatures; RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs); RFC 5155 DNSSEC Denial of Existence via Hash Authentication; RFC 6781 DNSSEC Practices Version 2; and RFC 6840 DNS Security Clarifications and Implementation Notes (DNSSEC).

[0289] (Secure SIP) It will be understood in light of this disclosure that Secure SIP contemplates a zero trust architecture. For calls processed exclusively on the platform, and where users and devices can be authenticated only by the platform as their home serving network, SIP and call processing can proceed without the intervention of Secure SIP processing in the control plane. Calls between two devices that are on the platform but not on the platform network, calls originating from outside the platform where a non-platform user may be a Visit Location Register (VLR) or roamer on the platform network, or where calls may be incoming from a foreign network, can follow Secure SIP processing.

[0290] (Maintaining a Zero Trust Architecture) In embodiments, the platform is configured to implement a database that may maintain processes and procedures for validating or rejecting SIP proxies used as part of SIP headers for SIP VIA resolution, i.e., call routing and address / eNUM resolution between the platform and destinations outside the platform. In these examples, the database may be dynamic and may be used for control plane processing of SIP resolution. In a zero trust architecture, there may be cases where calls are restricted to minimal security, for example, because the origin cannot be determined or there may be issues resolving the trustworthiness of the SIP proxy used in the VIA header.

[0291] (SIP whitelist) In embodiments, the platform may be configured to maintain a SIP whitelist detailing carrier-specific trusted proxies that have been initialized as trusted or verified through a third-party database or inter-carrier data exchange. According to these examples, VIAs that can match entries in the SIP whitelist may be considered trusted for address resolution and the full range of SIP Internet Key Exchange (IKE) and SIP key exchange mechanisms. In embodiments, initializing the SIP whitelist may require a management plane operation to query the proxy list between carriers, for example, for multicast registrations supported by the multicast address "sip.mcast.net" (224.0.1.75 in IPv4). Furthermore, the use of management plane queries may allow the whitelist to pull in all known and verified country-level proxies.

[0292] In an embodiment, an entry may be removed from the SIP whitelist by one of several options: by operator action; by a timeout where the proxy has not been used for a period of time (i.e., configurable) and has therefore "aged out" (although SIP options may be used to "keep" the proxy's state alive); by a third-party notification such as a management report over the Gx interface; and by an origin authentication failure; etc.

[0293] (SIP greylisting) In embodiments, the platform may be configured to maintain a SIP greylist detailing proxies that are used for the first time or carriers that may be encountered for the first time. If the carrier is known and has an alternate path to the origin, the platform may deploy a SIP ReInvite on the trusted path. If the SIP ReInvite is successful, the proxy may be moved to the whitelist for subsequent SIP resolution processing. In other examples, one of the following methodologies may be followed to move a SIP greylist entry to a SIP whitelist entry:

[0294] If the carrier is unknown, a third party data source such as the North American Numbering Plan (NANP) may be consulted to verify carrier credentials. In embodiments, this may require a database SIP, after which origin authentication may not be performed or the user may not be verified as a user on the platform, in which case the call may only be carried as a "restricted call," as discussed further herein.

[0295] In an embodiment, as another option, SIP option primitives may be used to check proxy validation information such as registrar information for certificate exchange or for checking against domain / realm information.

[0296] In embodiments, the platform may use SIP options to send a "test message" to an unknown proxy via a trusted proxy to verify that it trusts the unknown proxy (heuristic processing and validation). In embodiments, heuristics may be used based on previous call history to verify a proxy server as trusted or sufficiently trusted for use in routing the control plane through the platform SIP black / gray / white lists, and to perform demise and re-routing when not based on mechanisms such as SIP re-invite. In embodiments, SIP mechanisms such as SIP options may be used to test SIP black / gray / white lists and force re-registration and / or new keys for the proxy if in doubt.

[0297] In an embodiment, the platform may use peg counts maintained by the management plane to determine when a threshold of successful resolution has been reached that allows a proxy to be moved to the SIP whitelist.

[0298] (SIP blacklist) In embodiments, the platform may be configured to maintain a SIP blacklist of untrusted proxies, in which case the call may be immediately terminated or may be routed as a restricted call.

[0299] (Call Restrictions) In embodiments, the platform may be configured to provide limited calls with minimal capabilities, e.g., voice only, which may be controlled through Session Description Protocol (SDP) exchanges. By way of example, such calls may not be allowed to exercise the full capabilities of 5G and may be database restricted (e.g., no data exfiltration is allowed).

[0300] (Origin authentication) In embodiments, the platform may be configured to deploy several methods for performing caller authentication, including querying an eNUM database for SIP number matching, or querying a calling number identification in a CNUM database, or calling name in a CNAM database, or any combination. In certain examples, caller authentication may require access to a third party database, such as Neustar, Telcordia, or possibly the database of the originating carrier.

[0301] In embodiments, the platform may be configured so that caller authentication is not required for calls between platform devices hosted by the platform, and if the VLR process is successfully performed on the platform, caller authentication may not be required for calls between the platform and non-platform devices.

[0302] However, in embodiments, origin authentication may be required for all calls where the SIP proxy may not be verified. In this case, the only viable option is to issue a SIP re-INVITE; in effect, the platform may be able to issue its own INVITE (or re-INVITE) using a trusted path (if available) where the proxies are all known to be trustworthy.

[0303] It will be appreciated in light of this disclosure that OTT methods may be used for specific requirements, particularly those mandated by sovereigns, allowing the platform and its users to utilize very specific needs. In embodiments, the platform may enable caller authentication using third-party databases such as eNUM, CNAM, CNUM, etc. to verify that users and directory numbers have not been hacked. By these examples, the platform may also include correlating geolocation information with third-party databases (e.g., whether the phone is where it should be, etc.).

[0304] (Secure I / O) In embodiments, a platform may be configured to deploy with specific links that may require the use of new encryption or encryption techniques for highly secure data plane operations. In embodiments, these links may also be used to ensure "open" physical links, such as backhaul data links from a platform's Micro Data Center (MDC) to the platform's core network for control plane or data plane operations, where backhaul to a central core may be required (e.g., for access to the HSS).

[0305] (Backhaul data link from IMS to the Internet) In an embodiment, the platform may be configured to provide fronthaul for Common Public Radio Interface (CPRI) transport from a Radio Access Network (RAN) to a Micro Data Center (MDC) or platform core network. It will be appreciated in light of this disclosure that CPRI carries over-the-air information and therefore may be timing-sensitive, and therefore the techniques used may be configured to meet jitter requirements of less than 75 microseconds processing turnaround and less than 1.5 microseconds timing sensitivity for I / Q processing.

[0306] In an embodiment, the platform may be configured to provide an interface to cryptographic devices that is based on the UDP standard and may include a message-based interface, e.g., a secure stream or socket with a callback for successful transmission. The interface specification may support the following three exemplary application programming interfaces:

[0307] (1) In embodiments, a management API may allow for validation of authorized devices that may connect to the packet gateway. The API may call devices during recovery and startup and may allow for the use of certificate exchange. The API may also be used to initialize specific parameters for transport; for example, a C-RAN interface may require different parameters than a data interface.

[0308] (2) In embodiments, the data plane API may support standard UDP communications where the encryption device performs all (or most) of the packet processing and encryption. In these examples, the platform may provide the complete packet sequence to the device, and the platform device may manage all three layers, including Fibre Transport, MAC, and physical transport requirements. In embodiments, the interface specification may provide specific primitives to support acknowledgements, errors, and reporting.

[0309] (3) In embodiments, the C-RAN API may support the transmission of wireless data between a remote radio head (RRH) and a baseband processing unit in a micro data center (MDC) or radio access network (RAN). In these examples, the API may be configurable via the management plane to adjust the RRH type and sample rate, for example, for sub-6 GHz and mmW connections.

[0310] (Auto VPN) For end-to-end data plane traffic between platform users, the platform may deploy an automated VPN client, and key exchange and management may be provided through a third-party system that may be integrated into the Operations, Maintenance, Administration, and Provisioning (OMAP) interface.

[0311] For platform to non-platform calls originating and terminating on the platform network, VPN may also be applied, but in embodiments may be implemented from the platform to the serving RAN but not on the user equipment itself, depending on the capabilities and options of the user equipment. S / MIME, TLS, or IPSec options may also be supported for platform to non-platform calls on the platform network.

[0312] For platform-to-non-platform calls where one end is not on the platform network, the call may be subject to best-effort VPN service. This may also depend on the SDP exchange of supported options; that is, if the remote end is willing to use S / MIME, TLS, or IPSec, it may be attempted. If the link cannot be established due to an intervening service network, the SDP exchange can determine the best compromise. Finally, if it is determined that (i) there is no path for security, (ii) security is required for the call, (iii) an untrusted proxy is involved, and (iv) SIP re-INVITE may not be possible, the call may be restricted to a "restricted call" status that provides protection from the entire platform.

[0313] In embodiments, SIP may require a user agent (UA) acting on behalf of a user to register for service with a domain server responsible for resolving the user's location in subsequent location requests. Depending on these examples, the user agent may be either a client-side (UAC) or server-side (UAS) entity. As such, there may be strict procedures for aspects of SIP registration, location services, and UAC-UAS protocol processing. In embodiments, the SIP registrar may be a separate entity from the location server and need not be co-located. Typically, the SIP registrar may maintain the address of record for the UAC, although separation of the registrar and location server is possible, depending on the network and implementation. In various examples, a carrier may have one registrar database for all its UACs and many geographically distributed location servers. Registration may create a binding in the location service for a particular domain that associates the URI of the address of record with one or more contact addresses for the user.

[0314] In embodiments, SIP resolution may require specific protocols at the user level, transport level, and transaction level. However, because requests may involve other networks and domains and there may be no clear end-to-end requirements for a call from a UAC to a called UAC (or for verifying a call from a UAS to a called UAS), SIP may have holes that can be exploited. These may arise due to the fact that transport procedures are not end-to-end, but may be bidirectional, between adjacent carriers or session border controllers, or between intermediaries in a chain of intermediaries.

[0315] In many instances, SIP VIA can establish how a route can traverse many intermediaries before a location is found. It will be appreciated in light of this disclosure that this can be exacerbated by redirect servers and weak policies employed by inter-carrier boundary processing. Thus, the SIP VIA header field may indicate the transport used for a transaction and may identify where a response is to be sent. In these instances, a value may be added to the SIP-VIA header field only after a transport that can be used to reach the next hop has been selected. When a UAC generates a request, it must therefore insert SIP-VIA header information into the request, which in many instances must include a branch parameter. This parameter is used to identify the transaction created by the request and may be used by both the client and the server. In some instances, the branch parameter value must be unique across time and space for all requests sent by the UA. However, the exact format of the branch token may be carrier-implemented. The SIP registration procedure, SIP redirect, SIP location servers, and SIP VIA can be common in the following types of attacks: forgery; verification spoofing; password leakage (during registration); spam; message and data duplication; message modification; message insertion; message tampering; impersonation; spoofing; eavesdropping (adding SIP forks); replay; session spoofing, etc.

[0316] (LEO Constellation Security) In embodiments, the platform's LEO components may be shown to be more secure than land-based SIP registrars, SIP resolver / location server entities, or SIP redirect servers, which may be open to backdoor hacks (e.g., administrative threats) and internet-level attacks ranging from DDoS to malware. Moving the platform's registrar functionality and location services to the platform's LEO components may represent a near-zero likelihood that the platform's user information, such as SIP addresses, addresses of record, and information used during SIP processing (e.g., call ID and tag information), will be spoofed, spammed, cloned, impersonated, forked, or otherwise used in eavesdropping or malicious attacks.

[0317] (Strengthening stateless and stateful processing) In many instances, there may be specific reasons for stateless (normal VIA routing) and stateful (e.g., CALEA) processing. The use of LEO constellations may prove possible to create more optimized options for both stateless and stateful processing, including using SIP re-INVITE messages to "skip" VIAs that use a more trusted route to the origin, or using SIP OPTIONS processing to change the route at midpoints of the call as a result of an unexpected event or to enforce updated or new security policies. Furthermore, for users whose endpoints may not be verified or may not have location server bindings, it may be possible for the platform to create a one-off authorization that does not interfere with the terrestrial network and is maintained only in the LEO network. In embodiments, the platform may employ a very specific SIP dialog for the one-off authorization that may be unique and not open to terrestrial-based systems.

[0318] (SIP registrar database) In embodiments, the registrar function may be shown to be inherently easy to protect in a LEO constellation to prevent forgery and to prevent validation spoofing and password attacks. In a LEO backdoor attack, the platform may be shown to completely eliminate such attacks because the platform's LEO constellation can leave a clear audit trail for any LEO management plane access. To prevent malware attacks on the LEO SIP database, access to modify the LEO SIP database may, in embodiments, be restricted to flow through the LEO satellite control facility, where the LEO satellite control computer is a secure, access-limited facility isolated from the internet and external systems ("air-gapped"), ensuring satellite security.

[0319] In embodiments, the platform may be configured to allow hosting of an address of record for non-platform users who apply for a platform identity. By these examples, this identity may be granted on a temporary or one-time basis under certain circumstances. By these examples, this may not be possible in terrestrial networks where all appropriate location servers would need to be updated, but in LEO on the platform, the new address of record may be shared only among the LEO constellation, keeping it secret which is highly useful for battlefield operations.

[0320] (SIP Location Service) In embodiments, the platform's LEO component may be responsible for updating the SIP "tree" in the terrestrial DNS, but may use differentiated TLS methods for inter-carrier validation. Additionally, the LEO component may act as a universal default location service for non-verifiable UACs, and other platform validation mechanisms may apply, including the use of SIP dialogs for end-to-end, one-off, clearance procedures.

[0321] (Call control flow operation requirements) In embodiments, the platform's control plane related to SIP processing and Session Description Protocol (SDP) processing may be relocated to the LEO system (e.g., one or more LEO satellites, such as a LEO constellation). By way of example, this may include all mid-call triggers, such as conferences, add-ons, mid-call invites, etc. In other words, all call selection and call processing may be configured to run the entire 5G control plane for 5G call setup, which may occur on the LEO system (e.g., the LEO component of the platform).

[0322] However, in embodiments, some of the processing may continue on the ground once the call anchor Radio Access Network (RAN) and Mobility Management Entity (MME) are set up. In these examples, all calls may have an MME anchor and be set up by an Access Management Function (AMF) and a Session Management Function (SMF). In embodiments, certain control functions may remain in the terrestrial anchor point and core network, such as in the following four examples:

[0323] (1) Processing for the S2 interface (call control to device) and X2 interface (call control between base stations), which may involve handoffs between towers as the caller moves between towers. In embodiments, these transitions may be rapid and impact the media data stream. Therefore, the CSCF requirements for handoffs may best be handled by the platform core network and the RAN and MME anchor points.

[0324] (2) Providing the media controller gateway functionality that may be required for transcoding in VoLTE, since it is part of the call control during call establishment; for example, the Session Description Protocol (SDP) may need to determine the transcoder to use, which may involve back-and-forth negotiation and parameter configuration.

[0325] (3) In VoLTE, some functions, such as 4G fallback and circuit-switched fallback, may be split between the platform core network and LEO.

[0326] (4) Network management and configuration management may become challenges, requiring enhancements to the Gx interface and other management plane interfaces.

[0327] In embodiments, the platform may be configured to deploy secure SIP that maintains blacklists, greylists, and whitelists and can use origin authentication with SIP re-INVITES when the platform cannot verify the trust level of an attempted SIP path. Additional extensions may be possible in the platform LEO constellation, including the following three extensions:

[0328] (A) Handling Fake Base Stations. In embodiments, SIP may not validate base station (BTS) or cell IDs. This is a function of the Access Management Function (AMF) or Mobility Management Entity (MME), which may handle BTS authentication directly using encryption and registration functions in the radio access network (e.g., the gNB signature may be authenticated before use). In embodiments, the LEO component on the platform may store the gNB signature in an Equipment Identity Register (EIR), which may be persisted in the LEO constellation. With these examples, this means that validation of all BTSs may require a LEO authentication procedure as part of the AMF, may require a new Gx interface for "fast access," and may be shown to make the EIR unhackable.

[0329] (b) Handling Fake Devices. Management interfaces such as N2 (HSS → MME connection management) and signaling interfaces such as S1 (MME → UE) may, at some point, use encryption to interact with UEs (User Equipment). Therefore, to prevent fake devices, the Equipment Register (EIR) may be extended to include International Mobile Equipment Identity (IMEI) verification. In embodiments, this may be an HSS function, and in some embodiments, the entire HSS database may reside in the LEO constellation.

[0330] (c) Calls entirely on the platform. Keeping the HSS database in the LEO constellation can speed up call resolution entirely on the platform, minimizing call setup time and execution. The entire platform SIP registrar database may be expected to remain in the LEO constellation. While the constellation may be storage-bound, the number of platform users and devices may not be expected to tax the platform LEO system resources. In an embodiment, a medium-sized platform LEO component may have a minimum capacity of 1 TB per satellite.

[0331] For inbound calls, it will be understood in light of the disclosure that the CNAM (Call Name) database may always be part of the resolution with the IMS, requiring access to the HSS / HLR (Home Location Register) and UDM (User Data Management) DB. Thus, the IMS may undertake the resolution or may interface with another carrier to obtain it. Resolving the CNAM on the fly may not be critical as part of the resolution of a SIP inbound call, since it may be handled by the serving carrier at the terminating side or via access to the HSS in the core network.

[0332] (processing overhead) In embodiments, the number of SIP proxies may be driven by the number of BHCA (busy hour call attempts) that the platform can be designed to handle. For these examples, using 100-200k BHCA for VoLTE as a benchmark, a single instance IMS can handle 100k BHCA for SIP resolution.

[0333] Based on current information, a single LEO satellite is expected to provide the following performance characteristics: (1) 576 GPU cores per satellite for a medium-sized satellite system; (2) 192 GPUs may require a 76W power budget. In an embodiment, a medium-sized satellite may be expected to provide up to 700W of usable power for processing and computation. One-third of the power budget may be expected to be available for computation. This could support 576 GPU cores; (3) SIP is specialized for GPU processing and may not require a general-purpose CPU; and (4) each GPU is capable of running 1000+ threads. Thus, a single LEO satellite may be capable of 500K threads per instance of time, or up to 10M BHCA per satellite based on an Erlang model (e.g., 2-minute call holding time). In an embodiment, a small or medium-sized constellation may be able to process 500M or more BHCA.

[0334] (database overhead) The maximum number of VIAs handled by the platform at any one time can be in the thousands. In an embodiment, 1 TB of capacity can be more than enough to handle the database requirements (stateless and stateful) per instance of time or for 10M BHCA. In an embodiment, the platform can exclusively use the SIP resolver of the LEO constellation and maintain all secure SIP processing of the LEO constellation, e.g., Black, White, and Gray, as well as Origin Authentication and SIP Re-Invite.

[0335] In an embodiment, CNAM resolution may not be required in the LEO constellation as long as the terminating carrier processes the database DIP to fetch the CNAM entry.

[0336] In embodiments, for calls hosted entirely by the platform, the HSS may be located in the LEO constellation to limit round trip delay. Additionally, the operation of the HSS and SIP proxy in the LEO constellation allows the platform to use its own methods to "test" the authenticity of the SIP proxy through data and signature checks, such as:

[0337] (a) Use of SIP option requests for UAS-to-UAS checking, for example, performing domain checks or using proxy cross-referencing.

[0338] (b) SIP dialog processing for UAC-to-UAC "handshakes," such as via one-time keys and challenges. In embodiments, this may be useful for calls from non-platform callers to the platform, calls from the platform to non-platform call recipients, and calls that may be entirely on the platform, but where the user is not using an authorized device. Database requirements for maintaining SIP proxies, equipment registrations (EIRs), and SIP black / white / grey lists may be expected to be small, less than 20 GB per satellite. It is understood in light of this disclosure that HSS requirements may depend on the number of platform users and therefore may not exceed 500 GB per satellite.

[0339] (LEO satellites may be a key element of secure 5G network architecture) In embodiments, the platform with its dedicated SG Secure Network can move computing, data, and application intelligence into the network, transforming it from a transactional transport medium into a robust and dynamic computing platform. This fundamental change in 5G architecture has the potential to enable next-generation future applications requiring ultra-low latency response times, such as virtual reality, autonomous vehicles, and industrial robotics, at scale.

[0340] In embodiments, the Platform Edge may provide a secure distributed edge network with integrated RAN, cloud, and backhaul, with seamless provisioning, which may be important for enabling next generation low latency applications and having the ability to set up a 5G network platform "on the fly" for remote operation.

[0341] In embodiments, LEO satellites may be a key element of the platform edge network. The platform's LEO satellites may extend the 5G network ubiquitously and globally by providing secure backhaul and may include a complete platform security framework with full support for software-defined networking (SDN). This approach allows each LEO satellite to become an actual 5G network node in the platform, tightly integrating 5G network functions, potentially resulting in a more secure platform with a robust, high-performance 5G network.

[0342] (LEO satellite backhaul providing ubiquity, security, and redundancy) Low Earth Orbit (LEO) satellites, or a blend of geostationary and LEO satellites, can provide an ideal solution for backhaul connectivity. In embodiments, a constellation including 5G LEO satellites can extend the reach of a platform 5G network to any part of the Earth. In this way, LEO satellite backhaul connectivity can be easily and quickly established by deploying small terrestrial terminals at 5G radio access network (RAN) locations.

[0343] It will be appreciated in light of this disclosure that space-based routing of LEO satellites can be difficult to intercept or disrupt, making LEO backhaul highly secure. In embodiments, a platform LEO solution may further enhance LEO security by incorporating proprietary secure control plane, data model, sandboxing, and I / O encryption techniques. The security possible from the physical isolation of LEO satellites in space may be enhanced with the platform's security framework and may be particularly valuable for secure standalone 5G networks for military, intelligence, and commercial applications.

[0344] For certain sovereign governments and militaries, this platform may enable them to provide instant and secure connectivity to secure facilities such as embassies and military deployments. For example, the LEO satellites on the platform could provide backhaul from a 5G RAN at a military base in Afghanistan to a U.S.-based 5G core without landing anywhere between Afghanistan and the U.S., or in any country. Similarly, a secure backhaul connection could be established from an aircraft in flight or a ship at sea to a U.S. 5G core. Furthermore, LEO backhaul could be valuable for providing connectivity to rural addresses and providing uniform capabilities to remotely selected sovereign military bases, facilities, and infrastructure.

[0345] In locations with fiber optic or microwave backhaul, the LEO satellite backhaul provided by the platform can enhance 5G robustness by providing physically diverse, space-based, redundant backhaul paths. Terrestrial-based backhaul can be subject to unexpected interruptions, such as when a fiber cable is accidentally cut by a backhoe or when a microwave transmission path is disrupted by interference. Therefore, by providing redundant LEO satellite links to cell sites that require reliable service, temporary disruptions to fiber or microwave backhaul can be instantly restored via LEO backhaul. Furthermore, incorporating software-defined networking (SDN) into the LEO satellite platform can further enhance the ability to switch between terrestrial and satellite paths and switch back.

[0346] It will be appreciated in light of this disclosure that the decomposed architecture of a LEO constellation formed by multiple identical LEO satellites can make LEO satellite backhaul resilient and scalable. Furthermore, the placement of spare satellites in orbit distributed throughout a platform's LEO constellation may enable rapid replacement of failed satellites. This capability, combined with continuous replenishment operational policies and multiple satellite coverage at each 5G cell site, may ensure continuous LEO backhaul availability on the platform. As 5G network usage increases, the platform's LEO constellation can easily scale to accommodate increased backhaul usage by launching more satellites and reducing each satellite's coverage footprint. This may be similar to increasing the capacity of a cellular network by increasing the number of cell sites in a particular area.

[0347] In embodiments, platform LEO satellite backhaul can provide significant benefits for secure standalone 5G networks, including security, ubiquity, immediacy, resilience, and scalability. Security can be provided by utilizing a completely space-based link between the RAN and the 5G network core that is highly difficult to intercept, or can be further enhanced and disrupted by the platform's proprietary secure control plane, data model, sandboxing, and I / O encryption technologies. Ubiquity can be provided by extending the platform's 5G network to connect to RANs located anywhere in the world. Immediacy can be achieved by provisioning a 5G RAN within hours through the rapid deployment of one or more satellite ground terminals. Resilience can be provided by high availability augmented by the self-healing capabilities of a distributed LEO satellite constellation, potentially leading to virtually continuous 5G network availability. Scalability can be achieved by incrementally launching more satellites to increase capacity, which can be thought of as analogous to increasing cell site density in areas with growing populations. The deployment of a custom-designed LEO platform solution specifically for 5G will enable unparalleled levels of security and robustness.

[0348] In embodiments, the platform may incorporate a custom-designed LEO satellite system (also referred to throughout this disclosure as the "LEO system") specifically designed for 5G into its end-to-end platform. The platform LEO system includes a platform security framework (secure control plane, data protection, smart sandboxing, I / O encryption) and integrated software-defined networking (SDN) to create a LEO backhaul segment and an integrated 5G system that meets the platform's objectives. As a result, the platform's LEO backhaul may prove to be significantly more secure than a typical commercial LEO system.

[0349] In an embodiment, the LEO satellites of the (platform) LEO system may incorporate, among other features and advantages: (1) a LEO satellite constellation designed for 5G and dedicated to the platform network; (2) platform security protocols and encryption, which may include LEO backhaul; (3) onboard processing and routing of traffic (i.e., data centers in the sky), which may include platform-specific software-defined networking (SDN); (4) inter-satellite links that can keep all backhaul traffic isolated in space between the 5G RAN and the 5G core network regardless of separation distance (e.g., Afghanistan to DC); (5) platform LEO satellites manufactured by select aerospace industry suppliers with domestically sourced and / or securely sourced software that complies with the platform's software security standards; and (6) command, control, and telemetry of the platform LEO satellites, which may use encryption approved by the U.S. National Security Agency (e.g., currently "Gryphon") or other selected sovereign.

[0350] In embodiments, the LEO satellites on the platform can provide users with capabilities and benefits such as: security of sovereign military or government facilities and commercial installations; flexible, adaptable, and relocatable military and government operations; assured availability at critical sites; disaster recovery and backhaul redundancy; and uniform capacity to regional addresses.

[0351] (LEO components on the platform) To demonstrate compliance with platform 5G system performance and operational goals, the platform LEO backhaul may be shown to provide at least the following: (1) platform security protocols and encryption encompassing the LEO backhaul; and (2) onboard processing and routing of traffic (i.e., data centers in the air), including integrated software-defined networking (SDN) control and traffic routing. In embodiments, applicant understands that these two functions may be central to integrating the LEO backhaul into the platform's security envelope and network management. In embodiments, the LEO backhaul, LEO security, and LEO SDN may be shown to demonstrate: (1) security robustness equivalence between fiber and LEO backhaul paths; (2) passage of SDN control of traffic routing over the LEO backhaul path; and (3) SDN traffic control and routing equivalence between fiber and LEO backhaul paths.

[0352] With network capabilities and edge computing within each LEO satellite and backhaul network, a platform 5G LEO solution can provide unparalleled levels of platform security, redundancy, and robustness for military and government applications of 5G, as well as the immediate ubiquity required for extending 5G to rural and remote locations anywhere in the world.

[0353] It will be appreciated in light of this disclosure that entities receiving and acting on Session Description Protocol (SDP) messages need to be aware that the session description may not be trustworthy unless it is obtained via an authenticated transport protocol from a known, trusted source. In embodiments, secure SIP processing on the platform may mitigate this problem. If the session description is not obtained in a trustworthy manner, in embodiments, an endpoint may take precautions because, among other attacks, the media session received may not be the one intended, the destination to which media is being sent may not be the one expected, any of the parameters of the session may be incorrect, or media security may be compromised.

[0354] In embodiments, the use of a key exchange descriptor (e.g., SDP) can support the transport of keys over a secure channel, SSL / TLS, but only if the SDP can be conveyed over a secure and trusted channel. Examples of such channels would be embedding the SDP inside an S / MIME message or a TLS-secured HTTP session. In light of this disclosure, it is understood that it is important to ensure that the secure channel is between the parties authorized to participate in the session, and not an intermediary. If a caching proxy server may be used, it is important to ensure that the proxy is trusted or that the SDP cannot be accessed using platform secure SIP.

[0355] In an embodiment, a platform micro data center (MDC) may include a radio head; a fronthaul network; an edge data center including a RAN running in the edge data center and customer workloads running in the edge data center; and a backhaul network including via customer-owned IP connectivity and via platform LEO connectivity.

[0356] (LEO system using 5G SDN functions) Software-defined networking (SDN) capabilities as described in this disclosure may be a particularly useful feature of 5G technology. SDN is a critical component of 5G, such that 5G transport may not be possible without SDN. The use of SDN in cellular networks may have been available in some earlier cellular networks, such as at least some later versions of fourth-generation (4G) networks. While LEO systems may be primarily used in 5G networks, applicant recognizes that LEO systems may also be used in other networks that utilize SDN capabilities.

[0357] The organization and / or architecture of the control plane in most 4G and third-generation (3G) networks may be the same, such that the control plane cannot control application entities or layers. These communication networks typically include a signaling network that may be used with ground-based routers. In 4G, the signaling network may be SIP, and in 3G, the signaling network may be SS7, both of which typically use ground-based routers in the same manner. In contrast to these typical 3G and 4G networks, LEO systems may utilize SDN in 5G networks to provide the desired functionality of specifically separating the control plane from the data plane and application layer control of the control plane. LEO systems may use at least one SDN controller to use or direct the control plane with respect to the data plane.

[0358] As described above, 5G-related SDN may allow for routing and management to secure the control plane so that network control signaling can be separated from the data plane (e.g., voice, data traffic, etc.). The ability to separate the planes from one another allows virtual functions supporting the control plane to be supported by computing on a LEO system (e.g., a LEO satellite) separate from the LEO satellite whose resources support data communication across the data plane between the two locations. In separating and securing the control plane, signaling and handshaking may be performed securely between these two locations to support data communication across the data plane and to implement specific data plane operations, such as broadcast, multicast, specific types of routing, etc.

[0359] In some examples, the LEO system may be able to use the OpenDaylight standard (e.g., use of SDN and network function virtualization (NFV), such as use of the OpenDaylight Representational State Transfer (REST) ​​API) to distinguish and separate control between an SDN controller on the LEO system, which may provide control of the control plane, and SDN applications (e.g., SDN applications may be on a ground system to instruct or use the SDN controller on the LEO system). This standard's functionality may include use of application programming interfaces (APIs), which may be used in the LEO system to instruct the control plane. These APIs between the SDN applications (e.g., on the ground) and the SDN controller in the LEO system (i.e., in the air), may be used to instruct the control plane with respect to the data plane (e.g., take action on data flows). The control plane SDN controller may also manipulate other APIs that affect data flows in the data plane, as described in more detail below.

[0360] (Transfer plane / data plane control of LEO systems) LEO systems can use forwarding plane or data plane technologies to address the forwarding plane problem. Communications of LEO satellites with earth stations in a LEO system can include a view of each LEO satellite for a relatively short period (e.g., about 6 to 10 minutes) before the connection may need to be switched to a new LEO satellite over the horizon. The buffering and logistics required to maintain an uninterrupted data stream and support normal packet processing while traffic flows to and from the earth station can be challenging for LEO systems because, at the ground level, the ground or ground system may require tracking subsystems, gimbal subsystems, and / or other types of subsystems that can connect to the LEO satellites and then proactively modify routing tables from the ground station through the LEO satellites to the LEO system. This is sometimes referred to as the forwarding plane problem.

[0361] In general, the forwarding plane (sometimes called the data plane or user plane) may be a terrestrial system on the ground working with routers in the LEO system, where the LEO satellites are moving at high speeds (e.g., X miles per second) and the routers in the terrestrial system are fixed. In summary, there may be fixed routers on the ground and moving routers on the LEO satellites in the sky. The forwarding or data plane may need to be proactive so that it can anticipate future LEO satellite arrivals (e.g., within a one-hour window) and route efficiently without interruption and without disrupting the control plane, since the control plane is not time-sensitive but can eliminate or at least limit dropouts that can terminate calls and / or cancel signaling channels.

[0362] In some examples, there may be communications between LEO satellites, such that a forwarding plane or data plane may be needed at least partially in the sky via the LEO system. In some 5G and SDN network examples, the control plane may be under the control of an application on the ground. For these examples, the control plane may be under the control of the application, and the application may need to invoke certain types of capabilities (e.g., broadcast capabilities), so it may be necessary to have a forwarding plane or data plane (or at least a portion of the forwarding plane) in the sky of the LEO system that may be adaptable to application commands or able to encompass what the application may be doing.

[0363] For example, consider the case where communication takes place between New York and Tokyo. If an application chooses to perform this communication function, the LEO system (above ground) forwarding or data plane may handle the terrestrial system (on the ground) forwarding plane, but may also handle the above ground forwarding plane through communication between LEO satellites. In this example, the LEO system, by utilizing 5G SDN as described in this disclosure, can provide the ability to take over this control so that it can request all LEO satellites in New York and all LEO satellites in Tokyo to run this communication or broadcast application. The associated data stream may need to be duplicated twice so that one stream can be sent to the New York LEO satellite and another data stream can be sent to the Tokyo LEO satellite at the same time. (Control and data plane nodal network)

[0364] In some examples, the control plane may be arranged as control plane nodes (e.g., each LEO satellite may be a node), which may be connected by free-space optical links or transmissions. These free-space optical links may be lasers in space. The control plane nodes, e.g., LEO satellites, may be connected by free-space optical links or transmissions. In contrast, as noted above, terrestrial systems (e.g., terrestrial backhaul) may be connected by physical fiber optic cables.

[0365] In this exemplary embodiment, the control plane loads may be connected by free-space optical links that traverse the control plane nodes. An example of this may include networks (e.g., 5G networks) that expect that the control plane may reside in nodes that are physically separate from the nodes carrying the data plane in most cases. In most cases (except for secure calls), the data plane may be performed terrestrially (i.e., via a terrestrial system). LEO systems can generally direct the control plane with respect to managing this special set of control plane nodes with LEO characteristics that may bias control plane activity.

[0366] A data plane may be formed from one or more data plane nodes (e.g., each data plane node may be a terrestrial device). In an example, these terrestrial devices may be connected by fiber optic cables. For example, a terrestrial SDN network (e.g., as provided by a carrier) may include interconnectable data plane nodes. A control plane may be used to manage the data plane (i.e., data plane nodes) such that all data plane nodes are considered equivalent to find the optimal node based on topology, traffic flow, latency, etc. The control plane may further be instructed to select some data plane nodes over others with respect to security (e.g., using SIP black / gray / white lists), as described herein.

[0367] (LEO system overview example) In an exemplary embodiment, referring now to the exemplary embodiment of FIG. 21 , a LEO system 2110 is shown at 2100 in communication with an edge network 2112 and a core network 2114 of a 5G network. A previous standard control plane may typically be used between the edge network 2112 (e.g., a 5G edge network or a 5G cloud) and the core network 2114 (e.g., a 5G core network or a 5G core cloud). As shown in FIG. 21 , the LEO system 2110 may utilize software-defined networking (SDN) to separate the data plane from the control plane of the 5G network. The edge network 2112 may be connected to the LEO system 2110 via a control plane such that the LEO system 2110 exclusively directs or uses (e.g., uses an SDN controller) the control plane between the edge network 2112 and the core network 2114 of the 5G network. The LEO system 2110 may determine and generate routes for the data plane by using or directing the control plane.

[0368] In an exemplary embodiment, as shown in FIG. 21 , a first user may use their first user device to send a service request from a first location (where the first user device is located) over a 5G network to transmit data from the first location to a second user device at a second location. The LEO system 2110 may establish software-defined networking (SDN) exclusive control of the control plane (e.g., using the SDN controller 2116) based on the service request. The LEO system 2110 may determine and generate a path for the data plane from the first location to the second location based on the service request and control of the control plane on the LEO system 2110. Data may be transmitted along the data plane from the first user device at the first location to the second user device at the second location based on the generated path of the data plane. In some examples, the second user device may access this transmission from the first user device from the edge network 2112 via the Internet 2120. Core network 2114 may provide signaling to various destinations that traverse LEO system 2110 via Internet 2120.

[0369] In an exemplary embodiment, as described above and shown in FIG. 21 , the LEO system 2110, and in particular the control plane of the LEO system 2110, may be contained in one or more control plane nodes 2118, connected by free space optical links (e.g., which may also be referred to as satellite communications links or inter-satellite links) that form the control plane of the 5G network across one or more control plane nodes 2118. The SDN controller 2116 may be used by the one or more control plane nodes 2118 to direct or use the control plane in selecting one or more data plane nodes 2122 that form the data plane of the 5G network across one or more selected data plane nodes 2122. The one or more control plane nodes 2118 may use the SDN controller 2116 to determine and generate routes for data across the one or more selected data plane nodes 2122. The one or more control plane nodes 2118 may be one or more LEO satellites. The one or more selected data plane nodes may include at least one of a LEO satellite, a terrestrial network device, and a combination thereof (e.g., a mixture of one or more LEO satellites and one or more terrestrial network devices).

[0370] In some examples, the data plane (e.g., bearer network) may be in the form of fiber. The data plane may provide transport of VPN / non-VPN data and / or voice / video data.

[0371] SIP may be commonly used by LEO system 2110 to signal and control multimedia communication sessions, such as with voice and video calling applications, as described in more detail below. Specifically, secure SIP may be used to provide blacklists and whitelists, as well as source authentication, as described in this disclosure. In some examples, SIP greylisting, as described in this disclosure, may also be utilized.

[0372] The HSS may generally be used to generate authentication vectors for subscriber authentication. The HSS may also be used by the LEO system 2110 as described in this disclosure. In an example, for a 5G network, the Authentication Server Function (AUSF) may rely on information provided by the HSS, such as International Mobile Subscriber Identity (IMSI) data, which in turn utilizes a Unified Data Management (UDM), a data repository managed by the HSS. The AUSF may generally be similar to the functionality of an HSS / AAA server in a 4G network for authenticating user equipment (UE). The UDM may generally provide various operations (e.g., similar to the HSS / AAA in 4G), such as user identification processing, user authentication, subscription management, and access authorization. The HSS, together with the AUSF and / or UDF, may be used with subscriber data, Subscriber Identity Module (SIM) information, and phone information as described in this disclosure. These HSS-related modules may be used, among other things, to verify the identity of a requesting system using certificates, as described above with respect to verifying a user's identity using risk-based multi-factor authentication.

[0373] The LEO system 2110 can interact with various software applications to provide different types of control and direction to the control plane. For example, some applications may include network interactive voice response (IVR), DN pooling, private dialing plans, network private branch exchange (PBX), portability, announcements, and / or disaster recovery.

[0374] The LEO system 2110 may also include and / or provide a Session Description Protocol (SDP), as described in more detail below. SDP may generally involve endpoints negotiating parameters of exchanges, such as session announcements, session invitations, and other parameters. SDP may generally be used between endpoints for negotiation of media types, formats, and other related properties. In particular, the LEO system may use SDP for programming applications that may deal with private networks or specific interworking requirements (e.g., language translation, announcements, etc.).

[0375] The LEO system 2110 may generally use an SDN controller 2116 for network-related control such as routing, forwarding, and access control lists (ACLs). The SDN controller 2116 may be used to provide data plane control via a data plane control interface (e.g., an API) so that packet forwarding actions can be issued by the SDN controller 2116 (e.g., associated SDN control software).

[0376] (LEO System Handshake Process) The LEO system may provide handshaking functionality by using a handshake subsystem (e.g., a handshake application) that may manage all inter-carrier handshakes. For example, sensitive and secure communications (e.g., phone calls) may be transmitted in a sovereign military application. If the transmission is between Washington, D.C., and a military base, the transmission may traverse at least three to four terrestrial connection points or more. Typically, this transmission may follow a data plane that includes a route via one or more undersea cables. These undersea cables may be connected by one or more terrestrial networks that route the transmission across the undersea cables. The data plane route may include several terrestrial networks in less developed countries or simply countries with minimal or no security standards (e.g., below software security standards established by platforms that may be relevant to sovereign military security standards). The control plane may determine all of these undersea and terrestrial points (e.g., undersea cables and terrestrial devices) to establish the data plane route.

[0377] Each time a communication or transmission passes through a country's embassy or ground point, the communication may be passing through different carriers with a carrier handshake. As mentioned above, the secure Domain Name System (DNS) is designed to protect the integrity of inter-carrier signaling information, but many inter-carrier relationships rely on trust. Carrier handshake security issues are typically addressed by the carrier's session border controller so that each carrier can validate the communication as meeting its security profile. However, there is no way to determine the trustworthiness of local security profile standards. For example, if a communication and / or transmission passes through a high-risk country, the communication systems of these countries may have minimal security standards (e.g., implementing minimally secure or completely insecure security protocols) as described above, which may allow information to be accessed through attacks or hacks (e.g., man-in-the-middle attacks). These countries with risky communication security standards have immature networks where administrators may be unaware of attacks and external attackers accessing and / or extracting data over the ground links of these networks. Thus, by moving the control plane (i.e., including routing decisions) to the LEO system (i.e., LEO satellites), it may no longer be necessary to obtain permission from either terrestrial or submarine carriers. Furthermore, the LEO system, with control of the control plane, provides at least control over which terrestrial and / or submarine carriers may be permitted for routing by the data plane. These carriers may be selected based on being sovereign carriers with known security standards that meet the LEO system administrator's security standards (e.g., as set by sovereign military security standards for communications / transmission).

[0378] (Database transferred to or set up in the LEO system) (User Device Identification Database) Transferring control of the route to the LEO system (i.e., control to the sky) can provide route resolution where the user device (e.g., handset) may be located anywhere in the world. In an example, this may be achieved by transferring relevant databases, such as databases related to routing (e.g., telephone numbering databases), to the LEO system. For example, in order for the LEO system to determine where in the world a user device may be located, the LEO system may need information related to the user device in the LEO system, such as user device identification information. Specifically, the user device identification information may include mobile identification information, user information, carrier information, and / or the owner of the user device. This database with user device identification information may be transferred to, or at least accessible by, the LEO system to eliminate the above-mentioned handshakes (e.g., terrestrial and / or undersea handshakes). Other databases involved in and / or necessary for control of the route may be transferred to, or at least accessible by, the LEO system as needed to support “control plane” functions. These databases may be duplicated in many respects when transferred to the LEO system.

[0379] (Portability Database) Another database included in (e.g., created in) or accessed by the LEO system may be a portability database (e.g., a number portability database) to assist with any complex issues related to portability issues. These portability issues may refer, for example, to a situation where a user switches carriers and retains their phone number information, but the original database holding the user's information is moved from carrier to carrier (referred to as "number portability"). At this time, the number may lose its association with the carrier. This disassociation may be captured in the number portability database so that the LEO system can use the number portability database to resolve these and other similar issues. For example, in order for the LEO system to track a user's mobile phone, the LEO system may need to determine the user's actual carrier. This may be accomplished by going through the number portability database, since the phone number itself does not indicate an associated carrier. Furthermore, in order for the LEO system to determine that the user is a legitimate user, the LEO system may need the user's mobile identity and home service information. The home service information may be maintained by the user's carrier, which may be copied to the LEO system or at least accessed by the LEO system. In examples, some carriers may not want this type of information traveling in the air over the LEO system, but as long as the LEO system can determine that the user belongs to a carrier (e.g., preferably a legitimate carrier such as Verizon®), the LEO system may send a query to the carrier for verification. Specifically, the query may include a LEO system request identifying the user as being on the LEO system's network, providing MZ information from a portability database, referencing the link between the user and the carrier, and requesting authorization to provide service to the user.The carrier may respond that the LEO system is or is not authorized to provide service to the user. In summary, in an example, the LEO system may have access to MZ data and phone number data, as well as access to an airborne number portability database (e.g., the data and number portability database may be pushed to the LEO system on one or more LEO satellites).

[0380] (encryption key) If the user is authorized by the carrier, the carrier may send several encryption keys to the LEO system for decrypting information the LEO system may need. For example, the carrier may provide an encryption key, such as an anchor key, for the user's communications (e.g., the anchor key may be associated with the user and / or the user device). The anchor key may be maintained at the end of the end-to-end network that may serve the user's communications (e.g., the last point in the network chain). The anchor key may be used for all transactions for the user device. In some examples, once the user equipment communications are complete (e.g., all communications related to the same transaction or within a predetermined time frame have been sent or received), the anchor key may be discarded and its relationship to the home serving network information may be discarded. Furthermore, a communication may then be sent back to the home serving network requesting compensation for providing service to the user at the user's location. This example is a snapshot of how call processing is performed using encryption keys.

[0381] In some instances, there may be security risks in terrestrial systems when a call is terminated. For example, when a call ends, a user's anchor key may be intended to be disassembled and destroyed, but many carriers may retain the anchor key information. This may pose a security risk to these users because the anchor key information is stored by one or more carriers and may be accessible to external attacks. Access to the anchor key may also result in security breaches, such as misregistration attacks or replay attacks that artificially extend a session. By shifting the control / management of this anchor key to the LEO system, this disassembly and destruction can be controlled and managed by the LEO system based on criteria set by an administrator, and users can be free from being bound by other terrestrial system criteria (e.g., minimum type network criteria) that may conflict with the administrator's preferred security criteria.

[0382] In another example, the anchor key mechanism may be maintained and executed at the edge of the network (e.g., on a visitor network). In this example, the anchor key mechanism may not be on the LEO system, but the mechanism may subtend or support the LEO system. In another example, a LEO system may be at the edge of the network (e.g., serving an embassy point and bypassing a local network) and use the anchor key mechanism.

[0383] (Home service information using the application) In some exemplary embodiments, home service information may optionally be moved to the LEO system. For example, home serving information may be moved to the LEO system for classified groups of users (e.g., only users authorized to use the LEO system). The classified groups of users may also indicate only users from one or more selected or designated sovereign nations. For users from other countries, associated carriers may be identified, and the LEO system may then send queries to these associated carriers and have the carriers respond to the queries. Using the example where two users (a first user and a second user) are within a classified group of users and selected / designated countries, a signal connection may be established from the first user's location A to the second user's location Z. The LEO system (e.g., a specific control plane application of the LEO system) may perform this connection, which may initiate or activate services.

[0384] In some exemplary embodiments, the active service may be an interactive voice response (IVR) service because the user was unable to make a call and instead sent a communication through an IRV device. The IVR may play a message (e.g., a recorded voice of the user), or a message may be sent to a private branch exchange (PBX) type system (e.g., an Internet Protocol Private Branch Exchange (IP PBX)) to attempt to locate the first and / or second user within the PBX group. This process may be performed via a software application, such as an IVR application. The software application may run on the LEO system or remain running on the terrestrial system. Generally, the control plane on the LEO system allows flexibility for the administrator of the LEO system to decide which applications can be moved to the LEO system depending on availability, urgency, and security requirements. Each time a software application is moved to the LEO system (e.g., in the air), computational power may need to be determined to accommodate increased processing. In some examples, as described above, only application control may run on the LEO system (e.g., app control in the air and applications on the ground), while the application itself can continue to run on the ground system. In another example, some applications (which would normally be run on the ground) may be run on the LEO system (e.g., running app control and some applications in the sky), especially for sensitive safety applications.

[0385] (LEO system with Session Initiation Protocol (SIP) and Session Description Protocol (SDP)) In an exemplary embodiment, control plane messages may need to be tracked while a connection is actively running between a first user's location A and a second user's location Z. Some of these control plane messages may be related to billing, while others may be related to features that may be initiated or invoked during a call. For example, a user may decide to add another user to a call. This may be referred to as a mid-call trigger. The same process described above (e.g., the process used to set up a call between a first user and a second user) may be repeated in a mid-call trigger to add another user or users to the call. These mid-call triggers may need to have a good reputation, as Session Initiation Protocol (SIP) and all of its associated processing functions as described in this disclosure may need to be added to the LEO system (i.e., added to the satellites overhead). Thus, in some examples, SIP may be replicated in the LEO system for triggers such as mid-call triggers.

[0386] LEO systems can use and deploy SIP resolution for dedicated computation in support of the control plane, so that a layer of SIP security (i.e., empty security protocols) can ensure all communications can be secured in the signaling and control planes. 5G communications networks and computing platforms may deploy a layer of SIP so that the control plane can be used over SIP. For example, SIP resolvers can be deployed in LEO systems, particularly in the forward plane (e.g., forwarding plane satellite operations with LEO), so that calls can bypass unknown, unverified, greylist, or blacklist proxies, or where source identity cannot be confirmed using its extended SIP security protocols. Secure SIP with diversion routing may be used to eliminate typical "middle" processing (e.g., rerouting a call by a user who was not properly identified). In some examples, VPNs may be provided by encryption technologies processed by the core network in the platform's data plane and may be part of SIP / SIP extensions and secure SIP that can be implemented by the LEO system (e.g., of the platform) in the control plane.

[0387] SIP may involve pure signaling that may connect communications (e.g., from location A to location Z). Session Description Protocol (SDP) is a protocol that may be used to disseminate call model information and / or adapt the call model in real time, as well as add services during a call. In some instances, SDP may be implemented as a voice-only operation. In other instances, SDP may be used for Short Message Service (SMS) traffic and multimedia traffic, since multimedia traffic may typically be implemented over the control plane (e.g., a data plane may not be needed to send short messages such as SMS messages or minimum-byte packets). Efficiencies can be gained by using the control plane for this end-to-end signaling of secure data.

[0388] In some exemplary embodiments, SIP may be added to a LEO system (i.e., over the air) with full SIP capabilities in the form of SIP virtual servers (e.g., which may also be referred to as SIP proxies or registrars) that can provide management of SIP calls within the network. The LEO system may also include Session Description Protocol (SDP) virtual servers. These SDP virtual servers may be used in conjunction with SIP virtual servers to specify and carry sessions (e.g., session media). SDP virtual servers may be used in multimedia communication sessions for session invitations and session announcements, primarily used in streaming media applications such as video conferencing and VoIP. For example, a first user may add a second user to a call with an intermediate trigger, but the added second user may be from a country with security concerns and may speak a different language than the first user. Using SDP virtual servers, the LEO system can initiate real-time interpretation functions (e.g., translating from one language to another in real time for the first speaker and vice versa via back-translation for the second speaker). In some instances, there may be sovereign military applications under the control of the SDP virtual server, and an SDP virtual server (including SDP-related software) may be required on the LEO system to control these sovereign military applications. Having SDP functionality on the LEO system also enables control plane and data plane encryption processing and end-to-end encryption. Thus, having SIP and SDP virtual servers (i.e., SIP software and SDP software) on the LEO system has several advantages.

[0389] In an example embodiment, moving the SDP functionality to the LEO system allows software development (e.g., to support DevOps and may include DevSecOps as described above) to be managed on the LEO system, thereby further improving security management. For example, the SDP may enable programmers to change the model (e.g., change the call model). While the call model might otherwise typically be fixed, moving the SDP to the LEO system may enable the call model to be changed, new functionality to be added, and / or other actions to be taken in support of software applications running on the ground (i.e., on the ground system), e.g., by implementing changes to the call model through the SDP.

[0390] (Data blocking from the control plane) In some example embodiments, multimedia traffic may be carried over the control plane (e.g., using SDP). The LEO system may provide the ability to block multimedia traffic from being carried over the control plane to improve security. Specifically, the control plane may block SMS traffic and multimedia traffic from using the control plane. This may prevent dangerous data, such as insecure video, malware, etc., from being transmitted over the control plane.

[0391] For example, if SMS and multimedia messaging services (MMS) are stopped from the control plane, each instance where there is an SMS or MMS requirement may need to set up a bearer channel (e.g., a data plane channel). The data plane may be performed, for example, via geostationary (GEO) and medium earth orbit (MEO) satellites and / or terrestrial networks (e.g., terrestrial devices), as is done for typical data plane connections. In other exemplary embodiments, the data plane may be performed over a LEO system depending on the data.

[0392] (LEO systems that use a control plane to direct data plane routing) In an exemplary embodiment, the LEO system may use its control of the control plane to direct routing in the data plane. Typically, the control plane may provide information to a terrestrial device (e.g., a terrestrial server). Once the control plane sets up a route (e.g., a route from location A to Z), the portion of the control plane near A may then communicate the step-by-step routing with the portion of the data plane near A. Specifically, this communication may be between the LEO system and a terrestrial device (e.g., a terrestrial server) near location A where the data plane originates. For example, the portion of the control plane (e.g., the LEO system) near A may provide the following instructions: to reach location Z, a data link may need to be set up to router # near location A; link #, undersea cable #, cross-connect # may terminate and go to router # instead, etc., until it terminates at router # near location Z. The control plane can set up the physical path route that is communicated. The control plane may evaluate the physical path and provide the physical path information to the data plane, which may set up this physical path (e.g., the setup may be done using typical standard Internet routing protocols).

[0393] Having a control plane on the LEO system may allow for customized control of the data plane's data plane routing. This is especially important when dealing with high-security data. For example, highly secure calls may require purpose-built routing through trusted terrestrial networks and / or trusted LEO networks. In this arrangement, control of the data plane routing may be initiated and monitored by the highly secure LEO system. Routing data plane connectivity across the globe may be controlled with respect to taking into account security standards around the world, such that routes may be configured to avoid routes through certain regions. This may be based on the country of the region and / or whether the region has security standards below a preferred security standard (e.g., below software security standards established by the platform, which may be related to sovereign military security standards), such that this threshold may be used in determining and configuring data plane routes. The LEO system may manage and direct the control plane in routing the data plane to meet the LEO system's rules, protocols, and / or standards. These rules, protocols, and / or standards may be configured by an administrator of the LEO system.

[0394] Thus, in some examples, a limited amount of particularly sensitive traffic on the data plane may be carried through the LEO system for a specified security level (e.g., a threshold level of security). For example, if data can be classified and / or marked with various levels of security, the LEO system may be able to determine whether data is associated with a particular level of security or above, indicating that the data plane may be handled according to administrator standards (e.g., running all or part of the data plane on the LEO system). Alternatively, communications may be distinguished as having some or any level of security versus communications with no level of security, such that secure communications may be treated differently depending on the data plane. In some examples, at the highest security level, the control plane may be in a secure mode such that managing, controlling, and / or coordinating the data plane can be accomplished as needed to comply with security (e.g., as identified by an administrator's security rules). This complying security may result in the data plane being carried out on the ground (e.g., via a ground system), in the air (e.g., via a LEO system), or a combination thereof.

[0395] (Identifying ground paths to avoid for LEO systems) The data plane may pass to the ground via a bearer channel or connection, or it may pass across a LEO system (e.g., across one or more LEO satellites via free-space optical links between LEO satellites). The passage of the data plane across LEO satellites may be highly secure. In contrast, the passage of the data plane across a bearer connection or channel via a terrestrial system / device may be insecure. Therefore, controlling the routing of this terrestrial data plane is important for security. The terrestrial data plane may also be configured with additional encryption. A path or route may include ground-based stations, which may be interconnected by submarine communication cables and several terrestrial cables. For example, several submarine communication cables exist, including SEA-ME-WE 3 (Southeast Asia-Middle East-West Europe 3), African Coast-Europe (ACE), Asia-America Gateway (AAG) cable system, and ITUR (Italy-Turkey-Ukraine-Russia). Terrestrial communication options may be limited, as some cables are constructed by consortia. To avoid certain cable lines (e.g., to avoid passing through areas of substandard security), the LEO system may instruct the control plane to configure paths for the data plane that avoid one or more cable lines that may be reported to the router. These different cable lines may be coded with identifiers such as a Common Language Facility Identifier (CLFI) or a Common Location Language Identifier (CLLI). A CLLI may be a code that specifies a terrestrial link from one point to another (e.g., point A to point B). A CLFI may be a Facility Identifier that references, for example, a submarine cable from point A to Z.

[0396] When a path may be generated for the data plane, the path may include or consist of a combination of CLFIs and CLLIs. Each CLFI may be considered a conduit, and each CLLI may be considered a cross-connect point. The generated path may include a chain of CLFIs and CLLIs, which may represent a data plane path. The control plane may generate this path for the data plane. In some examples, a terrestrial carrier may be instructed that these are CLFIs and / or CLLIs that may be approved for a bearer channel. CLFIs and / or CLLIs that may not be on an approved list (e.g., an approved whitelist and an unapproved blacklist for CLFIs and CLLIs) may be instructed to the terrestrial carrier so that devices and cables associated with unapproved CLFIs and CLLIs (e.g., on the blacklist or not on the whitelist) may not be used in the data plane path. In some examples, a list of approved CLFIs and / or CLLIs may be used to instruct the terrestrial carrier (e.g., a path whitelist, such as a whitelist of CLFIs and / or CLLIs). This list may be a predetermined list that may be determined and configured by an administrator of the LEO system. This list may be updated by the administrator as the whitelist (approved) and / or blacklist (unapproved) of CLFIs and / or CLLIs may change. In some examples, the generated proposed routes themselves (e.g., based on security criteria for different regions, countries, ground equipment, etc., as described above) may be used to direct the approved CLFIs and / or CLLIs to the terrestrial carrier.

[0397] Because SIP headers can contain routing information, the data plane path can be identified from the SIP headers. The LEO system can access and / or retrieve the SIP headers to identify the data plane routing information. Because the data plane may run through the Internet, identifying the data plane path from the data plane itself can be difficult (e.g., Internet routers typically have their own independent control over actions related to data plane routing). Arrangements with carriers may be established such that a provided list of approved CLFIs and / or CLLIs (e.g., CLFI and CLLI whitelists) can only be used for routing data plane traffic through the listed CLFIs and / or CLLIs (i.e., CLFI and CLLI whitelists). In some examples, the whitelists may include blacklists of approved terrestrial network VIAs (e.g., SIP VIAs) and unauthorized terrestrial network VIAs (e.g., SIP VIAs).

[0398] In an exemplary embodiment, the LEO system may have the capability for the control plane to similarly manage routing and communications for the data plane to the LEO satellites. In this example, some LEO satellites may be authorized, while others may not. Data plane routing through the LEO system may be permitted only via authorized LEO satellites. Authorized satellites may be members of the LEO system and thus form constellations. Also, some authorized satellites may be part of other constellations that are not necessarily part of the LEO system. Similar to the CLFI and CLLI lists described above, the LEO system may also include a whitelist (authorized satellites) and / or a blacklist (unauthorized satellites) of satellites. Satellites may be referenced in the list by some form of identifying information that can be associated with and correspond to each satellite (e.g., LEO satellite). In some examples, the LEO system may use the control plane to generate data plane routing only via authorized LEO satellites or via a combination of authorized LEO satellites and authorized terrestrial systems.

[0399] In an exemplary embodiment, a LEO satellite may typically only interact with satellites within the same constellation, such as a LEO satellite member to a LEO system (e.g., when all satellites within the same constellation have the same level of security standards, forming a closed ecosystem). In this example, a data plane path when traveling across satellites may include only LEO satellites within the same constellation. In other exemplary embodiments, LEO satellites of the same constellation (e.g., members of a LEO system) may interact with satellites of other constellations, which may have security standards that are the same or different from those of the satellite's LEO system constellation. Thus, based on an approved list of satellites and / or satellite constellations (e.g., similar to the satellite whitelist described above) or administrator-selected security standards, a data plane path may be set up across multiple constellations with security standards that at least meet the security standards of the constellation of satellites associated with the LEO system.

[0400] In an exemplary embodiment, the LEO system may configure the data plane (e.g., using the control plane) to have a path that includes a combination of LEO satellites (e.g., from the same constellation or multiple constellations) and ground systems, such that the path may pass through one or more authorized LEO satellites and one or more authorized ground systems. This combination may require the data plane path to go from location A to the sky, back from the sky to the ground, back from the ground to the sky, and then from the sky to location Z, as needed, to provide the most direct path via only authorized satellites and authorized ground systems.

[0401] (LEO system-wide data plane flexibility for highly secure data) Complete control of the control plane for higher security transactions (e.g., calls) may generate preferred routing because the locus of control for the control plane is on the LEO system. Some communications may have specific security requirements (e.g., multi-level security requirements or multiple level security (MLS)) that may have to be met through a data plane running over the LEO system (e.g., via a LEO satellite). This can avoid security concerns, especially for overly sensitive information (i.e., highly secure traffic). For other communications, the data plane may use terrestrial equipment, links, and systems (e.g., terrestrial servers).

[0402] For example, for highly secure calls, tailored routing via trusted terrestrial networks and / or trusted LEO networks may be achieved. Specifically, for example, for a given particularly sensitive secure call, a system administrator of the LEO system for the control plane may provide an indication that the terrestrial network is untrustworthy and therefore the sensitive call may need to be routed over the LEO system. Alternatively, the data plane may be routed through the LEO system for part of the path (where this part of the path may be through an area with less than standard network security), and the data plane may be migrated to a terrestrial network (e.g., associated terrestrial devices) for the remainder of the path (e.g., the remainder of the path may be through a network with security at or above the administrator-selected network security preference). Data plane traffic (e.g., bandwidth and capacity in bits per second) may be substantially higher and larger than control plane traffic. Thus, there may be a general interest in limiting and reducing data plane traffic as much as possible on the LEO system (i.e., the satellite hardware of the LEO satellites) to reduce costs associated with the satellite hardware required to accommodate the data plane traffic.

[0403] The control plane on the LEO system allows flexibility in providing the data plane. This flexibility may include the ability to provide the entire data plane over the LEO system (i.e., empty), the ability to provide a portion of the data plane over the LEO system (e.g., a combination of terrestrial and LEO systems), or the ability to not provide the data plane over the LEO system (i.e., the data plane entirely over the terrestrial network). This can be based on the data itself, such that the data plane of sensitive data can be run entirely over the LEO system, or only a portion of the data plane can be run over the LEO system. For example, highly secure MLS communications may be transmitted entirely over the data plane over the LEO system.

[0404] (LEO system satellite configuration) In an exemplary embodiment, dedicated compute to support the control plane can provide edge compute nodes on the LEO system to address latency issues. Power resources on a LEO system satellite(s) can be shifted from communications to compute, specifically for control plane computation. For example, each LEO system satellite can be a compact satellite focused on computing (e.g., narrowband computing) that dedicates more power to onboard computing. This differs from most standard satellites, which are focused on communications rather than computing. The LEO system can utilize cloud computing and SDN to move calls to various members of the LEO system. Using SDN, compute can be dedicated to support the control plane of the LEO system (e.g., LEO satellite).

[0405] A LEO system may be configured to run a control plane and at least a portion of a data plane. As described above, in some examples, the entire data plane may be run on a LEO system. A LEO system may be run on a single satellite and / or multiple satellites (e.g., as part of a satellite constellation). The computing power of each satellite's hardware may be used to determine the number of satellites required for a LEO system. The data plane and control plane may be two separate channels, although these separate channels may be run via a single satellite (e.g., the data plane and control plane are run via the same hardware). In other examples, both channels may be run simultaneously via the same multiple LEO satellites (e.g., a constellation of LEO satellites). This may be accomplished all the way from location A to location Z. With this in mind, a LEO system may need to monitor and manage the data plane load to avoid overburdening the hardware of one or more satellites (e.g., below the hardware's headroom limits). The LEO system can determine the allocation of control and / or data planes across multiple satellites while considering optimized bandwidth and speed, along with balanced loading across the hardware of the multiple satellites (e.g., based on headroom for each satellite). Additionally, the allocation decision may be prioritized based on the security of the data, such that MLS high-security traffic is prioritized over other low-security traffic.

[0406] The LEO system may include LEO management software that may run on satellite hardware, which may include control plane software (e.g., signaling software) and data plane software. As described above, the control plane software may be used to access databases, such as the number database, the MZ database, and the polling HSS database. The control plane software may use access to these databases to determine how to connect communications from location A to location Z and then set up the data plane based on this determination.

[0407] In an exemplary embodiment, a LEO system may be set up with customized LEO satellites having a 5G control plane. The custom LEO satellites may include customized logic and decision-making capabilities. In some examples, a control plane may be set up on the LEO system such that the control plane can be customized at the application layer to implement control plane functions. Satellite intelligence and various control functions may be incorporated to make the customized LEO satellite system unique compared to other satellite systems.

[0408] There may be a partial correlation between control plane complexity and data plane traffic. This may indicate the size, scale, and scope of the control plane hardware, software, and system resources, whose complexity may vary depending on the data plane. For example, as the amount of data plane traffic increases (e.g., gigabits per second, 2 gigabits per second, 10 gigabits per second, 100 gigabits per second), the control plane may need to become more sophisticated to accommodate this traffic. This may not be linear (i.e., not one-to-one), such that a 10x increase in data plane traffic size requires a doubling of the control plane complexity to manage this traffic. In an example, this complexity may indicate more work for the control plane, which may indicate computational power. Control plane algorithms may only need to change when new applications or new call types are introduced. Changing control plane algorithms may require the LEO software to be updated, such as by uploading new LEO software to replace the previous LEO software instead of reprogramming. The amount of data may not affect the control plane, except that the control plane requires more power to handle connections per second or per hour.

[0409] (LEO System Satellite Configuration and Applications) The LEO system may include the ability to run various software applications, or at least the control portions of various applications that were previously run on ground equipment. Various software applications may be moved to the LEO system (i.e., one or more satellites), with the SDN application having control of the control plane or at least being able to influence the control plane. In some examples, as described above with respect to SDN applications, these software applications may be separated between the control portion (i.e., control of the control plane) residing in the LEO system (i.e., in the air) and the remainder of the application residing in ground systems. In other examples, the entire application, or at least the majority of the application, may be executed on the LEO system to avoid security issues from running these applications across one or more ground systems. To do this, the LEO system may require sufficient computing power, which may be hardware-based. This may be sufficient computing power (and associated hardware) to accommodate the execution of at least the control portion of the application, the majority of the application, and / or the entire application (e.g., as needed based on the security criteria of each application).

[0410] For example, each LEO satellite may include a server computer (e.g., a general-purpose computer) capable of executing control software (e.g., an application control portion) that can be directed by a LEO software application (e.g., a control plane application and a data plane application with an API interface between the applications). This arrangement may be the same for any telecommunications network, including 5G networks and other enhancements or upgrades to 5G networks. Specifically, the LEO software applications may be executed at one of the communication points (e.g., location A or location Z) such that application control may be executed on the LEO system. For example, an application server may execute these LEO software applications over a network (e.g., the Internet) from a ground system on the ground (e.g., location A, location Z, or another location). The LEO software applications may be executed across a combination of locations (e.g., location A, location Z, and another location). In some examples, in addition to the control software, at least a portion of the LEO software application may be executed on the LEO satellite. The application control portion may be executed on the LEO system (e.g., an application control in the air and an application on the ground) such that the application itself can continue to run on the ground system. In other examples, as described above, some applications may also move all or at least a majority of the application from the terrestrial system to one or more satellite LEO systems. In an exemplary embodiment, a Kubernetes server may be used to provide control plane related software applications that determine when and where to run pods, manage traffic routing, and scale pods based on utilization or other metrics that may be defined by an administrator of the LEO system.

[0411] In some examples, applications are moved to the LEO system such that these applications can be specialized, highly secure applications and are not third-party applications. These highly secure applications may be API-type applications for secure communications such as "hotline" calls. Generally, most applications typically run on terrestrial systems (e.g., cellular) such that only the control plane aspects of these applications may be moved to the LEO system. Highly secure applications may run entirely, or at least a majority of the application may run on the LEO system.

[0412] Furthermore, additional security options may allow portions of an application or the entire application to be migrated to a LEO system. One form of security may include encryption of data transmitted by the application. Furthermore, in some examples, backhaul over a terrestrial link can be avoided by instead extending the data plane over the LEO system, with or without overhead encryption, so that data can be transmitted via LEO satellites.

[0413] (Third-party applications) In an exemplary embodiment, the LEO system can interact with third-party applications. Third-party applications (e.g., video applications) may typically be hosted on third-party servers. Utilizing the previous call example (locations A to Z), the LEO system may allow a user to transmit video on the third-party server using a third-party video application during the call. The third-party application running on the third-party server may not be subject to control of the control plane by the LEO system. What may be subject to control is the data path for this communication and transmission (e.g., where the stream of data is running). Specifically, the LEO system can direct the control plane (e.g., using an SDN controller). Upon a mid-call trigger, the control plane may be used to direct the data plane (i.e., data traffic) to the Z location via a specified path based on application control in the LEO system. While the LEO system is using the control plane to direct data plane routing, applications can continue to run on ground systems and devices, including third-party applications.

[0414] (Reprogrammable or reconfigurable type of satellite for LEO system) In an exemplary embodiment, a reprogrammable LEO satellite system can be reconfigured to manage the control plane. Typically, most legacy satellites are set up to handle large amounts of traffic over data plane communication pipes. Because satellites typically lack the computer hardware to locally implement control plane functions, reconfiguring a legacy satellite that has already been launched can be difficult. There may be a need to launch a reprogrammable satellite that can be remotely reconfigured. For example, a reprogrammable LEO satellite may include field programmable gate array (FPGA) hardware (e.g., using tunable repeaters with digital repeater filters) that is remotely flashed and flexibly reconfigurable from terrestrial systems and devices on the ground. In other examples, a reprogrammable LEO satellite may be reprogrammed without an FPGA, while utilizing other techniques to provide LEO software reprogrammability, such that the LEO satellite can be reprogrammed to manage the control plane. Applicant understands that various reprogrammability techniques can be used with or without FPGA hardware.

[0415] It may be of interest to provide interconnection, interoperability, communication, transmission and reception with other satellites in the sky. As an example, other satellites that are not part of the LEO system (e.g., third-party satellites) may be launched with reprogrammability (e.g., the ability of reprogrammable satellites to synchronize in terms of interfacing with the LEO system) that allows these satellites to be added and / or linked to the LEO system after launch. These other LEO satellites can be added to the LEO system's constellation of satellites to form new constellations of LEO satellites. Reprogrammability can be used as a way to extend the LEO system's 5G control plane capability interface to other third-party satellites that are not original members of the LEO system (e.g., reprogrammable third-party satellites). In some exemplary embodiments, satellites may be launched with integrated field-programmable gate arrays (FPGAs) (e.g., the DirectStream FPGAs described herein), which may technically allow for at least easier reprogramming than previous satellite architectures. Using FPGAs, the LEO satellite hardware can be flashed and reconfigured from the ground to provide the functionality described herein, particularly software related to managing the control plane versus the data plane. In other examples, reprogrammable LEO satellites may be reprogrammed without an FPGA, utilizing other techniques to provide for reprogramming of the LEO software such that the LEO satellite may include reprogrammed software related to managing the control plane relative to the data plane. In other exemplary embodiments, applications may be built on a ground system and then uploaded to the LEO system (i.e., the LEO software of one or more satellites) using appropriate security measures.

[0416] (LEO system interacting with application plane and data plane via API) In an example embodiment, referring now to the example embodiment of FIG. 22, a LEO system 2110 is shown at 2200 using a control plane to interact with the application plane and data plane of a 5G network. As described above, the control plane runs along the LEO system 2110 and can involve and / or communicate with other planes, such as the data plane and application plane (sometimes referred to as the management plane), using an SDN controller 2116. In some examples, these planes may be segmented and separated from each other with distinct authentication and privilege boundaries. In some examples, the control plane may include one or more SDN controllers 2116 that communicate with each other in providing the responsibilities of the SDN controllers. The application plane typically hosts SDN applications 2230 that can communicate with and direct the SDN controllers via a northbound interface (e.g., a standard northbound API for providing an application control interface). The northbound interface can use northbound APIs to provide network configuration and management for the SDN controller 2116. As described above, the northbound APIs may be OpenDaylight APIs (e.g., using OpenDaylight Representational State Transfer (REST) ​​APIs) to provide an interface between the application plane (which may include, e.g., a user interface) and the control plane. SDN applications 2230 can communicate necessary transport operations and resources to the SDN controller 2116 on the control plane via these northbound APIs. Each SDN application 2230 may include application logic and drivers. SDN applications may relate to network, business, service, and cloud orchestration. SDN applications may also provide network analysis, routing, traffic engineering, mobility, network virtualization, quality of service (QoS), monitoring, security, and so on.Other applications (e.g., business applications 2232 and third-party applications 2234), as described above, may be included in the application plane to configure the network for various purposes. In the control plane, the SDN controller 2116 may translate application plane requirements from northbound APIs to control routes for the data plane. The SDN controller 2116 may be used to generate network maps used by SDN applications (e.g., in determining data plane routes). The data plane, sometimes referred to as the infrastructure plane or layer, refers to the network infrastructure or devices 2240 (e.g., routers, switches such as physical and virtual switches that may include LAN switches and packet switches, network devices, core networks, base stations, etc.) that implement the SDN data path and forward data traffic. The network infrastructure or devices 2240 may directly control data processing and forwarding for the data path throughout the network. The SDN controller 2116 can communicate with this data layer (e.g., data plane network infrastructure or devices) via a southbound interface (e.g., southbound APIs such as OpenFlow), which may provide a control data interface. The southbound API may provide data plane control by using a control protocol such as OpenFlow, which is a communication protocol that can provide access to the data plane of the network infrastructure or device 2240. In summary, the SDN controller 2116 may receive instructions from the SDN application 2230, which may be relayed to the network infrastructure or device 2240. The SDN controller 2116 may also extract information about the network from the network infrastructure or device 2240 (e.g., a view of the network, including events and statistics), which may be communicated back to the SDN application.

[0417] (Customizable satellite reprogrammability) In an exemplary embodiment, the SDP and SDN controller elements can be moved to the LEO system, including associated APIs. A degree of reprogrammability is possible through these APIs. These APIs can be powerful enough to implement additional data streams and functionality through these APIs that affect the data flow through the LEO system. This can control the flow through the LEO system (e.g., satellite), such as mid-call triggers.

[0418] In customized satellites, a general-purpose server computer that can be fully reprogrammed by developers may be used on the satellite. In some examples, a Linux server may be used on the LEO satellite that can provide a development operating environment such that applications can be created on the ground (e.g., on the ground system) and uploaded to the LEO system. The LEO system may include a platform that can be run through its validation and then instantiated for the LEO software application.

[0419] (Programming Sandboxing AI Gate) In some example embodiments, there may be computational diversification in the LEO system using sandboxing AI gates. The introduction of sandboxing by the LEO system may be used to prevent the introduction of applications with malware, such that the malware attempts to escape the sandbox or affect the host. Some software applications may run within a sandbox such that the sandbox is wiped if the malware attempts to access memory or data space outside of the sandbox. Other sandboxing techniques may also be used, as described in this disclosure.

[0420] (Other Enterprise Security in LEO Systems) The LEO system may utilize other enterprise-type security, as described in this disclosure. For example, if an application host may be on a Linux server, the LEO constellation provider may not implement typical protections (e.g., host-based firewalls). The LEO system may include firewall security. As noted above, sandboxes may be used knowing whether the host is protected by a firewall. Sandbox rules may be required such that a violation of the sandbox will result in the destruction of the associated application.

[0421] (High precision timing navigation for LEO systems) Precise navigation in timing can be based on a calculated timing build. In LEO systems, the Network Timing Protocol (NTP) may be used to address all communications as time-based. On the ground in terrestrial systems, GPS or NTP may be used. NTP may be an internet-based protocol. Packet networks may require timing functions to maintain packet order and packet priority. For timing, LEO systems may be able to generate and use their own timing references, improving security and robustness. LEO systems can use standard timing standards, such as those used in all networks that may require relatively precise timing for synchronization (e.g., SDN networks, 4G networks, 5G networks). Timing may be from GPS, satellites, and / or other sources. GPS may be preferred because it is satellite-based, isolated in the sky, and generally considered more reliable.

[0422] In one example, a LEO system may include LEO satellites capable of providing a secure sky timing signal for the LEO system, with satellites equipped with their own internal timing source (e.g., generated internally on a customized satellite) that may be comparable to GPS but provide an additional level of security beyond typical GPS for precise timing. This may be achieved using rubidium clocks, photon timing, etc.

[0423] (Other LEO system features) In example embodiments, the LEO system may provide various other functions. The LEO system may provide the ability to ensure that inter-satellite links can maintain all backhaul traffic separated in space between base transceiver stations and the core network, regardless of separation distance. In some examples, machine learning applications may be utilized with the LEO system. The LEO system may provide an enhancement to LEO security by applying a secure control plane to 5G with artificial intelligence (AI) automation (e.g., using machine learning applications). For example, the security of the LEO system can manage the security of the network as it travels around the world.

[0424] (LEO system process) 23 is a diagram illustrating an example of a 5G configuration process generally at 2300. In this example, software-defined networking (SDN) can be utilized to separate the data plane from the control plane of a 5G network 2302. The separated control plane may be implemented across a low earth orbit (LEO) system between the edge network and the core network of the 5G network, such that the LEO system exclusively directs or uses the control plane 2304. Paths for the data plane may be determined and generated by the LEO system exclusively using the control plane 2306.

[0425] 24 illustrates an exemplary LEO-oriented 5G telecommunications process at 2400. In this example, a service request from a first location may be received over a 5G network at 2402 to transmit data from the first location to a second location. Software-defined networking (SDN) control of a control plane of the 5G network may be established exclusively on the LEO system at 2404 based on the service request. A path for a data plane from the first location to the second location may be determined and generated at 2406 based on the service request and the control of the control plane on the LEO system. Data may be transmitted from the first location to the second location based on the generated path of the data plane at 2408.

[0426] (Platform use of other technologies) LEO systems or more general platforms may utilize other technologies. For example, the platform may use Open RAN (O-RAN)-specific items for distributed unit / central unit (DU / CPU) splitting and may implement some specific security language. For example, certificates may be tied to these O-RAN-specific components, including eCPRI stacks / modems. In other examples, the platform may use Secure Edge Proxy Protection (SEPP) in 5G networks. In some exemplary embodiments, the platform may use SEPP to stop bid-down attacks, stop SMS and MMS from running over the control plane, and / or ensure that old keys can be deleted (e.g., using a proxy connection to verify that the previous serving carrier destroyed the keys).

[0427] (MDC sizing) Aerial / satellite imagery may provide local determination of sufficient radio placement, which may be based on site conditions. In embodiments, deployment and placement may be planned with radio head locations and edge data center locations. Edge data centers may be sized according to the number of servers. Ethernet fronthaul, RAN, and routing infrastructure may be configured and shipped to the customer with predetermined installation locations for the radio heads. Once the radio heads are installed, self-provisioning begins.

[0428] (Edge DC provisioning) In an embodiment, the platform may be configured such that an edge data center (DC) initiates an outbound secure connection to a platform provisioning server. In an embodiment, the edge (DC) may be self-provisioning, and in conjunction with a local provisioning agent running on the edge DC, the platform may provision the following software services: RAN, initial bootstrap configuration of radio heads, switching, routing, security, edge DC cloud layer, backhaul, and the like.

[0429] (Customer self-provisioning of edge cloud) Applicant can appreciate in light of this disclosure that customers and users can use the GUI interface for the following purposes: (1) configuring the edge cloud, (2) secure storage and transfer to the central workload (on the edge cloud) using their own key server or one provided on the platform, (3) seamlessly extending the central workload to deploy workloads, (4) self-provisioning user equipment to the site-specific 5G network, and (5) monitoring the status of the cloud and local 5G network.

[0430] (Continuous management and optimization) In embodiments, the platform may monitor and operate the local 5G network and edge cloud. In these examples, the platform may collect data from users' devices that have network coverage, and by doing so, the platform may automatically reconfigure radio characteristics for optimal coverage.

[0431] Additionally, the platform can monitor the edge cloud and network for capacity adjustments, including working with customers to upgrade capacity.

[0432] In an embodiment, the software layers for one or more micro data centers include: (1) auto-sizing, (2) spare space remote radio planning, (3) spare space provisioning, (4) spare space cloud layer, (5) spare space provisioning interface for cloud infrastructure, cloud workloads, user equipment, etc., and (6) spare space monitoring and radio optimization.

[0433] (Micro Data Center - Deployment Architecture) In embodiments, a micro data center (MDC) may include a modular data center architecture that can share some of the same components as some typical data centers. To that end, the MDC may be designed to be portable and provide plug-and-play capabilities. The MDC may have pre-configured compute, storage, and networking, and may further include built-in cooling and fire and security systems. In embodiments, the platform network MDC may prepare all hardware for use and may also provide a ready-to-use software platform for application deployment.

[0434] Each MDC may be deployed individually, or all platform MDCs may be configured together to form a large distributed data center. In these examples, user workloads may reside on one MDC or may be distributed across multiple MDCs.

[0435] (User Management - Accounts and Domains) In embodiments, the platform may be configured to provide each user with an account that may be organized in a hierarchical directory structure. According to these examples, each account may have only one entry in the structure. In embodiments, user authentication information and other attributes may be stored in the entry.

[0436] In these examples, a user must belong to only one domain. A domain may have subdomains, forming a parent-child relationship. A domain may have multiple subdomains, but only one parent domain. In an embodiment, all domains, subdomains, and accounts form a tree structure, with the root of the tree being the root domain. In an embodiment, one domain administrator account may be automatically created when a domain is created, and the domain administrator may have the authority to manage subdomains and accounts.

[0437] In embodiments, accounts on the platform can allocate resources from the platform and become owners of these resources. To control system resource usage, the platform may assign quotas to every account or domain. In these examples, accounts may not allocate more resources than their quota, and the total resources of subdomains, accounts, and groups may not exceed the quota of their parent domain.

[0438] (group) In embodiments, a group may be a collection of accounts that may belong to different domains. Through these examples, a group can act as a container for resources so that users from different domains can work on common tasks. Groups are created by domain administrators, who act as group administrators and can invite other users to join the group. Each group belongs to the domain administrator's domain. As such, groups can own their own resources and receive their own allocations, although resource usage may be limited by domain allocations.

[0439] (service) In embodiments, a micro data center (MDC) can provide a multi-tenant service environment. Both infrastructure as a service (IaaS) and platform as a service (PaaS) can be provided. In embodiments, IaaS may include the basic building blocks for applications, providing access to networking, compute, an...

Claims

1. 1. A computer-implemented method for providing low earth orbit (LEO)-directed fifth generation (5G) telecommunications, comprising: receiving, at one or more LEO satellites of a LEO system, a service request from a first location via a 5G network to transmit data from the first location to a second location; establishing software-defined networking (SDN) control of a control plane of the 5G network based on the service request, the SDN control being performed exclusively on one or more of the LEO satellites of the LEO system to provide sole control and management of data routing between the first location and the second location on a data plane; determining and generating, by the one or more of the LEO satellites of the LEO system, a path for the data plane from the first location to the second location based on the service request and the control of the control plane; transmitting the data from the first location to the second location based on the generated route of the data plane; The method, wherein the data plane is exclusively a terrestrial network.

2. 10. The method of claim 1, wherein the LEO system includes software operating on one or more LEO satellites.

3. 10. The method of claim 1, further comprising utilizing Session Initiation Protocol (SIP) to secure signaling and communications in the control plane.

4. 10. The method of claim 1, further comprising utilizing a Session Description Protocol (SDP) to provide at least one of delivery of call model information, real-time call model adaptation, and mid-call service addition.

5. 10. The method of claim 1, further comprising initiating the mid-trigger event during a call between a first user device at the first location and a second user device at the second location such that Session Initiation Protocol (SIP) and Session Description Protocol (SDP) are used to provide security for the mid-trigger event.

6. 10. The method of claim 1, wherein the route is determined based on at least one of a whitelist of approved terrestrial network VIAs and a blacklist of unauthorized terrestrial network VIAs.

7. 7. The method of claim 6, wherein the whitelist includes at least one of a Common Language Facility Identifier (CLFI), a Common Location Language Identifier (CLLI), a LEO satellite identifier, and a terrestrial network device identifier.

8. 10. The method of claim 1, wherein the data transmitted from the first location to the second location is encrypted.

9. detecting anomalies in the 5G network using pattern recognition algorithms and / or artificial intelligence; and if the 5G network anomaly is detected, reprogramming the data plane to mitigate the 5G network anomaly using the SDN.

10. 1. A low earth orbit (LEO) system for providing fifth generation (5G) telecommunications, comprising: one or more LEO satellites; one or more control plane nodes connected by free space optical links, the one or more control plane nodes forming a control plane of a 5G network across the one or more control plane nodes; a software-defined networking (SDN) controller operating on the one or more LEO satellites for use by the one or more control plane nodes and for instructing the control plane to select one or more data plane nodes, the one or more data plane nodes forming a data plane of the 5G network across the one or more selected data plane nodes; the one or more control plane nodes use the SDN controller to determine and generate routes for data across the one or more selected data plane nodes; A LEO system, wherein each of the one or more selected data plane nodes is a terrestrial network device.

11. 11. The LEO system of claim 10, wherein the one or more control plane nodes are one or more LEO satellites.

12. 11. The LEO system of claim 10, wherein the SDN controller utilizes network function virtualization (NFV) to use the control plane.

13. 11. The LEO system of claim 10, further comprising at least one database associated with routing such that user identification information in said at least one database is used to eliminate a handshaking process.

14. 11. The LEO system of claim 10, further comprising one or more encryption keys for decrypting information related to user device communications and transactions.

15. 11. The LEO system of claim 10, further comprising pattern recognition algorithms and / or artificial intelligence for detecting 5G network anomalies, wherein the SDN controller reprograms the data plane to mitigate the 5G network anomaly if the 5G network anomaly is detected.

Images