Secure virtual private mobile and ip networks in the cloud

Abstract

The present disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communication platform deployed on a public cloud infrastructure. This mobile network allows end-to-end control of the automatic and programmatic deployment and configuration of mobile network components. The following embodiments can effectively create and deploy a true global private end-to-end software-defined network (SDN) for 3G, 4G, LTE, and 5G mobile communications on the fly from scratch. Users will effectively act as their own mobile operator, with the ability to customize available functionality through a programmatic interface.

Description

TECHNICAL FIELD

[0001] This PCT international application claims benefit from U.S. Provisional Patent Application 62 / 886,471 filed August 14, 2019. TECHNICAL FIELD

[0003] The present disclosure relates to a fully software-defined, fully virtualized, customizable mobile communication platform deployed on a public cloud infrastructure. BACKGROUND

[0004] A mobile network can include a radio access network and a mobile core network interconnected with backhaul circuits. The mobile network can further communicate with other data networks through the public Internet. Conventional mobile core networks rely heavily on fixed, custom hardware components to perform the functions required to enable end-to-end communications. These hardware-driven mobile core networks are rigid, inflexible, and inelastic in the deployment and subsequent provisioning and maintenance processes. As various previously distinct types of network traffic (such as voice, messaging, and data) increasingly converge, conventional mobile core networks can be simplified to the point that the entire mobile core network can be virtualized and implemented in software, without reliance on dedicated hardware components. SUMMARY

[0005] The present disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communication platform deployed on a public cloud infrastructure as a hybrid of configurable instances of cloud containers and cloud daemons. This mobile network allows for private and secure end-to-end network traffic routing within the mobile network and between the mobile network and other private and public networks. This mobile network can be deployed in the cloud on the fly in a highly elastic manner and can further be configured and reconfigured automatically and programmatically on the fly. The embodiments disclosed herein effectively provide a platform that enables the on-the-fly and dynamic creation and deployment of a true private global end-to-end software-defined network (SDN) for 3G, 4G, LTE, and 5G mobile communications from scratch. Users of this platform essentially play the role of their own mobile carrier, allowing them to customize the available functionality through a programmatic interface.

[0006] In one embodiment, a method for information routing over such a mobile network is disclosed. The method can include intercepting, at a wireless network controller, first data from a wireless end device; redirecting the first data to a private software-defined and fully virtualized mobile core and data routing network deployed in a public cloud platform; wherein the mobile core and the data routing network comprise a hybrid of a plurality of cloud instances of data processing containers and a plurality of cloud data routing daemons. The method can further include directing the first data through the plurality of cloud instances of data processing containers to a first private virtual packet gateway implemented as one of the plurality of cloud instances of data processing containers in the mobile core and the data routing network; routing the first data from the first private virtual packet gateway to the plurality of cloud data routing daemons; routing the first data from the plurality of cloud data routing daemons to a standalone cloud application terminating at a second packet gateway through a private virtual cross-connect implemented in the public cloud platform. The method can further include providing access to the standalone cloud application to the wireless end device.

[0007] In another embodiment, a private software-defined and fully virtualized mobile core and data routing network deployed in a public cloud platform is disclosed. The mobile core and data routing network can include a first set of cloud container instances configured to receive data from a wireless end device through a wireless network controller; a second set of cloud container instances configured to implement a set of mobile core network functions through processing the data received from the wireless network controller by the first set of cloud container instances. The virtualized mobile core and data routing network can further include a third set of cloud container instances; and a set of routing daemons deployed in the public cloud platform. The third set of cloud container instances function as a packet gateway for routing data processed by the second set of cloud container instances to the set of routing daemons deployed in the public cloud platform. The set of routing daemons are configured to route data received at the set of routing daemons to a private cloud network configured to route messages according to multi-protocol label switching.

[0008] In another embodiment, a private wireless sensor network is disclosed. The wireless sensor network can include a plurality of distributed sensors, each of the sensors integrated with a wireless subscriber identity module (SIM) having a plurality of remotely activatable international mobile subscriber identity (IMSI) profiles. The wireless sensor network can further include a private software-defined and fully virtualized mobile core deployed in a public cloud platform for receiving data collected by the plurality of distributed sensors over a wireless access network to generate output data. The mobile core includes a mix of a plurality of instances of data processing containers for processing the received data. The wireless sensor network can further include a plurality of private routing daemons deployed in the public cloud platform; and a private cloud network configured according to multi-protocol label switching routing messages. The output data of the mobile core is routed from the plurality of private routing daemons to the private cloud network and further from the private cloud network to a private cloud application. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 An example architecture of a traditional mobile communication platform based on dedicated hardware components is shown to implement the functionality of a mobile core network;

[0010] Figure 2 An example architecture of a mobile communication platform is shown, whose mobile core is fully defined in software and fully virtualized in a public cloud infrastructure;

[0011] Figure 3 A cloud-implemented security and virtual cross-connect between a mobile core network and other independent cloud instances that can be virtualized in a public cloud infrastructure is shown;

