A platform for computing at the mobile edge

Abstract

A platform for providing computing resources at and / or near a mobile network border is disclosed. The platform can be used to provide computing resources adjacent to a small cell radio via at least one mobile edge computing ("MEC") device and at least one MEC controller. The MEC device can be used as a data plane to support data flow traffic. The MEC controller can provide a microservices architecture designed for elasticity, scalability, and extensibility. The platform can be used to decentralize a core network and / or associated macrocell network topology of a mobile network operator to generate a platform with enhanced flexibility, reliability, and performance. The platform may include a security architecture for effective privacy and access within a distributed topology of a network at and / or near the edge of a mobile network border.

Description

[0001] This application is a divisional application of the same patent application, filed on February 24, 2017, with application number 201780025063.4.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This patent application claims the benefit of co-pending U.S. Provisional Patent Application No. 62 / 299,673, filed February 25, 2016, which is incorporated herein by reference in its entirety. Technical Field

[0004] Embodiments of the present invention relate to a platform for providing computing resources at and / or near the boundaries of mobile networks. Background Art

[0005] In network systems, and especially in wireless network systems / architectures, the network boundary exists at the boundary between the privately managed side of the network and the provider-managed side. Prior to mobile and cloud technologies, the network boundary was the service area of ​​the privately managed network (e.g., the physical boundary of a campus or office building), where services from the privately managed network extended. However, with the advent of mobile and / or cloud technologies, the network boundary has become more amorphous, extending beyond the “physical” service area while still remaining confined to the privately managed platform. For example, because client devices operate from a remote location from the company office, they can operate on a privately managed network even though they are within a public managed network. Therefore, with mobile and cloud technologies, client devices and applications can operate on extended networks, where the network boundary can be the boundary between a trusted privately managed network and an untrusted public managed network.

[0006] Providing computing resources at and / or near the network boundary can lead to operations in untrusted and / or harsh environments, potentially compromising security. However, balancing security and operational efficiency can make it difficult to provide adequate protection and security strategies for client network devices and applications operating at and / or near the network boundary. Often, balancing security and operational needs in such environments hinders the scalability and extensibility of the platform providing such computing resources.

[0007] This disclosure aims to overcome one or more of the problems mentioned above. Summary of the Invention

[0008] This document discloses a platform of software and hardware components for providing computing resources at and / or near the boundaries of a mobile network. This platform can be used to provide computing resources adjacent to small-cell radios via at least one mobile edge computing (“MEC”) device and at least one MEC controller provided at or near the network boundary. Implementations of the MEC controller and MEC device within the network can generate a secure platform (e.g., a security sandbox) and a platform that facilitates scalability and extensibility within distributed networks (e.g., using multiple client devices within the network). Furthermore, the platform can facilitate the hosting of third-party applications used by client devices and / or mobile network operators (“MNOs”).

[0009] In some embodiments, the MEC device can be used as a data plane to support data flow traffic between client devices and the network. For example, the MEC device can be used to run third-party applications on client devices by implementing a multi-tenant environment via a sandbox scheme. In some embodiments, the MEC controller can be used as a control plane to provide out-of-band control over the configuration, policy management, and operation of all managed MEC device devices. The MEC controller itself can use or implement a microservices architecture designed for resilience, scalability, and extensibility. This platform can be used to decentralize the core network and / or associated macrocell network topology of the MNO to create a more flexible, reliable, and efficient platform than existing platforms.

[0010] The platform of this invention may include a security architecture for effective privacy and access within a distributed topology at and / or near the network boundary. This can be achieved by implementing security modules that are essential to the functionality of the MEC controller and extend for this purpose throughout each MEC device. The security modules can be configured to verify any action of any platform component within, at, and / or near the network boundary environment before being granted access to the network and / or being given the authority to issue commands (which would change the configuration or state of one or more components in the operating environment of the MEC device). In some embodiments, the framework of the security modules may be multiple components built across multiple layers, each component being constructed to address various attack vectors and potential exploits at each layer to minimize the risk of unauthorized access.

[0011] Instead of initiating an Internet Protocol Security (“IPSec”) tunnel from the small cell radio to the MNO security gateway, the MEC device can install itself in this data path to act as an IPSec server to the small cell radio and an IPSec client device to the MNO security gateway server. The MEC controller may include a core service platform designed as a microservices architecture to provide centralized control and aggregation of all capabilities offered by the platform, which can isolate the scope of specific functions to a set of dedicated instances that can be scaled independently. Furthermore, strict integration with the MEC controller can be achieved through a common gateway module within the core service platform, allowing third-party integration and control in conjunction with or as a replacement for the gateway module.

[0012] Some embodiments may include a discovery service module as a component of a platform responsible for providing MEC devices in the field, which may include autonomous provisioning at / near the network boundary environment.

