Secure virtual private mobile and IP network in cloud

Abstract

To provide a novel, fully software-defined, fully virtualized, and customizable mobile communication platform deployed on a public cloud infrastructure.SOLUTION: The mobile network allows an end-to-end control of a deployment and a structure by an automatic program of a mobile network component. This embodiment enables the immediate creation and deployment of a true private global end-to-end software-defined network (SDN) for 3G, 4G, LTE, and 5G mobile communications from a blank slate. A user can effectively act as his / her own mobile carrier and customize available functions for the user through a programmatic interface.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] This PCT international patent application claims priority to U.S. Provisional Patent Application No. 62 / 886,471, filed August 14, 2019.

[0002] The present disclosure relates to a fully software defined, fully virtualized, customizable mobile communications platform that is deployed on a public cloud infrastructure. [Background technology]

[0003] A mobile network may include a radio access network and a mobile core network interconnected by backhaul lines. The mobile network may further communicate with other data networks via the public Internet. Traditional mobile core networks rely heavily on fixed, custom-built hardware components to perform the functions required to achieve end-to-end communication. These hardware-driven mobile core networks are rigid, inflexible, and less adaptable during deployment and subsequent provisioning and maintenance. As various traditionally different types of network traffic (e.g., voice, messaging, and data) are increasingly integrated into one, legacy mobile core networks may be simplified to the extent that the entire mobile core network may be virtualized and implemented in software without relying on dedicated hardware components. Summary of the Invention

[0004] The present disclosure relates to a fully software defined, fully virtualized, customizable mobile communications platform that is deployed on public cloud infrastructure as a mix of configurable instances of cloud containers and cloud daemons. Such a mobile network allows private, secure routing of end-to-end network traffic within the mobile network and between the mobile network and other private and public networks. Such a mobile network is instantly deployable in the cloud with high elasticity. Moreover, it can be automatically programmatically provisioned and reconfigured during operation. The implementations disclosed herein essentially provide a platform that allows for the immediate dynamic creation and deployment of truly private global end-to-end software defined networks (SDNs) for 3G, 4G, LTE and 5G mobile communications from a clean slate. Users of such a platform essentially act as their own mobile carriers, allowing them to customize the features available to them via programmatic interfaces.

[0005] In one implementation, a method of information routing through such a mobile network is disclosed. The method may include intercepting first data from a wireless terminal device at a radio network controller and redirecting the first data to a private software-defined fully virtualized mobile core and data routing network deployed in a public cloud platform, the mobile core and data routing network including a mix of multiple cloud instances of data processing containers and multiple cloud data routing daemons. The method may further include directing the first data through the multiple cloud instances of data processing containers to a first private virtual packet gateway implemented as one instance of the multiple cloud instances of data processing containers in the mobile core and data routing network, routing the first data from the first private virtual packet gateway to the multiple cloud data routing daemons, and routing the first data from the multiple cloud data routing daemons to an independent cloud application terminated at a second packet gateway via a private virtual cross connect implemented in the public cloud platform. The method may further include providing the wireless terminal device with access to the independent cloud application.

[0006] In another implementation, a private software-defined fully virtualized mobile core and data routing network deployed in a public cloud platform is disclosed. The mobile core and data routing network may include a first set of instances of cloud containers configured to receive data from wireless terminal devices via a radio network controller, and a second set of instances of cloud containers configured to implement a set of mobile core network functions by processing data received by the first set of instances of cloud containers from the radio network controller. The virtualized mobile core and data routing network may further include a third set of instances of cloud containers and a set of routing daemons deployed in the public cloud platform. The third set of instances of cloud containers can function as a packet gateway for routing data processed by the second set of instances of cloud containers to the set of routing daemons deployed in the public cloud platform. The set of routing daemons can be 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.

