Secure virtual private mobile and IP network in cloud

Abstract

The present disclosure relates to a fully software-defined, fully virtualized and customizable mobile communication platform deployed on a public cloud infrastructure. Such a mobile network allows end-to-end control of automatic and programmed deployment and configuration of mobile network components. The following embodiments can efficiently create and deploy a real global private end-to-end software defined network (SDN) immediately for 3G, 4G, LTE, and 5G mobile communications starting from the beginning. A user can effectively serve as a mobile operator of the user, and available functions can be customized through a programmed interface.

Description

[0001] This application is a divisional application of patent application filed on February 14, 2022, with application number 202080057532.2 and title "Secure Virtual Private Mobile and IP Networks in the Cloud". Technical Field

[0002] This disclosure relates to a fully software-defined, fully virtualized, customizable mobile communication platform deployed on a public cloud infrastructure. Background Technology

[0003] Mobile networks may include radio access networks interconnected with backhaul circuits and mobile core networks. Mobile networks can further communicate with other data networks via the public Internet. Traditional mobile core networks rely heavily on fixed, custom-designed hardware components to perform the functions required for end-to-end communication. These hardware-driven mobile core networks are rigid, inflexible, and lack resilience in deployment and subsequent provisioning and maintenance. With the increasing convergence of various previously different types of network traffic, such as voice, messaging, and data, traditional mobile core networks may be simplified to the point that the entire mobile core network can be virtualized and implemented in software, without relying on dedicated hardware components. Summary of the Invention

[0004] This disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communications platform deployed on 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 in a highly resilient manner on the fly and can be further configured and reconfigured automatically and programmatically during operation. The embodiments disclosed herein effectively provide a platform capable of creating and deploying truly private global end-to-end software-defined networks (SDNs) for 3G, 4G, LTE, and 5G mobile communications from scratch, both instantly and dynamically. Users of this platform essentially act as their own mobile operators, allowing them to customize the available functionality through a programming interface.

[0005] In one embodiment, a method for routing information through such a mobile network is disclosed, performed by a software-defined and virtualized mobile core and data routing network deployed in a cloud platform. The method may include receiving first data from a radio access network, the first data originating from a wireless terminal device, the first data source being encapsulated by a multi-tiered IP address space. The virtualized mobile core and data routing network includes one or more cloud instances of each of one or more data processing containers and a multi-tiered routing program deployed in the cloud platform. Each of the one or more data processing containers corresponds to one or more mobile core functions, and the number of cloud instances is adjusted according to the service volume level of the one or more mobile core functions. The method may further include transposing the multi-tiered IP address space to route the first data using the one or more cloud instances of each of the one or more data processing containers and the multi-tiered routing program in the cloud platform.

[0006] In another embodiment, a circuit in a cloud platform is disclosed for implementing a software-defined and virtualized mobile core and data routing network. This circuit can be configured to implement: a first set of cloud container instances configured to receive data from wireless terminal devices via a radio access network; a second set of cloud container instances configured to implement a set of mobile core network functions by processing data received from the radio access network by the first set of cloud container instances; a third set of cloud container instances; and a set of multi-level virtual routers. The circuit can be further configured to implement the third set of cloud container instances as a packet gateway for routing data processed by the second set of cloud container instances to the multi-level virtual routers. The circuit can be further configured to implement the multi-level virtual routers to route data received from the multi-level virtual routers. The circuit can be further configured to implement each of the cloud containers to perform one or more mobile core functions, the number of cloud instances in the first set, second set, or third set of cloud container instances being adjusted according to the service load level of the one or more mobile core functions.

[0007] In another embodiment, a communication network is disclosed. This communication network may include a software-defined and virtualized mobile core deployed in a cloud platform for receiving and processing data collected by multiple distributed sensors via a wireless access network to generate output data. The virtualized mobile core is configured to implement one or more instances of each of one or more data processing containers to process the received data. Each of the multiple distributed sensors integrates a Wireless Subscriber Identity Module (SIM) with multiple remotely activated International Mobile Subscriber Identity (IMSI) profiles. The communication network may further include a multi-tiered virtual router deployed in the cloud platform for routing the data collected by the multiple distributed sensors. The one or more instances of each of the one or more data processing containers are configured to perform one or more mobile core functions, the number of cloud instances being adjusted according to the service volume level of the one or more mobile core functions. Attached Figure Description