[0013] By utilizing a decentralized approach and security modules, this platform can deploy or "push" mobile applications to the edge and / or vicinity of the network boundary environment, making it technically possible for the mobile application to be located closest to the end user. Furthermore, MNOs and / or client device users with devices located within, or near, the network boundary environment can easily and efficiently scale up or down as needed, with minimal or no interference to other modules within the platform.

[0014] While these potential advantages can be achieved through the technical solutions provided herein, their realization is not required. The invention disclosed herein can be implemented to realize these technical advantages, whether individually or in combination, to seek or achieve these potential advantages.

[0015] Other features, aspects, objects, advantages, and possible applications of the invention will become apparent from a study of the exemplary embodiments and examples described below in conjunction with the accompanying drawings. Attached Figure Description

[0016] The above and other objects, aspects, features, advantages, and possible applications of the invention will become apparent from the following more specific description presented in conjunction with the accompanying drawings, in which:

[0017] Figure 1 An exemplary mobile edge computing (“MEC”) server configuration that can be used with the platform of this invention is shown.

[0018] Figure 2 An exemplary MEC controller that can be used with field-deployed MEC devices is shown.

[0019] Figure 3An exemplary core service platform microservice architecture that can be used in an MEC controller is shown.

[0020] Figure 4 An exemplary architecture design for a messaging architecture that can be used with the platform of this invention is shown.

[0021] Figure 5 An exemplary authentication implementation scheme is shown via a public gateway module that can be executed by the platform of this invention.

[0022] Figure 6 Exemplary processing steps for registering new MEC devices, which can be performed by the discovery service module, are shown.

[0023] Figure 7 An exemplary high-level architecture of the platform of the present invention is shown, which includes both MEC devices and MEC controllers associated with radio networks, network operators and the Internet.

[0024] Figure 8 An exemplary 3GPP control and data plane architecture for third-party NFV EPC components, other than the MEC controller agent architecture, is shown in the platform of this invention.

[0025] Figure 9 An exemplary PKI implementation that can be used by a security module is shown.

[0026] Figure 10 An exemplary RBAC implementation that can be used by a security module is shown. Detailed Implementation

[0027] The following description is of embodiments currently contemplated for carrying out the invention. This description is not intended to be limiting, but is made only for the purpose of describing the general principles and features of the invention. The scope of the invention should be determined with reference to the claims.

[0028] A platform for providing computing resources at and / or near the boundaries of a mobile network is disclosed. This platform can be used within a wireless network capable of connecting to a privately managed network (e.g., the Internet or a private Internet). The wireless network may include at least one server (e.g., a server computer) that enables communication between client devices (e.g., personal computers, touchpads, mobile smartphones, etc.) on the privately managed network and the server and / or another client device. The server may include a radio modem capable of facilitating communication with the wireless network. The server may also include a network interface capable of facilitating communication with the privately managed network and / or other networks. Thus, the server can act as a gateway between networks. The gateway function of the server can perform any necessary translations in the data transmitted between the networks. In some embodiments, the privately managed network may operate based on the Transmission Control Protocol / Internet Protocol (“TCP / IP”) protocol, and the wireless network may communicate with the privately managed network via a router implemented within the server.

[0029] The platform of this invention can be used to provide computing resources (e.g., hardware and software components, modules, applications, devices, etc.) adjacent to small cell radios. Small cell radios can be used as access nodes for wireless connectivity in wireless networks. Furthermore, the combination of small cell radios and MEC devices can be used to generate smart cell radios. Smart cell radios can be used as access nodes for wireless connectivity across multiple spectrum ranges and technologies in wireless networks. Smart cell connectivity is not based on static spectrum (i.e., it does not depend on the configuration of the antennas used). Instead, smart cell connectivity can transmit multiple frequencies and technologies due to their ability to control the spectrum via software. Wireless connectivity can be achieved through other means, including static spectrum-based connectivity (such as, for example, macrocells, Wi-Fi, etc.).

[0030] The platform of this invention may include at least one mobile edge computing (“MEC”) device and at least one MEC controller placed at or near a network boundary. In some embodiments, the MEC device may be placed in the line between a small cell and a mobile network operator (“MNO”), and the MEC controller may reside within the core network of the MNO. The core network of the mobile operator may be the central part of the mobile network, which may include macro cells (e.g., cell base stations, cell towers, etc.) to provide services to client devices connected to the mobile network via an access network. Orchestration implementations of the MEC controller and MEC device can generate a secure platform for computing at and / or near the network boundary in a distributed network (e.g., using multiple client devices within one or more networks). The platform of this invention also facilitates scalability and extensibility, enabling client device users and / or the MNO to extend, add, remove, and / or modify the network. The platform of this invention also facilitates the hosting of third-party applications used by client devices and / or the MNO. The third party may be an entity authorized by the MNO to delegate control over a scope of the administratively defined network environment.