[0007] In yet another implementation, a private wireless sensor network is disclosed. The wireless sensor network may include a plurality of distributed sensors, each distributed sensor integrated with a wireless subscriber identity module (SIM) having a plurality of international mobile subscriber identity (IMSI) profiles that can be remotely activated. The wireless sensor network may further include a private software-defined fully virtualized mobile core deployed in a public cloud platform to receive data collected by the plurality of distributed sensors over a radio access network to generate output data. The mobile core may include a mix of a plurality of instances of data processing containers to process the received data, a plurality of private routing daemons deployed in the public cloud platform, and a private cloud network configured to route messages according to multi-protocol label switching. The output data of the mobile core may be further routed from the plurality of private routing daemons to a private cloud network and from the private cloud network to a private cloud application. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an example architecture of a conventional mobile communication platform based on dedicated hardware components for implementing the functions of a mobile core network. [Diagram 2] FIG. 1 illustrates an example architecture for a mobile communications platform with a fully software-defined, fully virtualized mobile core in a public cloud infrastructure. [Diagram 3]FIG. 1 illustrates a secure virtual cross-connect that can be implemented in the cloud between a virtualized mobile core network in a public cloud infrastructure and other independent cloud instances. [Figure 4] FIG. 2 illustrates a communication path between a mobile device and a cloud instance via a conventional mobile core network implemented in hardware, showing a connection section exposed to the unsecured public Internet. [Diagram 5] FIG. 1 illustrates an example of an implementation of a mobile core network virtually cross-connected to other cloud instances in an environment including multiple different cloud platforms. [Figure 6] A diagram showing example functional components of a mobile core network for signaling, data processing and information routing. [Figure 7] FIG. 1 illustrates an example implementation of a mobile core network as a mix of containers and daemons deployed on a public cloud infrastructure. [Figure 8] FIG. 1 illustrates another example implementation of a mobile core network as a container and a tanker. [Figure 9] FIG. 1 illustrates an example routing layer implemented as a daemon or container in the cloud to facilitate end-to-end communication through a virtualized mobile core. [Figure 10] FIG. 1 illustrates an example scheme for providing automated deployment and provisioning services of private mobile core networks and virtual cross-connects to other independent cloud instances. [Figure 11] FIG. 1 illustrates an example implementation of a computing device that can be used as the underlying hardware in the cloud or as a user terminal device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The present disclosure relates to a fully software defined, fully virtualized, customizable mobile communications platform that is deployed on a public cloud infrastructure as a mix of configurable instances of cloud containers and cloud daemons. Such a mobile network allows private, secure routing of end-to-end network traffic within the mobile network and between the mobile network and other private and public networks. Such a mobile network is instantly deployable in the cloud with high elasticity. Moreover, it can be automatically programmatically provisioned and reconfigured during operation. The implementations disclosed herein essentially provide a platform that allows for the immediate dynamic creation and deployment of truly private global end-to-end software defined networks (SDNs) for 3G, 4G, LTE and 5G mobile communications from a clean slate. Users of such a platform essentially act as their own mobile carriers, allowing them to customize the features available to them via programmatic interfaces.

[0010] 1 illustrates an example system architecture of a mobile communication network 100. The mobile communication network 100 may include User Equipment (UE) 103 that communicates with a Mobile Core Network (CN) 107 via a Radio Access Network (RAN) 105. The User Equipment 103 may be implemented as a mobile or fixed terminal device, including but not limited to a mobile phone, tablet, personal digital assistant (PDA), wearable device, distributed sensor, Internet of Things (IoT) terminal, desktop computer, and laptop computer, configured to access the RAN 105 via a wireless connection. These example terminal devices are shown as 140-152 in FIG. 1.

[0011] The radio access network 105 may include, for example, base stations 120, 122, 124 and radio network controllers (RNCs) 126 and 128. The base stations 120, 122, and 125 aggregate wireless uplink signals from user devices and broadcast wireless downlink signals to user devices via over-the-air radio channels. The RNCs 126 and 128 may further aggregate signals from the base stations 120, 122, and 124 or deliver signals to the base stations 120, 122, and 124 via wired backhaul connections as indicated by dashed arrows 121, 123, 125. The RNCs further function to control the connected base stations to provide provisioning of radio channels and signal characteristics.

[0012] As further shown in FIG. 1, the RNCs 126 and 128 can communicate with the mobile core network 101 via wired backhauls 127 and 129. The mobile core network 101 can be designed to perform various control, signal processing, information routing, and signal gateway functions separately or in a combined manner (e.g., all as data packets) according to a predefined stack of transmissions and signaling protocols for voice, messages, and / or data packets. The mobile core network 101 can further transmit or receive data to or from other networks 109. For example, as shown in FIG. 1, the mobile core network 101 can communicate with IP networks such as the Internet 160, fixed voice networks such as the Public Switched Network (PSTN) 162, and the like. Thus, signals can be routed between the user equipments 140-152 and the Internet 160 and / or the PSTN 162 via the mobile core network. Signals can also be routed between one user equipment and another user equipment via base stations, RNCs, and the mobile core network.

[0013] The base stations, RNCs, and mobile core network, collectively referred to as a mobile network, may be installed and operated by a single wireless carrier or provider. Different wireless carriers independently operate their own mobile networks. A user subscribes a terminal to a particular wireless carrier to access the mobile network of the particular wireless carrier. If the user terminal is moved to an area where only base stations of other wireless carriers are accessible, the user terminal can connect to these base stations by roaming. For example, as shown in FIG. 1, the base stations 120, 122, RNC 126, and mobile core network 101 may be operated by a first wireless carrier, while the base station 124 and RNC 128 may be operated by a second wireless carrier. User equipment 140-150 may subscribe to the first wireless carrier, while user equipment 152 may subscribe to the second wireless carrier. Among the user equipments 140-150 subscribed to a first wireless carrier, the user equipments 140-144 may be located within the signal coverage areas of the base stations 120 and 122 of the first wireless carrier and therefore can access the mobile network of the first wireless network without roaming. However, the user equipments 146-150 also subscribed to the first wireless carrier may be located outside the signal coverage areas of the base stations 120 and 122 but within the coverage area of ​​the base station 124 belonging to the second wireless carrier. Thus, the user equipments 146-150 may roam on the mobile network provided by the second wireless carrier. Signals from the user equipments 146-150 received by the base station 124 and the corresponding RNC 128 may be delivered by the second wireless carrier to the mobile core network 101 of the first wireless carrier via switching nodes such as shown by node 131. Such signals may then be processed by the mobile core network 101 and routed to other wireless user equipment (such as user equipment 140-144), an IP network (e.g., the Internet 160), the PSTN 162, etc. that are determined to be the destination of the signal.