[0008] Figure 1 An example architecture of a traditional mobile communication platform based on dedicated hardware components is shown to implement the functions of a mobile core network; Figure 2 An example architecture of a mobile communication platform is shown, in which the mobile core is fully defined in software and fully virtualized in a public cloud infrastructure. Figure 3 This demonstrates a secure and virtual cross-connection in the cloud that can be implemented between a mobile core network and other independent cloud instances, which can be virtualized in a public cloud infrastructure. Figure 4 The diagram illustrates a communication path between a mobile device and a cloud instance via a traditional mobile core network implemented in hardware, showing the connection leg exposed to the insecure public internet; Figure 5 This illustrates an example of implementing mobile core network and virtual cross-connection to other cloud instances in an environment involving multiple different cloud platforms; Figure 6 Exemplary functional components of a mobile core network for signaling, data processing, and information routing are shown. Figure 7 An exemplary implementation of a mobile core network as a hybrid of containers and daemons deployed in a public cloud infrastructure is shown; Figure 8 Another exemplary implementation of a mobile core network as a container and box is shown; Figure 9An exemplary routing layer, implemented as a daemon or container in the cloud, is shown to facilitate end-to-end communication via a virtualized mobile core. Figure 10 An exemplary scheme is shown for providing services that enable automated deployment and provide private mobile core networks and virtual cross-connections to other standalone cloud instances; Figure 11 An exemplary implementation of a computer device is shown, which may serve as underlying hardware in the cloud or as a user terminal device. Detailed Implementation

[0009] This disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communications platform deployed on 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 in a highly resilient manner on the fly and can be further configured and reconfigured automatically and programmatically during operation. The embodiments disclosed herein effectively provide a platform capable of creating and deploying truly private global end-to-end software-defined networks (SDNs) for 3G, 4G, LTE, and 5G mobile communications from scratch, both instantly and dynamically. Users of this platform essentially act as their own mobile operators, allowing them to customize the available functionality through a programming interface.

[0010] Figure 1 An example system architecture of a mobile communication network 100 is illustrated. The mobile communication network 100 may include user equipment (UE) 103 communicating with a mobile core network (CN) 107 via a radio access network (RAN) 105. The user equipment 103 may be a mobile or fixed terminal device, including but not limited to mobile phones, tablets, personal digital assistants (PDAs), wearable devices, distributed sensors, Internet of Things (IoT) terminals, desktop computers, and laptops, all configured to access RAN 105 via a wireless connection. These example terminal devices... Figure 1 The value is specified as 140-152.

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

[0012] like Figure 1 As further shown, 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, signaling, information routing, and signaling gateway functions individually or in a fused manner (e.g., all as packets) according to a predefined transport and signaling protocol stack for voice, messages, and / or packets. The mobile core network 101 can further transmit or receive data to or from other networks 109. For example, as... Figure 1 As 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, etc. Therefore, signals can be routed between user equipment 140-152 and the Internet 160 and / or PSTN 162 via the mobile core network. Signals can be further routed between one user equipment and another via base stations, RNCs, and the mobile core network.

[0013] Base stations, RNCs, and the mobile core network are collectively referred to as a mobile network, which can be installed and operated by a single wireless operator or vendor. Different wireless operators can operate their own mobile networks independently. Users can subscribe their terminal devices to a specific wireless operator to access that operator's mobile network. When a user's terminal moves to a geographical area accessible only to base stations of other wireless operators, the user's terminal can still be allowed to connect to those 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 equipment 140-150 can be subscribed to by the first wireless operator, while user equipment 152 can be subscribed to by the second wireless operator. Among user equipment 140-150 subscribed to by the first wireless operator, user equipment 140-144 can be located within the signal coverage area of ​​base stations 120 and 122 of the first wireless operator, and therefore can access the mobile network of the first wireless network without roaming. However, user equipment 146-150, also subscribed to by 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 belonging to the second wireless operator. Therefore, user equipment 146-150 can roam on the mobile network provided by the second wireless operator. Signals received from user equipment 146-150 and by base station 124 and corresponding RNC 128 can be transmitted by the second wireless operator to the mobile core network 101 of the first wireless operator via a switching node (as shown in node 131). The signal can then be processed by the mobile core network 101 and routed to other wireless user equipment (such as user equipment 140-144), IP networks (such as intranet 160), PSTN 162, etc., regardless of the signal's destination.