[0012] Figure 4 A communication path between a mobile device and a cloud instance through a traditional mobile core network implemented in hardware is shown, showing the connection legs exposed to the insecure public Internet;

[0013] Figure 5 An example of implementing a mobile core network and virtual cross-connect to other cloud instances in an environment involving multiple different cloud platforms is shown;

[0014] Figure 6 Example functional components of a mobile core network for signaling, data processing, and information routing are shown;

[0015] Figure 7 An example implementation of a mobile core network as a mix of containers and daemons deployed in a public cloud infrastructure is shown;

[0016] Figure 8Another example implementation of a mobile core network as a container and a box is shown;

[0017] Figure 9 An example routing layer implemented as a daemon or container in the cloud is shown to facilitate end-to-end communication through a virtualized mobile core;

[0018] Figure 10 An example scheme for providing automatic deployment and provisioning of private mobile core networks and virtual cross-connects to other independent cloud instances is shown;

[0019] Figure 11 An example implementation of a computer device is shown that can be implemented as an underlying hardware in the cloud or as a user terminal device. DETAILED DESCRIPTION

[0020] The present disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communication platform deployed on public cloud infrastructure as a hybrid of configurable instances of cloud containers and cloud daemons. Such a mobile network allows private and secure end-to-end network traffic routing within and between the mobile network and other private and public networks. Such a mobile network can be deployed on the fly in the cloud in a highly elastic manner and can be further configured and reconfigured automatically and programmatically on the fly. The implementations disclosed herein effectively provide a platform that enables the on-the-fly and dynamic creation and deployment of a true private global end-to-end software-defined network (SDN) for 3G, 4G, LTE, and 5G mobile communications from scratch. Users of such a platform essentially play their own mobile operator, allowing them to customize the available functionality through a programmatic interface.

[0021] Figure 1 An example system architecture of a mobile communication network 100 is shown. The mobile communication network 100 can include user equipment (UE) 103 that communicates with a mobile core network (CN) 107 through a radio access network (RAN) 105. The user equipment 103 can be a mobile or fixed terminal device including, but not limited to, a mobile phone, a tablet, a personal digital assistant (PDA), a wearable device, a distributed sensor, an Internet of Things (loT) terminal, a desktop computer, and a laptop, all of which are configured to access the RAN 105 through a wireless connection. The terminal devices of these examples are illustrated in Figure 1

[0022] ​For example, the radio access network 105 can include base stations 120, 122, 124 and radio network controllers (RNCs) 126 and 128. The base stations 120, 122, and 125 can collect wireless uplink signals from user equipment and broadcast wireless downlink signals to user equipment over air radio channels. The RNCs 126 and 128 can further collect signals from or distribute signals to the base stations 120, 122, and 124 over wired backhaul connections as shown by the dashed arrows 121, 123, and 125. The RNCs further control the base stations connected thereto to provide provisioning of radio channels and signal characteristics.

[0023] As Figure 1 Further shown, the RNCs 126 and 128 can communicate with the mobile core network 101 over wired backhaul 127 and 129. The mobile core network 101 can be designed to perform various control, signal processing, information routing, and signal gateway functions according to pre-defined voice, message, and / or packet transmission and signaling protocol stacks, either individually or in a converged manner (e.g., all as packets). The mobile core network 101 can further transmit or receive data to or from other networks 109. For example, as Figure 1 shown, the mobile core network 101 can communicate with IP networks such as the Internet 160, fixed voice networks such as the Public Switched Telephone Network (PSTN) 162, and the like. Thus, signals can be routed between user equipment 140-152 and the Internet 160 and / or the PSTN 162 through the mobile core network. Signals can further be routed between one user equipment and another user equipment through the base stations, RNCs, and mobile core network.

[0024] The base stations, RNCs, and mobile core network, collectively referred to as the mobile network, can be installed and operated by a single wireless operator or vendor. Different wireless operators can independently operate their own mobile networks. A user can subscribe a terminal device to a particular wireless operator to access the wireless operator's mobile network. When the user terminal moves to a geographic area where only base stations of other wireless operators are accessible, the user terminal can still be allowed to connect to these base stations through roaming. For example, as Figure 1As shown, base stations 120, 122, RNC 126, and mobile core network 101 can be operated by a first wireless operator, while base station 124 and RNC 128 can be operated by a second wireless operator. User devices 140-150 can be subscribed to the first wireless operator, while user device 152 can be subscribed to the second wireless operator. Among the user devices 140-150 that are subscribed to the first wireless operator, user devices 140-144 can be located within the signal coverage area of base stations 120 and 122 of the first wireless operator, and thus can access the mobile network of the first wireless network without roaming. However, user devices 146-150, which are also subscribed to the first wireless operator, can be located outside the signal coverage area of base stations 120 and 122, but within the coverage area of base station 124, which belongs to the second wireless operator. Thus, user devices 146-150 can roam on the mobile network provided by the second wireless operator. Signals from user devices 146-150 and received by base station 124 and corresponding RNC 128 can be transferred by the second wireless operator through a switching node (shown as node 131) to the mobile core network 101 of the first wireless operator. The signals can then be processed and routed by the mobile core network 101 to other wireless user devices (e.g., user devices 140-144), IP networks (e.g., intranet 160), PSTN 162, etc., wherever the destination of the signals is.