[0014] The mobile core network 101 belonging to the first wireless carrier may further route signals to a mobile core network belonging to a second wireless carrier as shown by 102 in FIG. 1 so that user equipment (such as user equipments 140-144) subscribed to the first wireless carrier may communicate with user equipment 152 subscribed to the second wireless carrier. In this case, communication information is routed from the mobile core network 101 to the mobile core network 102 via a switching node as shown by arrow 133 and node 135. Such communication information may then be further transmitted via the mobile core network 102, the RNC 128 and the base station 124 to the user equipment 152 subscribed to the second wireless carrier. Similarly, user equipment 152 subscribed to the second wireless carrier can transmit communication information to user equipment (such as user equipment 140-144) subscribed to the first wireless carrier using the reverse path, i.e., through base station 124, RNC 128, mobile core network 102, mobile core network 101, RNC 126, and base station 120 or 122.

[0015] The mobile core networks 101 and 102 of FIG. 1 may be implemented as dedicated custom hardware components for performing various network functions, as shown in FIG. 1 as equipment racks and cabinets 111 and 113 in the mobile core networks 101 and 102. Alternatively, the mobile core networks 101 and 102 may be implemented and defined entirely in software and fully virtualized, as shown in FIG. 2. In the particular implementation shown in FIG. 2, the radio access network portion 105 of the mobile network remains the same as that of the implementation of FIG. 1, but the mobile core networks 107 (including, for example, mobile core network A 203 and mobile core network B 205) can be deployed in a public cloud platform 202 as software instances rather than dedicated equipment racks. The cloud-based mobile core networks 203 and 205 can further communicate with other off-cloud networks 109, including but not limited to IP networks 160, PSTN systems 162, and other off-cloud mobile core networks 230.

[0016] While the implementation of the mobile core networks 101 and 102 in dedicated hardware components as shown in FIG. 1 has several drawbacks and limitations, the cloud-based fully virtualized mobile core networks 203 and 205 as shown in FIG. 2 are advantageous in several respects. In particular, the implementation of the mobile core network based on dedicated customized hardware is inflexible, non-adaptive, and difficult to deploy, modify, reconfigure, extend and scale. For example, the extension and scaling of the capacity of a hardware-based mobile core network usually requires costly equipment replacement and often requires a very long period of time for installation and testing. The utilization of various hardware components in different parts of such a core network, even if deployed with careful consideration at the beginning, may become unbalanced as user profiles evolve, leading to a loss of efficiency in the utilization of the deployed hardware network equipment. Upgrades are often limited without replacing outdated network equipment. Network equipment based on hardware implementations requires very high capital investments and is therefore usually deployed and configured by large wireless carriers serving a large customer base. Thus, the configuration of the network often cannot be flexibly adjusted to individual subscribers or groups of subscribers. Network configurations are typically inflexible and static, making it extremely difficult to programmatically implement network configurations in an automated manner.

[0017] However, a virtualized mobile core network is much more agile, flexible, adaptable and simple to deploy, especially when such a mobile core network is implemented in the cloud to leverage existing underlying hardware resources and cloud management and provisioning tools and interfaces. Such a virtualized mobile core network is instantly deployable in the cloud without direct capital investment in expensive dedicated hardware components. As a result, the barriers to network deployment are low and the mobile core can be deployed with a simple mouse click. Similarly, modification, extension and scaling of such an already deployed virtualized mobile core network will require only software updates and cloud resource reconfiguration. The deployment, maintenance, upgrade, replacement and configuration of the underlying hardware resources will be handled by the cloud platform and service provider, independent and separate from the software defined mobile core network.