[0014] The mobile core network 101 belonging to the first wireless operator can further transmit signals to the mobile core network belonging to the second wireless operator, such as... Figure 1 As shown in 102, this allows user equipment (e.g., user equipment 140-144) subscribed to the first wireless operator to communicate with user equipment 152 subscribed to the second wireless operator. In this case, communication information can be passed from mobile core network 101 to mobile core network 102 via switching nodes, as shown by arrows 133 and node 135. This communication information can be further transmitted to user equipment 152 subscribed to the second wireless operator via mobile core network 102, RNC 128, and base station 124. Similarly, user equipment 152 subscribed to the second wireless operator can send communication information to user equipment (e.g., user equipment 140-144) subscribed to the first wireless operator via a reverse path, i.e., along base station 124, RNC 128, mobile core network 102, mobile core network 101, RNC 126, and base station 120 or 122.

[0015] Figure 1 The mobile core networks 101 and 102 can be implemented as dedicated custom hardware components for performing various network functions, such as Figure 1The equipment racks and cabinets 111 and 113 within the mobile core networks 101 and 102 shown. Alternatively, the mobile core networks 101 and 102 can be implemented and defined entirely in software and fully virtualized, as... Figure 2 As shown. In Figure 2 In the specific embodiment shown, the radio access network portion 105 of the mobile network remains connected to... Figure 1 The implementation scheme is the same, but the mobile core network 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 a software instance rather than a dedicated equipment rack. The cloud-based mobile core networks 203 and 205 can further communicate with other external cloud networks 109, including but not limited to IP network 160, PSTN system 162 and other external cloud mobile core networks 230.

[0016] like Figure 1 As shown, implementing mobile core networks 101 and 102 in dedicated hardware components faces several drawbacks and limitations, while... Figure 2 As shown, fully virtualized mobile core networks 203 and 205 in the cloud offer several advantages. Specifically, implementations of mobile core networks based on dedicated and custom hardware are inflexible, lack resilience, and are difficult to deploy, modify, reconfigure, expand, and upgrade. For example, expanding and extending the capacity of a hardware-based mobile core network typically involves replacing expensive equipment and often requires excessively long installation and testing times. Utilizing various hardware components in different parts of such a core network, even if initially deployed with careful consideration, can become unbalanced as user scenarios change, leading to decreased efficiency of the deployed hardware network equipment. Upgrades are often limited unless outdated network equipment is replaced. Because hardware-based network equipment requires very high capital expenditures, they are typically deployed and configured by large wireless operators serving large customer bases. Therefore, network configurations often cannot be flexibly customized to the needs of individuals or groups of users. Such network configurations are often rigid and static, and implementing network configuration automatically and programmatically can be very difficult.

[0017] However, virtualized mobile core networks are more agile, flexible, and resilient, and can be deployed directly, especially when 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 immediately in the cloud without requiring direct capital investment in expensive dedicated hardware components. Therefore, the barrier to deployment is low; deploying a mobile core is as simple as clicking a mouse. Similarly, modifications, expansions, and upgrades to already deployed virtualized mobile core networks involve only software updates and cloud resource reconfiguration. The deployment, maintenance, upgrades, replacements, and configurations of the underlying hardware resources are handled by the cloud platform and service providers, independent of and decoupled from the software-defined mobile core network.