[0025] The mobile core network 101 belonging to the first wireless operator can further transfer signals to the mobile core network belonging to the second wireless operator, as shown by arrow 132 and node 135, so that user devices subscribed to the first wireless operator (e.g., user devices 140-144) can communicate with user device 152 subscribed to the second wireless operator. In this case, the communication information can be transferred from the mobile core network 101 to the mobile core network 102 through a switching node, as shown by arrow 133 and node 135. The communication information can be further transmitted to user device 152 subscribed to the second wireless operator through mobile core network 102, RNC 128, and base station 124. Likewise, user device 152 subscribed to the second wireless operator can send communication information to user devices subscribed to the first wireless operator (e.g., user devices 140-144) using the reverse path, i.e., along base station 124, RNC 128, mobile core network 102, mobile core network 101, RNC 126, and base stations 120 or 122. Figure 1

[0026] Figure 1 The mobile core networks 101 and 102 can be implemented as special-purpose custom hardware components for performing various network functions, such as Figure 1 ​The mobile core networks 101 and 102 are implemented in dedicated hardware components, such as the equipment racks and cabinets 111 and 113 shown in FIG. 1. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2. Figure 2 As shown in FIG. 1, the mobile core networks 101 and 102 are implemented in dedicated hardware components, such as the equipment racks and cabinets 111 and 113 shown in FIG. 1. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2. Figure 2 As shown in FIG. 1, the mobile core networks 101 and 102 are implemented in dedicated hardware components, such as the equipment racks and cabinets 111 and 113 shown in FIG. 1. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2. Figure 1 As shown in FIG. 1, the mobile core networks 101 and 102 are implemented in dedicated hardware components, such as the equipment racks and cabinets 111 and 113 shown in FIG. 1. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2.

[0027] As shown in FIG. 1, the mobile core networks 101 and 102 are implemented in dedicated hardware components, such as the equipment racks and cabinets 111 and 113 shown in FIG. 1. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2. Figure 1 As shown in FIG. 1, the mobile core networks 101 and 102 are implemented in dedicated hardware components, such as the equipment racks and cabinets 111 and 113 shown in FIG. 1. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2. Figure 2 As shown in FIG. 1, the mobile core networks 101 and 102 are implemented in dedicated hardware components, such as the equipment racks and cabinets 111 and 113 shown in FIG. 1. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2.

[0028] However, virtualized mobile core networks are more agile, flexible, and resilient, and can be deployed directly, especially when such mobile core networks are implemented in the cloud to leverage existing underlying hardware resources and cloud management and configuration tools and interfaces. Such virtualized mobile core networks can be deployed in the cloud immediately without direct capital investment in expensive dedicated hardware components. Therefore, the threshold for network deployment is low and a mobile core can be deployed with a click of a mouse. Similarly, modifications, extensions, and upgrades to already deployed such virtualized mobile core networks involve only software updates and cloud resource reconfigurations. The deployment, maintenance, upgrade, replacement, and configuration of underlying hardware resources are taken care of by the cloud platform and service provider independently of and decoupled from the software-defined mobile core network.

[0029] Due to the flexibility and resilience offered by software-defined mobile core networks in the cloud, an organization, a business, etc. (referred to herein as "business") can act as its own wireless carrier. In other words, instead of sharing a mobile core network with others, a business, for example, can choose to deploy its own private global mobile core network. In one case, the business can want to connect its employees through its private global mobile core network. In another case, the business can want to connect wireless sensors distributed in different geographical locations to a sensor network through its private mobile core network. The business can further deploy its own global mobile core network to integrate its mobile employees and sensors into a combined global private network. Regardless of the specific needs of the application, such a private mobile core network can be deployed and configured as a cloud instance immediately and with an initial cloud resource allocation based on the number of users (or sensors) and the overall mobile communication needs and characteristics of the business. The allocation of underlying cloud resources for the private mobile core network can be further dynamically and in real-time provided as a function of time after the initial deployment based on the communication patterns of the business. For example, depending on the nature of the business and the characteristics of the user communications, the private mobile core network of the business can be used more during certain time windows of the day, certain weeks of the month, and / or certain months or seasons of the year. Therefore, a private mobile core network implemented in the cloud can provide real-time resilience in resource allocation and can particularly leverage the cloud configuration tools and interfaces already developed and provided by the cloud service provider for dynamically and predictively configuring and allocating cloud computing resources. As a result, such a private mobile core network can reduce resource imbalances and underutilization and provide a more efficient mobile communication system. Moreover, since such private mobile core networks can be deployed independently of other mobile cores, they can be easily customized and configured in software automatically or at any selected time.