[0018] The flexibility and versatility provided by the software-defined mobile core network in the cloud allows institutions, enterprises, etc. (referred to herein as "enterprises") to act as their own wireless carriers. In other words, an enterprise may choose to deploy its own private global mobile core network, for example, rather than sharing a mobile core network with other enterprises. In some cases, an enterprise may want to connect its employees to each other via its private global mobile core network. In other cases, an enterprise may want to connect its wireless sensors distributed across various geographic locations to a sensor network via its private mobile core network. An enterprise may also deploy its global mobile core network to integrate both its mobile employees and sensors to form a composite private global network. Regardless of the specific needs of the application, such a private mobile core network can be instantly deployed and configured as a cloud instance with an initial cloud resource allocation tailored to the number of users (or sensors) and overall mobile communication needs and characteristics of the enterprise. The underlying cloud resource allocation for the private mobile core network can further be dynamically provisioned in real time after the initial deployment based on the enterprise's communication patterns over time. For example, an enterprise's private mobile core network may be more heavily used during certain times of the day, certain weeks of the month, and / or certain months or seasons of the year, depending on the nature of the enterprise's business and the characteristics of user communications. Thus, a cloud-implemented private mobile core network may provide real-time elasticity of resource allocation, and in particular may take advantage of cloud provisioning tools and interfaces already developed and provided by cloud service providers for dynamic, predictive provisioning and allocation of cloud computing resources.Such a private mobile core network thus reduces resource imbalance and underutilization, providing a more efficient mobile communications system. Moreover, because such a private mobile core network can be deployed independently of other mobile cores, it can be easily customized and configured automatically by software or at any selected time.

[0019] As further shown in the implementation 200 of FIG. 2, the radio access network 105 may remain non-virtualized. The above-mentioned enterprises having their own private virtualized mobile core networks 203 and 205 may not deploy their own radio access networks. Instead, the enterprises may use existing radio access networks 105 deployed by and belonging to other wireless mobile carriers. The enterprises may utilize these radio access networks by receiving radio signals from the radio access networks 105 and sending them to their private mobile core networks in the cloud or routing the signals from the private mobile core networks to the radio access network 105 via both edge switching connections 210 and 220 of FIG. 2. These switching connections may be made by network edge connectors that are co-located with the radio access network RNCs 126 and 128 before the backhauls 127 and 129, or co-located with traditional mobile core nodes belonging to the traditional wireless carrier that owns the access network 105 after the backhauls 127 and 129.

[0020] An enterprise acting as its global wireless carrier with the deployment of its software-defined mobile core network in the cloud may further be associated with a set of subscriber identity modules (SIMs). These SIMs may be provided to the enterprise's wireless devices 140-152 as shown by 241, 243, 245, 247, 249, 251 and 253 in FIG. 2. These SIMs may be recognized by the radio access network 105 as roaming devices, and signals from the wireless devices associated with these SIMs may be routed accordingly to and from the mobile core network implemented in the cloud via the network edge connectors 210 and 220. In some implementations, these SIMs may include multiple international mobile subscriber identity (IMSI) profiles based on the embedded universal integrated circuit card (eUICC) specification. These eUICCs are remotely configurable and activatable between different IMSI profiles. They are particularly suited for deployments with remote sensor devices that are difficult or inconvenient to physically access after installation. As radio access networks evolve, these devices may be able to communicate with peer radio access networks in roaming or sponsored modes, or with the home radio access network, using different programmable IMSI profiles without physical access to the SIM installed in the device.

[0021] The virtualized mobile core networks 203 and 205 of FIG. 2 implemented in the cloud can provide additional benefits to enterprises acting as their global wireless carriers. This is further illustrated in FIG. 2 and FIG. 3. Conceptually, an enterprise can deploy one or more information technology (IT) and computing infrastructures in the cloud independent of the mobile core network (labeled cloud instance A 204 and cloud instance B 206 in FIG. 2). It may be desirable for an enterprise to provide seamless access of these cloud computing infrastructures to its mobile users. Because both the mobile core network and the one or more cloud computing infrastructures are implemented as cloud instances, communication between them is routable within the cloud and can be facilitated by network processing and routing daemons also implemented in the cloud, which act as virtual cross connects 207 and 208 shown in FIG. 2. 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 infrastructure through the virtual mobile core network without exposing the information being communicated to the public Internet.

[0022] A specific diagram is shown in Figure 3. As shown in Figure 3, an enterprise user 302 communicates with a radio access network 304 via a private over-the-air communication channel 320. The radio access network 304 communicates with a private mobile core network 308 in the cloud via private physical connections 312, 314 and 322 through a switch 306. As shown at 312 and 316, the communication between the mobile core network and the enterprise cloud computing infrastructure 310 can be based on private secure routing in the cloud. At any point in time, no one of the communication legs between the user device 302 and the enterprise cloud computing infrastructure 310 is exposed to a non-private communication channel. Thus, the implementation of Figure 3 using a cloud-based mobile core network takes advantage of the underlying security mechanisms implemented in the cloud and provides a secure connection between the user device 302 and the cloud infrastructure 310 without the need to use additional tunneling techniques.