[0031] MEC devices are hardware components that can be configured to provide data services and security mechanisms for running programs from third parties, which may include untrusted programs from unverified third parties. In some embodiments, MEC devices can be used as a data plane to support data flow traffic between client devices and the network. For example, an MEC device can be part of a router architecture that determines the path of data. MEC devices can use computing standards to provide additional features, components, and / or capabilities that allow for large-scale deployment and management of MEC devices in any type of environment within the network. For example, an MEC device can be used to run third-party applications on client devices by implementing a multi-tenant environment (i.e., multiple client devices within the network) via a sandboxing scheme embodied in the programming configuration of the MEC device, while controlling resources such as memory, file descriptors, and / or system space. In one implementation, an MEC device can be used to directly integrate with a 3GPP (“3GPP”) Evolution of Packet Core (“EPC”) interface (e.g., 3G, LTE, 4G, etc.) to provide data processing services for all data traffic originating from and / or near client devices at the network boundary environment. In at least one embodiment, all data services allow selective routing of data traffic to local applications and / or services. For the purpose of inspecting and analyzing traffic, data services may also allow selective copying and delivery of all traffic to local or remote applications and / or services.

[0032] A MEC controller is a collection of hardware and software components that can be configured to command and control all MEC devices used by a given MNO. The MEC controller can provide the ability to extend to MEC devices, MNOs, and / or third parties, and can be used to operate MEC devices at scale. In some embodiments, the MEC controller can serve as a control plane to provide policy and configuration parameters via control logic through which MEC devices forward data. For example, the MEC controller can be configured to enable selective access to network access point names (“APNs”), where APNs can be used for services such as, but not limited to, unifying voice and data based on an Internet Protocol (“IP”) architecture, allowing voice to be treated as an IP application. In some embodiments, the MEC controller can internally implement a microservices architecture to provide secure, modular, and scalable services to both MEC devices and MNOs.

[0033] Microservice architectures can be designed for resilience, scalability, and extensibility. For example, each component in the MEC controller can be scaled horizontally (e.g., adding more nodes to the network instead of adding resources to a single node) and scaled independently. Each component in the MEC controller can also be configured for fault and security isolation, as well as encryption protection, including the use of authenticated and encrypted communication. Furthermore, the MEC controller can be primarily stateless, asynchronous, and operate via out-of-band communication activities. Therefore, the MEC controller can be operated without impacting the performance or availability of the MEC devices.

[0034] As noted above, the orchestration implementation of MEC controllers and MEC devices can generate a secure platform for computing within, at, and / or near the network boundary environment in a distributed network. One way the platform of this invention achieves this is by using it to decentralize the core network and / or associated macrocell network topology of the MNO. Decentralizing the topology through the use of MEC devices and MEC controllers can generate a more flexible, reliable, and efficient platform than existing platforms. Furthermore, the scalable platform can be used with all forms of client devices operating within, at, and / or near the network boundary environment, enabling the MNO to deploy a highly scalable, distributed pool of computing resources residing at and / or near the network boundary. For example, the platform of this invention can be able to deploy resources from a general x86 platform ecosystem delivering third-party applications to run on the network, facilitating instruction sets that can operate with inputs designed for any legacy system, product, or technology. These software resources do not need to be modified to fit the mobile network architecture and can instead be deployed as if operating in a traditional enterprise local area network (“LAN”).

[0035] This decentralization provides significant enhancements in cloud computing by enabling direct access between client devices and running applications, an operation referred to herein as cloud edge computing. In other words, unlike existing infrastructure such as IaaS (“Infrastructure as a Service”) or cloud computing services such as PaaS (“PaaS”) that operate outside of mobile networks, the platform of this invention allows applications to be deployed at the edge of the mobile network boundary, making it technically possible for the application to reside at the location closest to the end user (e.g., at / near the network boundary client device). To provide application developers with a platform that facilitates the most distributed and lowest-latency networks for client devices using over-the-air transmission, the MEC device can also be configured as a compact and powerful device programmed for a small user-to-host ratio.

[0036] As noted above, the platform of this invention can be used to construct a secure distributed network environment for x86 computing resources residing at and / or near the network boundary edge. This can be achieved through an orchestration of services supported by various components within the platform. For example, MEC device services may include, but are not limited to: 1) configuration and policy enforcement; 2) reporting and monitoring; and 3) software distribution and version control. MEC controller and / or MNO services may include, but are not limited to: 1) a role-based access control (“RBAC”) enabled Representational State Transfer (“REST”) application programming interface (“API”) to generate methods for regulating access to the network via a software architecture of an open-source information space (e.g., the World Wide Web) for the control of MEC devices and related services, including support for delegated access to third-party entities; 2) EPC integration for selective provisioning; and 3) metadata processing for offloading and centralized operations from MEC devices. Third-party services may include, but are not limited to: 1) extending direct connections to locally running services on adjacent server hardware to client devices; 2) integration into existing user authentication services; 3) integration into existing communication services; and 4) REST APIs for controlling delegated and / or permitted actions.