[0030] As Figure 2As further shown in implementation scheme 200, radio access network 105 can remain unvirtualized. Enterprises that own their private virtualized mobile core networks 203 and 205 may not need to deploy their own radio access network. Instead, they can use existing radio access networks 105 deployed by other wireless mobile operators and belonging to them. Enterprises can receive radio signals from radio access network 105 and direct the signals to their private mobile core network in the cloud, or route signals from their private mobile core network to radio access network 105, both through... Figure 2 Edge switching connections 210 and 220 are used to connect these radio access networks. These switching connections can be made by network edge connectors that coexist with RNCs 126 and 128 of the radio access network before backhaul 127 and 129, or coexist on traditional mobile core nodes belonging to traditional wireless operators that own access network 105 after backhaul 127 and 129.

[0031] Enterprises, acting as their own global wireless operators, deploy their software-defined mobile core networks in the cloud, which in turn can be associated with a set of Subscriber Identity Modules (SIMs). These SIMs can be provided to the enterprise's wireless devices 140-152, such as... Figure 2 As shown in figures 241, 243, 245, 247, 249, 251, and 253, these SIMs can be identified as roaming devices by the radio access network 105. Signals from radio devices associated with these SIMs can be routed accordingly via network edge connectors 210 and 220 to and from the mobile core network implemented in the cloud. In some implementations, these SIMs may contain multiple International Mobile Subscriber Identity (IMSI) profiles under the Embedded Universal Integrated Circuit Card (eUICC) specification. These eUICCs can be remotely configured and activated between different IMSI profiles. They are particularly suitable for deployment on remote sensor devices that are difficult or inconvenient to physically access after installation. As radio access networks evolve, these devices can communicate with partner radio access networks or home radio access networks in roaming or sponsored modes, using different IMSI profiles, and can be programmed without physical access to the SIMs installed in the devices.

[0032] Figure 2 In this context, the virtualized mobile core networks 203 and 205, implemented in the cloud, can offer additional benefits to enterprises acting as their own global wireless operators. This is in... Figure 2 and Figure 3 Further explanation is provided in the text. Conceptually, enterprises can deploy one or more information technology (IT) and computing infrastructures in the cloud. Figure 2The winning bidders are cloud instance A 204 and cloud instance B 206), independent of the mobile core network. Enterprises can wish to provide their mobile users seamless access to these cloud computing infrastructures. Since both the mobile core network and the one or more cloud computing infrastructures are implemented as cloud instances, communication between them can be routed in the cloud, facilitated by network handling and routing daemons also implemented in the cloud, which act as Figure 2 virtual cross-connects 207 and 208 shown in the middle. Signals and information routed within the cloud can be protected by cloud security mechanisms, such as generic routing encapsulation (GRE, similar to IPSec). Thus, the enterprise's mobile users can access the cloud computing infrastructures through a virtual mobile core network without exposing the information of the communication to the public Internet.

[0033] Figure 3 A specific illustration is provided. As shown in Figure 3 , the enterprise's users 302 communicate with the radio access network 304 through a private over-the-air communication channel 320. The radio access network 304 communicates with the private mobile core network 308 in the cloud through the exchange 306 through private physical connections 312, 314, and 322. Communication between the mobile core network and the enterprise cloud computing infrastructure 310 can be based on private and secure routing in the cloud, as shown by 312 and 316. At no point in time is any of the communication legs between the user devices 302 and the enterprise cloud computing infrastructure 310 exposed to a non-private communication channel. Thus, Figure 3 the implementation with the cloud-based mobile core network provides a secure connection between the user devices 302 and the cloud computing infrastructure 310, leverages the underlying security functionality implemented in the cloud, and does not require the use of additional tunneling technology.

[0034] Such security can not be easily achieved in a traditional system using an off-cloud mobile core, as shown in Figure 4 the system 400. As shown in Figure 4 , when the mobile core networks 402 and 404 are implemented off-cloud (e.g., as hardware-based mobile core networks), access to the cloud computing infrastructures 204 and 206 from the mobile core networks 402 and 404 will require going through the public Internet 406. Thus, communication between the user devices 140-152 and the cloud computing infrastructures 204 and 206 can be exposed to an insecure communication channel involving a leg of the public Internet 406 without protection by any in-cloud security measures.

[0035] While Figure 2 the cloud platform 202 is illustrated as a single cloud platform, the system of Figure 2 may alternatively be implemented in an environment with multiple cloud platforms, as shown in Figure 5The mobile core networks 103 and 105 can be deployed as cloud instances of the cloud platform 502 in one example embodiment. In another example embodiment, the mobile core networks such as 103, 105 and 501 can be deployed in different cloud platforms 502 and 504. Likewise, the enterprise cloud computing infrastructures 104 and 106 can be deployed in the same or different cloud platforms 506 and 508. The software-defined mobile core networks capable of being deployed in different cloud platforms can provide more flexibility for a particular enterprise. For example, if an enterprise already has existing cloud computing infrastructures in a particular cloud platform, it can choose the same cloud platform to deploy its mobile core network, so that the virtual cross-connections between the mobile core network and the cloud computing infrastructures can also be implemented in the same cloud platform. The various cloud platforms mentioned above can include, but are not limited to, Amazon™ AWS, Microsoft™ Azure, Google™ Cloud and IBM™ Cloud.