[0023] Such security cannot be easily implemented in a conventional system using an off-cloud mobile core, as shown in the system 400 of Fig. 4. As shown in Fig. 4, if the mobile core networks 402 and 404 are implemented off-cloud (e.g., implemented as hardware-based mobile core networks), access of the cloud infrastructures 204 and 206 from the mobile core networks 402 and 404 will need to go through the public Internet 406. Thus, communication between the user devices 140-152 and the cloud computing infrastructures 204 and 206 may be exposed to an insecure communication channel in the section involving the public Internet 406 without protection by in-cloud security measures.

[0024] Although the cloud platform 202 in FIG. 2 is shown as a single cloud platform, the system of FIG. 2 may alternatively be implemented in an environment having multiple cloud platforms as shown in FIG. 5. In one exemplary implementation, both mobile core networks 103 and 105 are deployable as cloud instances in cloud platform 502. In another exemplary implementation, mobile core networks such as 103, 105 and 501 may be deployed in different cloud platforms 502 and 504. Similarly, enterprise cloud computing infrastructures 104 and 106 may be deployed in the same or different cloud platforms 506 and 508. A software-defined mobile core network deployable in different cloud platforms may provide additional flexibility to a particular enterprise. For example, if an enterprise already has an existing cloud computing infrastructure in a particular cloud platform, it may choose that same cloud platform for the deployment of its mobile core network, such that the virtual cross-connect between the mobile core network and the cloud computing infrastructure may also be implemented in the same cloud platform. The various cloud platforms mentioned above may include, but are not limited to, Amazon's (trademark) AWS, Microsoft's (trademark) Azure, Google (trademark) Cloud, and IBM (trademark) Cloud.

[0025] The mobile core network described above may include various functional blocks for mobile service management, data processing and routing. An example is shown in FIG. 6. The mobile core network 602 in FIG. 6 may 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 may communicate with the RNC 126, for example, according to the S6a Diameter protocol. The mobile core network may further include a Spanning Tree Protocol (STP) processing component for processing signaling information according to the SS7 signaling protocol. The mobile core network may further include packet processing components, such as a Packet Gateway (PGW) 614 and corresponding multiplexer 612, which communicate with the RNC 126, for example, via the S5 / S8 / GPRS Tunneling Protocol (GTP) and with the external IP network 160 via the SGi protocol.

[0026] FIG. 6 is shown by way of example only. Those skilled in the art will appreciate that the mobile core network 602 may include many other components not shown in FIG. 6. For example, the mobile core network 602 may include other components for processing voice information not in the form of data packets and components for interfacing with the PSTN. The configuration of the mobile core network 602 may be guided by various underlying standards for 2G, 3G, LTE, 4G and 5G mobile communication systems. These other configurations may differ significantly from the configuration shown in FIG. 6. However, the cloud-implemented software-defined mobile core network and the underlying principles disclosed herein are applicable to these other mobile core configurations.

[0027] Various components of the software-based mobile core network can be implemented as containers in the cloud. Specifically, each of the above processing components can be developed and packaged as an application including all the necessary software stacks and its dependencies (e.g., libraries). Such application packages can be deployed as containers in the cloud. Each application can be deployed as multiple independent instances of containers running on an underlying computer in the cloud that shares the same host operating system and its kernel. Another alternative implementation of the mobile core network components in the cloud can be based on virtual machines. Compared to virtual machine architectures, container implementations are generally lightweight, resource-saving, and robust. Because containers are lightweight, they can be instantiated quickly and efficiently. Thus, as the service volume and system resource requirements of an application (e.g., a mobile core functional component) increase in real time, new instances of containers can be instantiated as needed to meet client demands, thereby providing the desired elasticity to the software-defined mobile core network. Similarly, if the service volume of an application decreases, the excess container can be quickly and efficiently removed with its user traffic redistributed to the remaining containers of the application. Tools such as Docker™ can be used to design and package software stacks for containers.

[0028] In addition to various instances of containers for different processing components, the mobile core network implementation may also include instances of other programs or daemons implemented in the cloud, designed to perform routing functions within the mobile core network, for example at the data link layer and / or network layer of the OSI model. Thus, the cloud implementation of the mobile core network may include a mix of containers and daemons, as shown in FIG. 7. In FIG. 7, the routing daemon is represented at 710. Container 704 represents multiple instances of one functional component (e.g., PGW container) of the multiple functional components of the mobile core network. Container 706 represents multiple instances of another functional component (e.g., HLR) of the multiple functional components of the mobile core network. The routing daemon may be implemented to facilitate the function of a particular container or all container instances of multiple container instances of the same component, or to facilitate communication between containers of the same component or between containers of different components. A group of containers may be organized as a tanker.

[0029] FIG. 8 further illustrates an example configuration of containers organized as tankers to implement a mobile core network. As shown in FIG. 8, signals from the RNC are intercepted by exchange connectors 802 and 210, multiplexed according to signal type (including but not limited to S6a diameter signals, SS7 signals, S5 / S8GTP signals, as shown at 830), and then destined for a mobile core network implemented as cloud containers 808 and 810 organized as tankers 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 within the clouds. Other cloud instances 830 (e.g., SMS proxy instances, over-the-air (OTA) instances, and HA shared storage instances) can also be further implemented to support the functions of the mobile core network.