[0037] The platform of this invention may include a security architecture for effective privacy and access within a distributed topology at and / or near the network boundary environment. This can be implemented through a security module that is essential to the functionality of the MEC controller and extends for this purpose throughout each MEC device. For example, the security module may be used for whitelisted access and control within the platform of this invention. In some embodiments, all components of the MEC controller and MEC devices may be built on top of the framework of the security module. In one embodiment, the framework of the security module may be a zero-trust model, whereby communication from any component at and / or near the network boundary environment may be enforced to prove its identity before being granted access to the network. Furthermore, the security module may be configured to verify any action of any platform component at and / or near the network boundary environment before being granted access to the network. The security module may also be configured to allow any inter-service communication only when used with an encrypted session using a Transport Layered Security (“TLS”) protocol that ensures privacy between communicating applications. In some embodiments, encrypted TLS sessions may be allowed through local and / or remote interfaces. In one embodiment, the TLS protocol may require explicit authentication before being granted access to the network. This can be achieved by using an X.509 certificate for each communication transmission instance.

[0038] Certificates can be widely used across the entire security architecture for TLS client device authentication and server authentication, as well as service / principle identity. For example, the platform of this invention can be configured to anchor all certificates to an extended chain of trust from an external public key infrastructure (“PKI”) environment, or a new root anchor can be established. Furthermore, action verification can proceed according to the following steps: 1) a request is made by a valid user; 2) for an authenticated user, the requested action is permitted; and 3) within the defined action scope, the requested action is permitted. Once successfully verified, the requested action can be cryptographically signed and transmitted to a destination service capable of executing the action.

[0039] In some embodiments, the security framework may be multiple components forming a multi-layered structure, each component configured to address various attack vectors and potential exploits at each layer to minimize the risk of unauthorized access. The first security layer may be built within the MEC device and based on key encryption using a hardware encryption unit (such as a Trusted Platform Module (“TPM”)) physically attached to a local host for storing a master key used to encrypt all keys stored on the device. For example, the first security layer may use public and private keys for authentication and encryption, where the private key is not shared between client devices and / or services. This can be achieved by ensuring that the private key is protected through the use of the TPM (if present) used to decrypt the private key. It is desirable that the private key is never shared between services or principles. Furthermore, the security framework may be configured such that it is the responsibility of the owner of the private key that protects its security, whether it is a service, an MEC device instance, or a person operating using a public API. The use of the TPM module (if present) can add additional hardware protection to the private key associated with the service or device running on the platform of this invention.

[0040] The use of TPM can facilitate the generation of a second security layer, which can be a trusted boot platform that verifies the integrity of the operating environment within the network. Within the operating environment, there can be a third security layer, which can be a runtime security module with security mechanisms to control the ability of applications and their users to interact with network elements. The runtime security module can use both process isolation and memory encryption. The use of process isolation can minimize the attack vector available to an attacker by restricting access to system resources to those resources required for the operation of that process. The use of memory encryption can provide additional protection against unauthorized access to sensitive data stored in memory for services running on components in the platform of this invention. A fourth security layer can be a security framework implemented by the actual application code running in the MEC device and / or MEC controller. Other embodiments may include more or fewer security layers.

[0041] As an exemplary embodiment, the security framework can be configured as a security module that provides authentication, authorization, and accounting (“AAA”) services via an internal communication bus to any principle requesting access to the MEC controller API or communication between components in the environment. The security module can implement an internal relational database for persistent storage of principle identities, roles, and permissions to provide the security module with a complete role-based access control (“RBAC”) policy framework for controlling access to the operating environment of the MEC device. A principle in the security module can refer to a service instance as part of the platform, an external service accessing a public API, or a human operator. For example, the security module can delegate the authentication and authorization of principles to an external identity provider service via the use of a Security Assertion Markup Language (“SAML”) data format. The security module can also provide comprehensive auditing of all principle activities, as actions performed by principles can be expected to be received and cryptographically signed by the security module. The security module can also provide a public key infrastructure (“PKI”) for issuing and revoking digital certificates used for principle authentication and authorization. Trust anchors in the PKI can be established by the MEC controller root certificate authority or by an existing certificate authority of the network operator. Security modules can be built on AAA and PKI services to cryptographically identify principles and verify the scope of any requested action (in particular the service or device that will be affected by the action(s)) and allow changes to be made by the principle.

[0042] The security framework can provide layers through the following: (1) authenticated connection establishment, wherein a principle is not allowed to communicate with any principle or service that does not use an encrypted session, and is encrypted and authenticated for this purpose using the principle's digital certificate; (2) isolation of communication, wherein all communication between modules that change or alter the state of the environment can be required to do so only through communication via the security module, since direct communication is not permitted; (3) constraint of permissions, wherein modules outside the security module can be configured to only receive instructions and provide responses generated by executing those instructions, wherein all instructions can be sent to the security module as requests, and only instructions with cryptographic signatures from the security module can be accepted by any other service in the environment to modify their respective configurations; (4) no trust assumption for non-security module components, wherein the security module can be configured such that components (including new instances of the security module instance) are not trusted to communicate in the environment unless explicitly authorized and issued with cryptographic signatures by an existing security module; and (5) isolation of scope and function, wherein the security module can be configured such that modules do not share functions and therefore have independent attack vectors, meaning that exploitation of one module will not directly affect the functionality or security of another module.