[0018] Due to the flexibility and resilience offered by software-defined mobile core networks in the cloud, organizations, enterprises, etc. (referred to as "enterprises") can act as their own wireless operators. In other words, an enterprise, for example, can choose to deploy its own private global mobile core network instead of sharing a mobile core network with others. In one scenario, the enterprise may want to connect its employees through its private global mobile core network. In another scenario, the enterprise may want to connect wireless sensors distributed across different geographical locations to a sensor network through its private mobile core network. The enterprise can further deploy its own global mobile core network to integrate its mobile employees and sensors, forming a combined global private network. Regardless of the specific application requirements, such a private mobile core network can be immediately deployed and configured as a cloud instance, with initial cloud resource allocation based on the number of users (or sensors) and the enterprise's overall mobile communication needs and characteristics. The allocation of the underlying cloud resources of the private mobile core network can be further dynamically and in real-time provided after the initial deployment, based on the enterprise's communication patterns as a function of time. For example, depending on the nature of the enterprise's business and the characteristics of user communications, the enterprise's private mobile core network may be used more frequently during specific time windows of a day, specific weeks of a month, and / or specific months or seasons of a year. Therefore, private mobile core networks implemented in the cloud can provide real-time elasticity in resource allocation and can leverage cloud configuration tools and interfaces already developed and provided by cloud service providers for the dynamic and predictive configuration and allocation of cloud computing resources. Consequently, such private mobile core networks can reduce resource imbalances and underutilization, providing a more efficient mobile communication system. Furthermore, because these private mobile core networks can operate independently of other mobile core deployments, they can be easily customized and configured automatically in software or at any chosen time.

[0019] like 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.

[0020] 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.

[0021] 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 2These are labeled as cloud instances A 204 and B 206, independent of the mobile core network. Enterprises may wish to provide their mobile users with seamless access to these cloud infrastructures. Because the mobile core network and one or more cloud infrastructures are implemented as cloud instances, communication between them can be routed in the cloud, facilitated by network processing and routing daemons also implemented in the cloud, which act as... Figure 2 The virtual cross-connects 207 and 208 shown in the diagram are functional. Signals and information routed within the cloud can be protected by cloud security mechanisms such as Generic Routing Encapsulation (GRE, similar to IPSec). Therefore, a company's mobile users can access cloud computing infrastructure through a virtual mobile core network without exposing their communications to the public internet.

[0022] Figure 3 A specific explanation was provided. For example... Figure 3 As shown, enterprise user 302 communicates with radio access network 304 via private over-the-air communication channel 320. Radio access network 304 communicates with private mobile core network 308 in the cloud via private physical connections 312, 314, and 322 through switch 306. Communication between the mobile core network and enterprise cloud computing infrastructure 310 can be based on private and secure routing in the cloud, as shown in 312 and 316. At any time, neither communication leg between user equipment 302 and enterprise cloud computing infrastructure 310 is exposed to non-private communication channels. Therefore, Figure 3 The implementation and cloud-based mobile core network provide a secure connection between user equipment 302 and cloud computing infrastructure 310, leveraging basic security features implemented in the cloud and eliminating the need for additional tunneling technologies.

[0023] Such security may not be easily achieved in traditional systems using off-cloud mobile cores, such as Figure 4 As shown in system 400. Figure 4 As shown, when mobile core networks 402 and 404 are implemented outside the cloud (e.g., as a hardware-based mobile core network implementation), accessing cloud computing infrastructures 204 and 206 from mobile core networks 402 and 404 will require traversing the public internet 406. Therefore, communication between user equipment 140-152 and cloud computing infrastructures 204 and 206 may be exposed to an insecure communication channel involving the public internet 406, without any cloud-based security measures.

[0024] Although Figure 2 The cloud platform 202 is described as a single cloud platform, but Figure 2 The system can be alternatively implemented in environments with multiple cloud platforms, such as... Figure 5As shown in the diagram. In one exemplary embodiment, mobile core networks 103 and 105 can be deployed simultaneously as cloud instances of cloud platform 502. In another exemplary embodiment, mobile core networks such as 103, 105, and 501 can be deployed in different cloud platforms 502 and 504. Similarly, enterprise cloud computing infrastructures 104 and 106 can be deployed on the same or different cloud platforms 506 and 508. The ability to deploy software-defined mobile core networks on different cloud platforms can provide greater flexibility for specific enterprises. For example, if an enterprise already has existing cloud computing infrastructure on a particular cloud platform, it can choose the same cloud platform to deploy its mobile core network, thus enabling virtual cross-connections between the mobile core network and the cloud computing infrastructure within 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.

[0025] The mobile core network discussed above can include various functional blocks for mobile service management, data processing, and routing. Figure 6 An example is shown in the figure. Figure 6 The mobile core network 602 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 information with the RNC 126 according to, for example, 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 a corresponding multiplexer 612, which communicate with the RNC 126 via, for example, the S5 / S8 / GPRS Tunneling Protocol (GTP) and with the external IP network 160 via the SGi protocol.