[0036] The mobile core networks discussed above can include various functional blocks for mobile service management, data processing and routing. Figure 6 An example is shown in FIG. 6. Figure 6 The mobile core network 602 of FIG. 6 can include mobile service and subscription management components, databases or servers such as a short message service center (SMSC), a home subscriber server (HSS) and a home location register (HLR). These components can communicate with the RNC 126 according to, for example, S6a Diameter protocol. The mobile core network can further include a spanning tree protocol (STP) processing component for processing signaling information according to SS7 signaling protocol. The mobile core network can further include packet processing components such as a packet gateway (PGW) 614 and a corresponding multiplexer 612, which communicate with the RNC 126 through, for example, S5 / S8 / GPRS tunneling protocol (GTP) and with the external IP network 160 through SGi protocol.

[0037] Figure 6 are shown merely as an example. Those of ordinary skill in the art can understand that the mobile core network 602 can include many other components not shown in FIG. 6. For example, the mobile core network 602 can include other components for processing voice information in non-packet form and components for interfacing with the PSTN. The configuration of the mobile core network 602 can be guided by various underlying standards for 2G, 3G, LTE, 4G and 5G mobile communication systems. These other configurations can be quite different from the configuration illustrated in FIG. 6. However, the software-defined mobile core networks implemented in the cloud and the basic principles disclosed herein are applicable to those other mobile core configurations. Figure 6 Figure 6

[0038] ​​Various components of a software-based mobile core network can be implemented as containers in the cloud. In particular, each of the processing components described above can be developed and packaged as an application, including all of the required software stack and its dependencies (e.g., libraries). Such an application package can be deployed as a container in the cloud. Each application can be deployed as multiple independent container instances running on underlying computers in the cloud that share the same host operating system and its kernel. Other alternative implementations of mobile core network components in the cloud can be based on virtual machines. Compared to virtual machine architectures, the implementation of containers is typically lightweight, resource-conserving, and powerful. Because they are lightweight, containers can be instantiated quickly and efficiently. Thus, when the volume of services of an application (e.g., a mobile core function component) and the system resource requirements increase over time, new instances of the container can be instantiated as needed to meet customer demand, providing the elasticity required for a software-defined mobile core network. Likewise, when the volume of services of an application decreases, excess containers can be removed quickly and efficiently, with their user traffic being redistributed to the remaining containers of the application. The software stack of a container can be designed and then packaged using tools such as Docker™.

[0039] In addition to various instances of containers for different processing components, the implementation of a mobile core network can also include instances of other programs or daemons implemented in the cloud that are designed to perform routing functions of the mobile core network in, for example, the data link and / or network layers of the OSI model. Thus, the cloud implementation of a mobile core network can include a mix of containers and daemons, as shown in Figure 7 In the example of Figure 7 , routing daemons are represented by 710. Containers 704 represent multiple instances of one of the multiple functional components of the mobile core network (e.g., PGW containers). Containers 706 represent multiple instances of another one of the multiple functional components of the mobile core network (e.g., HLR). Routing daemons can be implemented to facilitate the functioning of a particular container or all multiple container instances of the same component, or can be implemented to facilitate communication between containers of the same component or between containers of different components. A group of containers can be organized into a bin.

[0040] Figure 8 An example configuration for implementing containers of a mobile core network organized in bins is further shown. As Figure 8As shown, signals from the RNC can be intercepted by the interconnects 802 and 210, multiplexed according to signal type (as shown at 830, including but not limited to S6a Diameter signals, SS7 signals, S5 / S8 GTP signals), and then directed to a mobile core network implemented as cloud containers 808 and 810, which are organized as bins 804 and 806. These containers can be deployed to implement various functions of the mobile core network, as described above. The mobile core network can be further connected to other cloud instances 820 through virtual cross-connects implemented in the cloud. Other cloud instances 830 (e.g., SMS proxy instances, over-the-air (OTA) instances, and HA shared storage instances) can be further implemented to facilitate the functions of the mobile core network.

[0041] Figure 9 Further details are shown for implementing data routing functions at network layers II and III (data link layer and network layer) between a mobile core network and other networks on or off the cloud. As shown at 900, example data routing can be deployed in the cloud as multi-level routers, including core routers (CR) 910 and 912, virtual cloud routers (VCLR) 920 and 922, virtual route and forwarding (VRF) aware bin routers (VATR) 930, virtual CE routers (VCER) 950, as shown at 940 interconnected through various communication interfaces. Figure 9 Figure 9 As shown, these multi-level virtual routers are connected to a virtual mobile core network 902 and a virtual multi-protocol label switching (MPLS) private cloud 904.

[0042] Figure 9 The various multi-level routers in 900 can be implemented as cloud daemons rather than containers. In particular, public cloud service providers typically do not allow users to bring their own public IP space within actual cloud container instances. In order to perform IP routing between PGWs, these virtual routers can be implemented as programs (daemons) deployed in the cloud. In an alternative implementation based on the use of virtual machines rather than visualizations of containers within a private hardware cloud, IP addressing space can be more easily customized. Figure 9 The multi-layer IP routing scheme of 900 can be used in a container implementation to transfer IP addressing space limitations in the public cloud.