[0043] Figure 1 An exemplary MEC server configuration that can be used with the platform of this invention is shown. The MEC device may be an embedded x86 hardware device running a hardened Linux operating environment, an MEC controller agent (i.e., a device service agent), a selected data plane Network Functions Virtualization (“NFV”) EPC module, and core third-party applications. The Linux operating environment and the NFV EPC data plane module can receive and transmit data in and out of the MEC device via a secure Internet Protocol (“IPsec”) suite for authenticating and encrypting each IP packet of a communication session. The MEC device may include the MEC controller agent, voice fixed-mobile coverage (“FMC”) functionality provided by the NFV EPC data plane module, a local voice service running within the MEC device, and the NFV EPC data plane module. Exemplary third-party applications are shown as a content delivery node (“CDN”), an enterprise application public network interface, and a video analytics probe. MEC devices can provide core data processing functions, including but not limited to: 1) caching - selectively caching and / or storing content on the local device via third-party caching applications; 2) Local Breakout, also known as local IP access - selectively routing traffic to servers for local services or local connections; 3) Edge Switch Port Analyzer (“SPAN”) - mirroring all traffic for data analysis.

[0044] Instead of initiating an IPSec tunnel from the small cell radio to the MNO security gateway, the MEC device can install itself in this data path, acting as both an IPSec server to the small cell radio and an IPSec client device to the MNO security gateway server. Therefore, the functionality and control of the small cell radio do not need to be changed in this topology. Instead, the MEC device can add new data processing capabilities before being transmitted to the network operator's core network. This feature alone makes the MEC device well-suited for operation in harsh, untrusted environments, such as outdoor stadiums or public office areas.

[0045] The MEC controller can provide a centralized provisioning and management platform for mobile edge computing devices, functions, and services through multiple platform modules. These may include, but are not limited to, core service platforms, operator service gateways, enterprise service gateways, device service agents, and discovery services. In general, the platform module can provide the following core services: 1) centralized orchestration of hardware and software components for all computing devices at and / or near the network boundary environment; 2) aggregation and standardization of third-party APIs for service operation at and / or near the network boundary environment; 3) lifecycle and configuration management of device firmware and software (including operating environment), core device software features, and third-party software; 4) centralized reporting and capacity planning; and 5) integration into existing EPC modules and third-party infrastructure for BRAC, MEC device, and user provisioning.

[0046] Figure 2 An exemplary topology and the relationships between the various components are illustrated. The core service platform can serve as the core of the MEC controller, and it can perform all processing on the control plane and operational services. For example, the core service platform can be designed as a microservices architecture, providing centralized control and aggregation of all capabilities offered by the platform. This design can isolate the scope of specific functions to a dedicated set of instances for independent scaling, fault and attack vector isolation. The enterprise service gateway and the operator service gateway are public interfaces used to provide network user interfaces for client device users and operator users, respectively, and will be discussed in more detail later.

[0047] like Figure 3-Figure 4 As shown, the core service platform may include multiple components and / or modules. These may include, but are not limited to: 1) a security module; 2) a device module; 3) a telemetry module; 4) an EPC module; and 5) a public gateway module. The core service platform can be accessed through... Figure 3 The API shown is a standardized API for communication between services to each microservice.

[0048] The security module can cryptographically authenticate and sign all actions via support for issued X.509 certificates. In some implementations, actions can be authorized for a desired scope for a given principle (e.g., a user or service). The security module can use Federal Information Processing Standard (“FIPS”) 186-4 and / or National Security Agency (“NSA”) Suite B standards. The security module can also be configured to explicitly authorize and track each action using built-in RBAC and auditing capabilities. All services and principles can provide their identity via X.509 certificates issued for digital identities.

[0049] refer to Figure 9The security module PKI topology can have a trust anchor, which implements a root certificate authority (“CA”) or an intermediate CA that signs existing PKIs managed by an MNO. Each security module can act as an intermediate CA for the trust anchor, and any instance of a security module can issue a digital identity to the root and be used to verify the certificate chain of all services via the Online Certificate State Protocol (“OCSP”).

[0050] The device module can be configured for one-to-many management of MEC devices. For example, the device module can facilitate communication with deployed MEC devices. The device module can facilitate application and device lifecycle management. The device module can also be configured to maintain persistent communication with devices and can be horizontally scaled to allow the addition of up to 100,000+ devices. Therefore, this module can simplify orchestration and integration with the Northbound Business Support System (“BSS”) and Operations Support System (“OSS”) platforms. The device module can manage the tracking of the state of asynchronous commands sent to MEC devices, providing other modules with an abstraction to observe the final state of the request. The device module can also manage the distribution of authenticated and authorized messages received from the core service platform to one or more MEC devices, as indicated in the authenticated message.