[0030] Figure 9 shows details for implementing data routing functions in network layers II and III (data link layer and network layer) in the cloud between the mobile core network and other networks on or off the cloud. As shown in Figure 9, the example data routing can be deployed in the cloud as multiple levels of routers including core routers (CR) 910 and 912, virtual cloud routers (VCLR) 920 and 922, VRF (Virtual Routing and Forwarding) Aware Tanker Router (VATR) 930, and virtual CE router (VCER) 950 interconnected by various communication interfaces as shown in Figure 9. These multi-level virtual routers are connected to a virtual mobile core network 902 and a virtual multiprotocol label switching (MPLS) private cloud 904.

[0031] The various multi-level routers in FIG. 9 may be implemented as cloud daemons rather than containers. In particular, public cloud service providers do not generally allow users to bring their public IP space into the actual cloud container instances. 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 virtualization using virtual machines in a private hardware cluster rather than using containers, the IP address space can be more easily customizable. The multi-layer IP routing scheme in FIG. 9 may be used in a container implementation to replace the limitations of IP address space in the public cloud.

[0032] These routers form a cloud cluster and together with the 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 actual services may not be attached to these routers. The VATR may be a VRF-aware cloud instance and provide services attached to a specific VRF. The VCER may not be VRF-aware and may be designed to provide services that can use anycast private / public IPs. The VCER may not be tied to a specific VPC and may exist in multiple instances within the network.

[0033] The VCLR essentially plays the role of a PE from the core routers. Therefore, adding or removing any service would only require changes on the VCLR. No changes are required from the core side. Also, as shown in Figure 9, only two Generic Routing Encapsulation (GRE) tunnels from the VCLR to the core routers are sufficient to provide the service in a highly available manner. The use of MPLS between the VCLR and the core routers and the encapsulation of MPLS in the GRE tunnels also eliminates the need to have a tunnel per VRF (non-VRF-Lite). The VCLR connects to other service instances (such as VATR, and WL tankers, and VCER) through GRE tunnels, without MPLS, on the basis of one tunnel per VRF (VRF Lite).

[0034] MPLS VPN 904 may be implemented in the cloud, providing a private network with global reach across all major cloud platforms (e.g., Google, AWS, Microsoft, IBM). Thus, enterprise wireless IP traffic terminating at the PGW in the private mobile core can be privately routed to the enterprise's remote IP networks. These remote sites can be physical sites or, as previously described, virtual networks inside the cloud. When the remote sites are virtual networks in the cloud, the routing instances and MPLS VPN cloud 904 shown in FIG. 9 essentially act as virtual cross connects shown as 207 and 208 in FIG. 2 above. The MPLS VPN cloud 904 further provides routing to other cloud clusters in the mobile core and routing instances such as the cloud clusters shown in FIG. 9.

[0035] FIG. 10 illustrates an exemplary manner in which a private virtualized mobile core network and associated virtualized IP routing functions can be offered as a configurable service. A service provider can deploy a global MPLS VPN cloud 904. The service provider may further provide a service configuration interface, such as a web interface 1010, to potential users (such as enterprise users). The users can use this web interface to issue service requests to the mobile core and routing server 1002 so that the service provider can instantly deploy a private mobile core and virtual router 1030 for the users in the cloud. The users can also modify, configure, and provision the deployed private mobile core and router 1030 from the web interface 1010 via an application program interface (API) 1011. Subscription, allocation, and management of cloud resources can be provided by a server 1020 from a cloud service provider. A request for cloud resources required to deploy the private mobile core and router 1030 is processed by the service provider and sent to the server 1020 as indicated by arrow 1013. Alternatively, as indicated by arrow 1015, interaction with server 1020 may occur directly from the user.

[0036] Finally, FIG. 11 illustrates an exemplary computer system 1100 for implementing any of the computing components and devices required for the above disclosure. The computer system 1100 can include a communication interface 1102, a system circuit 1104, an input / output (I / O) interface 1106, a storage 1109, and a display circuit 1108 that generates a machine interface 1110 for local or remote display, for example in a web browser running on a local or remote machine. The machine interface 1110 and the I / O interface 1106 can include a GUI, a touch display, voice recognition or facial recognition input, buttons, switches, speakers, or other user interface elements. Further examples of the I / O interface 1106 include microphones, video and still image cameras, headset and microphone input / output jacks, universal serial bus (USB) connectors, memory card slots, and other types of inputs. 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.