[0043] ​These routers form a cloud cluster and along with mobile core container instances form a specific virtual private cloud (VPC) for an enterprise, for example. The VCLRs 920 and 922 only play a routing role and no actual services can be attached to these routers. The VATRs can be VRF aware cloud instances and provide services attached to specific VRFs. The VCERs can not have VRF awareness and can be designed to provide services with arbitrary broadcast private / public IP capability. The VCERs can not need to be bound to a specific VPC and multiple instances can exist in the network.

[0044] The VCLRs essentially play the role of PEs from the core routers. Therefore, adding or removing any service will only require changes to the VCLRs. No changes will be required from the core side. Also, as shown in Figure 9 GRE tunnels from the VCLRs to the core routers, are sufficient to provide services in a high availability manner. The use of MPLS between the VCLRs and the core routers and encapsulating the MPLS in GRE tunnels also eliminates the requirement of having one tunnel per VRF (non-VRF Lite). The VCLRs connect with other service instances (such as VATRs, WL-tankers, and VCERs) through GRE tunnels without using MPLS on a per VRF (VRF Lite) one tunnel basis.

[0045] MPLS VPN 904 can be implemented in the cloud and provide private networks with global reach in all major cloud platforms (e.g., Google, AWS, Microsoft, IBM). Therefore, the wireless of an enterprise’s IP traffic terminating at the PGW of a private mobile core can be routed privately to the enterprise’s remote IP network. These remote sites can be one physical site or, as previously described, a virtual network within a cloud. In the case where the remote sites are virtual networks within a cloud, the PGW of the private mobile core can be connected to the cloud using a virtual cross-connect as shown in Figure 9 The routing instances and MPLS VPN cloud 904 essentially function as the virtual cross-connect shown in Figure 2 as 207 and 208 in Figure 9 The cloud cluster shown in

[0046] Figure 10An exemplary manner in which a private and virtualized mobile core network and related virtualized IP routing functionality can be provided as a configurable service is shown. The provider of the service can deploy a global MPLS VPN cloud 904. The provider of the service can further provide a service configuration interface, such as a web interface 1010 to potential users, such as enterprise users. Users can use the web interface to initiate service requests to the mobile core and routing server 1002, which the service provider can then immediately deploy a private mobile core and virtual router 1030 in the cloud for the user. The user can further modify, configure and provision the deployed private mobile core and router 1030 from the web interface 1010 through an application program interface (API) 1011. Cloud resource subscription, allocation and management can be provided by a server 1020 from the cloud service provider. Requests for cloud resources needed to deploy the private mobile core and router 1030 can be handled by the provider of the service and sent to the server 1020, as shown by arrow 1013. Alternatively, the interaction with the server 1020 can be conducted directly by the user, as shown by arrow 1015.

[0047] Finally, Figure 11 An exemplary computer system 1100 for implementing any of the computing components and devices needed to implement the above disclosure is shown. The computer system 1100 can include a communication interface 1102, system circuitry 1104, input / output (I / O) interface 1106, storage 1109, and display circuitry 1108 that generates a machine interface 1110, either locally or remotely, such as in a web browser running on a local or remote machine. The machine interface 1110 and the I / O interface 1106 can include a graphical user interface, touch sensitive display, voice or facial recognition input, buttons, switches, speakers, and other user interface elements. Other examples of the I / O interface 1106 include microphones, video and still image cameras, earphone and microphone input / output jacks, universal serial bus (USB) connectors, memory card slots, and other types of input. The I / O interface 1106 can further include magnetic or optical media interfaces (e.g., CD ROM or DVD drives), serial and parallel bus interfaces, and keyboard and mouse interfaces.

[0048] The communication interface 1102 can include a wireless transmitter and receiver ("transceiver") 1112 and any antenna 1114 used by the transmit and receive circuitry of the transceiver 1112. The transceiver 1112 and antenna 1114 can support Wi-Fi network communications, for example, according to any version of IEEE 802.11, such as 802.11h or 802.11ac. The communication interface 1102 can also include a wired transceiver 1116. The wired transceiver 1116 can provide a physical layer interface for any wide range of communication protocols, such as any type of Ethernet, Data Over Cable Service Interface Specification (DOCSIS), Digital Subscriber Line (DSL), Synchronous Optical Network (SONET), or other protocols.

[0049] The memory 1109 can be used to store various initial, intermediate, or final data. The memory 1109 can be centralized or distributed, and can be local or remote to the computer system 1100. For example, the storage 1109 can be hosted remotely by a cloud computing service provider.

[0050] The system circuitry 1104 can include any combination of hardware, software, firmware, or other circuitry. The system circuitry 1104 can be implemented, for example, with one or more system on a chip (SoC), application specific integrated circuits (ASICs), microprocessors, discrete analog and digital circuits, and other circuitry. The system circuitry 1104 is part of what implements any desired functionality related to the components of the above-described embodiments. As just one example, the system circuitry 1104 can include one or more instruction processors 1118 and a memory 1120. The memory 1120 stores, for example, control instructions 1126 and an operating system 1124. In one embodiment, the instruction processor 1118 executes the control instructions 1126 and the operating system 1124 to perform any desired functionality related to the various components of the above-described embodiments.