[0026] Figure 6 This is merely shown as an example. Those skilled in the art will understand that the mobile core network 602 may include... Figure 6 Many other components are not shown. For example, the mobile core network 602 may include additional 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 of 2G, 3G, LTE, 4G, and 5G mobile communication systems. These additional configurations may be related to... Figure 6 The configurations described in the document differ significantly. However, the software-defined mobile core network implemented in the cloud and the basic principles disclosed herein are applicable to those other mobile core configurations.

[0027] The various components of a software-defined mobile core network can be implemented as containers in the cloud. Specifically, each of the aforementioned processing components can be developed and packaged as an application, including all necessary software stacks and their dependencies (e.g., libraries). This application package can be deployed as a container in the cloud. Each application can be deployed as multiple independent container instances, running on the underlying computers in the cloud, sharing 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, container implementations are typically lightweight, resource-efficient, and robust. Because they are lightweight, containers can be instantiated quickly and efficiently. Therefore, when the service volume and system resource requirements of an application (e.g., mobile core functional components) increase over a period of time, new instances of containers can be instantiated as needed to meet customer demand, providing the resilience required for a software-defined mobile core network. Similarly, when the service volume of an application decreases, excess containers can be quickly and efficiently removed, and their user traffic is redistributed to the remaining containers of the application. The container's software stack can be designed and then packaged using tools such as Docker™.

[0028] 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, designed to perform routing functions of the mobile core network at, for example, the data link and / or network layers of the OSI model. Therefore, a cloud implementation of a mobile core network can include a hybrid of containers and daemons, such as... Figure 7 As shown. In Figure 7 In this context, the routing daemon is represented by 710. Container 704 represents multiple instances of one of the multiple functional components of the mobile core network (e.g., a PGW container). Container 706 represents multiple instances of another of the multiple functional components of the mobile core network (e.g., an HLR). Routing daemons can be implemented to facilitate the functionality of a specific container or all multiple container instances of the same component, or they 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 box.

[0029] Figure 8 An exemplary configuration of a container within a box is further illustrated for an organization implementing a mobile core network. (Example:) Figure 8As shown, signals from the RNC can be intercepted by switching connectors 802 and 210, multiplexed according to signal type (as shown in 830, including but not limited to S6a Diameter signals, SS7 signals, and S5 / S8 GTP signals), and then directed to the mobile core network implemented as cloud containers 808 and 810, which are organized into boxes 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 via virtual cross-connections implemented in the cloud. Other cloud instances 830 (e.g., SMS agent instances, over-the-air (OTA) instances, and HA shared storage instances) can be further implemented to facilitate the functionality of the mobile core network.

[0030] Figure 9 Further details are shown regarding the implementation of data routing functions at Network Layers II and III (Data Link Layer and Network Layer) between the mobile core network and other networks in the cloud or on-premises. Figure 9 As shown, the example data route can be deployed as a multi-tiered router in the cloud, including Core Routers (CR) 910 and 912, Virtual Cloud Routers (VCLR) 920 and 922, Virtual Router and Forwarder (VRF) Awareness Box Router (VATR) 930, and Virtual CE Router (VCER) 950, such as... Figure 9 As shown, they are interconnected through various communication interfaces. These multi-level virtual routers are connected to the virtual mobile core network 902 and the virtual multiprotocol label switching (MPLS) private cloud 904.

[0031] Figure 9 Various multi-tiered routers in a cloud environment can be implemented as cloud daemons rather than containers. Specifically, public cloud service providers typically do not allow users to bring their own public IP space within actual cloud container instances. To perform IP routing between PGWs, these virtual routers can be implemented as programs (daemons) deployed in the cloud. In visual alternative implementations based on using virtual machines instead of containers within private hardware cloud servers, the IP addressing space may be easier to customize. Figure 9 Multi-tiered IP routing schemes can be used in container implementations to alleviate IP addressing space limitations in the public cloud.

[0032] These routers form cloud clusters and, together with mobile core container instances, form enterprise-specific Virtual Private Clouds (VPCs). VCLRs 920 and 922 only function as routers, and no actual services can be attached to them. VATRs can be VRF-aware cloud instances and provide services attached to a specific VRF. VCERs may not be VRF-aware and may be designed to provide services with the ability to use arbitrary broadcast private / public IPs. VCERs may not need to be bound to a specific VPC, and multiple instances can exist in the network.