[0051] The telemetry module can be used for statistics and logging. For example, all events and metrics from MEC devices and MEC controllers can be captured by the telemetry module. The telemetry module can also support trigger-based actions, provide near real-time analytics of the entire environment, and offload telemetry analytics from MEC devices. In some implementations, all event data processing is performed via the telemetry module. This reduces the device's computational resource requirements compared to performing event data processing elsewhere. The telemetry module can also provide an interface for event processing from third-party applications used in support of the core service platform. For example, control plane elements of the Service Gateway (“SGW”) can send proprietary notifications to listening services that are part of the telemetry module. The telemetry module can provide callback capabilities, particularly the ability to notify different services if a threshold has been exceeded or a specific event has occurred. This allows for asynchronous push notifications to appropriate services based on condition types for those services that want to receive notifications, which can then be used for further processing and handling.

[0052] The EPC module can communicate with the MNO's EPC components, thus enabling integration and communication with the MNO EPC for network provisioning and policy enforcement. The EPC module may contain NFV EPC control plane SGW and Packet Data Network Gateway (“PGW”) elements. The EPC module can also be configured to enforce policy and user changes and support Gx, S5, and S11 interfaces. When the MEC device is deployed or decommissioned, the EPC module can also provide the ability to add or remove data plane instances running within the MEC device.

[0053] The public gateway module can provide a public REST API to the MEC controller and / or MEC devices, and thus enable external services and users to access the platform via REST API endpoints. The platform can be configured such that the public gateway module is the only public interface for third-party consumers accessing the core service platform. In other words, the only way to interface with the platform will be through the REST API of the public gateway module. The public gateway module can be configured to allow all access to the network authorized by the operator (e.g., via the MEC identity store). The public gateway module can also be configured to support the network user interface gateway using an AAA authentication framework provided by the security module for authorized connection attempts, and can be built independently, or further extended or consumed from existing client portal REST APIs.

[0054] Integration with the MEC controller can be strictly achieved through the REST API provided by the public gateway module within the core service platform, allowing third-party integration and control in conjunction with or as a replacement for enterprise service and / or operator service gateways. Therefore, user interactions with the core service platform can be performed through any of the enterprise service and / or operator service gateways or through third-party products that conform to the core service platform's public gateway API.

[0055] Furthermore, the platform can be configured such that control of any MEC device is limited to a secure and persistent connection between the device and the core service platform. As mentioned above, control of any MEC device can be central to the functionality of the core service platform. Therefore, the core of the security framework can be implemented and provided by a security module within the core service platform. This software suite can be responsible for authorizing access to any component intending to communicate with the network. The security module can also cryptographically sign all commands from other services to verify the integrity and validity of any command.

[0056] refer to Figure 4A security framework can also be implemented throughout the core service platform, ensuring that no module is trusted to communicate with another module without explicit authentication, such as using X.509 certificates. Internally, all communication between modules of the core service platform (inter-service API) can be handled by a proprietary JavaScript Object Notation (“JSON”) message format and transmitted via the Advanced Message Queuing Protocol (“AMQP”), which abstracts the implementation of any module from another module. Exchanged messages can be in a uniform format, called command messages, representing the scope, action, and parameters of the action requested to be performed on the receiving microservice. The standardized command message format allows different microservices to communicate without relying on the design or architecture of remote microservices. An AMQP-compliant message bus can provide secure, isolated, and / or controlled message delivery between services and can be used to implement synchronous communication (such as Remote Procedure Calls (“RPC”)) or asynchronous communication. Furthermore, the message bus can allow isolated fault domains, ensuring that no single microservice is responsible for managing state or communicating with remote microservices. The core service platform can use JSON key-value storage to track and record the state of asynchronous commands invoked on remote microservices.

[0057] Therefore, messaging protocols can allow for complete architectural isolation of a given module, enabling independence without affecting other modules for the following purposes: 1) changing the underlying implementation of the module; 2) extending or adding features; 3) increasing or decreasing the number of module instances in production; 4) fault isolation; and 5) attack vector isolation. Such a design also allows the core service platform to scale dynamically in any cloud-hosted environment. For example, if additional or more verbose telemetry data needs to be collected, additional telemetry modules can be deployed to handle the extra processing demands without affecting other modules. This scaling scheme can be applied to any module within the core service platform to allow resources to be allocated only to the precise functions that require them.