[0051] Accordingly, the above-described embodiments provide a fully virtualized and software-defined mobile core network that is deployed as instances of containers and daemons in one or more public cloud platforms. The mobile core network can be deployed with a multi-tiered virtual IP routing network that is also deployed in the public cloud platform as cloud daemons for transposing the IP addressing space of the cloud platform’s underlying hardware components and routing data traffic received and processed by the mobile core to other networks. These other networks can include, but are not limited to, other private cloud networks, other standalone cloud instances or applications, other fixed IP networks (e.g., fixed wide area networks), and public networks such as the public Internet and the PSTN. In some embodiments, mobile data can be received by the mobile core and then routed within the private cloud to global remote sites without exposing any of the communication legs on the public Internet, avoiding the inclusion of additional security tunneling. The deployment of the mobile core and virtual routing components in the public cloud platform can be offered as a service to enterprises. Accordingly, enterprises can instantly customize, deploy, configure, provision, and maintain their own mobile core and IP routing networks through an API interface. As a result, enterprises can effectively act as their own global mobile operators.

[0052] The above-described methods, apparatus, processes, and logic can be implemented in a number of different fashions and in a number of different combinations of hardware and software. For example, all or a portion of an implementation can be on a circuit board as part of a larger system, such as a mobile device, a wireless communication device, a desktop personal computer, a laptop computer, etc. In one example, all or a portion of an implementation can be on a single integrated circuit chip, or spread across multiple integrated circuit chips. In another example, all or a portion of an implementation can be on a single board, or spread across multiple boards. In yet another example, all or a portion of an implementation can be spread across several subsystems, which can be geographically distributed, for example, in different parts of a system-on-a-chip (SoC) or in different parts of multiple SoCs. In yet another example, all or a portion of an implementation can be spread across several devices, which can be geographically distributed, for example, in different parts of a system-on-a-chip (SoC) or in different parts of multiple SoCs.

[0053] The circuitry can further include or otherwise have access to instructions for execution by the circuitry. The instructions can be stored in a tangible storage medium that is not a transitory signal, such as flash memory, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM); or stored on a magnetic or optical disk, such as a compact disk read only memory (CDROM), hard disk drive (HDD), or other magnetic or optical disk; or stored in other machine-readable medium. A product, such as a computer program product, can include a storage medium and storage medium having stored therein instructions, which can be executed by a device to cause the device to perform any of the processes described above or illustrated in the figures.

[0054] Embodiments can be distributed as circuitry among multiple system components, e.g., among multiple processors and memory, optionally including multiple distributed processing systems. Parameters, databases, and other data structures can be separately stored and managed, can be incorporated into a single memory or database, can be logically and physically organized in many different ways, and can be implemented in many different ways, including as data structures such as linked lists, hash tables, arrays, records, objects, or implicit storage mechanisms. Programs can be part of a single program (such as a subroutine) or separate programs, distributed across several memories and processors, or implemented in many different ways, such as in libraries, such as shared libraries (e.g., dynamic link libraries (DLLs)). For example, a DLL can store instructions that, when executed by circuitry, perform any of the processes described above or shown in the figures.

Claims

1. An information routing method, characterized in that, include: The wireless access network receives first data from a wireless terminal device, wherein the wireless access network includes a base station and a wireless network controller; The first data is directed to a private software-defined and fully virtualized mobile core and data routing network deployed in a public cloud platform; wherein the mobile core and the data routing network comprise a hybrid of multiple cloud instances of multiple data processing containers and multi-level routers, each of the multiple data processing containers corresponds to one or more components in the mobile core and data routing network, and the number of cloud instances of each data processing container can be adjusted according to the service volume of the one or more components; The first data is routed through multiple cloud instances of the multiple data processing containers to a first private virtual packet gateway, which is implemented as one of the multiple cloud instances of the data processing containers in the mobile core and the data routing network. The first data is routed from the first private virtual packet gateway to the multi-level router; The first data is routed from the multi-level router to an independent cloud application terminating at the second packet gateway via a private virtual cross-connect implemented in the public cloud platform; and Provide the wireless terminal device with access to the standalone cloud application.

2. The method according to claim 1, characterized in that, The private virtual cross-connect includes a private virtual cloud network for routing multiprotocol label exchange messages.

3. The method according to claim 1, characterized in that, Further includes: The wireless access network receives second data from the wireless terminal device; The second data is redirected to the mobile core and the data routing network; The second data is directed to the first private virtual packet gateway; The second data is routed from the first private virtual packet gateway to the multi-level router; as well as The second data is routed from the multi-level router to an external remote IP network via a private virtual cloud network, thereby routing the multiprotocol label exchange message.