[0033] The VCLR essentially acts as a PE (Preinstallation Environment) from the core router. Therefore, adding or removing any service will only require changing the VCLR; no changes will be needed from the core side. Additionally, as... Figure 9 As shown, only two Generic Routing Encapsulation (GRE) tunnels from the VCLR to the core router are sufficient to provide service in a highly available manner. Using MPLS between the VCLR and the core router, and encapsulating the MPLS within GRE tunnels, also eliminates the requirement for one tunnel per VRF (non-VRF Lite). With one tunnel per VRF (VRF Lite), the VCLR connects to other service instances (such as VATR, WL-tanker, and VCER) via GRE tunnels, without using MPLS.

[0034] MPLS VPN 904 can be implemented in the cloud and provides globally distributed private networks across all major cloud platforms (e.g., Google, AWS, Microsoft, IBM). Therefore, the wireless routing of enterprise IP traffic terminated at the PGW of a private mobile core can be privately routed to the enterprise's remote IP networks. These remote sites can be physical sites or, as previously mentioned, virtual networks within the cloud. In the case where the remote site is a virtual network within the cloud, Figure 9 The routing instance and MPLS VPN cloud 904 shown are essentially as described above, in Figure 2 The virtual cross-connections shown as 207 and 208 are functional. MPLS VPN Cloud 904 further provides routing to other mobile core and routing instances within the cloud cluster, such as... Figure 9 The cloud cluster shown.

[0035] Figure 10This illustration demonstrates how a private and virtualized mobile core network and associated virtualized IP routing capabilities can be provided as a configurable service. The service provider can deploy a global MPLS VPN cloud 904. The service provider can further provide a service configuration interface, such as a web interface 1010 for potential users (e.g., enterprise users). Users can use the web interface to initiate service requests to the mobile core and routing server 1002, allowing the service provider to immediately deploy a private mobile core and virtual router 1030 for the user in the cloud. Users can further modify, configure, and provide the deployed private mobile core and router 1030 from the web interface 1010 via an application programming interface (API) 1011. Cloud resource subscription, allocation, and management can be provided by a server 1020 from a cloud service provider. Requests for cloud resources required to deploy the private mobile core and router 1030 can be processed by the service provider and sent to the server 1020, as indicated by arrow 1013. Alternatively, interaction with the server 1020 can be performed directly by the user, as indicated by arrow 1015.

[0036] at last, Figure 11 An exemplary computer system 1100 is shown, comprising any computing components and devices required to implement the above disclosure. The computer system 1100 may include a communication interface 1102, system circuitry 1104, input / output (I / O) interface 1106, storage 1109, and display circuitry 1108, which generates a machine interface 1110 locally or for remote display, such as in a web browser running on a local or remote machine. The machine interface 1110 and I / O interface 1106 may include a graphical user interface, a touch-sensitive display, voice or facial recognition input, buttons, switches, speakers, and other user interface elements. Other examples of I / O interface 1106 include microphones, video and still image cameras, headphone and microphone input / output jacks, universal serial bus (USB) connectors, memory card slots, and other types of input. I / O interface 1106 may 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] Communication interface 1102 may include a wireless transmitter and receiver (“transceiver”) 1112 and any antenna 1114 used by the transmitting and receiving circuitry of transceiver 1112. Transceiver 1112 and antenna 1114 may support Wi-Fi network communication, for example, according to any version of IEEE 802.11, such as 802.11h or 802.11ac. Communication interface 1102 may also include a wired transceiver 1116. Wired transceiver 1116 can provide a physical layer interface for any wide range of communication protocols, such as any type of Ethernet, Cable Service Interface Specification (DOCSIS), Digital Subscriber Line (DSL), Synchronous Optical Network (SONET), or other protocols.

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

[0039] System circuitry 1104 may include any combination of hardware, software, firmware, or other circuitry. System circuitry 1104 may be implemented, for example, using one or more system-on-chip (SoC), application-specific integrated circuit (ASIC), microprocessor, discrete analog and digital circuitry, and other circuitry. System circuitry 1104 is part of implementing any desired functionality related to the components of the above embodiments. As an example only, system circuitry 1104 may include one or more instruction processors 1118 and memory 1120. Memory 1120 stores, for example, control instructions 1126 and operating system 1124. In one embodiment, instruction processor 1118 executes control instructions 1126 and operating system 1124 to perform any desired functionality related to the various components of the above embodiments.

