English:
[0001] This PCT International Application claims benefit of the U.S. Provisional Patent Application Number 62/886,471 filed on August 14, 2019.
[0002] This disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communication platform deployed on public cloud infrastructure.
[0003] Mobile networks may include radio access networks and mobile core networks interconnected with backhaul circuits. Mobile networks may further communicate with other data networks via public Internet. Traditional mobile core networks rely heavily on fixed, custom built hardware components to perform functions required to achieve end-to-end communications. These hardware-driven mobile core networks are rigid, inflexible, and inelastic during deployment and subsequent provisioning and maintenance. With an increasing convergence of various previously distinct types of network traffic (e.g., voice, messaging, and data), the legacy mobile core networks may be simplified to the extent that an entire mobile core network could be virtualized and implemented in software without relying on dedicated hardware components.
[0004] This disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communication platform deployed on public cloud infrastructure l as a mix of configurable instances of cloud containers and cloud daemons. Such a mobile network allows for private and 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 may be instantly deployed in the cloud with high elasticity. They may further be automatically and programmatically provisioned and reconfigured during operation. The implementations disclosed herein effectively provides a platform that enables instant and dynamic creation and deployment of a true private global end-to-end software-defined network (SDN) for 3G, 4G, LTE, and 5G mobile communication from the ground up. Users of such a platform essentially act as their own mobile carrier, allowing them to customize the features available to them via a programmatic interface.
[0005] In one implementation, a method for information routing via 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 and fully virtualized mobile core and data routing network deployed in a public cloud platform wherein the mobile core and data routing network comprise a mixture 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 within 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; 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 access of the independent cloud application to the wireless terminal device.
[0007] In yet another implementation, a private wireless sensor network is disclosed. The wireless sensor network may include a plurality of distributed sensors each integrated with a wireless subscriber identity module (SIM) having multiple international mobile subscriber identity (IMSI) profiles that are remotely activatable. The wireless sensor network may further include a private software-defined and fully virtualized mobile core deployed in a public cloud platform for receiving data collected by the plurality of distributed sensors via a radio access network to generate output data. The mobile core may include a mixture of multiple instances of data processing containers for processing the received data; a plurality of private routing daemons deployed in the public cloud platform; and a private cloud network configured for routing messages according to multiprotocol label switching. The output data of the mobile core may be further routed from the plurality of private routing daemons to the private cloud network, and is further routed from the private cloud network to a private cloud application.
[0008] Figure 1 shows an example architecture of a traditional mobile communication platform based on dedicated hardware components for achieving functionality of mobile core networks.
[0009] Figure 2 shows an example architecture of a mobile communication platform with mobile cores fully defined in software and fully virtualized in public cloud infrastructure.
[0010] Figure 3 illustrates a secure and virtual cross connect that can be implemented in cloud between the mobile core network virtualized in public cloud infrastructure and other independent cloud instances.
[0011] Figure 4 shows a communication path between mobile devices and cloud instances via traditional mobile core networks implemented in hardware, showing connection legs that are exposed to unsecure public Internet.
[0012] Figure 5 shows an example of implementing mobile core networks and virtually cross connected to other cloud instances in an environment involving multiple different cloud platforms.
[0013] Figure 6 illustrates exemplary functional components of a mobile core network for signaling, data processing, and information routing.
[0014] Figure 7 shows an exemplary implementation of a mobile core network as a mixture of containers and daemons deployed in a public cloud infrastructure.
[0015] Figure 8 illustrates another exemplary implementation of mobile core networks as containers and tankers.
[0016] Figure 9 shows exemplary routing layers implemented as daemons or containers in the cloud for facilitating end-to-end communications via the virtualized mobile core.
[0017] Figure 10 illustrates an exemplary scheme for providing a service for automatic deployment and provisioning of private mobile core networks and virtual cross connect to other independent cloud instances.
[0018] Figure 11 shows an exemplary implementation of a computer device that may be used as the underlying hardware in the cloud or as a user terminal device.
[0019] This disclosure relates to a fully software-defined, fully virtualized, and customizable mobile communication platform deployed on public cloud infrastructure as a mix of configurable instances of cloud containers and cloud daemons. Such a mobile network allows for private and 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 may be instantly deployed in the cloud with high elasticity. They may further be automatically and programmatically provisioned and reconfigured during operation. The implementations disclosed herein effectively provides a platform that enables instant and dynamic creation and deployment of a true private global end-to-end software-defined network (SDN) for 3G, 4G, LTE, and 5G mobile communication from the ground up. Users of such a platform essentially act their own mobile carrier, allowing them to customize the features available to them via a programmatic interface.
[0020] Figure 1 illustrates an example system architecture of a mobile communication network 100. The mobile communication network 100 may include user equipment (UE) 103 communicating with mobile core networks (CNs) 107 via radio access networks (RANs) 105. The user equipment 103 may be implemented as mobile or fixed terminal devices including but not limited to mobile phones, tablets, personal digital assistants (PDAs), wearable devices, distributed sensors, Internet-of- things (loT) terminals, desktop computers, and laptop computers that are configured to access the RANs 105 via wireless connections. These example terminal devices are illustrated in Figure 1 as 140-152.
[0021] The radio access network 105, for example, may include base stations 120, 122, 124 and radio network controllers (RNCs) 126 and 128. The base stations 120, 122, and 125 may aggregate wireless uplink signals from the user equipment and broadcast wireless downlink signals to the user equipment via over-the-air radio channels. The RNCs 126 and 128 may further aggregate signals from base stations120, 122, and 124 or distribute signals to the base stations 120, 122, and 124 via wired backhaul connections shown by the dashed arrows 121 , 123, and 125. The RNCs further function to control the base stations connected therewith to provide provisioning of the radio channels and signal characteristics.
[0022] As further shown in Figure 1 , the RNCs 126 and 128 may communicate with the mobile core network 101 via wired backhaul 127 and 129. The mobile core network 101 may be designed to perform various control, signal processing, information routing, and signal gateway functions according to a predefined stack of transmission and signaling protocols for voices, messages, and/or data packets separately or in a converged manner (all as data packets, for example). The mobile core network 101 may further transmit to or receive data from other networks 109. For example, as shown in Figure 1 , the mobile core network 101 may communicate with an IP network such as the Internet 160, a fixed voice network such as the public switched telephone network (PSTN) 162, and the like. As such, signals can be routed between user equipment 140-152 and the Internet 160 and/or the PSTN 162 via the mobile core network. Signals may further be routed between one user equipment and another user equipment via the base stations, the RNCs, and the mobile core network.
[0023] The base stations, the RNCs and the 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 may independently operate their own mobile networks. A user may subscribe a terminal device to a particular wireless carrier to access the mobile network of that wireless carrier. When the user terminal is moved to a geographic region where only base stations from other wireless carriers are accessible, the user terminal may still be permitted to connect to these base stations by roaming. For example, as shown in Figure 1 , base stations 120, 122, RNC 126 and mobile core network 101 may be operated by a first wireless carrier, whereas base station 124 and RNC 128 may be operated by a second wireless carrier. User equipment 140-150 may be subscribed to the first wireless carrier whereas user equipment 152 may be subscribed to the second wireless carrier. Among the user equipment 140-150 subscribed to the first wireless carrier, the user equipment 140- 144 may be located within the signal coverage area of the base stations 120 and 122 of the first wireless carrier and thus can access the mobile network of the first wireless network without roaming. Flowever, the user equipment 146-150 that are also subscribed to the first wireless carrier may be located outside the signal coverage area of the base stations 120 and 122 but within the coverage area of the based station 124 belonging to the second wireless carrier. The user equipment 146-150 may thus roam on the mobile network provided by the second wireless carrier. The signal from the user equipment 146-150 and 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 an exchange node, as indicated by node 131 . Such signal may then be processed and routed by the mobile core network 101 to other wireless user equipment (such as user equipment 140-144), the IP network (e.g., internetwork 160), the PSTN 162, and the like, wherever the destination of the signal is determined to be.
[0024] The mobile core network 101 belonging to the first wireless carrier may further deliver signal to a mobile core network belonging to the second wireless carrier, as indicated by 102 of Figure 1 , so that the user equipment subscribed to the first wireless carrier (such as user equipment 140-144) can communicate with user equipment 152 subscribed to the second wireless carrier. In this case, communication information may be delivered from the mobile core network 101 to the mobile core network 102 via an exchange node, as indicated by arrow 133 and node 135. Such communication information may then be further transmitted to the user equipment 152 subscribed to the second wireless carrier via the mobile core network 102, the RNC 128 and the base station 124. Likewise, the user equipment 152 subscribed to the second wireless carrier may send communication information to the user equipment subscribed to the first wireless carrier (such as user equipment 140-144) using 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.
[0025] The mobile core network 101 and 102 of Figure 1 may be implemented as dedicated custom hardware components for performing the various network functions, as shown in Figure 1 as equipment racks and cabinets 111 and 113 within the mobile core network 101 and 102. Alternatively, the mobile core network 101 and 102 may be fully implemented and defined in software and fully virtualized, as shown in Figure 2. In the particular implementation shown in Figure 2, the radio access network portion 105 of the mobile network remains identical to that of the implementation in Figure 1 , but the mobile core network 107 (including, for example, mobile core network A 203 and mobile core network B 205) may be deployed in public cloud platform 202, and as software instances rather than dedicated equipment racks. The cloud-based mobile core networks 203 and 205 may further communicate with other off-cloud networks 109 including but not limited to the IP network 160, the PSTN system 162, and other off-cloud mobile core network 230.
[0026] Implementation of the mobile core network 101 and 102 in dedicated hardware components as shown in Figure 1 faces several drawbacks and limitations whereas the mobile core networks 203 and 205 fully virtualized in cloud as shown in Figure 2 are advantageous in several aspects. Specifically, implementations of mobile core network based on dedicated and customized hardware are inflexible, inelastic, and difficult to deploy, modify, reconfigure, expand, and scale. For example, expansion and scaling of the capacity of the hardware based mobile core networks usually involve replacing costly equipment and often take exceedingly long periods of time to install and to test. Utilization of various hardware components in different parts of such core networks, even if deployed initially with careful consideration, may become unbalanced as the user profiles evolve, leading to loss of efficiency in using the deployed hardware network equipment. Upgrades are often limited without replacing outdated network equipment. As the network equipment based on hardware implementation requires very high capital outlay, they are usually deployed and configured by large wireless carriers serving a large customer base. As such, configuration of the network often cannot be elastically tailored to individual or a group of subscribers. The network configuration is generally rigid and static, and it may be very difficult to implement network configurations automatically and programmatically.
[0027] Virtualized mobile core networks, however, are much more agile, flexible, elastic, and straightforward to deploy, particularly when such mobile core networks are implemented in cloud to leverage existing underlying hardware resources and cloud management and provisioning tools and interfaces. Such virtualized mobile core networks may be deployed in the cloud instantly without direct capital investment on expensive dedicated hardware components. As a result, there is a low barrier of network deployment, and a mobile core may be deployed at a simple mouse click. Likewise, modification, expansion and scaling of such virtualized mobile core networks that have already been deployed would only involve software update and cloud resource reconfiguration. Deployment, maintenance, upgrades, replacement, and configuration of the underlying hardware resources would be taken care of by providers of the cloud platform and service, independent of and decoupled from the software-defined mobile core networks.
[0028] Because of the flexibility and elasticity offered by software-defined mobile core networks in cloud, an institution, an enterprise or the like (referred to as “enterprise” herein) may act as its own wireless carrier. In other words, an enterprise, for example, may choose to deploy its own private global mobile core network rather than sharing mobile core network with others. In one scenario, the enterprise may desire to connect its employees via its private global mobile core network. In another scenario, the enterprise may desire to connect its wireless sensors distributed across various geographic locations into a sensor network via its private mobile core network. The enterprise may further deploy its own global mobile core network to integrate both its mobile employess and sensors to form a combined private global network. Regardless of specific needs of an applications, such private mobile core networks may be deployed and configured instantly as cloud instances with initial cloud resource allocation tailored to the number of users (or sensors) and the overall mobile communication needs and characteristics of the enterprise. Allocation of the underlying cloud resources for the private mobile core network may further be provisioned dynamically and in real-time after the initial deployment, based on the communication pattern of the enterprise as a function of time. For example, the private mobile core network of the enterprise may be more heavily used in a particular time window of a day, a particular week of a month, and/or a particular month or season of a year, depending on the nature of the business of the enterprise and characteristics of user communication. Accordingly, the private mobile core network implemented in the cloud may be provided with real-time elasticity in resource allocation and may particularly leverage cloud provisioning tools and interfaces that have already been developed and provided by the cloud service providers for dynamic and predictive provisioning and allocation of cloud computing resources. Such private mobile core networks thus reduce resource imbalance and under-utilization and provide a more efficient mobile communication system. In addition, because such private mobile core networks may be deployed independent of other mobile cores, they can be easily customized and configured in software automatically or at any chosen time.
[0029] As further shown in the implementation 200 of Figure 2, the radio access network 105 may remain un-virtualized. The enterprise described above having its private virtualized mobile core network 203 and 205 may not need to deploy its own radio access network. Rather, it may use existing radio access network 105 deployed by and belonging to other wireless mobile carriers. The enterprise may piggyback on these radio access network by receiving wireless signals from the radio access network 105 and directing the signals to its private mobile core network in the cloud, or routing signals from the private mobile core network to the radio access network 105, both via edge exchange connection 210 and 220 of Figure 2. These exchange connection may be made by network edge connectors co-located with RNC 126 and 128 of the radio access network prior to the backhaul 127 and 129, or co-located at traditional mobile cores nodes belonging to the traditional wireless carriers owning the access network 105, after the backhaul 127 and 129.
[0030] The enterprise acting as its own global wireless carrier with the deployment of its software-defined mobile core network in the cloud may in turn be associated with a set of subscriber identify modules (SIMs). These SIMs may be provided to wireless devices 140-152 of the enterprise, as indicated by 241 , 243, 245, 247, 249, 251 , and 253 of Figure 2. These SIMs may be recognized by the radio access network 105 as roaming devices and the signals from the wireless devices associated with these SIMs may be routed accordingly through the 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 may be remotely configured and activated between different IMSI profiles. They are particularly suitable for deployment with remote sensor devices that are difficult or inconvenient to access physically after installation. As the radio access network evolves, these devices may communicate with the partner radio access network in roaming mode or sponsored mode, or home radio access network, using different IMSI profiles that may be programed without physical access to the SIMs installed in the devices.
[0031] The virtualized mobile core network 203 and 205 of Figure 2 as implemented in the cloud may offer an additional benefit to the enterprise acting as its own global wireless carrier. This is further illustrated in both Figure 2 and Figure 3. Conceptually, the enterprise may deploy one or more information technology (IT) and computing infrastructure in the cloud (labeled as cloud instance A 204 and cloud instance B 206 in Figure 2), independent of the mobile core networks. It may be desirable for the 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, the communications between them may be routed within the cloud, facilitated by network processing and routing daemons also implemented in the cloud that function as virtual cross connects 207 and 208 shown in Figure 2. The signal and information being routed within the cloud may be protected by cloud security mechanism such as generic routing encapsulation (GRE, similar to IPSec). As such, the mobile users of the enterprise may access the cloud computing infrastructures via the virtual mobile core network without exposing the information being communicated to public internet.
[0032] Figure 3 provides a specific illustration. As shown in Figure 3, the user 302 of the enterprise communicates with the radio access network 304 via private over-the- air communication channels 320. The radio access network 304 communicates with the private mobile core network 308 in the cloud via private physical connection 312, 314, and 322 through exchange 306. The communications between the mobile core network and the enterprise cloud computing infrastructures 310 may be based on private and secure routing within the cloud, as indicated by 312 and 316. At no point is any one of the communication legs between the user device 302 and the enterprise cloud computing infrastructure 310 exposed to non-private communications channels. The implementation of Figure 3 with the cloud-based mobile core network thus provides secure connection between the user device 302 and the cloud infrastructure 310, leveraging the underlying security features implemented in the cloud and without the need of using additional tunneling technologies.
[0033] Such security may not be easily implemented in traditional system using off- cloud mobile cores, as illustrated in system 400 of Figure 4. As shown in Figure 4, when the mobile core networks 402 and 404 are implemented off-cloud (for example, implemented as hardware-based mobile core networks), access of the cloud infrastructures 204 and 206 from the mobile core networks 402 and 404 would need to be via public internet 406. The communication between the user devices 140-152 and the cloud computing infrastructures 204 and 206 thus may be exposed to insecure communication channels at the leg involving the public internet 406, without any protection from the in-cloud security measures.
[0034] While the cloud platform 202 of Figure 2 is illustrated as a single cloud platform, the system of Figure 2 may alternatively be implemented in an environment having multiple cloud platforms, as illustrated in Figure 5. In one exemplary implementation, the mobile core networks 103 and 105 may be both deployed as cloud instances in a cloud platform 502. In another exemplary implementation, the mobile core networks such as 103, 105 and 501 may be deployed in different cloud platforms 502 and 504. Likewise, the enterprise cloud computing infrastructures 104 and 106 may be deployed in the same or different cloud platforms 506 and 508. Software-defined mobile core networks that are capable of being deployed in different cloud platforms may provide added flexibility to a particular enterprise. For example, if the enterprise already has existing cloud computing infrastructure in a particular cloud platform, the same cloud platform may be chosen for 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 within the same cloud platform. The various cloud platform above may include but are not limited to AWS of AmazonTM, Azure of MicrosoftTM, GoogleTM cloud, and IBMTM cloud.
[0035] The mobile core network discussed above may include various functional blocks for mobile service management, data processing and routing. An example is shown in Figure 6. The mobile core network 602 of Figure 6 may include mobile service and subscription management components, database, or servers such as Short Message Service Center (SMSC), Home Subscriber Server (HSS), and Home Location Register (HLR). These components may communicate information with the RNC 126 according to, for example S6a Diameter protocol. The mobile core network may further include a Spanning Tree Protocol (STP) processing component for processing signaling information according to SS7 signaling protocol. The mobile core network may further include packet processing components such as the Packet Gateway (PGW) 614 and corresponding multiplexer 612 which communicate with RNC 126 via, for example, S5/S8/GPRS Tunneling Protocol (GTP), and communicate with external IP network 160 via SGi protocol.
[0036] Figure 6 is merely shown as an example. Those of ordinary skill in the art understand that the mobile core network 602 may include many other components that are not shown in Figure 6. For example, the mobile core network 602 may including other components for processing voice information that are 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 be significantly different from the one illustrated in Figure 6. However, the software- defined mobile core network implemented in the cloud and the underlying principle disclosed herein are applicable to those other mobile core configurations.
[0037] The various components of the software-based mobile core network may be implemented in the cloud as containers. In particular, each of the processing components above may be developed and packaged as an application including all required software stack and its dependencies (e.g., libraries). Such application packages may be deployed in the cloud as containers. Each application may be deployed as multiple independent instances of containers running on underlying computers in the cloud which share the same host operating system and its kernel. Other alternative implementation of the mobile core network components in clouds may be based on virtual machines. In comparison with the virtual machine architecture, the container implementation is generally lightweight, resource- conserving, and robust. Because they are lightweight, containers may be instantiated rapidly and efficiently. Thus, as the service volume and system resource needs for an application (e.g., a mobile core functional component) increase in rea-time, new instances of the container may be instantiated as needed to meet client demand, providing the elasticity desired for software-defined mobile core network. Likewise, when service volume of the application drops, excess containers may be removed quickly and efficiently with their user traffic redistributed to the remaining containers of the application. The software stack for the containers may be designed and then packaged using tool such as Docker TM.
[0038] In addition to various instances of containers for different processing components, the implementation of the mobile core network may also include instances of other programs or daemons implemented in cloud that are designed to perform routing function within the mobile core network in, for example, data link and/or network layer of the OSI model. As such, cloud implementation of the mobile core network may include a mixture of containers and daemons, as illustrated in Figure 7. In Figure 7, the routing daemons are represented by 710. Containers 704 represent multiple instances of one of the multiple function components of the mobile core network (PGW containers, for example). Containers 706 represent multiple instances of another one of the multiple function components of the mobile core network (e.g., HLR). The routing demons may be implemented for facilitating the functionality of a particular container or all of the multiple containers instances of the same components, or may be implemented to facilitate communications between containers of a same component or between containers of different components. A group of containers may be organized as a tanker.
[0039] Figure 8 further illustrates an exemplary configuration of containers organized in tankers for implementing a mobile core network. As shown in Figure 8, signals from a RNC may be intercepted by the exchange connectors 802 and 210, multiplexed according to signal type (as shown by 830, including but not limited to S6a diameter signals, SS7 signals, S5/S8 GTP signals), and then directed into the mobile core network implemented as cloud containers 808 and 810 organized as tankers 804 and 806. These containers may be deployed to implement various functions of the mobile core network, as described above. The mobile core network may be further connected to the other cloud instances 820 via virtual cross connect implemented in the cloud. Other cloud instances 830 (e.g., SMS proxy instances, Over-The-Air (OTA) instances, and HA shared storage instances) may be further implemented to facilitate the function of the mobile core network.
[0040] Figure 9 shows more details for implementing data routing functions in network layer II and III (datalink layer and network layer) in the cloud between the mobile core networks and other networks on or off-cloud. The example data routing, as shown in Figure 9, may be deployed in the cloud as routers at multiple levels, including core routers (CRs) 910 and 912, virtual cloud routers (VCLRs) 920 and 922, VRF (Virtual Routing and Forwarding) aware tanker router (VATR) 930, virtual CE routers (VCERs) 950 interconnected by various communication interfaces as indicated in Figure 9. These multilevel virtual routers are connected with the virtual mobile core network 902 and a virtual multiprotocol-label-switching (MPLS) private cloud 904.
[0041] The various multilevel routers in Figure 9 may be implemented as cloud daemons rather than containers. Specifically, public cloud service providers generally do not allow users to bring their own public IP space within the actual cloud container instances. In order to perform IP routing between PGWs, these virtual routers may be implemented as programs deployed in cloud (daemons). In an alternative implementation based on visualization using virtual machines within private hardware clusers rather than using containers, the IP addressing space may be more easily customizable. The multilayer IP routing scheme of Figure 9 may be used in the container implementation to transpose the IP addressing space limitation in public cloud.
[0042] These routers form a cloud cluster and together with the mobile core container instances, form a particular virtual private cloud (VPC) for an, e.g., enterprise. The VCLRs 920 and 922 only plays routing roles and no actual service may be attached to these routers. The VATR may be a VRF aware cloud instance and provides services attached to a particular VRF. The VCER may not be VRF aware and may be designed to provide service with an ability to use anycast private/public IP. The VCER may not need to be tied to a particular VPC and can exists more than one instances in the network.
[0043] The VCLR essentially plays the PE role from the core routers. As such, adding or removing any service will only require changes in VCLR. No changes will be required from the core side. Also, as shown in Figure 9, only two generic routing encapsulation (GRE) tunnels from VCLR to the core routers are sufficient to provide the service in high availability fashion. The use of MPLS between the VCLRs and the core routers and encapsulation of the MPLS in GRE tunnels also eliminate the requirement for having a tunnel per VRF (non-VRF Lite). The VCLRs are connected to other service instances (such as VATR, and WL-tanker, and VCER) via GRE tunnels under the basis of one tunnel per VRF (VRF Lite) and without use of MPLS.
[0044] The MPLS VPN 904 may be implemented in the cloud and provide a private network with global reach in all major cloud platforms (e.g., Google, AWS, Microsoft, IBM). As such, the wireless of IP traffic of an enterprise terminated at the PGW of the private mobile core may be privately routed to remote IP network of the enterprise. These remote site can be either a physical site or, as discussed earlier, a virtual network inside the cloud. In the case where the remote site is a virtual network inside the cloud, the routing instances and the MPLS VPN cloud 904 shown in Figure 9 essentially function as the virtual cross connect described previously and shown as 207 and 208 in Figure 2. The MPLS VPN cloud 904 further provides routing to other cloud clusters of mobile cores and routing instances such as the cloud cluster shown in Figure 9.
[0045] Figure 10 illustrates an exemplary manner in which the private and virtualized mobile core network and associated virtualized IP routing functions may be provided as a configurable service. The provider of the service may deploy the global MPLS VPN cloud 904. The provider of the service may further provide service configuration interface, such as a web interface 1010 to potential users (such as an enterprise user). A user may use the web interface to initiate a service request to a mobile core and routing server 1002 such that the provider of the service may instantly deploy the private mobile core and virtual routers 1030 for the user in the cloud. The user may further modify, configure and provision the deployed private mobile core and routers 1030 from the web interface 1010 via application program interface (API) 1011. The cloud resource subscription, allocation, and management may be provided by server 1020 from the cloud service provider. Requests for cloud resources needed for deploying the private mobile core and routers 1030 may be handled by the provider of the service and sent to server 1020, as shown by arrow 1013. Alternatively, interaction with the server 1020 may be made directly from the user, as shown by arrow 1015.
[0046] Finally, Figure 11 shows an exemplary computer system 1100 for implementing any of the computing components and devices needed for the disclosure above. The computer system 1100 may include communication interfaces 1102, system circuitry 1104, input/output (I/O) interfaces 1106, storage 1109, and display circuitry 1108 that generates machine interfaces 1110 locally or for remote display, e.g., in a web browser running on a local or remote machine. The machine interfaces 1110 and the I/O interfaces 1106 may include GUIs, touch sensitive displays, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the I/O interfaces 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 interfaces 1106 may further include magnetic or optical media interfaces (e.g., a CDROM or DVD drive), serial and parallel bus interfaces, and keyboard and mouse interfaces.
[0047] The communication interfaces 1102 may include wireless transmitters and receivers ("transceivers") 1112 and any antennas 1114 used by the transmitting and receiving circuitry of the transceivers 1112. The transceivers 1112 and antennas 1114 may support Wi-Fi network communications, for instance, under any version of IEEE 802.11 , e.g., 802.11 h or 802.11ac. The communication interfaces 1102 may also include wireline transceivers 1116. The wireline transceivers 1116 may provide physical layer interfaces for any of a wide range of communication protocols, such as any type of Ethernet, data over cable service interface specification (DOCSIS), digital subscriber line (DSL), Synchronous Optical Network (SONET), or other protocol.
[0048] The storage 1109 may be used to store various initial, intermediate, or final data. The storage 1109 may be centralized or distributed, and may be local or remote to the computer system 1100. For example, the storage 1109 may be hosted remotely by a cloud computing service provider.
[0049] The system circuitry 1104 may include hardware, software, firmware, or other circuitry in any combination. The system circuitry 1104 may be implemented, for example, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), microprocessors, discrete analog and digital circuits, and other circuitry. The system circuitry 1104 is part of the implementation of any desired functionality related to the components of the implementations above. As just one example, the system circuitry 1104 may include one or more instruction processors 1118 and memories 1120. The memories 1120 stores, for example, control instructions 1126 and an operating system 1124. In one implementation, the instruction processors 1118 executes the control instructions 1126 and the operating system 1124 to carry out any desired functionality related to the various components for the implementations above.
[0050] The implementations described above thus provide a fully-virtualized and software-defined mobile core network deployed as instances of containers and daemons in one or more public cloud platforms. The mobile core network may be deployed in conjunction with a multilayer virtual IP routing network also deployed in the public cloud platforms as cloud daemons for transposing the IP addressing space of the hardware components underlying the cloud platform and for routing the data traffic received and processed by the mobile core to other networks. These other networks may include but not limited to other private cloud networks, other independent cloud instances or applications, other fixed IP network (fixed wide-area- networks, for example), and public networks such as public internet and PSTN. In some implementation, the mobile data may be received by the mobile core and then routed within private cloud to remote global sites without exposing any of the communication legs to public internet, avoiding having to including additional overlay of security tunneling. The deployment of the mobile core and the virtual routing components in public cloud platforms may be integrally provided as a service to enterprises. As such, an enterprise may customize, deploy, configure, provision, and maintain its own mobile core and IP routing network instantly and via an API interface. The enterprise thus effectively acts as its own global mobile carrier.
[0051] The methods, devices, processing, and logic described above may be implemented in many different ways and in many different combinations of hardware and software. For example, all or parts of the implementations may be circuitry that includes an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or a microprocessor; an Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array (FPGA); or circuitry that includes discrete logic or other circuit components, including analog circuit components, digital circuit components or both; or any combination thereof. The circuitry may include discrete interconnected hardware components and/or may be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated circuit dies in a common package, as examples.
[0053] The implementations may be distributed as circuitry among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, 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 (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library, such as a shared library (e.g., a Dynamic Link Library (DLL)). The DLL, for example, may store instructions that perform any of the processing described above or illustrated in the drawings, when executed by the circuitry.

中文:
[0001]本PCT国际申请要求受益于2019年8月14日提交的美国临时专利申请62/886,471。
[0002]本公开内容涉及一种部署在公共云基础设施上的完全软件定义的、完全虚拟化的、可定制的移动通信平台。
[0003]移动网络可包括与回程电路互连的无线电接入网络和移动核心网络。移动网络可以进一步通过公共互联网与其他数据网络进行通信。传统的移动核心网络在很大程度上依赖固定的、定制的硬件组件来执行实现端到端通信所需的功能。这些硬件驱动的移动核心网络在部署和随后的供应和维护过程中是僵硬的、不灵活的、且没有弹性的。随着各种以前不同类型的网络流量(如语音、消息和数据)的日益融合,传统的移动核心网络可能会被简化,以至于整个移动核心网络可以被虚拟化并在软件中实现,而不依赖于专用的硬件组件。
[0004]本公开内容涉及一种完全软件定义的、完全虚拟化的和可定制的移动通信平台,其作为云容器和云守护程序的可配置实例的混合体部署在公共云基础设施上。这种移动网络允许在该移动网络内和在该移动网络与其他私有和公共网络之间进行私有和安全的端到端网络流量路由。这种移动网络可以以高弹性的方式即时部署在云中,且可以进一步在运行过程中自动和程序化地进行配置和重新配置。本文公开的实施方案有效地提供了一种平台,能够从头开始为3G、4G、LTE和5G移动通信即时和动态地创建和部署真正的私有全球端到端软件定义网络(SDN)。这种平台的用户基本上扮演着他们自己的移动运营商,允许他们通过编程界面定制可用的功能。
[0005]在一个实施方案中,公开了一种用于通过这种移动网络进行信息路由的方法。该方法可以包括在无线网络控制器处拦截来自无线终端设备的第一数据;将所述第一数据重定向到部署在公共云平台中的私有软件定义和完全虚拟化的移动核心和数据路由网络;其中,所述移动核心和所述数据路由网络包括数据处理容器的多个云实例和多个云数据路由守护程序的混合体。该方法可以进一步包括将所述第一数据通过所述数据处理容器的多个云实例引导到作为所述移动核心和所述数据路由网络中所述数据处理容器的多个云实例之一实现的第一私有虚拟分组网关;将所述第一数据从所述第一私有虚拟分组网关路由到所述多个云数据路由守护程序;通过在所述公共云平台中实现的私有虚拟交叉连接,将所述第一数据从所述多个云数据路由守护程序路由到终止于第二分组网关的独立云应用程序。该方法可进一步包括向所述无线终端设备提供所述独立云应用程序的访问。
[0007]在另一个实施方案中,公开了一种私有无线传感器网络。该无线传感器网络可包括多个分布式传感器,每个所述传感器都集成有无线用户身份模块(SIM),所述模块具有多个可远程激活的国际移动用户身份(IMSI)配置文件。该无线传感器网络可进一步包括部署在公共云平台中的私有软件定义和完全虚拟化的移动核心,用于接收由所述多个分布式传感器通过无线接入网络收集的数据,以生成输出数据。所述移动核心包括用于处理所接收数据的数据处理容器的多个实例的混合体。该无线传感器网络可进一步包括部署在所述公共云平台中的多个私有路由守护程序;以及被配置为根据多协议标签交换路由消息的私有云网络。所述移动核心的所述输出数据从所述多个私有路由守护程序被路由到所述私有云网络,并进一步从所述私有云网络被路由到私有云应用程序。
[0008]图1示出了一种基于专用硬件组件的传统移动通信平台的示例架构,以实现移动核心网络的功能;
[0009]图2示出了一种移动通信平台的示例架构,该平台的移动核心在软件中完全定义,并在公共云基础设施中完全虚拟化;
[0010]图3示出了可在公共云基础设施中虚拟化的移动核心网络和其他独立的云实例之间的一种云中实现的安全和虚拟交叉连接;
[0011]图4示出了通过以硬件实现的传统移动核心网络的一种移动设备和云实例之间的通信路径,显示暴露在不安全的公共互联网上的连接腿;
[0012]图5示出了在涉及多个不同云平台的环境中实现移动核心网络和虚拟交叉连接到其他云实例的一个示例;
[0013]图6示出了用于信令、数据处理和信息路由的移动核心网络的示例性功能组件;
[0014]图7示出了作为部署在公共云基础设施中的容器和守护程序混合体的移动核心网络的一个示例性实施;
[0015]图8示出了作为容器和箱的移动核心网络的另一个示例性实施;
[0016]图9示出了在云中作为守护程序或容器实施的一种示例性路由层,用于促进通过虚拟化移动核心的端到端通信;
[0017]图10示出了用于提供自动部署和提供私有移动核心网络和虚拟交叉连接到其他独立云实例的服务的一个示例性方案;
[0018]图11示出了计算机设备的一个示例性实施,该计算机设备可作为云中的底层硬件或作为用户终端设备。
[0019]本公开内容涉及一种完全软件定义的、完全虚拟化的和可定制的移动通信平台,其作为云容器和云守护程序的可配置实例的混合体部署在公共云基础设施上。这种移动网络允许在该移动网络内和在该移动网络与其他私有和公共网络之间进行私有和安全的端到端网络流量路由。这种移动网络可以以高弹性的方式即时部署在云中,且可以进一步在运行过程中自动和程序化地进行配置和重新配置。本文公开的实施方案有效地提供了一种平台,能够从头开始为3G、4G、LTE和5G移动通信即时和动态地创建和部署真正的私有全球端到端软件定义网络(SDN)。这种平台的用户基本上扮演着他们自己的移动运营商,允许他们通过编程界面定制可用的功能。
[0020]图1示出了移动通信网络100的示例系统架构。移动通信网络100可以包括通过无线电接入网络(RAN)105与移动核心网络(CN)107通信的用户设备(UE)103。用户设备103可以为移动或固定的终端设备,包括但不限于移动电话、平板电脑、个人数字助理(PDA)、可穿戴设备、分布式传感器、物联网(loT)终端、台式计算机和笔记本电脑,它们均被配置为通过无线连接访问RAN105。这些例子的终端设备在图1中被说明为140-152。
[0021]例如,无线电接入网络105可以包括基站120、122、124和无线电网络控制器(RNC)126和128。基站120、122和125可以聚集来自用户设备的无线上行链路信号并通过空中无线电信道向用户设备广播无线下行链路信号。RNC126和128可以进一步聚集来自基站120、122和124的信号,或通过虚线箭头121、123和125所示的有线回程连接将信号分配给基站120、122和124。RNC进一步控制与之相连的基站,以提供无线电信道和信号特性的供应。
[0022]如图1进一步所示,RNC126和128可以通过有线回程127和129与移动核心网络101通信。移动核心网络101可以被设计为根据预先定义的语音、消息和/或数据包的传输和信令协议堆栈单独或以融合的方式(例如,全部作为数据包)执行各种控制、信号处理、信息路由和信号网关功能。移动核心网络101可以进一步向其他网络109传输或接收数据。例如,如图1所示,移动核心网络101可以与IP网络如互联网160、固定语音网络如公共交换电话网络(PSTN)162等通信。因此,信号可以通过移动核心网络在用户设备140-152与互联网160和/或PSTN162之间路由。信号可以进一步通过基站、RNC和移动核心网络在一个用户设备和另一个用户设备之间进行路由。
[0023]基站、RNC和移动核心网络,统称为移动网络,可由单一无线运营商或供应商安装和运营。不同的无线运营商可以独立地运营他们自己的移动网络。用户可以将终端设备订阅给某一特定的无线运营商,以访问该无线运营商的移动网络。当用户终端移动到一个只有其他无线运营商的基站可以访问的地理区域时,用户终端仍然可以被允许通过漫游连接到这些基站。例如,如图1所示,基站120、122、RNC126和移动核心网络101可以由第一无线运营商运营,而基站124和RNC128可以由第二无线运营商运营。用户设备140-150可以被订阅给第一无线运营商,而用户设备152可以被订阅给第二无线运营商。在订阅第一无线运营商的用户设备140-150中,用户设备140-144可位于第一无线运营商的基站120和122的信号覆盖区域内,因此可以在不漫游的情况下访问第一无线网络的移动网络。然而,同样订阅了第一无线运营商的用户设备146-150可位于基站120和122的信号覆盖区域之外,但位于属于第二无线运营商的基站124的覆盖区域之内。因此,用户设备146-150可以在由第二无线运营商提供的移动网络上漫游。来自用户设备146-150并由基站124和相应的RNC128接收的信号可由第二无线运营商通过交换节点(如节点131所示)传递到第一无线运营商的移动核心网络101。然后,该信号可由移动核心网络101处理并路由到其他无线用户设备(如用户设备140-144)、IP网络(如内联网160)、PSTN162等,无论该信号的目的地是哪里。
[0024]属于第一无线运营商的移动核心网络101可以进一步向属于第二无线运营商的移动核心网络传递信号,如图1的102所示,以便订阅第一无线运营商的用户设备(例如用户设备140-144)可以与订阅第二无线运营商的用户设备152通信。在这种情况下,通信信息可以通过交换节点从移动核心网络101传递到移动核心网络102,如箭头133和节点135所示。该通信信息可以通过移动核心网络102、RNC128和基站124进一步传送到订阅第二无线运营商的用户设备152。同样,订阅第二无线运营商的用户设备152可以使用反向路径向订阅第一无线运营商的用户设备(例如用户设备140-144)发送通信信息,即,沿基站124、RNC128、移动核心网络102、移动核心网络101、RNC126、和基站120或122。
[0025]图1的移动核心网络101和102可以被实现为用于执行各种网络功能的专用定制硬件组件,如图1中所示的移动核心网络101和102内的设备架和机柜111和113。或者,移动核心网络101和102可以完全在软件中实现和定义,并完全虚拟化,如图2所示。在图2所示的特定实施方案中,移动网络的无线电接入网部分105仍然与图1中的实施方案相同,但移动核心网络107(包括例如移动核心网络A203和移动核心网络B205)可以部署在公共云平台202中,并作为软件实例而不是专用设备架。基于云的移动核心网络203和205可以进一步与其他云外网络109通信,包括但不限于IP网络160、PSTN系统162和其他云外移动核心网络230。
[0026]如图1所示,在专用硬件组件中实施移动核心网络101和102面临若干缺点和限制,而如图2所示,在云中完全虚拟化的移动核心网络203和205在若干方面是有利的。具体来说,基于专用和定制硬件的移动核心网络的实施是不灵活的,没有弹性的,并且难以部署、修改、重新配置、扩展和升级。例如,基于硬件的移动核心网络容量的扩大和扩展通常涉及更换昂贵的设备,并且往往需要超长的时间来安装和测试。在这种核心网络的不同部分利用各种硬件组件,即使最初是经过深思熟虑的部署,也可能随着用户情况的变化而变得不平衡,导致所部署的硬件网络设备的使用效率下降。如果不更换过时的网络设备,升级往往是有限的。由于基于硬件实施的网络设备需要非常高的资本支出,它们通常由服务于大型客户群的大型无线运营商部署和配置。因此,网络的配置往往不能根据个人或一组用户的情况弹性地定制。这种网络配置通常是僵化和静态的,自动和程序化地实施网络配置可能非常困难。
[0027]然而,虚拟化移动核心网络更加敏捷、灵活、有弹性,并且可以直接部署,特别是当这样的移动核心网络在云中实施以利用现有的底层硬件资源和云管理及配置工具和界面时。这种虚拟化的移动核心网络可以立即部署在云中,而不需要对昂贵的专用硬件组件进行直接的资本投资。因此,网络部署的门槛很低,只需点击鼠标就可以部署移动核心。同样,对已经部署的这种虚拟化移动核心网络的修改、扩展和升级也只涉及软件更新和云资源重新配置。底层硬件资源的部署、维护、升级、更换和配置将由云平台和服务的提供者负责,独立于软件定义的移动核心网络,并与之脱钩。
[0028]由于云中的软件定义的移动核心网络所提供的灵活性和弹性,机构、企业等(在此称为“企业”)可以充当其自身的无线运营商。换句话说,例如一个企业,可以选择部署自己的私有全球移动核心网络,而不是与他人共享移动核心网络。在一种情况下,该企业可能希望通过其私有的全球移动核心网络连接其员工。在另一种情况下,该企业可能希望通过其私有的移动核心网络将分布在不同地理位置的无线传感器连接到一个传感器网络。该企业可以进一步部署自己的全球移动核心网络,以整合其移动员工和传感器,形成一个组合的全球私人网络。无论应用的具体需求如何,这种私有移动核心网络可以立即被部署和配置为云实例,并根据用户(或传感器)的数量和企业的整体移动通信需求和特点进行初始云资源分配。私人移动核心网络的底层云资源的分配可以在初始部署后,根据企业的通信模式作为时间的函数,进一步动态和实时地提供。例如,根据企业的业务性质和用户通信的特点,企业的私有移动核心网络可能在一天的特定时间窗口、一个月的特定一周和/或一年的特定月份或季节中被更多地使用。因此,在云中实现的私有移动核心网络可以在资源分配中提供实时弹性,并且可以特别利用云服务提供商已经开发和提供的云配置工具和接口,用于动态和预测地配置和分配云计算资源。因此,这样的私有移动核心网络可以减少资源的不平衡和利用不足,并提供一个更有效的移动通信系统。此外,由于这种私有移动核心网络可以独立于其他移动核心部署,它们可以很容易地在软件中自动或在任何选定的时间进行定制和配置。
[0029]如图2的实施方案200中进一步所示,无线电接入网络105可以保持未虚拟化。上述拥有其私有虚拟化移动核心网络203和205的企业可能不需要部署其自己的无线电接入网络。相反,它可以使用由其他无线移动运营商部署并属于他们的现有无线接入网络105。企业可以通过接收来自无线电接入网络105的无线信号并将信号引向其在云中的私有移动核心网络,或将信号从私有移动核心网络路由到无线电接入网络105,两者都通过图2的边缘交换连接210和220,来搭接这些无线电接入网络。这些交换连接可以在回程127和129之前由与无线电接入网的RNC126和128共处的网络边缘连接器进行,或者在回程127和129之后,在属于拥有接入网络105的传统无线运营商的传统移动核心节点上共处。
[0030]企业作为其自己的全球无线运营商,在云中部署其软件定义的移动核心网络,可反过来与一组用户识别模块(SIM)相关联。这些SIM可以提供给企业的无线设备140-152,如图2的241、243、245、247、249、251和253所示。这些SIM可被无线接入网络105识别为漫游设备,来自与这些SIM相关的无线设备的信号可相应地通过网络边缘连接器210和220路由到在云中实现的移动核心网络,并从该网络中获得信号。在一些实施方案中,这些SIM可以包含嵌入式通用集成电路卡(eUICC)规范下的多个国际移动用户身份(IMSI)配置文件。这些eUICC可以在不同的IMSI配置文件之间进行远程配置和激活。它们特别适合部署在安装后很难或不方便物理访问的远程传感器设备上。随着无线接入网络的发展,这些设备可以在漫游模式或赞助模式下与合作伙伴的无线接入网络或家庭无线接入网络进行通信,使用不同的IMSI配置文件,可以在没有物理访问设备中安装的SIM的情况下进行编程。
[0031]图2中,在云中实现的虚拟化移动核心网络203和205可以为作为其自身全球无线运营商的企业提供额外的好处。这在图2和图3中都有进一步说明。从概念上讲,企业可以在云中部署一个或多个信息技术(IT)和计算基础设施(图2中标记为云实例A204和云实例B206),独立于移动核心网络。企业可能希望向其移动用户提供这些云计算基础设施的无缝访问。由于移动核心网络和一个或多个云计算基础设施都被实现为云实例,它们之间的通信可以在云中被路由,由也在云中实现的网络处理和路由守护程序促进,这些守护程序作为图2中所示的虚拟交叉连接207和208发挥作用。在云内路由的信号和信息可由云安全机制保护,如通用路由封装(GRE,类似于IPSec)。因此,企业的移动用户可以通过虚拟移动核心网络访问云计算基础设施,而不会将通信的信息暴露给公共互联网。
[0032]图3提供了一个具体的说明。如图3所示,企业的用户302通过私有空中通信通道320与无线电接入网络304进行通信。无线电接入网络304通过私有物理连接312、314和322通过交换306与云中的私有移动核心网络308进行通信。移动核心网络和企业云计算基础设施310之间的通信可以基于云中的私有和安全路由,如312和316所示。在任何时候,用户设备302和企业云计算基础设施310之间的任何一条通信腿都不会暴露在非私有的通信渠道中。因此,图3的实施与基于云的移动核心网络提供了用户设备302和云计算基础设施310之间的安全连接,利用了在云中实施的基本安全功能,并且不需要使用额外的隧道技术。
[0033]这样的安全性可能不容易在使用云外移动核心的传统系统中实现,如图4的系统400中所示。如图4所示,当移动核心网络402和404在云外实施时(例如,作为基于硬件的移动核心网络实施),从移动核心网络402和404访问云计算基础设施204和206将需要通过公共互联网406。因此,用户设备140-152与云计算基础设施204和206之间的通信可能暴露在涉及公共互联网406的腿的不安全通信通道中,而没有任何云内安全措施的保护。
[0034]虽然图2的云平台202被说明为单一的云平台,但是图2的系统可以替代性地在具有多个云平台的环境中实施,如图5中所示。在一个示例性实施方案中,移动核心网络103和105可以同时作为云平台502的云实例部署。在另一个示例性实施方案中,移动核心网络如103、105和501可以被部署在不同的云平台502和504中。同样地,企业云计算基础设施104和106可以部署在相同或不同的云平台506和508。能够部署在不同云平台的软件定义的移动核心网络可以为特定企业提供更多的灵活性。例如,如果企业已经在特定的云平台中拥有现有的云计算基础设施,则可以选择相同的云平台来部署其移动核心网络,这样移动核心网络和云计算基础设施之间的虚拟交叉连接也可以在同一云平台中实现。上述各种云平台可以包括但不限于亚马逊TM的AWS、微软TM的Azure、谷歌TM云和IBMTM云。
[0035]上面讨论的移动核心网络可以包括用于移动业务管理、数据处理和路由的各种功能块。图6中示出了一个例子。图6的移动核心网络602可以包括移动服务和订阅管理组件、数据库或服务器,例如短消息服务中心(SMSC)、家庭用户服务器(HSS)和家庭位置寄存器(HLR)。这些组件可以根据例如S6aDiameter协议与RNC126通信信息。移动核心网络可以进一步包括生成树协议(STP)处理组件,用于根据SS7信令协议处理信令信息。移动核心网络可以进一步包括分组处理组件,例如分组网关(PGW)614和相应的复用器612,它们通过例如S5/S8/GPRS隧道协议(GTP)与RNC126通信,并且通过SGi协议与外部IP网络160通信。
[0036]图6仅仅作为一个示例显示。本领域的普通技术人员可以理解,移动核心网络602可以包括图6中未显示的许多其他组件。例如,移动核心网络602可以包括用于处理非数据包形式的语音信息的其他组件以及用于与PSTN接口的组件。移动核心网络602的配置可以由2G、3G、LTE、4G和5G移动通信系统的各种基础标准指导。这些其他配置可能与图6中说明的配置有很大的不同。然而,在云中实现的软件定义的移动核心网络和本文公开的基本原理适用于那些其他移动核心配置。
[0037]基于软件的移动核心网络的各种组件可以作为容器在云中实现。特别是,上述每个处理组件可以被开发并打包为应用程序,包括所有需要的软件栈及其从属物(例如,库)。这种应用程序包可以作为容器部署在云中。每个应用程序可以被部署为多个独立的容器实例,在云中的底层计算机上运行,这些计算机共享相同的主机操作系统及其内核。云中移动核心网络组件的其他替代实现方式可以基于虚拟机。与虚拟机架构相比,容器的实现通常是轻量级的、节约资源的和强大的。因为它们是轻量级的,所以容器可以快速有效地被实例化。因此,当应用程序(例如,移动核心功能组件)的服务量和系统资源需求在重时间内增加时,可以根据需要实例化容器的新实例以满足客户需求,提供软件定义移动核心网络所需的弹性。同样,当应用程序的服务量下降时,多余的容器可以被快速有效地移除,其用户流量被重新分配到应用程序的剩余容器。容器的软件栈可以设计,然后使用DockerTM等工具进行打包。
[0038]除了用于不同处理组件的容器的各种实例之外,移动核心网络的实现还可以包括在云中实现的其他程序或守护程序的实例,这些程序或守护程序被设计为在例如OSI模型的数据链路和/或网络层中执行移动核心网络的路由功能。因此,移动核心网络的云实现可以包括容器和守护程序的混合体,如图7所示。在图7中,路由守护程序由710表示。容器704代表移动核心网络的多个功能组件之一的多个实例(例如,PGW容器)。容器706代表移动核心网的多个功能组件中的另一个的多个实例(例如,HLR)。路由守护程序可以被实现以促进特定容器或相同组件的所有多个容器实例的功能,或者可以被实现以促进相同组件的容器之间或不同组件的容器之间的通信。一组容器可以被组织成一个箱。
[0039]图8进一步示出了用于实现移动核心网络的组织在箱中的容器的一种示例性配置。如图8所示,来自RNC的信号可以被交换连接器802和210拦截,根据信号类型(如830所示,包括但不限于S6aDiameter信号、SS7信号、S5/S8GTP信号)进行复用,然后被引导到实现为云容器808和810的移动核心网络,其中,该云容器808和810被组织为箱804和806。这些容器可被部署以实现移动核心网络的各种功能,如上所述。移动核心网络可以通过在云中实现的虚拟交叉连接进一步连接到其他云实例820。其他云实例830(例如,SMS代理实例、空中(OTA)实例和HA共享存储实例)可以进一步实现,以促进移动核心网络的功能。
[0040]图9示出了用于在移动核心网络和云上或云下的其他网络之间在网络层II和III(数据链路层和网络层)实现数据路由功能的更多细节。如图9所示,示例数据路由可作为多级路由器部署在云中,包括核心路由器(CR)910和912、虚拟云路由器(VCLR)920和922、虚拟路由和转发(VRF)感知箱路由器(VATR)930、虚拟CE路由器(VCER)950,如图9所示通过各种通信接口互联。这些多级虚拟路由器与虚拟移动核心网络902和虚拟多协议标签交换(MPLS)私有云904相连。
[0041]图9中的各种多级路由器可以作为云守护程序而不是容器来实现。具体而言,公共云服务提供商通常不允许用户在实际的云容器实例内带来自己的公共IP空间。为了在PGW之间执行IP路由,这些虚拟路由器可以实现为部署在云中的程序(守护程序)。在基于在私有硬件云器内使用虚拟机而不是使用容器的可视化的替代实现中,IP寻址空间可能更容易定制。图9的多层IP路由方案可以在容器实现中使用,以转移公共云中的IP寻址空间限制。
[0042]这些路由器形成云集群,并与移动核心容器实例一起形成例如企业的特定虚拟私有云(VPC)。VCLR920和922仅发挥路由作用,并且没有实际服务可以附加到这些路由器。VATR可以是VRF感知的云实例,并提供附加到特定VRF的服务。VCER可能不具有VRF意识,并可能被设计为提供具有使用任意广播私人/公共IP能力的服务。VCER可能不需要绑定到特定的VPC,并且可以在网络中存在多个实例。
[0043]VCLR基本上扮演着来自核心路由器的PE角色。因此,添加或删除任何服务将只需要改变VCLR。将不需要从核心侧进行任何改变。另外,如图9所示,只有两条从VCLR到核心路由器的通用路由封装(GRE)隧道,就足以以高可用性的方式提供服务。在VCLR和核心路由器之间使用MPLS,并将MPLS封装在GRE隧道中,也消除了对每个VRF(非VRFLite)拥有一条隧道的要求。在每个VRF(VRFLite)一个隧道的基础上,VCLR通过GRE隧道与其他服务实例(如VATR、WL-tanker和VCER)连接,不使用MPLS。
[0044]MPLSVPN904可以在云中实现,并在所有主要的云平台(例如,谷歌、AWS、微软、IBM)中提供具有全球范围的私有网络。因此,在私有移动核心的PGW处终止的企业的IP流量的无线可以被私有地路由到企业的远程IP网络。这些远程站点可以是一个物理站点,或者如前所述,是云内的一个虚拟网络。在远程站点是云内的虚拟网络的情况下,图9中所示的路由实例和MPLSVPN云904基本上是作为前面描述的、在图2中显示为207和208的虚拟交叉连接发挥作用。MPLSVPN云904进一步提供对其他移动核心和路由实例的云集群的路由,例如图9中所示的云集群。
[0045]图10示出了私有和虚拟化移动核心网络和相关的虚拟化IP路由功能可以作为可配置服务提供的示例性方式。该服务的提供者可以部署全球MPLSVPN云904。该服务的提供者可以进一步提供服务配置界面,例如向潜在用户(例如企业用户)提供Web界面1010。用户可以使用网络界面向移动核心和路由服务器1002发起服务请求,这样,服务提供者可以立即在云中为用户部署私有移动核心和虚拟路由器1030。用户可以通过应用程序接口(API)1011从Web界面1010进一步修改、配置和提供所部署的私有移动核心和路由器1030。云资源订阅、分配和管理可由来自云服务提供商的服务器1020提供。对部署私有移动核心和路由器1030所需的云资源的请求可以由服务的提供者处理并发送到服务器1020,如箭头1013所示。或者,与服务器1020的互动可以直接由用户进行,如箭头1015所示。
[0046]最后,图11示出了用于实现上述公开内容所需的任何计算组件和设备的示例性计算机系统1100。计算机系统1100可以包括通信接口1102、系统电路1104、输入/输出(I/O)接口1106、存储1109以及显示电路1108,其在本地或为远程显示生成机器接口1110,例如,在本地或远程机器上运行的网络浏览器中。机器接口1110和I/O接口1106可以包括图形用户界面、触摸敏感显示器、语音或面部识别输入、按钮、开关、扬声器和其他用户界面元素。I/O接口1106的其他例子包括麦克风、视频和静态图像摄像机、耳机和麦克风输入/输出插孔、通用串行总线(USB)连接器、存储卡插槽和其他类型的输入。I/O接口1106可以进一步包括磁性或光学媒体接口(例如,CDROM或DVD驱动器),串行和并行总线接口,以及键盘和鼠标接口。
[0047]通信接口1102可以包括无线发射器和接收器(“收发器”)1112以及由收发器1112的发射和接收电路使用的任何天线1114。收发器1112和天线1114可以支持Wi-Fi网络通信,例如,根据IEEE802.11的任何版本,如802.11h或802.11ac。通信接口1102也可以包括有线收发器1116。有线收发器1116可以为任何广泛的通信协议提供物理层接口,例如任何类型的以太网、电缆服务接口规范(DOCSIS)、数字用户线(DSL)、同步光网络(SONET)或其他协议。
[0048]存储器1109可用于存储各种初始、中间或最终数据。存储器1109可以是集中式的或分布式的,并且可以是计算机系统1100的本地或远程。例如,存储1109可以由云计算服务提供商远程托管。
[0049]系统电路1104可以包括硬件、软件、固件或其他电路的任何组合。系统电路1104可以例如用一个或多个片上系统(SoC)、特定应用集成电路(ASIC)、微处理器、离散模拟和数字电路以及其他电路来实现。系统电路1104是实现与上述实施方案的组件有关的任何所需功能的一部分。仅作为一个例子,系统电路1104可以包括一个或多个指令处理器1118和存储器1120。存储器1120存储了例如控制指令1126和操作系统1124。在一个实施方案中,指令处理器1118执行控制指令1126和操作系统1124,以执行与上述实施方案的各种组件有关的任何所需功能。
[0050]因此,上述实施方案提供了完全虚拟化和软件定义的移动核心网络,该网络作为容器和守护程序的实例部署在一个或多个公共云平台中。移动核心网络可以与也部署在公共云平台中的多层虚拟IP路由网络一起部署,作为云守护程序,用于转置云平台底层硬件组件的IP寻址空间,并将移动核心接收和处理的数据流量路由到其他网络。这些其他网络可以包括但不限于其他私有云网络、其他独立的云实例或应用、其他固定IP网络(例如固定广域网)和公共网络,如公共互联网和PSTN。在一些实施方案中,移动数据可以由移动核心接收,然后在私有云内路由到全球远程站点,而不将任何通信腿暴露在公共互联网上,避免了包括额外的安全隧道覆盖。移动核心和公共云平台中的虚拟路由组件的部署可以作为一项服务提供给企业。因此,企业可以通过API接口立即定制、部署、配置、提供和维护自己的移动核心和IP路由网络。因此,企业可以有效地充当自己的全球移动运营商。
[0051]上述方法、装置、处理和逻辑可以以许多不同的方式和许多不同的硬件和软件的组合来实现。例如,全部或部分实施方案可以是包括指令处理器的电路,例如中央处理单元(CPU)、微控制器或微处理器;特定应用集成电路(ASIC)、可编程逻辑器件(PLD)或现场可编程门阵列(FPGA);或包括分立逻辑或其他电路元件的电路,包括模拟电路元件、数字电路元件或两者;或其任何组合。电路可以包括分立的相互连接的硬件元件和/或可以组合在单个集成电路芯片上,分布在多个集成电路芯片上,或在一个共同的封装中的多个集成电路芯片的多芯片模块(MCM)中实现,以上作为示例。
[0053]实施方案可以作为电路分布在多个系统组件之间,例如在多个处理器和存储器之间,可选地包括多个分布式处理系统。参数、数据库和其他数据结构可以单独存储和管理,可以合并到单个存储器或数据库中,可以在逻辑上和物理上以许多不同的方式组织,并且可以以许多不同的方式实现,包括作为数据结构,如链接列表、散列表、阵列、记录、对象或隐式存储机制。程序可以是单个程序的一部分(如子程序),也可以是单独的程序,分布在几个存储器和处理器上,或以许多不同的方式实现,如在库中,如共享库(如动态链接库(DLL))。例如,DLL可以存储指令,这些指令在被电路执行时,执行上述或图中所示的任何处理。