[0058] As noted above, the core service platform components of the MEC controller can provide a REST API. Enterprise and operator service gateways can provide the MEC controller with a web user interface that implements REST clients. These enterprise and operator service gateways can be used solely for providing a human interface to the environment. Figure 5As shown, the Enterprise and Operator Service Gateway can implement certificate authentication required by the MEC controller and implement and proxy traditional user authentication methods. Therefore, the platform of this invention can be configured such that the Enterprise and Operator Service Gateway is an optional component of the platform. For example, external services implementing the user interface for control in an MNO environment can consume the REST API without the need for the Enterprise and Operator Gateway. External services can directly consume the REST API by developing a REST client conforming to the MEC controller's public REST API gateway specification and by using an issued X.509 digital identity certificate to open an authenticated connection to the REST API.

[0059] Device service agents serve as an interface between all components and services operating within an MEC device, managed by the MEC controller. While the MEC controller itself is not required to process data on the mobile network, the platform can be configured so that any command and control functions can only originate from the MEC controller. For example, when a new MEC device (placed at the edge of the mobile network boundary) is initialized and joins the network, the device service agent can be responsible for communicating with the core service platform to update EPC control plane components, thus establishing control over the EPC data plane modules residing within the device. Therefore, the device service agent can provide a means to securely manage the ecosystem of MEC devices within, at, and / or near the network boundary environment. Furthermore, the device service agent can provide API translation and localized messaging and notifications between third-party applications running within the MEC device. For example, the device service agent can relay data required for processing location information, or it can forward location information from one service to another, both operating locally and proxied by the device service agent.

[0060] The discovery service can be a component of the platform of this invention, responsible for supplying MEC devices in the field (i.e., within, at, and / or near the network boundary environment), and may include autonomous supply. The discovery service can reside outside the MNO. The discovery service can allow new factory-delivered MEC devices to register with the MNO, establish encryption keys for all communication and authentication, and obtain an MNO-specific, signed X.509 digital identity certificate. For example, client devices can connect to a network operator by simply powering the client device to automatically register and obtain certificates (i.e., autonomous supply). Individual functions and / or operations may approve client devices joining the network, but the authentication and verification process can be automated via the discovery service. Figure 6The diagram illustrates processing steps that may be involved, which could include communication between the MEC device, the cloud-hosted discovery service, and the MEC controller running within the MNO, to ensure that private keys are not shared or transmitted at any point during autonomous provisioning. This process may include the use of TLS client authentication.

[0061] As noted above, the platform of this invention can provide cloud edge computing at and / or near the network boundary. MNOs and / or client device users with on-site devices can easily and efficiently scale up and / or scale down as needed with minimal or no interference to the modules within the platform. This can be accomplished in part by decentralizing the core network of the MNO, resulting in multiple small systems managed by a zero-trust security module. The platform can deploy mobile applications at the network boundary edge, making it technically possible for mobile applications to be located closest to the end user. Decentralizing the core network of the MNO also facilitates enhanced scaling management to meet data flow requirements without interfering with modules and without adjusting the security framework each time a device is added. Furthermore, the MEC device can verify the validity of all communications and commands sent from the MEC controller. Therefore, if a client device sends a command to the device (e.g., restart the client device), the MEC device can verify this action in addition to the system itself.

[0062] As noted above, the telemetry module can capture all events and metrics from both the MEC device and the MEC controller, so every event occurring at the MEC device can be sent to the telemetry module. If a client device user issues a request that cannot be executed by the MEC device, the event can be logged by the telemetry module. This information can be used to update the device so that subsequent requests for the same content can be executed.

[0063] refer to Figure 7 This paper discloses an exemplary high-level architecture of the platform of the present invention. This embodiment illustrates a platform having both MEC devices and MEC controllers associated with radio networks, network operators, and the Internet. In this figure, the MEC devices are shown residing at the mobile edge and communicating with at least one small cell radio and an MNO EPC vector via an encrypted tunnel formed by a security module.

[0064] Figure 8 This paper illustrates an exemplary 3GPP control and data plane architecture for third-party NFV EPC components, other than the MEC controller agent architecture, which can be used in... Figure 7 In the architecture.

[0065] Figure 9Exemplary PKI implementations or PKI topologies that can be used by security modules are shown, illustrating various instances of security modules that can occur through trust anchors.

[0066] Figure 10 An exemplary RBAC implementation that can be used by a security module is shown.

[0067] It will be apparent to those skilled in the art that many modifications and variations of the described examples and embodiments are possible in light of the foregoing teachings of this disclosure. The disclosed examples and embodiments are shown for illustrative purposes only. Other alternative embodiments may include some or all of the features disclosed herein. Thus, it is intended to cover all such modifications and alternative embodiments that may fall within the true scope of this invention, the true scope of which is given its full width. Furthermore, the disclosure of a range of values ​​is a disclosure of each value within that range, including endpoints.

Claims

1. A device for an edge computing environment, comprising: a network interface configured to communicate over a network, wherein the device is located at or near an edge of the network; The device is further configured to run one or more programs associated with one or more third parties, and is configured to: Obtaining commands and configuration information from a mobile edge computing MEC controller via the network interface; establishing security layers in the device, wherein a first security layer of the security layers includes an encryption key stored on the device; The security layer is used to prevent various attacks and potential exploits at each layer. The device is configured in a mobile edge computing MEC system as a mobile edge computing MEC device located at or near the edge of a management network.