[0040] Therefore, the above implementation provides a fully virtualized and software-defined mobile core network deployed as instances of containers and daemons within one or more public cloud platforms. The mobile core network can be deployed alongside a multi-tiered virtual IP routing network, also deployed within the public cloud platform, acting as a cloud daemon to transpose the IP addressing space of the underlying hardware components of the cloud platform and route data traffic received and processed by the mobile core to other networks. These other networks may include, but are not limited to, other private cloud networks, other standalone cloud instances or applications, other fixed IP networks (e.g., fixed WANs), 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 sites globally without exposing any communication legs to the public internet, avoiding additional security tunneling coverage. The deployment of the mobile core and virtual routing components within the public cloud platform can be offered to enterprises as a service. Therefore, enterprises can immediately customize, deploy, configure, provide, and maintain their own mobile core and IP routing networks via API interfaces. Thus, enterprises can effectively act as their own global mobile operators.

[0041] The methods, apparatus, processes, and logic described above can be implemented in many different ways and in many different combinations of hardware and software. For example, all or part of the implementation may 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 elements, including analog circuit elements, digital circuit elements, or both; or any combination thereof. The circuit may include discrete, interconnected hardware elements and / or may be combined on a single integrated circuit chip, distributed across multiple integrated circuit chips, or implemented in a multi-chip module (MCM) of multiple integrated circuit chips in a common package, as exemplified above.

[0042] The circuitry may further include or access instructions for execution by the circuitry. The instructions may be stored in a tangible storage medium that is not a transient signal, such as flash memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM); or stored on a magneto-optical disk or optical disk, such as an optical disc read-only memory (CD-ROM), hard disk drive (HDD), or other magneto-optical disk or optical disk; or stored on other machine-readable media. A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium that, when executed by circuitry in the device, cause the device to perform any of the processes described above or illustrated in the figures.

[0043] The implementation scheme can be distributed as circuitry across multiple system components, such as across multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures can be stored and managed separately, can be merged 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 subroutines) or standalone programs distributed across several memories and processors, or implemented in many different ways, such as in libraries, such as shared libraries (such as dynamic link libraries (DLLs)). For example, a DLL can store instructions that, when executed by the circuitry, perform any of the processes shown above or in the diagram.

Claims

1. An information routing method, executed by a software-defined and virtualized mobile core and data routing network deployed in a cloud platform, characterized in that, The method includes: The system receives first data from a wireless access network, the first data originating from a wireless terminal device, and the first data source is encapsulated by a multi-layered IP address space; wherein, the virtualized mobile core and data routing network includes one or more cloud instances of each data processing container in one or more data processing containers and a multi-level routing program deployed in the cloud platform; each of the one or more data processing containers corresponds to one or more mobile core functions, and the number of cloud instances is adjusted according to the service volume level of the one or more mobile core functions; and The first data is routed by transposing the multi-level IP address space using the one or more cloud instances of each of the one or more data processing containers and the multi-level routing program in the cloud platform.

2. The method according to claim 1, characterized in that, Before the first data is received by the software-defined and virtualized mobile core and data routing network, the first data is transmitted from the wireless terminal device via the air interface to the wireless access network containing at least one base station.

3. The method according to claim 1, characterized in that, The software-defined and virtualized mobile core and data routing network includes a first virtual packet gateway, which is implemented as an instance of one of the one or more cloud instances of each of the one or more data processing containers. The method further includes: In the cloud platform, the first data is routed from the first virtual packet gateway to the multi-level routing program; The first data is routed to an independent cloud application by the multi-level routing program via a private virtual cross-connect implemented in the cloud platform; and Provide the wireless terminal device with access to the standalone cloud application.

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

5. The method according to claim 3, characterized in that, Further includes: In response to the wireless access network receiving second data from the wireless terminal device, the device receives the second data from the wireless access network. The second data is directed to the first virtual packet gateway; In the cloud platform, the second data is routed from the first virtual packet gateway to the multi-level routing procedure; as well as The second data is routed to a remote IP network outside the cloud through the multi-level routing procedure.