4. The method according to claim 1, characterized in that, Further includes: The wireless access network receives second data from the wireless terminal device; The second data is redirected to the mobile core and the data routing network; The second data is directed to the first private virtual packet gateway; The second data is routed from the first private virtual packet gateway to the multi-level router; as well as The second data is routed from multiple cloud data routes to the multi-level router to the off-cloud mobile core network implemented using dedicated hardware components.

5. The method according to claim 1, characterized in that, Further includes: The wireless access network receives second data from the wireless terminal device; The second data is redirected to the mobile core and the data routing network; The second data is directed to the first private virtual packet gateway; The second data is routed from the first private virtual packet gateway to the multi-level router; as well as The second data is routed from the multi-level router to another private software-defined and fully virtualized mobile core implemented in the public cloud platform via a private virtual cloud network, thereby routing multiprotocol label exchange messages.

6. The method according to claim 1, characterized in that, Further includes: The number of container instances or the number of multi-level routers in the mobile core and the data routing network are automatically adjusted based on the utilization rate of the cloud computing resources underlying the mobile core and the data routing network.

7. A private software-defined and fully virtualized mobile core and data routing network deployed in a public cloud platform, characterized in that, include: The first group of cloud container instances is configured to receive data from wireless terminal devices via a wireless access network, wherein the wireless access network devices include a base station and a wireless network controller. The second group of cloud container instances, wherein each second group of cloud container instances corresponds to one or more components in the mobile core and data routing network, and the number of the second group of cloud container instances may be adjusted according to the service volume of the one or more components, and the second group of cloud container instances is configured to implement a set of mobile core network functions by processing the data received by the first group of cloud container instances. The third group of cloud container instances; and Multi-level routers deployed in the public cloud platform; The third group of cloud container instances acts as a data packet gateway, used to route the data processed by the second group of cloud container instances to the routing daemon set deployed in the public cloud platform. The routing daemon set is configured to route data received at the routing daemon set to a private cloud network configured to exchange routing messages according to Multiprotocol Label Exchange.

8. The mobile core and data routing network according to claim 7, characterized in that, The multi-level routers include a subset of core routers, a subset of virtual routing and forwarding (VRF) aware routers, and a subset of non-VRF aware routers.

9. The mobile core and data routing network according to claim 8, characterized in that, The connection between the core router subset and the non-VRF-aware router subset is performed under multiprotocol label switching encapsulated by General Routing Encapsulation (GRE).

10. The mobile core and data routing network according to claim 7, characterized in that, It further includes the private cloud network; wherein the private cloud network is further configured to route the data to a standalone cloud application that terminates at another packet gateway.

11. The mobile core and data routing network according to claim 7, characterized in that, It further includes the private cloud network; wherein the private cloud network is further configured to route the data to a remote IP network outside the cloud.

12. The mobile core and data routing network according to claim 7, characterized in that, It further includes the private cloud network; wherein the private cloud network is further configured to route the data to an off-cloud mobile core network implemented using dedicated hardware components.

13. The mobile core and data routing network according to claim 7, characterized in that, It further includes the private cloud network; wherein the private cloud network is further configured to route the data to another private software-defined and fully virtualized mobile core implemented in the public cloud platform.

14. A private wireless sensor network, characterized in that, include: Multiple distributed sensors, each of which integrates a wireless subscriber identity module (SIM) with multiple remotely activated International Mobile Subscriber Identity (IMSI) profiles; A privately defined and fully virtualized mobile core deployed in a public cloud platform is used to receive data collected by a plurality of distributed sensors via a wireless access network to generate output data, wherein the wireless access network includes base stations and a radio network controller; wherein the mobile core includes a mixture of multiple instances of a plurality of data processing containers for processing the received data; each of the plurality of data processing containers corresponds to one or more components in the mobile core, and the number of instances of each data processing container can be adjusted according to the service load of the one or more components; Multiple private multi-level routers deployed in the public cloud platform; and A private cloud network configured to exchange routing messages according to multiprotocol labeling; The output data of the mobile core is routed from the plurality of private multi-level routers to the private cloud network, and further routed from the private cloud network to the private cloud application.

15. The private wireless sensor network according to claim 14, characterized in that, The plurality of private multi-level routers include a subset of core routers, a subset of virtual routing and forwarding (VRF) aware routers, and a subset of non-VRF aware routers.

16. The private wireless sensor network according to claim 15, characterized in that, The connection between the core router subset and the non-VRF-aware router subset is performed under multiprotocol label switching encapsulated by General Routing Encapsulation (GRE).

17. The private wireless sensor network according to claim 14, characterized in that, The second output data from the mobile core is routed by the plurality of private multi-level routers to the private cloud network, and further routed from the private cloud network to an external remote IP network.

18. The private wireless sensor network according to claim 14, characterized in that, The second output data from the mobile core is routed by the plurality of private multi-level routers to the private cloud network, and further routed from the private cloud network to the off-cloud mobile core network implemented using dedicated hardware components.

19. The private wireless sensor network according to claim 14, characterized in that, The second output data from the mobile core is routed by the plurality of private multi-level routers to the private cloud network, and further routed from the private cloud network to another private software-defined and fully virtualized mobile core implemented on the public cloud platform.

Images