[0037] The communication interface 1102 may include a wireless transmitter and receiver ("transmitter / receiver") 112 and an optional antenna 1114 used by the transmit and receive circuitry of the transceiver 1112. The transceiver 1112 and antenna 1114 may support Wi-Fi network communications, for example, based on any version of IEEE 802.11, e.g., 802.11n or 802.11ac. The communication interface 1102 may include a wired transceiver 1116. The wired transceiver 1116 may provide a physical layer interface for any of a wide variety of communication protocols, such as Ethernet, Data Service Interface Standard over Cable (DOCSIS), Digital Subscriber Line (DSL), Synchronous Optical Network (SONET), or other protocols.

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

[0039] The system circuitry 1104 may include any combination of hardware, software, firmware, or other circuitry. The system circuitry 1104 may be implemented, for example, with one or more systems on a chip (SoC), application specific integrated circuits (ASICs), microprocessors, discrete analog and digital circuits, and other circuits. The system circuitry 1104 is part of an implementation of any desired functionality associated with the components of the implementations described above. By way of example only, the system circuitry 1104 may include one or more instruction processors 1118 and memory 1120. The memory 1120 stores, for example, control instructions 1126 and an operating system 1124. In one implementation, the instruction processor 1118 executes the control instructions 1126 and the operating system 1124 to perform any desired functionality associated with the various components for the implementations described above.

[0040] Thus, the above-described implementations provide a fully virtualized software-defined mobile core network that is deployed as container instances and daemons in one or more public cloud platforms. The mobile core network can be deployed with a multi-layer virtual IP routing network that is also deployed in the public cloud platform as a cloud daemon to replace the IP address space of the underlying hardware components of the cloud platform and to route data traffic received and processed by the mobile core to other networks. These other networks include, but are not limited to, other private cloud networks, other independent cloud instances or applications, other fixed IP networks (e.g., fixed wide area networks), and public networks such as the public Internet and PSTN. In some implementations, mobile data can be received by the mobile core and then routed within the private cloud to remote global sites without exposing any of the communication legs to the public Internet, avoiding the need to include additional overlays of security tunneling. The deployment of the mobile core and virtual routing components in the public cloud platform can be integrated and offered to enterprises as a service. Thus, enterprises can instantly customize, deploy, configure, provision, and maintain their mobile core and IP routing networks through API interfaces. The companies thus essentially act as their own global mobile carriers.

[0041] The methods, devices, processes and logic described above can be implemented in many different ways and with many different combinations of hardware and software. For example, all or part of the implementation can be a circuit including an instruction processor such as a central processing unit (CPU), microcontroller, or microprocessor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a field programmable gate array (FPGA), or a circuit including discrete logic or other circuit components including analog circuit components, digital circuit components, or both, or any combination thereof. The circuit may include, for example, discrete interconnected hardware components, and / or may be combined on a single integrated circuit die, distributed across multiple integrated circuit dies, or implemented in a multi-chip module (MCM) of multiple integrated circuit dies in a common package.

[0042] The circuitry may further include or access instructions for execution by the circuitry. The instructions may be stored in a tangible storage medium other than a transient signal, such as a flash memory, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM), or a magnetic or optical disk, such as a compact disk read only memory (CDROM), a hard disk drive (HDD), or other magnetic or optical disk, or in other machine-readable media. An article of manufacture, such as a computer program product, may include a storage medium and instructions stored thereon, which, when executed by the circuitry in the device, may cause the device to perform any of the processes described above or illustrated in the figures.

[0043] The implementation may be distributed as a circuit across multiple system components such as multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases and other data structures may be stored and managed separately, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many different ways, including as data structures such as linked lists, hash tables, arrays, records, objects or implicit storage mechanisms. Programs may be parts of a single program (e.g., subroutines), separate programs distributed across several memories and processors, or may be implemented in many different ways, such as libraries, such as shared libraries (e.g., dynamic link libraries (DLLs)). A DLL may, for example, store instructions that, when executed by a circuit, perform any of the operations described above or illustrated in the figures.

Claims

1. 1. A method for routing information, comprising: Intercepting first data from a wireless terminal device at a radio network controller; Redirecting the first data to a private, software-defined, fully virtualized mobile core and data routing network deployed in a public cloud platform, the mobile core and data routing network including a mix of multiple cloud instances of data processing containers and multiple cloud data routing daemons; routing the first data through the plurality of cloud instances of data processing containers to a first private virtual packet gateway implemented as an instance of the plurality of cloud instances of data processing containers in the mobile core and 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 an independent cloud application terminated at a second packet gateway via a private virtual cross connect implemented in the public cloud platform; and providing the wireless terminal device with access to the independent cloud application.

2. The method of claim 1 , wherein the data from the wireless terminal device is received by a radio access network including at least one base station and the radio network controller before being intercepted.

3. The method of claim 1 , wherein the private virtual cross connect comprises a private virtual cloud network for routing multi-protocol label switching messages.