6. The method according to claim 3, characterized in that, Further includes: In response to the wireless access network receiving second data from the wireless terminal device, the device receives the second data from the wireless access network. The second data is directed to the first virtual packet gateway; In the cloud platform, the second data is routed from the first virtual packet gateway to the multi-level routing procedure; as well as The second data is routed to the off-cloud mobile network through the multi-level routing procedure.

7. The method according to claim 3, characterized in that, Further includes: In response to the wireless access network receiving second data from the wireless terminal device, the device receives the second data from the wireless access network. The second data is directed to the first virtual packet gateway; In the cloud platform, the second data is routed from the first virtual packet gateway to the multi-level routing procedure; as well as The second data is routed to another software-defined and fully virtualized mobile core implemented in the cloud platform via the multi-level routing procedure.

8. A circuit in a cloud platform for implementing a software-defined and virtualized mobile core and data routing network, said circuit being configured to implement: The first group of cloud container instances is configured to receive data from wireless terminal devices via a wireless access network; The second group of cloud container instances is configured to implement a set of mobile core network functions by processing data received from the radio access network by the first group of cloud container instances. The third group of cloud container instances; and A set of multi-level virtual routers; in, The circuit is further configured to implement the third group of cloud container instances as a packet gateway, used to route the data processed by the second group of cloud container instances to the multi-level virtual router. The circuit is further configured to enable the multi-level virtual router to route data received from the multi-level virtual router; as well as The circuitry is further configured to enable each cloud container to perform one or more mobile core functions, the number of cloud instances of the first group of cloud container instances, the second group of cloud container instances, or the third group of cloud container instances being adjusted according to the service volume level of the one or more mobile core functions.

9. The circuit according to claim 8, characterized in that, It is further configured to implement the multi-level virtual router as a subset of the core router, a subset of virtual routing and forwarding (VRF) aware routers, or a subset of non-VRF aware routers.

10. The circuit according to claim 9, characterized in that, It is further configured to provide connectivity between the core router subset and the non-VRF-aware router subset under multiprotocol label switching encapsulated by Generic Routing Encapsulation (GRE).

11. The circuit according to claim 8, characterized in that, It is further configured to enable the multi-level virtual router to route the data to a standalone cloud application.

12. The circuit according to claim 8, characterized in that, It is further configured to enable the multi-level virtual router to route the data to a remote IP network outside the cloud.

13. The circuit according to claim 8, characterized in that, It is further configured to enable the multi-level virtual router to route the data to an off-cloud mobile network.

14. The circuit according to claim 8, characterized in that, It is further configured to enable the multi-level virtual router to route the data to another software-defined and virtualized mobile core implemented in the cloud platform.

15. A communication network, characterized in that, include: A software-defined and virtualized mobile core deployed in a cloud platform is used to receive and process data collected by multiple distributed sensors via a wireless access network to generate output data; wherein the virtualized mobile core is configured to implement one or more instances of each of one or more data processing containers to process the received data; each of the multiple distributed sensors integrates a Wireless Subscriber Identity Module (SIM) with multiple remotely activated International Mobile Subscriber Identity (IMSI) profiles; and A multi-level virtual router deployed in the cloud platform is used to route the data collected by the multiple distributed sensors; wherein, each of the one or more instances of the one or more data processing containers is configured to perform one or more mobile core functions, and the number of cloud instances is adjusted according to the service volume level of the one or more mobile core functions.

16. The communication network according to claim 15, characterized in that, The multi-level virtual router is used to route at least a portion of the output data from the virtualized mobile core to the cloud application.

17. The communication network according to claim 15, characterized in that, The multi-level virtual routers include a subset of core routers, a subset of virtual routing and forwarding (VRF) aware routers, or a subset of non-VRF aware routers.

18. The communication network according to claim 17, characterized in that, The connection between the core router subset and the non-VRF-aware router subset is based on multiprotocol label switching encapsulated by Generic Routing Encapsulation (GRE).

19. The communication network according to claim 16, characterized in that, The multi-level virtual router is used to route another portion of the output data from the virtualized mobile core to a remote IP network outside the cloud.

20. The communication network according to claim 16, characterized in that, The multi-level virtual router is used to route another portion of the output data from the virtualized mobile core to another software-defined and virtualized mobile core implemented in the cloud platform.

Images