2. The device according to claim 1, wherein: The apparatus is configured to operate in a data plane to support data flow traffic in the mobile edge computing MEC system.

3. The device according to claim 1, wherein: The mobile edge computing MEC controller is configured to operate in the mobile edge computing MEC system, and wherein the device is configured to receive the command and configuration information as policies and configuration parameters in a control plane of the mobile edge computing MEC system.

4. The device according to claim 1, wherein: The server including the mobile edge computing MEC controller is configured to operate as a gateway between the management network and a network managed by a mobile network operator MNO, wherein the gateway is configured to make conversions in data transmitted between the networks.

5. The device according to claim 1, wherein: The device is also located at a network boundary of a management network to enable execution of applications from the one or more third parties operating within the management network.

6. The device according to claim 5, wherein: The network boundary is enforced using a gateway that implements trusted functions based on network defined policies.

7. The device according to claim 1, wherein: The apparatus is also located in-line between the small cell radio and network equipment of a mobile network operator, MNO, to enable execution of applications from the one or more third parties operating within the mobile network operator's network.

8. The device according to claim 7, wherein: The device is also located in a data path defined by a secure IPSec tunnel or a secure messaging path between the small cell radio and a security gateway of the mobile network operator (MNO).

9. The device according to claim 1, wherein: The device is capable of operating as one of multiple edge computing devices in the edge computing environment, wherein the network includes a core service platform, the core service platform is included in the mobile edge computing MEC controller, and the core service platform is configured to manage the microservice architecture between the device and the edge computing environment.

10. The device according to claim 9, wherein: The core services platform provides centralized control and aggregation of capabilities provided by the edge computing environment, and wherein the core services platform is capable of isolating scopes of specific functionality to a set of dedicated instances for independent scaling.

11. The device according to claim 1, wherein: The means is provided from an x86 hardware device and wherein the one or more programs are operated on behalf of a client device or a mobile network operator.

12. A method for operating an apparatus of an edge computing environment, the method comprising: operating a network interface configured to communicate with a mobile edge computing, MEC, controller over a network, wherein the apparatus is located at or near an edge of the network, and wherein the apparatus is further configured to communicate with a client device; and Coordinating execution of one or more programs associated with the client device using operations including: Implementing commands and configuration information received from the mobile edge computing MEC controller; establishing security layers extending in the device, wherein a first security layer of the security layers includes an encryption key stored on the device; Wherein, the security layers are used to prevent various attacks and potential exploits at each layer, and The device is configured in a mobile edge computing MEC system as a mobile edge computing MEC device located at or near the edge of a management network.

13. The method according to claim 12, wherein: The apparatus is configured to operate in a data plane to support data flow traffic in the mobile edge computing MEC system.

14. The method according to claim 12, wherein: The mobile edge computing MEC controller is configured to operate in the mobile edge computing MEC system, and wherein the device is configured to receive the command and configuration information as policies and configuration parameters in a control plane of the mobile edge computing MEC system.

15. The method according to claim 12, wherein: The server including the mobile edge computing MEC controller is configured to operate as a gateway between the management network and a network managed by a mobile network operator MNO, wherein the gateway is configured to make conversions in data transmitted between the networks.

16. The method according to claim 12, wherein: The device is also located at a network boundary of a management network to enable execution of applications from one or more third parties operating within the management network.

17. The method according to claim 16, wherein: The network boundary is enforced using a gateway that implements trusted functions based on network defined policies.

18. The method according to claim 12, wherein: The apparatus also sits in-line between the small cell radio and network equipment of a mobile network operator, MNO, to enable execution of applications from one or more third parties operating within the mobile network operator's network.

19. The method according to claim 18, wherein: The device is also located in a data path defined by a secure IPSec tunnel or a secure messaging path between the small cell radio and a security gateway of the mobile network operator (MNO).

20. The method according to claim 12, wherein: The device is capable of operating as one edge computing device among multiple edge computing devices in the edge computing environment, wherein the network includes a core service platform, the core service platform is included in the mobile edge computing MEC controller, and the core service platform is configured to manage a microservice architecture between the device and the edge computing environment.

21. The method according to claim 20, wherein: The core services platform provides centralized control and aggregation of capabilities provided by the edge computing environment, and wherein the core services platform is capable of isolating scopes of specific functionality to a set of dedicated instances for independent scaling.

22. The method according to claim 12, wherein: The apparatus is provided from an x86 hardware device, and wherein the one or more programs are operated on behalf of the client device or on behalf of a mobile network operator providing services to the client device.

23. A machine-readable storage medium comprising instructions stored thereon, wherein: When the instructions are executed by a hardware component of a device in an edge computing environment, the hardware component is caused to perform the operation according to any one of claims 12 to 22.

Images