4. Intercepting second data from the wireless terminal device at the radio network controller; redirecting the second data to the mobile core and data routing network; addressing the second data to the first private virtual packet gateway; Routing the second data from the first private virtual packet gateway to the plurality of cloud data routing daemons; 2. The method of claim 1, further comprising: routing the second data from the plurality of cloud data routing daemons to an off-cloud remote IP network via a private virtual cloud network for routing multi-protocol label switching messages.

5. Intercepting second data from the wireless terminal device at the radio network controller; redirecting the second data to the mobile core and data routing network; Destining the second data to the first private virtual packet gateway; and Routing the second data from the first private virtual packet gateway to the plurality of cloud data routing daemons; 2. The method of claim 1, further comprising: routing the second data from the plurality of cloud data routing daemons to an off-cloud mobile core network implemented using dedicated hardware components.

6. Intercepting second data from the wireless terminal device at the radio network controller; redirecting the second data to the mobile core and data routing network; Destining the second data to the first private virtual packet gateway; and Routing the second data from the first private virtual packet gateway to the plurality of cloud data routing daemons; 2. The method of claim 1, further comprising: routing the second data from the plurality of cloud data routing daemons to another private software-defined fully virtualized mobile core implemented in the public cloud platform via a private virtual cloud network for routing multi-protocol label switching messages.

7. 10. The method of claim 1, further comprising automatically adjusting the mobile core and data routing network in terms of number of container instances or number of data routing daemons in response to utilization of cloud computing resources underlying the mobile core and data routing network.

8. 1. A private, software-defined, fully virtualized mobile core and data routing network deployed on a public cloud platform, comprising: a first set of instances of the cloud container configured to receive data from the wireless terminal device via the radio network controller; a second set of cloud container instances configured to implement a set of mobile core network functions by processing the data received by the first set of cloud container instances from the radio network controller; a third set of cloud container instances; and a set of routing daemons deployed on the public cloud platform; the third set of cloud container instances act as a packet gateway to route the data processed by the second set of cloud container instances to the set of routing daemons deployed in the public cloud platform; A mobile core and data routing network, wherein the set of routing daemons is configured to route the data received at the set of routing daemons to a private cloud network configured to route messages in accordance with Multi-Protocol Label Switching.

9. 9. The mobile core and data routing network of claim 8, wherein the set of routing daemons includes a subset of core routers, a subset of virtual routing and forwarding (VRF) aware routers, and a subset of non-VRF aware routers.

10. 10. The mobile core and data routing network of claim 9, wherein connectivity between the subset of core routers and the subset of non-VRF-aware routers is based on Multi-Protocol Label Switching encapsulated by Generic Routing Encapsulation (GRE).

11. 10. The mobile core and data routing network of claim 8, further comprising the private cloud network further configured to route the data to an independent cloud application terminated in another packet gateway.

12. 10. The mobile core and data routing network of claim 8, further comprising the private cloud network further configured to route the data to an off-cloud remote IP network.

13. 10. The mobile core and data routing network of claim 8, further comprising the private cloud network further configured to route the data to an off-cloud mobile core network implemented using dedicated hardware components.

14. 10. The mobile core and data routing network of claim 8, further comprising the private cloud network further configured to route the data to another private, software-defined, fully virtualized mobile core implemented in the public cloud platform.

15. a plurality of distributed sensors, each integrated with a wireless subscriber identity module (SIM) having a plurality of remotely activatable international mobile subscriber identity (IMSI) profiles; a private software-defined fully virtualized mobile core deployed in a public cloud platform for receiving data collected by the plurality of distributed sensors via a wireless access network to generate output data, the private software-defined fully virtualized mobile core including a mix of multiple instances of data processing containers for processing the received data; A plurality of private routing daemons deployed on the public cloud platform; a private cloud network configured to route messages according to multi-protocol label switching, A private wireless sensor network, wherein the output data of the mobile core is routed from the plurality of private routing daemons to the private cloud network, and from the private cloud network to a private cloud application.

16. The private wireless sensor network of claim 15 , wherein the plurality of private routing daemons includes a subset of core routers, a subset of virtual routing and forwarding (VRF) aware routers, and a subset of non-VRF aware routers.

17. 17. The private wireless sensor network of claim 16, wherein connectivity between the subset of core routers and the subset of non-VRF-aware routers is based on Multi-Protocol Label Switching encapsulated by Generic Routing Encapsulation (GRE).

18. 16. The private wireless sensor network of claim 15, wherein second output data from the mobile core is routed by the multiple private routing daemons to the private cloud network and further routed from the private cloud network to an off-cloud remote IP network.

19. 16. The private wireless sensor network of claim 15, wherein second output data from the mobile core is routed by the multiple private routing daemons to the private cloud network and from the private cloud network to an off-cloud mobile core network implemented using dedicated hardware components.

20. 16. The private wireless sensor network of claim 15, wherein second output data from the mobile core is routed by the multiple private routing daemons to the private cloud network and further routed from the private cloud network to another private software-defined fully virtualized mobile core implemented in the public cloud platform.

Images